9.7 Kapacitetsplanering och efterfrågeprognoser

Översikt och motivation

Varje system har ett tak. Beräkningskärnor tar slut, diskar fylls, anslutningspooler töms och en kö som var tom vid frukosten svämmar över vid lunch. Kapacitetsplanering är disciplinen att matcha utbudet av beräkning, lagring och nätverk mot den efterfrågan ni förväntar er, med tillräcklig marginal så att en normal dag aldrig kommer nära taket och en dålig dag fallerar graciöst snarare än katastrofalt. Efterfrågeprognoser är den andra halvan: att förutsäga hur mycket last som kommer, när och varför, så att utbudet anländer före efterfrågan snarare än efter avbrottet.

Det här kapitlet sitter mellan två grannar och förblir komplementärt till båda. Kapitel 3.5 behandlar skalbarhet som en arkitekturegenskap: hur ett system byggs så att det överhuvudtaget kan växa, genom tillståndslöshet, sharding och horisontell skalning. Kapitel 9.1 behandlar site reliability engineering (SRE), som sätter de tillförlitlighetsmål kapacitet måste försvara. Här tar ni arkitekturen som given och målen som fasta och besvarar sedan en kvantitativ fråga: hur mycket av allt behöver ni köpa, reservera och hålla i reserv så att systemet uppfyller sina servicenivåmål (SLO:er, tillförlitlighetsmålen från kapitel 9.1) genom prognostiserad efterfrågan och de toppar ni inte prognostiserade. Autoskalning och prestandateknik (kapitel 2.16) är verktyg ni använder här, men de är inte ersättningar för planering, och att förväxla dem med planering är ett vanligt och dyrt misstag.

För stora team slutar kapacitet vara ett kalkylblad en ingenjör sköter och blir en gemensam modell många tjänster beror på. En plattform med hundratals tjänster delar ändliga pooler: databasanslutningar, genomströmning i meddelandemäklare, kvoter på molnkonton, nätverksutgående trafik. Ett teams tillväxt kan svälta ett annats om ingen håller hela bilden. I företagssammanhang visar sig kapacitetsfel som antingen bortkastade miljoner i lediga infrastrukturer eller pinsamma avbrott under just de ögonblick som spelar störst roll. I myndigheter skärps insatserna ytterligare. En deklarationsfrist, ett bidragsansökningsfönster eller en folkhälsoregistreringskampanj koncentrerar ett lands efterfrågan till några få timmar, lasten är lagstadgad snarare än valfri och allmänheten minns en sajt som föll samman under en frist den själv satt. Kapacitetsplanering är hur ni håller dessa löften.

Nyckelprinciper

Planera kapacitet för prognostiserad efterfrågan plus medveten marginal. Kör inte nära mättnad.
Skilj kapacitetsplanering, autoskalning och prestandateknik åt. Var och en löser ett olika problem.
Prognostisera utifrån trend, säsongsvariation, kända händelser och affärstillväxt, inte bara förra veckan.
Hitta era verkliga gränser genom belastningstestning och benchmarking, inte genom gissning eller genom att vänta på att produktion hittar dem.
Behandla latens nära mättnad som ett stup, inte en sluttning. Utnyttjandemål finns på grund av köteori.
Känn till era hårda flaskhalsar: anslutningspooler, kvoter och enskilda punkter autoskalar inte.
Balansera kostnad mot tillförlitlighet med avsikt och granska kapacitet med regelbunden takt snarare än efter en incident.

Rekommendationer

Skilj kapacitetsplanering, autoskalning och prestandateknik åt

Dessa tre discipliner förväxlas ofta, och att förväxla dem leder till att man köper fel rättelse. Kapacitetsplanering är den medellånga till långa frågan om hur mycket total resurs ni måste provisionera, reservera och budgetera för över veckor, kvartal och år. Autoskalning är den kortsiktiga, automatiska justeringen av resurser för att följa last minut för minut: den flyttar er inom det omhölje planeringen provisionerade, men den kan inte trolla fram kvot ni aldrig reserverade, värma upp en kall databas eller skala en komponent som bara körs som en enda instans. Prestandateknik (kapitel 2.16) ändrar problemets form genom att göra varje arbetsenhet billigare, så att samma hårdvara betjänar mer efterfrågan.

Skillnaden är praktisk. När ett system är långsamt under last lägger autoskalning till instanser, prestandateknik gör varje instans snabbare och kapacitetsplanering avgör om ni har råd med instanserna och om den nedströms databasen kan ta emot de anslutningar de kommer att öppna. Ett team som bara sträcker sig efter autoskalning kommer att nå en hård gräns det aldrig planerade för. Ett team som bara sträcker sig efter prestandateknik kommer att optimera kod medan kontokvoten sätter tak oavsett. Ni behöver alla tre, och ni behöver veta vilken ett givet problem kräver.

