9.7 Kapacitetsplanlægning og efterspørgselsprognoser

Overblik og motivation

Hvert system har et loft. Beregningskerner løber tør, diske fyldes, forbindelsespuljer udmattes, og en kø, der var tom til morgenmad, flyder over til frokost. Kapacitetsplanlægning er disciplinen at afstemme udbuddet af beregning, lager og netværk med den efterspørgsel, I forventer, med nok luft til, at en normal dag aldrig kommer i nærheden af loftet, og en dårlig dag fejler elegant frem for katastrofalt. Efterspørgselsprognoser er den anden halvdel: at forudsige, hvor meget belastning der kommer, hvornår og hvorfor, så udbuddet ankommer før efterspørgslen frem for efter udfaldet.

Dette kapitel sidder mellem to naboer og forbliver komplementært til begge. Kapitel 3.5 dækker skalerbarhed som en arkitektonisk egenskab: hvordan et system bygges, så det overhovedet kan vokse, gennem tilstandsløshed, sharding og horisontal skalering. Kapitel 9.1 dækker site reliability engineering (SRE), som sætter de pålidelighedsmål, kapacitet skal forsvare. Her tager I arkitekturen som givet og målene som faste og besvarer så et kvantitativt spørgsmål: hvor meget af alt skal I købe, reservere og holde i reserve, så systemet opfylder sine servicemål (SLO’er, pålidelighedsmålene fra kapitel 9.1) gennem prognosticeret efterspørgsel og de spidsbelastninger, I ikke prognosticerede. Autoskalering og ydeevneoptimering (kapitel 2.16) er værktøjer, I bruger her, men de er ikke erstatninger for planlægning, og at forveksle dem med planlægning er en almindelig og dyr fejl.

For store teams holder kapacitet op med at være et regneark, en ingeniør fører, og bliver en fælles model, mange tjenester afhænger af. En platform med hundredvis af tjenester deler endelige puljer: databaseforbindelser, beskedmæglerens gennemløb, cloudkontokvoter, netværksudgående trafik. Ét teams vækst kan sulte et andets, hvis ingen har det fulde billede. I virksomhedssammenhænge viser kapacitetsfejl sig enten som spildte millioner i inaktiv infrastruktur eller pinlige udfald netop i de øjeblikke, der betyder mest. I det offentlige skærpes indsatsen yderligere. En skattefrist, et ydelsestilmeldingsvindue eller en folkesundhedsregistreringskampagne koncentrerer en nations efterspørgsel i få timer, belastningen er lovpålagt frem for valgfri, og offentligheden husker et site, der bukkede under for en frist, det selv satte. Kapacitetsplanlægning er, hvordan I holder de løfter.

Grundprincipper

Planlæg kapacitet for prognosticeret efterspørgsel plus bevidst luft; kør ikke tæt på mætning.
Adskil kapacitetsplanlægning, autoskalering og ydeevneoptimering; hver løser et forskelligt problem.
Prognosticér ud fra tendens, sæsonudsving, kendte begivenheder og forretningsvækst, ikke kun ud fra sidste uge.
Find jeres reelle grænser ved belastningstest og benchmarking, ikke ved gætværk eller ved at vente på, at produktion finder dem.
Behandl latens nær mætning som en klint, ikke en skråning; udnyttelsesmål findes på grund af kølære.
Kend jeres hårde flaskehalse: forbindelsespuljer, kvoter og enkeltpunkter autoskalerer ikke.
Afbalancér omkostning mod pålidelighed med vilje, og gennemgå kapacitet efter en fast kadence frem for efter en hændelse.

Anbefalinger

Adskil kapacitetsplanlægning, autoskalering og ydeevneoptimering

Disse tre discipliner forveksles ofte, og forveksling fører til at købe den forkerte rettelse. Kapacitetsplanlægning er det mellem- til langsigtede spørgsmål om, hvor mange samlede ressourcer I skal provisionere, reservere og budgettere med over uger, kvartaler og år. Autoskalering er den kortsigtede, automatiserede justering af ressourcer til at følge belastning minut for minut: den flytter jer inden for den ramme, planlægningen provisionerede, men den kan ikke fremtrylle kvote, I aldrig reserverede, varme en kold database op eller skalere en komponent, der kun kører som en enkelt instans. Ydeevneoptimering (kapitel 2.16) ændrer problemets form ved at gøre hver arbejdsenhed billigere, så den samme hardware betjener mere efterspørgsel.

