Vad Allspaws bok löser
Disciplinen att inte ta slut
John Allspaw skrev 'The Art of Capacity Planning' (O'Reilly, 2008; andra utgåvan 2017) efter att ha drivit drift på Flickr genom år av explosiv tillväxt. Hans tes: kapacitetsplanering är inte en engångsövning i ett kalkylark. Det är en kontinuerlig disciplin som kombinerar mätning, prognoser & ingenjörsjudgement. Hoppa över någon av dessa tre, & du springer antingen tömmer kapaciteten i produktion eller bränner pengar på maskinvara som är inaktiv.
Kapacitetsplanering sitter mellan två fellägen:
- Underprovisioning: tjänster körspår varmt, latency hoppar upp, felfrekvenser stiger, kunder försvinner. Det snabbaste sättet att förlora användare i en tillväxtfas.
- Överprovisioning: maskinvara sitter på 10% användning, ekonomi frågar varför budgeten växer utan att intäkterna följer med. Det snabbaste sättet att förlora din personal i en budgetgranskning.
Konsten ligger i att hitta korridoren mellan dessa två klippor och stanna inuti den medan arbetsbördan ändras.
Tre huvudfrågor driver varje kapacitetsövning:
- Vad har vi? Nuvarande kapacitet i konkreta enheter: förfrågningar per sekund, frågor per sekund, gigabyte lagring, samtidiga anslutningar.
- Vad behöver vi? Prognostiserad efterfrågan vid ett framtida datum med explicita osäkerhetsgränser.
- När måste vi agera? Ledtid för inköp, provisioning eller skalning. Molnet minskar detta till minuter; lokal server kan betyda månader.
Varför det inte kan vara ett kalkylark
Ett e-handelsföretag planerar kapacitet en gång per år, i november, genom att extrapolera föregående 12 månaders trafik linjärt. De kör på dedikerade servrar med en anskaffningsledtid på 6 veckor. Deras trafik visar stark veckovisa säsongsvariation (3x helgtopp), stark årlig säsongsvariation (5x Black Friday), & har vuxit 40% från år till år under tre år.
Arbetsbörda kontra användning
Två olika tal, båda obligatoriska
Kapacitetsplanering misslyckas när team mäter bara en av de två väsentliga dimensionerna.
Arbetsbörda: efterfrågan på systemet från utsidan. Förfrågningar per sekund, transaktioner per minut, megabyte per sekund, samtidiga användare. Arbetsbörda beskriver vad världen frågar av dig.
Användning: hur full systemet kör medan det serverar denna efterfrågan. CPU-procent, använt minne, ködjup, nätverksbandbredd, disk IOPS. Användning beskriver hur systemet mår under denna efterfrågan.
Arbetsbörda ensam säger vad som kommer men inte om du kan servera det. Användning ensam säger hur full du är men inte vad du kan förvänta dig imorgon. Du behöver båda, plottade sida vid sida, för att fatta kapacitetsbeslut.
Kapacitetsförhållande = arbetsbörda / användning. Om du serverar 1 000 förfrågningar per sekund med 50% CPU, är ditt kapacitetsförhållande 2 000 RPS per 100% CPU per server. Denna omvandlingsfaktor låter dig översätta prognostiserad arbetsbörda till erforderlig serverantalet.
Allspaw betonar mätning på rätt granularitet. Ett prov per minut döljer 30-sekunders toppar. Ett prov per timme döljer allt. Verklig kapacitetsarbete behöver submintutauflösning för toppnivåhändelser och minutauflösning för trendning. Något grovare producerar farlig falsk säkerhet.
Vad man ska instrumentera
Ditt team lanserar kapacitetsinstrumentering på en ny produktlansering (en videotranscodingservice). Du kan välja upp till 8 mätvärden för att spåra på submintutauflösning. Tjänsten tar emot videouppladdningar, kötätnar dem, transkodar till flera format, & skriver utmatning till objektlagring.
Trend, säsongsvariation, osäkerhet
Tre lager av varje prognos
Allspaw och Google SRE-boken är överens om strukturen för en användbar prognos: trend, säsongsvariation & osäkerhetsgränser. Hoppa över någon och prognosen blir vilseledande.
Trend: lutningen av efterfrågan över månader eller år. Ofta modellerad med linjär regression för korta fönster, exponentiell eller styckevis-linjär för sammansatt tillväxt. Trendlinjen svarar på 'vart är efterfrågan allmänt på väg?'
Säsongsvariation: de cykliska mönstren på flera tidsskalor. Daglig (toppdag eftermiddagstrafik), veckovisa (helgdagsökning), årlig (Black Friday, skattesäsong, skolår). Multiplikativ säsongsvariation skalas med trenden; additiv säsongsvariation lägger till en konstant förskjutning.
Osäkerhetsgränser: prognoskonen. En prognos utan gränser är en gissning. Verkliga prognoser publicerar en central uppskattning med explicita övre och nedre gränser, typiskt vid 90% eller 95% säkerhet. Konen vidgas när du projicerar längre in i framtiden. En 4-veckors prognos kan ha ±10% gränser; en 12-månaders prognos har ofta ±50%.
Avkoppling av affärstillväxt från teknisk efterfrågan: kapacitetsplaneringsprognoser teknisk arbetsbelastning, men affärsteam prognostiserar intäkter, registreringar eller kampanjer. Kapacitetsplanerares jobb är att översätta affärsprognoser till teknisk efterfrågan: en 30% registreringstillväxt kan betyda 30% fler API-anrop, men det kan betyda 80% fler om nya användare använder systemet tyngre, eller bara 15% om de konverterar till lägre kurser. Konverteringsförhållandet spelar roll lika mycket som den underliggande affärsprognosen.
Prognoser för helgtrafik
Din tjänst serverar en e-handelswebbplats. Förra årets Black Friday-trafik var 5x november-medelvärde, sustained över 12 timmar. Verksamheten har vuxit 40% från år till år. Marknadsföring lanserar en betald kampanj förväntat lägga till ytterligare 20% till Black Friday-trafiken det här året.
Att känna ditt tak
Hitta taket innan produktion gör det
Prognoser säger vad som kommer. Taktester säger dig om systemet kan servera det. Allspaw behandlar taktestning som en oacceptabel input till kapacitetsplanering: du vet inte din verkliga kapacitet förrän du har testat den under kontrollerad belastning.
Tre typer av taktester:
- Syntetisk belastningstester: en belastningsgenerator (k6, Locust, JMeter, vegeta) driver trafik på en måltjänst i staging. Öka belastning tills något går sönder. Brytpunkten är taket. Bäst för isolerad tjänstetestning.
- Produktionsbrandövning: medvetet minska kapaciteten i produktion (dränera en procent av servrar, döda en region) och observera hur den återstående kapaciteten hanterar verklig trafik. Testar verkligt produktionsbeteende inklusive oväntade interaktioner. Högsta förtroende men högsta risk.
- Skuggtrafik: spela av verklig produktionstrafik på en måltjänst som körs parallellt med produktion. Fångar verklig arbetsbelastningsmönster (sällsynta frågesammansättningar, konstiga användar-agents) utan att påverka användare. Stark mitt väg.
Headroom är bufferten mellan aktuell belastning och taket. SRE tumregler:
- 50% headroom i stadigt tillstånd för en enskild region tjänst (så ett regionfel inte uttömmer den överlevande regionen)
- 30% headroom för en multi-region tjänst med N+2 redundans
- 100%+ headroom närmar sig kända toppevenemang (Black Friday, sportfinaler)
Headroom är inte avfall. Det är kostnaden för att inte sida ingenjörer kl 03:00, inte förlora kunder under en topp, och inte drabbas av ett kaskadfel när en region misslyckas. Finansteam trycker ibland på att minska headroom; kapacitetsingenjörer måste artikulera kostnaden för att köra tight för att göra den konversationen faktisk snarare än emotionell.
Designa ett taktest
Du ärver en tjänst utan dokumenterat kapacitetstak. Aktuell produktionsbelastning är 800 förfrågningar per sekund över 12 servrar, genomsnittlig CPU 35%. Marknadsföring tillkännager en kampanj om 6 veckor förväntat driva trafik till 3 000 RPS vid topp.
Upp, ut eller diagonalt
När man lägger till kraft, lägger till boxar eller båda
Tre huvudsakliga skalningsstrategier, var och en med distinkta kostnad- och tillförlitlighetsprofiler:
Vertikal skalning (skalning upp): större maskiner. Ersätt 8-kärniga servrar med 32-kärniga servrar. Enklaste vägen; fungerar tills du slår på enskilda maskin-gränser. Enkelpunktfel förblir. Kostnaden växer icke-linjärt: en 32-kärnig maskin kostar ofta mer än 4x en 8-kärnig.
Horisontell skalning (skalning ut): fler maskiner. Lägg till servrar bakom en lastbalanserare. Kapaciteten skalas linjärt med serverantal. Fellägen skiftar: du måste hantera distribuerad samordning, men ett serverfel förstör längre tjänsten. Operativ komplexitet ökar.
Diagonal skalning (Allspaws term): skala upp först till en bekväm per-server storlek, skala sedan ut från där. Kombinerar enklare drifter av stora servrar med redundansen hos flera servrar. De flesta produktionstjänster bor i diagonal skalning territorium.
Reserverad kontra on-demand prissättning: molnleverantörer belönar förutsägbarhet. Reserverad kapacitet är 30-60% billigare än on-demand men kräver ett 1-3 års engagemang. Kapacitetsplanerare låser vanligtvis stabil efterfrågan med reserverad kapacitet och burstrar in i on-demand för toppar. Att felberäkna denna uppdelning kan antingen slösa pengar (överreserverad) eller exponera budget för överraskning (underreserverad under toppar).
Spot-instanser och avbrutbar arbetsbelastning: 60-90% billigare än on-demand men kan återkrävas med minuters varning. Lämpad för batchjobb, analys, träningsarbetsbelastning, eller någon tjänst utformad för smidig avbrott. Användarvänlig produktion trafik undviker vanligtvis spot.
Välja en skalningsväg
Din videotranscodingservice körs på 8 medelstor molninstanser (8 kärnor vardera). Du förväntar 3x tillväxt under de kommande 6 månaderna. Arbetsbelastningen är CPU-bunden, paralleliserbar per video, & varje videotranscode tar 90 sekunder från början till slut. Reserverade instanser kostar 50% av on-demand. Spot-instanser kostar 30% av on-demand men kan avslutas med 2-minuters varning.
Kapacitetsplaneringskärer
Där kapacitetsplaneringskompetensen betalar
Kapacitetsplanering är sällan en jobbtitel på egen hand. Färdigheterna visas under flera roller:
Site Reliability Engineer: kapacitetsplanering är ett kärn-SRE ansvar. De flesta SRE-team har en eller två ingenjörer som specialiserar sig på kapacitet, ägnar sig åt prognosmodellerna, taktesten och provisioneringsautomationen.
Cloud Cost / FinOps Engineer: en nyare roll fokuserad på molnutgiftsoptimering. Kombinerar kapacitetsplanering med finansiell modellering, avtalsförhandling och reserverad-instansportföljehantering. Betalar extremt bra på stora molnäga företag eftersom molnräkningar ofta är den näst största kostnaden efter lönekostnader.
Performance Engineer: fokuseras på per-nod effektivitet och taktestning. Jobbet: extrahera mer kapacitet från samma maskinvara genom profilering, optimering och arkitektoniska ändringar. Tung systemornas och språkruntimes-kunskap.
Capacity Planning Specialist: på mycket stora företag (Google, Meta, Amazon, Netflix), dedikerad kapacitetsplanering team existerar. De äger prognosmodeller över hela flottan, förhandlar inköp i stor skala, och samordnar med ekonomi på flertårsmaskinvaruvägar.
Färdigheter som sammansätter: tidsserier-analys (R, Python statsmodeller, Prophet), köteori (M/M/1, M/M/c, Little's Law), åtminstone ett konfigurationshanteringsverktyg, åtminstone ett molnkostnadskontrollpanel, och förmåga att skriva en prognosrapport som en CFO kan förstå och agera på. De tekniska färdigheterna får dig intervjun; kommunikationsfärdigheterna får dig budgeten.
Att avsluta
Vad du nu vet
Kapacitetsplanering är en kontinuerlig disciplin, inte en årlig övning. Du har täckt:
- Korridoren mellan underprovisioning och överprovisioning
- Arbetsbörda kontra användning som två dimensioner av mätning
- Trend, säsongsvariation och osäkerhetsgränser som tre lager av varje prognos
- Taktester (syntetisk, skugga, brandövning) som det enda sättet att veta verklig kapacitet
- Headroombuffertar och varför de inte är avfall
- Diagonal skalning och reserverad/on-demand/spot prissättningsbeslut
- Karriärsvägar där dessa färdigheter tjänar budgetmyndighet
Två idéer spelar mest roll. Prognosera med gränser, aldrig med enskilda punkter. Och mät ditt tak innan produktion gör det. Bär dessa två framåt och resten följer.
Rekommenderad läsning: Allspaws 'The Art of Capacity Planning' (O'Reilly, 2017 andra utgåva), de relevanta kapitlen i Googles SRE Book (gratis på sre.google/books/), och Brendan Greggs 'Systems Performance' för den underliggande systemarbetet. Geometry-of companion-lektionen går djupare på den visuella strukturen: Littles Law som område, kötaiongskurvor, trendlutningar, och headroomenveloper.