Prognostisera efterfrågan från trend, säsongsvariation, händelser och affärstillväxt

En prognos byggd på förra veckans genomsnitt missar varje intressant ögonblick. Bygg er från fyra distinkta komponenter. Trenden är den underliggande riktningen: växer efterfrågan, är den platt eller krymper den, och hur fort? Säsongsvariation är det återkommande mönstret: den dagliga toppen klockan 9, det veckovisa lugnet på helger, den årliga vågen före högtiderna. Händelsedrivna toppar är engångskoncentrationerna: en produktlansering, en marknadsföringskampanj, ett omnämnande i tv, en myndighets inlämningsfrist. Affärsdriven tillväxt är den efterfrågan er egen färdplan skapar: en ny marknad, en stor kund som introduceras, en funktion som tredubblar begäranden per session.

Använd rätt teknik för var och en. En tidsserie av historisk last, nedbruten i trend och säsongsvariation, ger er en försvarbar baslinje för stabil efterfrågan. Händelser kan inte extrapoleras från historik eftersom de saknar historik. De kommer från att tala med verksamheten, läsa färdplanen och fråga marknadsföring och produkt vad de är på väg att lansera. De mest skadliga kapacitetsfelen är nästan alltid händelser som ingenjörer aldrig hörde talas om. Botemedlet är organisatoriskt, inte statistiskt: en stående kanal där produkt, marknadsföring och drift deklarerar kommande toppar tillräckligt långt i förväg för att provisionera för dem.

Sätt utnyttjandemål och respektera köteoretiska stupet

Instinkten att köra infrastruktur “het” vid 90 % utnyttjande för att spara pengar är en fälla, och skälet är köteori, behandlad på djupet i kapitel 11.3. När en resurs närmar sig fullt utnyttjande stiger väntetiden inte mjukt och linjärt. Den exploderar. En server vid 50 % utnyttjande har bekväm marginal. Samma server vid 90 % kan se latens flera gånger sämre, och vid 95 % kan kön löpa amok helt. Latens nära mättnad är ett stup, inte en sluttning, och era användare känner stupet som timeouter, omförsök och fel långt innan resursen tekniskt är “full.”

Det är därför kapacitetsplanerare sätter utnyttjandemål väl under 100 %, vanligen i intervallet 50 % till 70 % för latenskänsliga tjänster, högre för genomströmningsorienterat batcharbete som tolererar köande. Målet är inte slöseri. Det är priset för förutsägbar latens. Välj målet utifrån SLO:n: om ert latensmål är strängt är ert utnyttjandetak lägre, eftersom den svanslatens köande ger är precis det som spräcker en SLO. Marginal och säkerhetsmarginal är samma idé från två håll. Marginal är gapet mellan normal last och kapacitet. Säkerhetsmarginal är det gapet uttryckt som försäkring mot en prognos som blir för hög, en failover som koncentrerar last eller en topp ni inte såg komma.

Hitta verkliga gränser genom belastningstestning och benchmarking

Ni kan inte planera kring en gräns ni inte har mätt. Belastningstestning driver syntetisk eller återspelad trafik mot ett system för att observera hur latens, genomströmning och felfrekvens beter sig när lasten stiger, och var de går sönder. Benchmarking mäter en komponent isolerat för att fastställa dess tak: begäranden per sekund per instans, skrivningar per sekund per databasnod, meddelanden per sekund per mäklarpartition. Tillsammans ger de er de två tal planering behöver: hur mycket en enhet kapacitet levererar och var hela systemet faller.

Kör flera distinkta tester. Ett belastningstest ramper till förväntad topp och bekräftar att SLO:n håller med marginal. Ett stresstest pressar bortom brytpunkten för att se hur systemet fallerar, eftersom ett system som degraderar graciöst är mycket olikt ett som kollapsar. Ett uthållighetstest håller måttlig last i timmar eller dagar för att avslöja minnesläckor, anslutningsutmattning och diskfyllnadsproblem som bara dyker upp över tid. Ett topptest slänger på last plötsligt för att kontrollera om autoskalning och buffertar absorberar den innan användare märker det. Testa mot produktionslik data och topologi, eftersom en gräns uppmätt på en leksaksdatamängd ljuger. Kör om dessa tester när systemet ändras, så att era tal beskriver systemet ni har snarare än det ni hade för ett år sedan.

Välj provisioneringsstrategier medvetet