Skellet er praktisk. Når et system er langsomt under belastning, tilføjer autoskalering instanser, ydeevneoptimering gør hver instans hurtigere, og kapacitetsplanlægning afgør, om I har råd til instanserne, og om den nedstrøms database kan acceptere de forbindelser, de vil åbne. Et team, der kun rækker efter autoskalering, rammer en hård grænse, det aldrig planlagde for; et team, der kun rækker efter ydeevneoptimering, optimerer kode, mens kontokvoten loftet dem uanset. I har brug for alle tre, og I skal vide, hvilken et givent problem kalder på.

Prognosticér efterspørgsel ud fra tendens, sæsonudsving, begivenheder og forretningsvækst

En prognose bygget på sidste uges gennemsnit vil misse hvert interessant øjeblik. Byg jeres ud fra fire adskilte komponenter. Tendensen er den underliggende retning: vokser, flader eller skrumper efterspørgslen, og hvor hurtigt? Sæsonudsving er det gentagne mønster: den daglige spids klokken 9, den ugentlige stilhed i weekender, den årlige bølge før højtiderne. Begivenhedsdrevne spidser er de enkeltstående koncentrationer: en produktlancering, en marketingkampagne, en tv-omtale, en offentlig indberetningsfrist. Forretningsdrevet vækst er den efterspørgsel, jeres egen køreplan skaber: et nyt marked, onboarding af en stor kunde, en funktion der tredobler forespørgsler pr. session.

Brug den rette teknik til hver. En tidsserie af historisk belastning, dekomponeret i tendens og sæsonudsving, giver jer en forsvarlig baseline for stabil efterspørgsel. Begivenheder kan ikke ekstrapoleres fra historik, fordi de ikke har nogen historik; de kommer fra at tale med forretningen, læse køreplanen og spørge marketing og produkt, hvad de er ved at lancere. De mest skadelige kapacitetsfejl er næsten altid begivenheder, ingeniørafdelingen aldrig hørte om. Kuren er organisatorisk, ikke statistisk: en stående kanal, hvor produkt, marketing og drift erklærer kommende spidser langt nok i forvejen til at provisionere til dem.

Sæt udnyttelsesmål, og respektér kølære-klinten

Instinktet til at køre infrastruktur “varm” ved 90 % udnyttelse for at spare penge er en fælde, og grunden er kølære, dækket i dybden i kapitel 11.3. Når en ressource nærmer sig fuld udnyttelse, stiger ventetiden ikke blidt og lineært; den eksploderer. En server ved 50 % udnyttelse har behagelig luft; den samme server ved 90 % kan se latens flere gange værre, og ved 95 % kan køen løbe helt løbsk. Latens nær mætning er en klint, ikke en skråning, og jeres brugere mærker klinten som timeouts, genforsøg og fejl lang tid før, ressourcen teknisk er “fuld.”

Det er grunden til, at kapacitetsplanlæggere sætter udnyttelsesmål langt under 100 %, almindeligvis i intervallet 50 % til 70 % for latensfølsomme tjenester, højere for gennemløbsorienteret batcharbejde, der tåler køopbygning. Målet er ikke spild; det er prisen for forudsigelig latens. Vælg målet ud fra SLO’en: hvis jeres latensmål er strengt, er jeres udnyttelsesloft lavere, fordi den halelatens, køopbygning producerer, netop er det, der sprænger en SLO. Luft og sikkerhedsmargin er den samme idé fra to retninger. Luft er hullet mellem normal belastning og kapacitet; sikkerhedsmargin er det hul udtrykt som forsikring mod en prognose, der løber for højt, en failover, der koncentrerer belastning, eller en spids, I ikke så komme.

Find reelle grænser gennem belastningstest og benchmarking

I kan ikke planlægge omkring en grænse, I ikke har målt. Belastningstest driver syntetisk eller genafspillet trafik mod et system for at observere, hvordan latens, gennemløb og fejlrate opfører sig, efterhånden som belastningen stiger, og hvor de knækker. Benchmarking måler en komponent isoleret for at fastlægge dens loft: forespørgsler pr. sekund pr. instans, skrivninger pr. sekund pr. databasenode, beskeder pr. sekund pr. mæglerpartition. Sammen fortæller de jer de to tal, planlægning har brug for: hvor meget en enhed kapacitet leverer, og hvor hele systemet vælter.

Kør flere forskellige tests. En belastningstest ramper op til forventet spids og bekræfter, at SLO’en holder med luft. En stresstest presser forbi bristepunktet for at se, hvordan systemet fejler, fordi et system, der nedgraderes elegant, er meget anderledes end et, der kollapser. En soaktest holder moderat belastning i timer eller dage for at afsløre hukommelseslækager, forbindelsesudmattelse og diskfyldningsproblemer, der kun optræder over tid. En spidstest smækker pludselig belastning på for at tjekke, om autoskalering og buffere absorberer den, før brugere bemærker det. Test mod produktionslignende data og topologi, fordi en grænse målt på et legetøjsdatasæt lyver. Kør disse tests igen, når systemet ændrer sig, så jeres tal beskriver det system, I har, frem for det, I havde for et år siden.

Vælg provisioneringsstrategier bevidst

Cloududbydere lader jer købe den samme kapacitet på måder, der afvejer pris mod fleksibilitet, og at blande dem godt er, hvor rigtige penge spares. On demand-kapacitet er fleksibel og dyr: I betaler fuld takst for evnen til at starte og stoppe når som helst, hvilket passer til uforudsigelig og kortlivet belastning. Reserveret kapacitet (forpligtelser på et eller tre år eller besparelsesplaner) er billigere pr. enhed til gengæld for et løfte om at blive ved med at bruge den, hvilket passer til jeres stabile baseline. Spotinstanser sælger overskydende kapacitet med dyb rabat, men kan generobres med kort varsel, hvilket passer til fejltolerant, afbrydeligt arbejde som batchbehandling og tilstandsløse workers.

Mønstret, der virker, er lagdelt. Dæk jeres stabile baseline med reserveret kapacitet til laveste enhedsomkostning, absorbér daglig og ugentlig variation med on demand-autoskalering, og skub afbrydeligt batcharbejde over på spot for at høste rabatten. Hold en varm bufferpulje af forprovisioneret kapacitet til tjenester, der ikke tåler koldstartsforsinkelsen ved skalering fra nul, så en pludselig spids møder klar kapacitet frem for en kø, mens nye instanser starter op. Den rette blanding er en porteføljebeslutning, og den skifter, efterhånden som jeres efterspørgselsform og udbyderens prissætning ændrer sig, så gensyn den.

Kortlæg hårde flaskehalse, der ikke autoskalerer

Autoskalering avler farlig selvtillid, fordi mange grænser sidder nedstrøms for det, der skalerer, og ikke bevæger sig, når det gør. Database-forbindelsespuljer er det klassiske eksempel: skalér jeres tilstandsløse lag fra 10 til 100 instanser, og hver åbner forbindelser til den samme database, som har et hårdt loft over samtidige forbindelser og vil begynde at afvise nye. Cloudkonti bærer kvoter på næsten alt: instanser pr. region, IP-adresser, API-kald pr. sekund, funktionssamtidighed. Ethvert enkeltpunkt i arkitekturen, en primær database, en leder-node, en fælles cache, et licenseret apparat, er et loft, som horisontal skalering andetsteds ikke kan hæve.

Gør disse eksplicitte. Hold en skriftlig fortegnelse over hver hård grænse mellem en forespørgsel og dens svar: puljestørrelser, kvoteværdier, enkeltinstanskomponenter, tredjeparts hastighedsgrænser, licenssædetal. Registrér for hver den nuværende værdi, det nuværende forbrug og den belastning, hvor den binder. Denne fortegnelse er forskellen mellem en kapacitetsplan, der beskriver hele systemet, og en, der kun beskriver de lette, elastiske dele, mens en forbindelsespulje stille venter på at afslutte jeres lancering. Hæv kvoter i forvejen, fordi udbyderes kvoteforhøjelser kan tage dage at godkende.

Provisionér til spidsbegivenheder, ikke kun gennemsnittet

Gennemsnit skjuler de øjeblikke, der betyder noget. Et system dimensioneret til middelbelastning vil fejle ved spidsen, og for mange organisationer er spidsen hele pointen: detailbølgen på den største shoppingdag, streamingspidsen ved en live finale, skatteportalen på indberetningsfristen, ydelsessitet, når tilmeldingen åbner. Planlæg disse navngivne begivenheder enkeltvis. Estimér spidsen ud fra forretningen (forventede samtidige brugere, forespørgsler pr. session, multiplen over en normal dag), provisionér til den spids med luft, belastningstest på det niveau, og stage kapaciteten før begivenheden frem for at kæmpe under den.

Behandl en lancering eller frist som en driftsbegivenhed med en runbook. Forvarm caches og bufferpuljer, hæv kvoter på forhånd, frys risikable udrulninger i vinduet, og sæt mennesker på vagt, der kan handle, hvis prognosen viser sig for lav. Efter begivenheden så indfang den faktiske spids og hvor tæt I kom på jeres grænser, fordi det tal er det bedste input til næste års plan. Offentlige frister fortjener særlig omhu: de er selvpålagte, offentligt kendte og urokkelige, så der er ingen undskyldning for at blive overrasket og ingen måde at skjule det på, når I er.

Instrumentér kapacitet, og gennemgå den efter en kadence