Molnleverantörer låter er köpa samma kapacitet på sätt som byter pris mot flexibilitet, och att blanda dem väl är där verkliga pengar sparas. Kapacitet på begäran är flexibel och dyr: ni betalar fullt pris för förmågan att starta och stoppa när som helst, vilket passar oförutsägbar och kortlivad last. Reserverad kapacitet (åtaganden på ett eller tre år, eller sparplaner) är billigare per enhet i utbyte mot ett löfte att fortsätta använda den, vilket passar er stabila baslinje. Spot-instanser säljer ledig kapacitet till djup rabatt men kan återtas med lite förvarning, vilket passar feltoleranta, avbrytbara arbeten som batchbearbetning och tillståndslösa arbetare.

Mönstret som fungerar är skiktat. Täck er stabila baslinje med reserverad kapacitet för lägsta enhetskostnad, absorbera daglig och veckovis variation med autoskalning på begäran och skjut avbrytbart batcharbete till spot för att skörda rabatten. Behåll en varm buffertpool av förprovisionerad kapacitet för tjänster som inte tolererar kallstartsfördröjningen vid skalning från noll, så att en plötslig topp möter färdig kapacitet snarare än en kö medan nya instanser startar. Rätt blandning är ett portföljbeslut, och den skiftar när er efterfrågeform och leverantörens prissättning ändras, så omvärdera den.

Kartlägg hårda flaskhalsar som inte autoskalar

Autoskalning föder en farlig tillförsikt, eftersom gott om gränser sitter nedströms det som skalar och inte flyttar sig när det gör det. Databasens anslutningspooler är det klassiska exemplet: skala ert tillståndslösa lager från 10 till 100 instanser och var och en öppnar anslutningar till samma databas, som har ett hårt tak för samtidiga anslutningar och börjar vägra nya. Molnkonton bär kvoter på nästan allt: instanser per region, IP-adresser, API-anrop per sekund, funktionssamtidighet. Varje enskild punkt i arkitekturen, en primär databas, en ledarnod, en delad cache, en licensierad apparat, är ett tak horisontell skalning på andra ställen inte kan höja.

Gör dessa uttryckliga. Håll en skriven inventering över varje hård gräns mellan en begäran och dess svar: poolstorlekar, kvotvärden, enkelinstanskomponenter, tredjepartsbegränsningar av takt, antal licensplatser. För var och en, registrera det nuvarande värdet, den nuvarande användningen och den last vid vilken den binder. Den inventeringen är skillnaden mellan en kapacitetsplan som beskriver hela systemet och en som bara beskriver de enkla, elastiska delarna medan en anslutningspool i tysthet väntar på att avsluta er lansering. Höj kvoter före behov, eftersom leverantörers kvothöjningar kan ta dagar att godkänna.

Provisionera för toppevenemang, inte bara genomsnittet

Genomsnitt döljer de ögonblick som spelar roll. Ett system dimensionerat för medellast kommer att fallera vid toppen, och för många organisationer är toppen hela poängen: detaljhandelsvågen på den största shoppingdagen, streamingtoppen vid en direktsänd final, deklarationsportalen på inlämningsfristen, bidragssajten när ansökningsperioden öppnar. Planera dessa namngivna händelser individuellt. Uppskatta toppen från verksamheten (förväntade samtidiga användare, begäranden per session, multipeln över en normal dag), provisionera till den toppen med marginal, belastningstesta på den nivån och iscensätt kapaciteten före händelsen snarare än att kämpa under den.

Behandla en lansering eller frist som en driftshändelse med en körbok. Förvärm cacher och buffertpooler, höj kvoter i förväg, frys riskfyllda driftsättningar under fönstret och sätt människor i jour som kan agera om prognosen visar sig för låg. Efter händelsen, fånga den faktiska toppen och hur nära ni kom era gränser, eftersom det talet är den bästa indata till nästa års plan. Myndigheters frister förtjänar särskild omsorg: de är självpåförda, offentligt kända och orubbliga, så det finns ingen ursäkt för att bli överraskad och inget sätt att gömma sig när man är det.

Instrumentera kapacitet och granska den med en takt

Kapacitetsplanering drivs av data, och datan kommer från observerbarheten i kapitel 9.2. Följ utnyttjandet av varje begränsad resurs (CPU, minne, disk, nätverk, anslutningspooler, köedjup) mot dess gräns, så att ni kan se marginalen krympa innan den försvinner. Bevaka mättnadssignaler direkt: kölängder, väntetider och avvisningsfrekvenser avslöjar att köstupet närmar sig. Trendberäkna dessa över veckor för att projicera när en resurs kommer att nå sitt tak vid nuvarande tillväxttakt och larma på projektionen snarare än enbart det nuvarande värdet, så att ni provisionerar före väggen snarare än vid den.