Kapacitetsplanlægning kører på data, og dataene kommer fra observerbarheden i kapitel 9.2. Følg udnyttelsen af hver begrænset ressource (CPU, hukommelse, disk, netværk, forbindelsespuljer, kødybde) mod dens grænse, så I kan se luften skrumpe, før den forsvinder. Iagttag mætningssignaler direkte: kølængder, ventetider og afvisningsrater afslører kølære-klinten, der nærmer sig. Trendér disse over uger for at projicere, hvornår en ressource rammer sit loft ved den nuværende vækstrate, og alarmér på projektionen frem for kun den nuværende værdi, så I provisionerer før muren frem for ved den.

Hold kapacitetsgennemgange efter en fast kadence, månedligt eller kvartalsvis, frem for kun efter en hændelse. I hver gennemgang så sammenlign prognose med faktisk efterspørgsel og ret modellen, gennemgå fortegnelsen over hårde grænser og tjek luft mod hver, se på kommende begivenheder og forretningsplaner, og afgør, hvad der skal reserveres, hæves eller pensioneres. Hold en levende kapacitetsmodel: et simpelt dokument eller regneark, der kortlægger efterspørgselsdrivere til ressourcebehov, så enhver kan spørge “hvad sker der med databasen, hvis trafikken fordobles” og få svar fra modellen i stedet for fra et udfald. Modellen er aldrig perfekt, men en skrevet, regelmæssigt rettet model slår intuition hver gang.

Afvejninger: fordele og ulemper

Tilgang	Fordele	Ulemper
Højt udnyttelsesmål	Lavere omkostning pr. enhed; mindre inaktiv kapacitet	Latens eksploderer nær mætning; ingen plads til spidser eller failover
Generøs luft	Forudsigelig latens; absorberer spidser og failover	Højere stabil omkostning; kan skjule ineffektivitet
Reserveret kapacitet	Laveste enhedspris for stabil baseline	Forpligtelsesrisiko hvis efterspørgslen falder eller skifter
On demand-kapacitet	Fleksibel; matcher variabel belastning minut for minut	Højeste enhedspris; kan overraske budgettet
Spotinstanser	Dyb rabat til afbrydeligt arbejde	Generobres uden varsel; uegnet til tilstandsfuldt eller latenskritisk arbejde
Autoskalering	Følger belastning automatisk inden for rammen	Kan ikke overskride reserveret kvote; koldstart; maskerer nedstrøms grænser
Bufferpulje (varm kapacitet)	Absorberer pludselige spidser øjeblikkeligt	Betaler for inaktiv kapacitet mellem spidser

Den centrale spænding er omkostning mod pålidelighed, og der er ingen indstilling, der optimerer begge. Kør slankt, og I sparer penge, til den dag en spids møder en mættet ressource, og latensen falder af kølære-klinten. Kør generøst, og I sover godt, mens I betaler for luft, der står ubrugt det meste af tiden. Løs spændingen med SLO’en frem for med frygt eller sparsommelighed. Provisionér nok luft til at opfylde pålidelighedsmålet gennem prognosticerede spidser plus en margin, og ikke mere, og lad så FinOps (finansiel drift af cloudforbrug, kapitel 9.4) jage det spild, der ikke forsvarer en SLO. Målet er bevidst balance: hver krone luft købt med vilje for at købe en kendt mængde pålidelighed, og hver krone spild fjernet med vilje, fordi den intet køber.

Spørgsmål til drøftelse med dit team

Kender vi faktisk den belastning, ved hvilken hver af vores hårde flaskehalse binder, eller antager vi, at autoskalering vil redde os? De fleste teams kan fortælle jer, at deres instanser autoskalerer, og de fleste kan ikke fortælle jer samtidighedsgrænsen på deres primære database, hastighedsgrænsen på deres vigtigste tredjepart eller den kontokvote, der loftet deres funktionssamtidighed. Det er de grænser, der afslutter lanceringer, og de bevæger sig ikke, når det tilstandsløse lag skalerer. Tag den skriftlige fortegnelse over hårde grænser med, hvis I har en, og hvis ikke, er den mangel fundet. For hver grænse vil I have tre tal: loftet, dagens forbrug og det efterspørgselsniveau, hvor de mødes. Overalt, hvor I ikke kan frembringe alle tre, har I en flaskehals, I styrer med håb.
Hvornår belastningstestede vi sidst til niveauet af vores værste kommende spids, på produktionslignende data, og holdt SLO’en med luft? En kapacitetsplan er et sæt påstande om, hvordan systemet opfører sig under belastning, og en uafprøvet påstand er et gæt i jakkesæt. Den spids, der betyder noget, er ikke sidste måneds gennemsnit, men den næste lancering, højtid eller frist, og testen betyder kun noget, hvis data og topologi ligner produktion, fordi en grænse målt på et legetøjsdatasæt lyver. Tag resultaterne af jeres seneste stress- og soaktests med, inklusive hvor systemet knækkede, og hvordan det fejlede, da det gjorde. Hvis det ærlige svar er, at I aldrig med vilje har drevet systemet til dets bristepunkt, vil I opdage det punkt i produktion, på det værst tænkelige tidspunkt, med brugere der ser på.
Hvordan fortæller produkt, marketing og drift ingeniørafdelingen om en spids, før den sker, og hvor langt i forvejen? De dyreste kapacitetsfejl er ikke modelfejl; de er begivenheder, ingeniørafdelingen aldrig hørte om, før trafikken ankom. En prognose kan ekstrapolere tendens og sæsonudsving fra historik, men en begivenhed har ingen historik, så den kan kun komme fra de mennesker, der planlægger den. Tag de sidste tre efterspørgselsspidser med, og spørg for hver, hvor mange dages varsel ingeniørafdelingen fik, og om det var nok til at reservere kapacitet og belastningstest. Den dokumentation, I vil have, er en stående kanal med en ledetid, der er lang nok til at provisionere imod, fordi alene cloudkvoteforhøjelser kan tage dage. Hvis kanalen ikke findes, er jeres kapacitetsplan blind for netop de øjeblikke, den findes for at beskytte.
Hvilket udnyttelsesmål kører hver latensfølsom tjeneste faktisk ved, og kan vi spore det tal tilbage til dens SLO frem for til et omkostningsmål? Det har betydning, fordi presset for at køre infrastruktur varm er konstant og kommer fra den del af organisationen, der ser regningen, men ikke kølære-klinten, så medmindre målet er skrevet ned og begrundet ud fra latensmålet, driver det opad, til en spids finder kanten. De modstridende hensyn er reelle penge på den ene side og halelatens på den anden, og den ærlige position er, at luft under 100 % er prisen for forudsigelig latens, ikke spild at trimme. Tag den nuværende udnyttelse af jeres øverste tjenester, den SLO hver forsvarer, og den latens, I målte ved den udnyttelse under belastning, med, så drøftelsen argumenterer ud fra dokumentation frem for ud fra instinkt. På en virksomheds- eller offentlig platform, hvor én fælles pulje bakker mange tjenester op, så aftal målet centralt og registrér, hvem der må ændre det, fordi et enkelt team, der stille hæver sit loft, kan skubbe en ressource, andre afhænger af, ud over klinten for alle.
Hvad er vores blanding af reserveret, on demand og spot, hvornår gensyne vi den sidst, og passer den stadig til formen af vores efterspørgsel? Blandingen er, hvor både de største vedvarende besparelser og det største vedvarende spild gemmer sig, fordi en stabil baseline betalt til on demand-takster brænder penge hver time, mens en overforpligtet reserveret position betaler for kapacitet, efterspørgslen siden er vokset fra eller faldet under. Spændingen er omkostning mod fleksibilitet og forpligtelsesrisiko: reserveret kapacitet er billigst pr. enhed, men låser jer fast, spot er endnu billigere, men kan generobres uden varsel, og on demand køber frihed med en præmie. Tag den nuværende fordeling efter omkostning, den efterspørgselskurve den skal dække, og generobringsraten og sprængradius for enhver spotarbejdsbyrde med, så rummet kan se, om afbrydeligt arbejde reelt er afbrydeligt. I virksomheds- og offentlige sammenhænge så bind de reserverede forpligtelser til indkøbs- og budgetcyklussen, fordi flerårige forpligtelser og besparelsesplaner er finansielle forpligtelser, økonomi og revision vil have begrundet mod prognosticeret efterspørgsel, ikke mod sidste kvartals bekvemmelighed.
Når en navngiven spidsbegivenhed nærmer sig, hvem ejer forvarmning, kvoteforhøjelser, udrulningsfrysninger og go/no-go-kaldet, og er det skrevet som en runbook, vi har øvet? Spidsbegivenheder er de øjeblikke, kapacitetsplanlægning findes for at beskytte, og de fejler oftest ikke fordi planen var forkert, men fordi ingen var ansvarlig for at udføre den under pres på dagen. De hensyn, der konkurrerer her, er fart og autonomi mod koordinering: teams vil blive ved med at levere, men en risikabel udrulning i bølgevinduet kan omgøre måneders provisionering, så nogen skal have autoriteten til at fryse og stoppe lanceringen. Tag runbooken for jeres næste store begivenhed, ledetiderne for kvoteforhøjelser og bufferpuljeforvarmning og optegnelsen over, hvem der havde hver rolle sidst, og om overdragelserne holdt, med. For en offentlig frist, der er selvpålagt, offentligt kendt og urokkelig, så navngiv den ansvarlige ejer og eskaleringsvejen eksplicit, fordi der ikke er mulighed for at skære belastning eller bede borgere komme tilbage senere, og en spids, ingen ejer, er en spids, ingen vil forsvare, når den ankommer.