Håll kapacitetsgranskningar med regelbunden takt, månadsvis eller kvartalsvis, snarare än bara efter en incident. I varje granskning, jämför prognos mot faktisk efterfrågan och korrigera modellen, gå igenom inventeringen av hårda gränser och kontrollera marginalen mot var och en, titta på kommande händelser och affärsplaner och avgör vad som ska reserveras, höjas eller avvecklas. Håll en levande kapacitetsmodell: ett enkelt dokument eller kalkylblad som mappar efterfrågedrivare till resursbehov, så att vem som helst kan fråga “vad händer med databasen om trafiken fördubblas” och få ett svar från modellen i stället för ett avbrott. Modellen är aldrig perfekt, men en skriven, regelbundet korrigerad modell slår intuition varje gång.

Avvägningar: för- och nackdelar

Tillvägagångssätt	Fördelar	Nackdelar
Högt utnyttjandemål	Lägre kostnad per enhet. Mindre ledig kapacitet	Latens exploderar nära mättnad. Inget utrymme för toppar eller failover
Generös marginal	Förutsägbar latens. Absorberar toppar och failover	Högre löpande kostnad. Kan dölja ineffektivitet
Reserverad kapacitet	Lägsta enhetspris för stabil baslinje	Åtagenderisk om efterfrågan faller eller skiftar
Kapacitet på begäran	Flexibel. Matchar variabel last minut för minut	Högsta enhetspris. Kan överraska budgeten
Spot-instanser	Djup rabatt för avbrytbart arbete	Återtas utan varsel. Olämpligt för tillståndsbärande eller latenskritiskt arbete
Autoskalning	Följer last automatiskt inom omhöljet	Kan inte överstiga reserverad kvot. Kallstarter. Maskerar nedströmsgränser
Buffertpool (varm kapacitet)	Absorberar plötsliga toppar omedelbart	Betalar för ledig kapacitet mellan toppar

Den centrala spänningen är kostnad mot tillförlitlighet, och det finns ingen inställning som optimerar båda. Kör slimmat och ni sparar pengar tills den dag en topp möter en mättad resurs och latensen faller över köstupet. Kör generöst och ni sover gott medan ni betalar för marginal som står ledig större delen av tiden. Lös spänningen med SLO:n snarare än med rädsla eller snålhet. Provisionera tillräcklig marginal för att uppfylla tillförlitlighetsmålet genom prognostiserade toppar plus en marginal och inte mer, och låt sedan FinOps (finansiell drift för molnutgifter, kapitel 9.4) jaga det slöseri som inte försvarar en SLO. Målet är medveten balans: varje krona marginal köpt med avsikt för att köpa en känd mängd tillförlitlighet, och varje krona slöseri borttagen med avsikt eftersom den inte köper något.

Frågor att diskutera med ditt team