Sektorperspektiv

Startup. Jeres knappeste ressource er ingeniøropmærksomhed, så hold kapacitetsplanlægning billig og støt jer til cloududbyderens elasticitet til daglig variation. Det ene, I ikke kan springe over, er en skriftlig liste over de hårde grænser, der ikke autoskalerer: jeres primære databaseforbindelsesloft, jeres vigtigste tredjeparts hastighedsgrænse og de kontokvoter, I ville ramme under en pludselig funktions- eller pressespids. Belastningstest til flere gange jeres normale spids på produktionsstore data, før jeres første reelle bølge, fordi den skrøbelige selvtillid, autoskalering giver, netop er det, der brister, når en database afviser forbindelser.

Lille virksomhed. I har ingen kapacitetsspecialist og et stramt budget, så behandl dette som et køb-og-konfigurér-problem frem for et modelleringsprojekt. Foretræk administrerede tjenester, der absorberer skalering for jer, sæt forbrugsalarmer og simple udnyttelsesdashboards, så en løbsk regning eller en mættende ressource er synlig tidligt, og kend de få navngivne begivenheder (et sæsonrush, en stor kunde der går live), der vil definere jeres år. Reservér kapacitet til jeres stabile baseline for at skære regningen, og modstå at bygge prognosemaskineri, I ikke kan vedligeholde, når efterspørgselsformen næsten ikke bevæger sig.

Stor virksomhed. Problemet er et fælles, endeligt sæt puljer bag hundredvis af tjenester, så kapacitet bliver porteføljestyring: en vedligeholdt fortegnelse over hårde grænser, udnyttelsesmål udledt centralt af SLO’er og en bevidst blanding af reserveret, on demand og spot, gensyn mod levende priser. Standardisér belastnings-, stress-, soak- og spidstestene, så hvert team måler på samme måde på produktionslignende data, og kør kapacitetsgennemgange efter en kadence, der fanger skrumpende luft, før en hændelse gør det. Budgettér koordineringen eksplicit, fordi ét teams vækst kan sulte et andets, når ingen har hele modellen.

Offentlig sektor. Efterspørgslen er ofte lovmæssigt koncentreret i en urokkelig, offentligt kendt frist, så planlæg specifikt for den navngivne spids, og provisionér en bred sikkerhedsmargin, da I ikke kan skære belastning eller bede borgere komme tilbage senere. Indkøbsregler former provisionering: flerårige reserverede forpligtelser og leverandørkvoteaftaler skal begrundes mod prognosticeret efterspørgsel og overleve revision, så hold prognosen, belastningstestdokumentationen og fortegnelsen over hårde grænser dokumenteret og forsvarlig. Offentliggør realistiske forventninger, hvor I kan, hæv udbydergrænser langt før vinduet, og registrér den sande spids hver cyklus, fordi offentlig ansvarlighed betyder, at en portal, der bukker under for en frist, den selv satte, er en fejl, hele landet ser.

Eksempler

Startup. Et startup på ti personer kører en forbrugerapp på autoskalerende cloudinfrastruktur og føler sig sikker, fordi instansantallet vokser med belastningen. Deres første tv-indslag tredobler trafikken på en time, det tilstandsløse lag skalerer smukt, og appen vælter alligevel: hver ny instans åbnede databaseforbindelser, til databasen ramte sit forbindelsesloft og begyndte at afvise dem. Lektien omformer deres praksis. De tilføjer en forbindelsespooler foran databasen, skriver hver hård grænse mellem en forespørgsel og et svar ned og belastningstester til flere gange deres normale spids på et produktionsstort datasæt. De dækker deres stabile baseline med en reserveret kapacitetsforpligtelse for rabatten og holder en lille varm bufferpulje, så den næste spids møder klar kapacitet. Ændringerne koster en uge og forvandler deres skrøbelige selvtillid til en plan, de kan forsvare.

Stor virksomhed. En global detailhandler behandler sin største salgsdag som årets kapacitetsbegivenhed. Måneder i forvejen bygger et tværfagligt team en efterspørgselsprognose ud fra tidligere års tendens og sæsonudsving plus varesortimentsplanen, oversætter prognosen til ressourcebehov gennem en kapacitetsmodel og provisionerer til den projicerede spids med generøs luft. De belastnings-, stress-, soak- og spidstester hele stien på produktionslignende data, hæver hver relevant cloudkvote uger i forvejen, forvarmer caches og bufferpuljer og fryser risikable udrulninger i det omkringliggende vindue. Reserveret kapacitet dækker den stabile baseline for omkostning, on demand-autoskalering absorberer den daglige kurve, og afbrydeligt batcharbejde kører på spot. Observerbarhed følger hver begrænset ressource mod dens grænse i realtid under begivenheden, med alarmer på projiceret mætning frem for nuværende værdi. Dagen går uden drama, hvilket netop er det udfald, planlægningen købte.