Vet vi faktiskt vid vilken last var och en av våra hårda flaskhalsar binder, eller antar vi att autoskalning räddar oss? De flesta team kan säga att deras instanser autoskalar, och de flesta kan inte säga gränsen för samtidiga anslutningar på sin primära databas, takbegränsningen för API-anrop hos sin viktigaste tredjepart eller den kontokvot som sätter tak för deras funktionssamtidighet. Det är de gränser som avslutar lanseringar, och de flyttar sig inte när det tillståndslösa lagret skalar. Ta med den skrivna inventeringen över hårda gränser om ni har en, och om ni inte har det är den frånvaron fyndet. För varje gräns vill ni ha tre tal: taket, dagens användning och den efterfrågenivå där de möts. Överallt där ni inte kan producera alla tre har ni en flaskhals ni hanterar med hopp.
När belastningstestade vi senast till nivån för vår värsta kommande topp, på produktionslik data, och höll SLO:n med marginal? En kapacitetsplan är en uppsättning påståenden om hur systemet beter sig under last, och ett otestat påstående är en gissning i kostym. Toppen som spelar roll är inte förra månadens genomsnitt utan nästa lansering, högtid eller frist, och testet betyder bara något om data och topologi liknar produktion, eftersom en gräns uppmätt på en leksaksdatamängd ljuger. Ta med resultaten av era senaste stress- och uthållighetstester, inklusive var systemet gick sönder och hur det fallerade när det gjorde det. Om det ärliga svaret är att ni aldrig har drivit systemet till sin brytpunkt med avsikt kommer ni att upptäcka den punkten i produktion, vid värsta möjliga tidpunkt, med användare som tittar.
Hur berättar produkt, marknadsföring och drift för ingenjörer om en topp innan den inträffar, och hur långt i förväg? De dyraste kapacitetsfelen är inte modelleringsfel. De är händelser ingenjörer aldrig hörde talas om förrän trafiken anlände. En prognos kan extrapolera trend och säsongsvariation från historik, men en händelse saknar historik, så den kan bara komma från de människor som planerar den. Ta med de tre senaste efterfrågetopparna och fråga, för var och en, hur många dagars varsel ingenjörerna fick och om det räckte för att reservera kapacitet och belastningstesta. Beläggen ni vill ha är en stående kanal med en ledtid lång nog att provisionera mot, eftersom enbart molnkvothöjningar kan ta dagar. Om kanalen inte finns är er kapacitetsplan blind för just de ögonblick den finns för att skydda.
Vilket utnyttjandemål körs varje latenskänslig tjänst faktiskt på, och kan vi spåra det talet tillbaka till dess SLO snarare än till ett kostnadsmål? Det spelar roll eftersom trycket att köra infrastruktur het är konstant och kommer från den del av organisationen som ser räkningen men inte köstupet, så om inte målet är nedskrivet och motiverat utifrån latensmålet driftar det uppåt tills en topp hittar kanten. De konkurrerande hänsynen är verkliga pengar på ena sidan och svanslatens på den andra, och den ärliga positionen är att marginal under 100 % är priset för förutsägbar latens, inte slöseri att trimma. Ta med det nuvarande utnyttjandet för era främsta tjänster, den SLO var och en försvarar och den latens ni uppmätte vid det utnyttjandet under last, så att diskussionen argumenterar utifrån belägg snarare än instinkt. På en företags- eller myndighetsplattform där en delad pool bär många tjänster, kom överens om målet centralt och registrera vem som får ändra det, eftersom ett enda team som i tysthet höjer sitt tak kan driva en resurs andra beror på över stupet för alla.
Vad är vår blandning av reserverad, på-begäran- och spot-kapacitet, när omvärderade vi den senast, och matchar den fortfarande formen på vår efterfrågan? Blandningen är där de största varaktiga besparingarna och det största varaktiga slöseriet båda gömmer sig, eftersom en stabil baslinje betald till på-begäran-priser bränner pengar varje timme medan en överförbunden reserverad position betalar för kapacitet som efterfrågan sedan växt ifrån eller fallit under. Spänningen är kostnad mot flexibilitet och åtagenderisk: reserverad kapacitet är billigast per enhet men låser in er, spot är ännu billigare men kan återtas utan varsel och på-begäran köper frihet till ett pålägg. Ta med den nuvarande fördelningen efter kostnad, den efterfrågekurva den är avsedd att täcka och återtagandefrekvensen och sprängradien för eventuella spot-arbetslaster, så att rummet kan se om avbrytbart arbete verkligen är avbrytbart. I företags- och myndighetssammanhang, knyt de reserverade åtagandena till upphandlings- och budgetcykeln, eftersom fleråriga åtaganden och sparplaner är finansiella skyldigheter som ekonomi och revision vill se motiverade mot prognostiserad efterfrågan, inte mot förra kvartalets bekvämlighet.
När ett namngivet toppevenemang närmar sig, vem äger förvärmning, kvothöjningar, driftsättningsfrysningar och go/no-go-beslutet, och är det nedskrivet som en körbok vi har övat? Toppevenemang är de ögonblick kapacitetsplanering finns för att skydda, och de fallerar oftast inte för att planen var fel utan för att ingen var ansvarig för att genomföra den under press på dagen. De hänsyn som konkurrerar här är fart och autonomi mot samordning: team vill fortsätta leverera, men en riskfylld driftsättning under vågfönstret kan göra månader av provisionering om intet, så någon måste hålla befogenheten att frysa och att stoppa lanseringen. Ta med körboken för ert nästa stora evenemang, ledtiderna för kvothöjningar och uppvärmning av buffertpool och registret över vem som höll varje roll förra gången och om överlämningarna höll. För en myndighetsfrist som är självpåförd, offentligt känd och orubblig, namnge den ansvariga ägaren och eskaleringsvägen uttryckligen, eftersom det inte finns något alternativ att kasta last eller be medborgare komma tillbaka senare, och en topp ingen äger är en topp ingen kommer att försvara när den anländer.

Sektorsperspektiv

Startup. Din knappaste resurs är ingenjörsuppmärksamhet, så håll kapacitetsplaneringen billig och lita på molnleverantörens elasticitet för daglig variation. Det enda du inte kan hoppa över är en skriven lista över de hårda gränser som inte autoskalar: ditt primära databasanslutningstak, din viktigaste tredjeparts takbegränsning och de kontokvoter du skulle nå vid en plötslig funktions- eller pressopp. Belastningstesta till flera gånger din normala topp på produktionsstor data före din första verkliga våg, eftersom den bräckliga tillförsikt autoskalning ger dig är precis det som går sönder när en databas vägrar anslutningar.

Småföretag. Du har ingen kapacitetsspecialist och en snäv budget, så behandla detta som ett köp-och-konfigurera-problem snarare än ett modelleringsprojekt. Föredra hanterade tjänster som absorberar skalningen åt dig, sätt utgiftslarm och enkla utnyttjandepaneler så att en skenande räkning eller en mättad resurs syns tidigt och känn till de få namngivna händelser (en säsongsrusch, en stor kund som går live) som kommer att definiera ditt år. Reservera kapacitet för din stabila baslinje för att skära räkningen och stå emot att bygga prognosmaskineri du inte kan underhålla när efterfrågans form knappt rör sig.

Storföretag. Problemet är en delad, ändlig uppsättning pooler bakom hundratals tjänster, så kapacitet blir portföljstyrning: en underhållen inventering av hårda gränser, utnyttjandemål härledda centralt från SLO:er och en medveten blandning av reserverad, på-begäran- och spot-kapacitet omvärderad mot levande prissättning. Standardisera belastnings-, stress-, uthållighets- och topptesterna så att varje team mäter på samma sätt på produktionslik data och kör kapacitetsgranskningar med en takt som fångar krympande marginal innan en incident gör det. Budgetera samordningen uttryckligen, eftersom ett teams tillväxt kan svälta ett annats när ingen håller hela modellen.

Offentlig sektor. Efterfrågan är ofta lagligen koncentrerad till en orubblig, offentligt känd frist, så planera för den namngivna toppen specifikt och provisionera en bred säkerhetsmarginal, eftersom du inte kan kasta last eller be medborgare komma tillbaka senare. Upphandlingsregler formar provisionering: fleråriga reserverade åtaganden och leverantörskvotavtal måste motiveras mot prognostiserad efterfrågan och överleva revision, så håll prognosen, belastningstestbeläggen och inventeringen av hårda gränser dokumenterade och försvarbara. Publicera realistiska förväntningar där du kan, höj leverantörsgränser långt före fönstret och registrera den sanna toppen varje cykel, eftersom offentlig ansvarsskyldighet betyder att en portal som viker sig under en frist den själv satt är ett misslyckande hela landet ser.

Exempel

Startup. Ett startup på tio personer driver en konsumentapp på autoskalande molninfrastruktur och känner sig trygga eftersom instansantalet växer med lasten. Deras första tv-inslag tredubblar trafiken på en timme, det tillståndslösa lagret skalar vackert och appen faller ändå: varje ny instans öppnade databasanslutningar tills databasen nådde sitt anslutningstak och började vägra dem. Lärdomen omformar deras praxis. De lägger en anslutningspoolare framför databasen, skriver ned varje hård gräns mellan en begäran och ett svar och belastningstestar till flera gånger sin normala topp på en produktionsstor datamängd. De täcker sin stabila baslinje med ett reserverat kapacitetsåtagande för rabatten och behåller en liten varm buffertpool så att nästa topp möter färdig kapacitet. Ändringarna kostar en vecka och omvandlar deras bräckliga tillförsikt till en plan de kan försvara.

Storföretag. En global detaljhandlare behandlar sin största försäljningsdag som årets kapacitetshändelse. Månader i förväg bygger ett tvärfunktionellt team en efterfrågeprognos från tidigare års trend och säsongsvariation plus sortimentsplanen, översätter prognosen till resursbehov genom en kapacitetsmodell och provisionerar till den projicerade toppen med generös marginal. De belastnings-, stress-, uthållighets- och topptestar hela vägen på produktionslik data, höjer varje relevant molnkvot veckor i förväg, förvärmer cacher och buffertpooler och fryser riskfyllda driftsättningar för det omgivande fönstret. Reserverad kapacitet täcker den stabila baslinjen för kostnad, autoskalning på begäran absorberar den dagliga kurvan och avbrytbart batcharbete körs på spot. Observerbarhet följer varje begränsad resurs mot dess gräns i realtid under händelsen, med larm på projicerad mättnad snarare än nuvarande värde. Dagen passerar utan dramatik, vilket är precis det utfall planeringen köpte.