Offentlig sektor. En national skattemyndighed driver en indberetningsportal, hvis efterspørgsel er lovmæssigt koncentreret i dagene før en urokkelig frist, når et helt land indberetter på én gang. Myndigheden planlægger specifikt for den spids frem for for et årligt gennemsnit, der ville være meningsløst. Den estimerer samtidige indberettere ud fra tidligere år og befolkningsdata, provisionerer til den spids med en bred sikkerhedsmargin, fordi der ikke er mulighed for at skære belastning eller bede borgere komme tilbage senere, og belastningstester til den projicerede samtidighed på realistiske data. Teamet fører en skriftlig fortegnelse over hver kvote og hvert enkelt fejlpunkt, hæver grænser hos udbydere langt før vinduet og sætter udnyttelsesmål lave nok til, at kølære-klinten holder sig langt fra fristbølgen. Efter hver indberetningssæson registrerer de den sande spids og hvor meget luft, der var tilbage, og fodrer næste års model. Offentligheden ser en portal, der forbliver oppe på den dag, den er designet til, hvilket er hele pointen med institutionens løfte.

Business case: motivation, ROI og TCO

Afkastet af kapacitetsplanlægning viser sig som to undgåede omkostninger, der trækker i modsat retning, hvilket er det, der gør disciplinen værdifuld. Underprovisionering koster udfald, og udfald under spidsbegivenheder koster mest: tabt omsætning, tabte transaktioner og omdømmeskade netop når publikum er størst. Et detailsite nede på sin største dag eller en offentlig portal, der kollapser på sin indberetningsfrist, betaler for års planlægning i en eneste dårlig time. Overprovisionering koster den modsatte vej, i cloudregninger for kapacitet, der står inaktiv, og i virksomhedsskala løber nogle få procentpoint kronisk overprovisionering på tværs af en flåde op i millioner om året. Kapacitetsplanlægning er den praksis, der finder den bevidste midte: nok til at forsvare SLO’en gennem spidser, ikke mere end det.

Omkostningen ved at adoptere er mest disciplin frem for værktøj. I bygger en efterspørgselsprognose, skriver jeres hårde grænser ned, kører belastningstests efter en kadence, blander jeres provisioneringsstrategier og holder regelmæssige kapacitetsgennemgange. Den samlede ejeromkostning (TCO) forbedres fra begge sider på én gang: færre kapacitetsdrevne hændelser sænker omkostningen ved nedetid og nødrespons, og kontinuerlig korrekt dimensionering plus en fornuftig reserveret-og-spot-blanding sænker den stabile infrastrukturregning. For at fremlægge sagen for ledelsen så forbind kapacitet til de tal, de allerede følger. Bind underprovisionering til tabt omsætning pr. time spidsnedetid og til SLO-brud med kontraktlige bøder, og bind overprovisionering til FinOps-spildrapporten fra kapitel 9.4. Argumentet er ikke abstrakt forsigtighed; det er penge på begge sider af en skala, I kan sætte med vilje.

Anti-mønstre og faldgruber

Autoskalering som plan: at stole på elastiske instanser, mens en databaseforbindelsespulje, kontokvote eller et enkeltpunkt stille loftet hele systemet.
At køre varm for at spare penge: at sigte mod 90 %-plus udnyttelse og møde kølære-klinten, hvor latens eksploderer, og SLO’en brister.
Gennemsnit i stedet for spidser: at dimensionere til middelbelastning, så systemet fejler netop ved den spidsbegivenhed, der retfærdiggjorde at bygge det.
Prognoser kun fra historik: at ekstrapolere tendens og sæsonudsving, mens man misser lanceringen eller kampagnen, ingeniørafdelingen aldrig fik besked om.
Uafprøvede grænser: at planlægge omkring et bristepunkt, ingen har målt, og så opdage det i produktion på det værst tænkelige tidspunkt.
Legetøjsdata-belastningstests: at måle kapacitet på urealistiske data og topologi og producere tal, der lyver om det reelle system.
Ingen fortegnelse over hårde grænser: at styre kvoter, puljer og enkeltpunkter fra hukommelsen og med håb frem for en skriftlig, vedligeholdt liste.
Reservér-alt eller reservér-intet: at overforpligte sig til reserveret kapacitet, efterspørgslen vokser fra eller skrumper under, eller betale fuld on demand-takst for en stabil baseline.
Kapacitetsgennemgang kun efter hændelser: at behandle planlægning som reaktiv brandslukning i stedet for en regelmæssig kadence, der provisionerer før behov.