Offentlig sektor. En nationell skattemyndighet driver en deklarationsportal vars efterfrågan lagligen är koncentrerad till dagarna före en orubblig frist, när ett helt land deklarerar på en gång. Myndigheten planerar för den toppen specifikt snarare än för ett årligt genomsnitt som skulle vara meningslöst. Den uppskattar samtidiga deklaranter från tidigare år och befolkningsdata, provisionerar till den toppen med en bred säkerhetsmarginal eftersom det inte finns något alternativ att kasta last eller be medborgare komma tillbaka senare och belastningstestar till den projicerade samtidigheten på realistisk data. Teamet håller en skriven inventering över varje kvot och enskild felpunkt, höjer gränser hos leverantörer långt före fönstret och sätter utnyttjandemål tillräckligt låga för att köstupet hålls långt från fristvågen. Efter varje deklarationssäsong registrerar de den sanna toppen och hur mycket marginal som återstod och matar nästa års modell. Allmänheten ser en portal som håller sig uppe på den dag den är designad för, vilket är hela poängen med institutionens löfte.

Affärsnytta: motiv, ROI och TCO

Avkastningen på kapacitetsplanering visar sig som två undvikna kostnader som drar åt motsatta håll, vilket är det som gör disciplinen värdefull. Underprovisionering kostar avbrott, och avbrott under toppevenemang kostar mest: förlorade intäkter, förlorade transaktioner och anseendeskada just när publiken är störst. En detaljhandelssajt som ligger nere på sin största dag eller en myndighetsportal som kollapsar på sin inlämningsfrist betalar för år av planering på en enda dålig timme. Överprovisionering kostar åt andra hållet, i molnräkningar för kapacitet som står ledig, och i företagsskala löper några procentenheter kronisk överprovisionering över en flotta till miljoner dollar om året. Kapacitetsplanering är praxisen som hittar den medvetna mitten: tillräckligt för att försvara SLO:n genom toppar, inte mer än så.

Kostnaden för att anta är mestadels disciplin snarare än verktyg. Ni bygger en efterfrågeprognos, skriver ned era hårda gränser, kör belastningstester med en takt, blandar era provisioneringsstrategier och håller regelbundna kapacitetsgranskningar. Total ägandekostnad (TCO) förbättras från båda sidor på en gång: färre kapacitetsdrivna incidenter sänker kostnaden för driftstopp och nödsvar, och kontinuerlig rättstorleksanpassning plus en förnuftig reserverad-och-spot-blandning sänker den löpande infrastrukturräkningen. För att driva ärendet inför ledningen, koppla kapacitet till de tal de redan bevakar. Knyt underprovisionering till förlorade intäkter per timme av topptid i driftstopp och till SLO-brott med avtalsenliga viten, och knyt överprovisionering till FinOps-slöseriet i rapporten från kapitel 9.4. Argumentet är inte abstrakt försiktighet. Det är pengar på båda sidor av en ratt ni kan ställa med avsikt.

Antimönster och fallgropar

Autoskalning som plan: att lita på elastiska instanser medan en databasanslutningspool, kontokvot eller enskild punkt i tysthet sätter tak för hela systemet.
Att köra hett för att spara pengar: att sikta på 90 %-plus utnyttjande och möta köstupet, där latensen exploderar och SLO:n bryts.
Genomsnitt i stället för toppar: att dimensionera för medellast så att systemet fallerar vid just det toppevenemang som motiverade bygget.
Att prognostisera enbart från historik: att extrapolera trend och säsongsvariation medan man missar lanseringen eller kampanjen ingenjörerna aldrig fick veta om.
Otestade gränser: att planera kring en brytpunkt ingen har mätt och sedan upptäcka den i produktion vid värsta möjliga tidpunkt.
Belastningstester med leksaksdata: att mäta kapacitet på orealistisk data och topologi och producera tal som ljuger om det verkliga systemet.
Ingen inventering av hårda gränser: att hantera kvoter, pooler och enskilda punkter efter minnet och hopp snarare än en skriven, underhållen lista.
Reservera allt eller reservera inget: att överförbinda sig till reserverad kapacitet som efterfrågan växer ifrån eller krymper under, eller att betala fulla på-begäran-priser för en stabil baslinje.
Kapacitetsgranskning endast efter incidenter: att behandla planering som reaktiv brandbekämpning i stället för en regelbunden takt som provisionerar före behov.

Mognadsmodell

Nivå 1, Initiera: Kapacitet är reaktiv och ad hoc. Team lägger till resurser efter att de tagit slut, litar på att autoskalning hanterar allt och har ingen prognos, ingen inventering av hårda gränser och ingen belastningstestning. Toppevenemang möts med hopp, och avbrott under lanseringar och frister behandlas som otur.
Nivå 2, Utveckla: Grundläggande praxis dyker upp men varierar per team. Viss övervakning visar utnyttjande, viss belastningstestning sker före stora evenemang, stora kvoter är kända och en grov prognos finns på vissa ställen, men modellen underhålls inte, nedströms flaskhalsar missas ofta och marginal sätts efter tumregel snarare än utifrån SLO:n.
Nivå 3, Standardisera: Kapacitetsplanering är en dokumenterad disciplin upprätthållen i hela organisationen. En efterfrågeprognos kombinerar trend, säsongsvariation, händelser och affärstillväxt, en skriven inventering av hårda gränser underhålls, utnyttjandemål härleds från SLO:er, belastnings-, stress-, uthållighets- och topptester körs med en takt mot produktionslik data och provisionering blandar reserverad, på-begäran- och spot-kapacitet medvetet. En stående kanal bär händelsevarningar från produkt och marknadsföring till ingenjörer.
Nivå 4, Hantera: Kapacitet mäts och styrs mot utgångslägen. Prognos jämförs mot faktisk efterfrågan varje cykel och felet följs och drivs ned, utnyttjande, mättnadssignaler och marginal mot varje hård gräns trendberäknas och larmas på som projektioner snarare än nuvarande värden, toppevenemang granskas efteråt mot den sanna observerade toppen och provisioneringsblandning, täckning av reserverade åtaganden och kostnad per SLO rapporteras som mått som grindar beslut att gå eller inte gå. Data, inte intuition, avgör vad som ska reserveras, höjas eller avvecklas.
Nivå 5, Orkestrera: Kapacitetsplanering förbättras kontinuerligt och är integrerad i hela organisationen. Prognoser valideras och förfinas automatiskt, mättnad projiceras och provisioneras mot innan den anländer, provisioneringsblandningar optimeras mot levande prissättning, toppevenemang körs från repeterade körböcker och kostnad och tillförlitlighet balanseras medvetet mot SLO:n över hela plattformen. Kapacitetsmodellen är en gemensam, adaptiv tillgång som balanserar om flottan när efterfrågans form och leverantörens prissättning skiftar.

Idéer för diskussion

Vad är ert nuvarande utnyttjandemål för latenskänsliga tjänster, och kan ni motivera det utifrån er SLO och köbeteendet snarare än utifrån en önskan att spara pengar?
Vilka av era komponenter kan inte autoskala alls, och vad händer med resten av systemet när en av dem mättas?
Om er trafik fördubblades nästa kvartal, vilken resurs når sitt tak först, och hur många dagars ledtid skulle ni behöva för att höja den?
Hur avgör ni blandningen av reserverad, på-begäran- och spot-kapacitet, och när omvärderade ni den senast mot er faktiska efterfrågeform?
När ett toppevenemang närmar sig, vem äger förvärmning, kvothöjningar och go/no-go-beslutet, och är det nedskrivet som en körbok?
Utlöses era kapacitetslarm på projicerad mättnad veckor i förväg, eller bara på nuvarande utnyttjande när väggen redan är nära?

Viktigaste punkter

Kapacitetsplanering matchar utbud mot prognostiserad efterfrågan med medveten marginal. Den är skild från autoskalning (kortsiktig, inom omhöljet) och prestandateknik (billigare arbetsenheter).
Prognostisera utifrån trend, säsongsvariation, kända händelser och affärstillväxt och få händelsevarningar från produkt och marknadsföring, eftersom händelser saknar historik att extrapolera.
Respektera köteorins stup (kapitel 11.3): latens exploderar nära mättnad, så sätt utnyttjandemål utifrån er SLO och håll verklig marginal.
Hitta gränser genom belastnings-, stress-, uthållighets- och topptester på produktionslik data och håll en skriven inventering över hårda flaskhalsar som inte autoskalar.
Blanda reserverad, på-begäran- och spot-kapacitet med varma buffertpooler, planera namngivna toppevenemang individuellt och granska kapacitet med en takt snarare än efter avbrott.

Referenser och vidare läsning

Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering: How Google Runs Production Systems
Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne (eds.), The Site Reliability Workbook: Practical Ways to Implement SRE
John Allspaw, The Art of Capacity Planning: Scaling Web Resources in the Cloud
Neil J. Gunther, Guerrilla Capacity Planning: A Tactical Approach to Planning for Highly Scalable Applications and Services
Martin L. Abbott and Michael T. Fisher, The Art of Scalability: Scalable Web Architecture, Processes, and Organisations for the Modern Enterprise
Brendan Gregg, Systems Performance: Enterprise and the Cloud
Leonard Kleinrock, Queueing Systems, Volume 1: Theory
J. R. Storment and Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management