Modenhedsmodel

Niveau 1, Opstart: Kapacitet er reaktiv og ad hoc. Teams tilføjer ressourcer, efter de løber tør, stoler på autoskalering til alt og har ingen prognose, ingen fortegnelse over hårde grænser og ingen belastningstest. Spidsbegivenheder mødes med håb, og udfald under lanceringer og frister behandles som uheld.
Niveau 2, Udvikling: Basale praksisser dukker op, men varierer fra team til team. Noget overvågning viser udnyttelse, noget belastningstest sker før store begivenheder, større kvoter er kendt, og en grov prognose findes nogle steder, men modellen vedligeholdes ikke, nedstrøms flaskehalse overses ofte, og luft sættes efter tommelfingerregel frem for ud fra SLO’en.
Niveau 3, Standardisering: Kapacitetsplanlægning er en dokumenteret disciplin håndhævet i hele organisationen. En efterspørgselsprognose kombinerer tendens, sæsonudsving, begivenheder og forretningsvækst; en skriftlig fortegnelse over hårde grænser vedligeholdes; udnyttelsesmål udledes af SLO’er; belastnings-, stress-, soak- og spidstests kører efter en kadence mod produktionslignende data; og provisionering blander reserveret, on demand og spot bevidst. En stående kanal bærer begivenhedsvarsler fra produkt og marketing til ingeniørafdelingen.
Niveau 4, Styring: Kapacitet måles og styres mod baselines. Prognose sammenlignes med faktisk efterspørgsel hver cyklus, og fejlen følges og drives ned; udnyttelse, mætningssignaler og luft mod hver hård grænse trendes og alarmeres på som projektioner frem for nuværende værdier; spidsbegivenheder gennemgås bagefter mod den sande observerede spids; og provisioneringsblanding, reserveret forpligtelsesdækning og omkostning pr. SLO rapporteres som målinger, der lukker go/no-go-beslutninger. Data, ikke intuition, afgør, hvad der skal reserveres, hæves eller pensioneres.
Niveau 5, Orkestrering: Kapacitetsplanlægning forbedres løbende og er integreret på tværs af organisationen. Prognoser valideres og forfines automatisk, mætning projiceres og provisioneres imod, før den ankommer, provisioneringsblandinger optimeres mod levende priser, spidsbegivenheder kører fra øvede runbooks, og omkostning og pålidelighed afbalanceres bevidst mod SLO’en på tværs af hele platformen. Kapacitetsmodellen er et fælles, adaptivt aktiv, der rebalancerer flåden, efterhånden som efterspørgselsform og udbyderpriser skifter.

Idéer til drøftelse

Hvad er jeres nuværende udnyttelsesmål for latensfølsomme tjenester, og kan I begrunde det ud fra jeres SLO og kølæreadfærden frem for ud fra et ønske om at spare penge?
Hvilke af jeres komponenter kan slet ikke autoskalere, og hvad sker der med resten af systemet, når en af dem mættes?
Hvis jeres trafik fordobledes næste kvartal, hvilken ressource rammer så sit loft først, og hvor mange dages ledetid skulle I bruge på at hæve den?
Hvordan afgør I blandingen af reserveret, on demand og spot, og hvornår gensyne I den sidst mod jeres faktiske efterspørgselsform?
Når en spidsbegivenhed nærmer sig, hvem ejer forvarmning, kvoteforhøjelser og go/no-go-beslutningen, og er det skrevet ned som en runbook?
Udløses jeres kapacitetsalarmer på projiceret mætning uger i forvejen, eller kun på nuværende udnyttelse, når muren allerede er tæt på?

Vigtigste pointer

Kapacitetsplanlægning afstemmer udbud med prognosticeret efterspørgsel med bevidst luft; den er adskilt fra autoskalering (kortsigtet, inden for rammen) og ydeevneoptimering (billigere arbejdsenheder).
Prognosticér ud fra tendens, sæsonudsving, kendte begivenheder og forretningsvækst, og få begivenhedsvarsler fra produkt og marketing, fordi begivenheder ikke har nogen historik at ekstrapolere fra.
Respektér kølære-klinten (kapitel 11.3): latens eksploderer nær mætning, så sæt udnyttelsesmål ud fra jeres SLO og hold reel luft.
Find grænser med belastnings-, stress-, soak- og spidstest på produktionslignende data, og hold en skriftlig fortegnelse over hårde flaskehalse, der ikke autoskalerer.
Bland reserveret, on demand og spot med varme bufferpuljer, planlæg navngivne spidsbegivenheder enkeltvis, og gennemgå kapacitet efter en kadence frem for efter udfald.

Referencer og videre 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