9.7 Capaciteitsplanning en vraagvoorspelling

Overzicht en motivatie

Elk systeem heeft een plafond. Rekenkernen raken op, schijven lopen vol, verbindingspools raken uitgeput en een wachtrij die bij het ontbijt leeg was loopt tijdens de lunch over. Capaciteitsplanning is de discipline van het afstemmen van het aanbod aan rekenkracht, opslag en netwerk op de vraag die je verwacht, met genoeg ruimte dat een normale dag het plafond nooit benadert en een slechte dag soepel in plaats van catastrofaal faalt. Vraagvoorspelling is de andere helft: voorspellen hoeveel belasting er komt, wanneer en waarom, zodat het aanbod arriveert vóór de vraag in plaats van na de uitval.

Dit hoofdstuk zit tussen twee buren en blijft complementair aan beide. Hoofdstuk 3.5 behandelt schaalbaarheid als architectuureigenschap: hoe een systeem is gebouwd zodat het überhaupt kan groeien, via statelessness, sharding en horizontaal schalen. Hoofdstuk 9.1 behandelt site reliability engineering (SRE), dat de betrouwbaarheidsdoelen stelt die capaciteit moet verdedigen. Hier neem je de architectuur als gegeven en de doelen als vast, en beantwoord je een kwantitatieve vraag: hoeveel van alles moet je kopen, reserveren en in reserve houden zodat het systeem zijn service level objectives (SLO’s, de betrouwbaarheidsdoelen uit hoofdstuk 9.1) haalt door de voorspelde vraag en de pieken die je niet voorspelde. Autoscaling en performance engineering (hoofdstuk 2.16) zijn hier gebruikte hulpmiddelen, maar ze zijn geen vervanging voor planning, en ze voor planning aanzien is een gangbare en dure fout.

Voor grote teams houdt capaciteit op een spreadsheet te zijn die een engineer bijhoudt en wordt een gedeeld model waarvan veel services afhangen. Een platform van honderden services deelt eindige pools: databaseverbindingen, doorvoer van berichtenbrokers, quota van cloudaccounts, netwerkegress. De groei van het ene team kan de andere uithongeren als niemand het hele plaatje houdt. In ondernemingscontexten verschijnen capaciteitsfouten als miljoenen verspild aan ongebruikte infrastructuur of beschamende uitval op precies de momenten die ertoe doen. Bij de overheid worden de inzetten scherper. Een belastingdeadline, een inschrijfperiode voor uitkeringen of een publieke gezondheidsregistratiecampagne concentreert de vraag van een land in een paar uur, de belasting is wettelijk verplicht in plaats van optioneel en het publiek onthoudt een site die bezweek onder een deadline die ze zelf stelde. Capaciteitsplanning is hoe je die beloftes nakomt.

Kernprincipes

Plan capaciteit voor voorspelde vraag plus bewuste ruimte. Draai niet dicht bij verzadiging.
Scheid capaciteitsplanning, autoscaling en performance engineering. Elk lost een ander probleem op.
Voorspel uit trend, seizoensgebondenheid, bekende gebeurtenissen en bedrijfsgroei, niet alleen uit vorige week.
Vind je echte grenzen door belastingtesten en benchmarken, niet door gokken of wachten tot productie ze vindt.
Behandel latentie nabij verzadiging als afgrond, niet als helling. Benuttingsdoelen bestaan vanwege wachtrijtheorie.
Ken je harde knelpunten: verbindingspools, quota en enkelvoudige punten autoscalen niet.
Balanceer kosten tegen betrouwbaarheid met opzet, en beoordeel capaciteit volgens een vast ritme in plaats van na een incident.

Aanbevelingen

Scheid capaciteitsplanning, autoscaling en performance engineering

Deze drie disciplines worden vaak verward, en verwarring leidt tot het kopen van de verkeerde oplossing. Capaciteitsplanning is de middellange-tot-lange-termijnvraag hoeveel totale resources je moet inrichten, reserveren en begroten over weken, kwartalen en jaren. Autoscaling is de kortetermijn, geautomatiseerde aanpassing van resources om belasting minuut voor minuut te volgen: ze beweegt je binnen de envelop die planning inrichtte, maar kan geen quota toveren die je nooit reserveerde, geen koude database opwarmen of een component schalen die als enkele instantie draait. Performance engineering (hoofdstuk 2.16) verandert de vorm van het probleem door elke werkeenheid goedkoper te maken, zodat dezelfde hardware meer vraag bedient.

Het onderscheid is praktisch. Wanneer een systeem onder belasting traag is, voegt autoscaling instanties toe, maakt performance engineering elke instantie sneller en beslist capaciteitsplanning of je de instanties kunt betalen en of de downstreamdatabase de verbindingen kan accepteren die ze zullen openen. Een team dat alleen naar autoscaling grijpt raakt een harde grens waarvoor het nooit planning maakte. Een team dat alleen naar performance engineering grijpt optimaliseert code terwijl het accountquota ze hoe dan ook begrenst. Je hebt alle drie nodig, en je moet weten welke een gegeven probleem vraagt.

Voorspel vraag uit trend, seizoensgebondenheid, gebeurtenissen en bedrijfsgroei

Een voorspelling gebouwd op het gemiddelde van vorige week mist elk interessant moment. Bouw de jouwe uit vier aparte componenten. De trend is de onderliggende richting: groeit de vraag, is ze vlak of krimpt ze, en hoe snel? Seizoensgebondenheid is het zich herhalende patroon: de dagelijkse piek om 9 uur, de wekelijkse rust in het weekend, de jaarlijkse golf voor de feestdagen. Gebeurtenisgedreven pieken zijn de eenmalige concentraties: een productlancering, een marketingcampagne, een televisievermelding, een aangiftedeadline van de overheid. Door het bedrijf gedreven groei is de vraag die je eigen roadmap creëert: een nieuwe markt, een grote klant die instapt, een functie die verzoeken per sessie verdrievoudigt.

Gebruik de juiste techniek voor elk. Een tijdreeks van historische belasting, ontbonden in trend en seizoensgebondenheid, geeft je een verdedigbare basislijn voor stabiele vraag. Gebeurtenissen kunnen niet uit historie worden geëxtrapoleerd omdat ze geen historie hebben. Ze komen uit praten met het bedrijf, de roadmap lezen en marketing en product vragen wat ze gaan lanceren. De meest schadelijke capaciteitsfalen zijn bijna altijd gebeurtenissen waarvan engineering nooit hoorde. De remedie is organisatorisch, niet statistisch: een permanent kanaal waar product, marketing en beheer aankomende pieken ver genoeg vooraf melden om ervoor in te richten.

Stel benuttingsdoelen en respecteer de afgrond van de wachtrijtheorie

Het instinct om infrastructuur “heet” te draaien op 90% benutting om geld te besparen is een valstrik, en de reden is wachtrijtheorie, diepgaand behandeld in hoofdstuk 11.3. Naarmate een resource volledige benutting nadert, stijgt wachttijd niet zacht en lineair, maar explodeert ze. Een server op 50% benutting heeft comfortabele ruimte. Dezelfde server op 90% kan latentie van meerdere malen slechter zien, en op 95% kan de wachtrij volledig op hol slaan. Latentie nabij verzadiging is een afgrond, geen helling, en je gebruikers voelen de afgrond als timeouts, herhalingen en fouten lang voordat de resource technisch “vol” is.

Daarom stellen capaciteitsplanners benuttingsdoelen ruim onder 100%, gewoonlijk in het bereik van 50% tot 70% voor latentiegevoelige services, hoger voor doorvoergerichte batchwerk dat wachtrijen verdraagt. Het doel is geen verspilling. Het is de prijs van voorspelbare latentie. Kies het doel uit de SLO: als je latentiedoelstelling strikt is, is je benuttingsplafond lager, omdat de staartlatentie die wachtrijen produceren precies is wat een SLO opblaast. Ruimte en veiligheidsmarge zijn hetzelfde idee uit twee richtingen. Ruimte is het gat tussen normale belasting en capaciteit. Veiligheidsmarge is dat gat uitgedrukt als verzekering tegen een voorspelling die te hoog uitvalt, een failover die belasting concentreert of een piek die je niet zag aankomen.

Vind echte grenzen door belastingtesten en benchmarken

Je kunt niet plannen rond een grens die je niet hebt gemeten. Belastingtesten sturen synthetisch of herspeeld verkeer naar een systeem om te observeren hoe latentie, doorvoer en foutpercentage zich gedragen naarmate belasting stijgt en waar ze breken. Benchmarken meet een component geïsoleerd om haar plafond vast te stellen: verzoeken per seconde per instantie, schrijfacties per seconde per databasenode, berichten per seconde per brokerpartitie. Samen vertellen ze je de twee getallen die planning nodig heeft: hoeveel een capaciteitseenheid levert en waar het hele systeem omvalt.

Draai verschillende tests. Een belastingtest loopt op naar verwachte piek en bevestigt dat de SLO met ruimte standhoudt. Een stresstest duwt voorbij het breekpunt om te zien hoe het systeem faalt, want een systeem dat soepel degradeert is heel anders dan een dat instort. Een soaktest houdt uren of dagen matige belasting vast om geheugenlekken, verbindingsuitputting en schijfvolproblemen bloot te leggen die pas in de tijd verschijnen. Een spiketest gooit plotseling belasting erop om te controleren of autoscaling en buffers die absorberen voordat gebruikers het merken. Test tegen productieachtige data en topologie, want een grens gemeten op een speelgoeddataset liegt. Draai deze tests opnieuw wanneer het systeem verandert, zodat je getallen het systeem beschrijven dat je hebt in plaats van dat van een jaar geleden.

Kies provisioningstrategieën bewust

Cloudaanbieders laten je dezelfde capaciteit kopen op manieren die prijs tegen flexibiliteit ruilen, en ze goed mengen is waar echt geld wordt bespaard. On-demand-capaciteit is flexibel en duur: je betaalt het volle tarief voor het vermogen op elk moment te starten en stoppen, wat past bij onvoorspelbare en kortlevende belasting. Gereserveerde capaciteit (verbintenissen van een of drie jaar, of savings plans) is goedkoper per eenheid in ruil voor een belofte haar te blijven gebruiken, wat past bij je stabiele basislijn. Spot-instanties verkopen reservecapaciteit met diepe korting maar kunnen met weinig waarschuwing worden teruggevorderd, wat past bij foutentolerant, onderbreekbaar werk zoals batchverwerking en stateless workers.

Het patroon dat werkt is gelaagd. Dek je stabiele basislijn met gereserveerde capaciteit voor de laagste eenheidskosten, absorbeer dagelijkse en wekelijkse variatie met on-demand autoscaling en duw onderbreekbaar batchwerk naar spot om de korting te oogsten. Houd een warme bufferpool van vooraf ingerichte capaciteit voor services die de koudestartvertraging van schalen vanaf nul niet verdragen, zodat een plotselinge piek klare capaciteit ontmoet in plaats van een wachtrij terwijl nieuwe instanties opstarten. De juiste mix is een portfoliobeslissing en verschuift naarmate je vraagvorm en de prijzen van de aanbieder veranderen, dus herzie haar.

Breng harde knelpunten in kaart die niet autoscalen

Autoscaling kweekt gevaarlijk vertrouwen, omdat veel grenzen downstream zitten van het ding dat schaalt en niet meebewegen wanneer het dat doet. Database-verbindingspools zijn het klassieke voorbeeld: schaal je stateless laag van 10 naar 100 instanties en elk opent verbindingen met dezelfde database, die een harde limiet heeft op gelijktijdige verbindingen en nieuwe zal gaan weigeren. Cloudaccounts dragen quota op bijna alles: instanties per regio, IP-adressen, API-aanroepen per seconde, functieconcurrency. Elk enkelvoudig punt in de architectuur, een primaire database, een leidernode, een gedeelde cache, een gelicentieerd apparaat, is een plafond dat horizontaal schalen elders niet kan verhogen.

Maak deze expliciet. Houd een geschreven inventaris bij van elke harde grens tussen een verzoek en zijn respons: poolgroottes, quotawaarden, componenten met één instantie, snelheidslimieten van derden, aantallen licentieplaatsen. Leg voor elk de huidige waarde, het huidige gebruik en de belasting waarbij het knelt vast. Deze inventaris is het verschil tussen een capaciteitsplan dat het hele systeem beschrijft en een dat alleen de makkelijke, elastische delen beschrijft terwijl een verbindingspool stilletjes wacht om je lancering te beëindigen. Verhoog quota vóór de behoefte, want quotaverhogingen van aanbieders kunnen dagen duren om te worden goedgekeurd.

Richt in voor piekgebeurtenissen, niet alleen het gemiddelde

Gemiddelden verbergen de momenten die ertoe doen. Een systeem gedimensioneerd op gemiddelde belasting faalt op de piek, en voor veel organisaties is de piek het hele punt: de retailgolf op de grootste winkeldag, de streamingpiek bij een live finale, het belastingportaal op de aangiftedeadline, de uitkeringssite wanneer inschrijving opent. Plan deze benoemde gebeurtenissen individueel. Schat de piek uit het bedrijf (verwachte gelijktijdige gebruikers, verzoeken per sessie, het veelvoud boven een normale dag), richt in naar die piek met ruimte, test de belasting op dat niveau en zet de capaciteit klaar vóór de gebeurtenis in plaats van tijdens haar te haasten.

Behandel een lancering of deadline als operationele gebeurtenis met een runbook. Warm caches en bufferpools voor, verhoog quota vooraf, bevries riskante deployments tijdens het venster en zet mensen in bereikbaarheid die kunnen handelen als de voorspelling te laag blijkt. Leg na de gebeurtenis de werkelijke piek vast en hoe dicht je bij je grenzen kwam, want dat getal is de beste invoer voor het plan van volgend jaar. Overheidsdeadlines verdienen speciale zorg: ze zijn zelfopgelegd, publiek bekend en onverzettelijk, dus er is geen excuus voor verrast worden en geen manier je te verbergen als dat gebeurt.

Instrumenteer capaciteit en beoordeel haar volgens een ritme

Capaciteitsplanning draait op data, en de data komt uit de observeerbaarheid van hoofdstuk 9.2. Volg de benutting van elke beperkte resource (CPU, geheugen, schijf, netwerk, verbindingspools, wachtrijdiepte) tegen haar limiet, zodat je ruimte ziet krimpen voordat ze verdwijnt. Let direct op verzadigingssignalen: wachtrijlengtes, wachttijden en afwijzingspercentages onthullen de naderende wachtrijafgrond. Trend deze over weken om te projecteren wanneer een resource haar plafond raakt bij de huidige groeisnelheid, en alarmeer op de projectie in plaats van alleen de huidige waarde, zodat je inricht vóór de muur in plaats van erop.

Houd capaciteitsreviews volgens een vast ritme, maandelijks of per kwartaal, in plaats van alleen na een incident. Vergelijk in elke review voorspelling met werkelijke vraag en corrigeer het model, loop de harde-grensinventaris door en controleer de ruimte tegen elke grens, kijk naar komende gebeurtenissen en bedrijfsplannen en besluit wat je reserveert, verhoogt of afschaft. Houd een levend capaciteitsmodel: een eenvoudig document of spreadsheet dat vraagdrijvers aan resourcebehoeften koppelt, zodat iedereen kan vragen “wat gebeurt er met de database als het verkeer verdubbelt” en een antwoord uit het model krijgt in plaats van een uitval. Het model is nooit perfect, maar een geschreven, regelmatig gecorrigeerd model verslaat intuïtie elke keer.

Afwegingen: voor- en nadelen

Aanpak	Voordelen	Nadelen
Hoog benuttingsdoel	Lagere kosten per eenheid. Minder ongebruikte capaciteit	Latentie explodeert nabij verzadiging. Geen ruimte voor pieken of failover
Ruime marge	Voorspelbare latentie. Absorbeert pieken en failover	Hogere vaste kosten. Kan inefficiëntie verbergen
Gereserveerde capaciteit	Laagste eenheidsprijs voor stabiele basislijn	Verbintenisrisico als vraag daalt of verschuift
On-demand-capaciteit	Flexibel. Volgt variabele belasting minuut voor minuut	Hoogste eenheidsprijs. Kan het budget verrassen
Spot-instanties	Diepe korting voor onderbreekbaar werk	Zonder bericht teruggevorderd. Ongeschikt voor stateful of latentiekritiek werk
Autoscaling	Volgt belasting automatisch binnen de envelop	Kan gereserveerd quotum niet overschrijden. Koude starts. Maskeert downstreamgrenzen
Bufferpool (warme capaciteit)	Absorbeert plotselinge pieken direct	Betaalt voor ongebruikte capaciteit tussen pieken

De centrale spanning is kosten tegen betrouwbaarheid, en er is geen instelling die beide optimaliseert. Draai schraal en je bespaart geld tot de dag dat een piek een verzadigde resource ontmoet en latentie van de wachtrijafgrond valt. Draai ruim en je slaapt goed terwijl je betaalt voor ruimte die meestal ongebruikt zit. Los de spanning op met de SLO in plaats van met angst of zuinigheid. Richt genoeg ruimte in om het betrouwbaarheidsdoel door voorspelde pieken plus een marge te halen, en niet meer, en laat FinOps (financiële operaties voor cloudkosten, hoofdstuk 9.4) de verspilling opjagen die geen SLO verdedigt. Het doel is bewuste balans: elke euro ruimte met opzet gekocht om een bekende hoeveelheid betrouwbaarheid te kopen, en elke euro verspilling met opzet verwijderd omdat ze er geen koopt.

Vragen om met je team te bespreken

Kennen we werkelijk de belasting waarbij elk van onze harde knelpunten knelt, of nemen we aan dat autoscaling ons redt? De meeste teams kunnen vertellen dat hun instanties autoscalen, en de meeste kunnen niet vertellen wat de limiet op gelijktijdige verbindingen op hun primaire database is, de API-snelheidslimiet van hun belangrijkste derde partij of het accountquotum dat hun functieconcurrency begrenst. Dat zijn de grenzen die lanceringen beëindigen, en ze bewegen niet mee wanneer de stateless laag schaalt. Neem de geschreven inventaris van harde grenzen mee als je die hebt, en als je die niet hebt, is die afwezigheid de bevinding. Voor elke grens wil je drie getallen: het plafond, het gebruik van vandaag en het vraagniveau waarbij ze elkaar ontmoeten. Overal waar je niet alle drie kunt produceren, heb je een knelpunt dat je met hoop beheert.
Wanneer hebben we voor het laatst belastingtests gedaan op het niveau van onze ergste komende piek, op productieachtige data, en hield de SLO met ruimte stand? Een capaciteitsplan is een set beweringen over hoe het systeem zich onder belasting gedraagt, en een ongetoetste bewering is een gok in een pak. De piek die telt is niet het gemiddelde van vorige maand maar de volgende lancering, feestdag of deadline, en de test betekent alleen iets als data en topologie op productie lijken, want een grens gemeten op een speelgoeddataset liegt. Neem de resultaten van je meest recente stress- en soaktests mee, inclusief waar het systeem brak en hoe het faalde toen het dat deed. Als het eerlijke antwoord is dat je het systeem nooit met opzet tot zijn breekpunt hebt gedreven, dan ontdek je dat punt in productie, op het slechtst denkbare moment, met gebruikers die kijken.
Hoe vertellen product, marketing en beheer engineering over een piek voordat hij gebeurt, en hoe ver vooraf? De duurste capaciteitsfalen zijn geen modelfouten. Het zijn gebeurtenissen waarvan engineering nooit hoorde tot het verkeer arriveerde. Een voorspelling kan trend en seizoensgebondenheid uit historie extrapoleren, maar een gebeurtenis heeft geen historie, dus ze kan alleen komen van de mensen die haar plannen. Neem de laatste drie vraagpieken mee en vraag voor elk hoeveel dagen waarschuwing engineering kreeg en of dat genoeg was om capaciteit te reserveren en de belasting te testen. Het bewijs dat je wilt is een permanent kanaal met een doorlooptijd lang genoeg om tegen in te richten, want alleen al quotaverhogingen van de cloud kunnen dagen duren. Als het kanaal niet bestaat, is je capaciteitsplan blind voor precies de momenten die het moet beschermen.
Op welk benuttingsdoel draait elke latentiegevoelige service werkelijk, en kunnen we dat getal herleiden tot haar SLO in plaats van tot een kostendoel? Dit doet ertoe omdat de druk om infrastructuur heet te draaien constant is en komt van het deel van de organisatie dat de rekening ziet maar niet de wachtrijafgrond, dus tenzij het doel is opgeschreven en uit de latentiedoelstelling onderbouwd, drijft het omhoog tot een piek de rand vindt. De concurrerende overwegingen zijn echt geld aan de ene kant en staartlatentie aan de andere, en de eerlijke positie is dat ruimte onder 100% de prijs van voorspelbare latentie is, geen verspilling om weg te snoeien. Neem de huidige benutting van je topservices mee, de SLO die elk verdedigt en de latentie die je bij die benutting onder belasting mat, zodat de discussie uit bewijs argumenteert in plaats van instinct. Spreek op een onderneming- of overheidsplatform waar één gedeelde pool veel services draagt het doel centraal af en leg vast wie het mag wijzigen, want één team dat stilletjes zijn plafond verhoogt kan een resource waarvan anderen afhangen voor iedereen over de afgrond duwen.
Wat is onze mix van gereserveerde, on-demand- en spotcapaciteit, wanneer herzagen we die voor het laatst, en past ze nog bij de vorm van onze vraag? De mix is waar zowel de grootste aanhoudende besparingen als de grootste aanhoudende verspilling zich verbergen, want een stabiele basislijn betaald tegen on-demandtarieven verbrandt elk uur geld terwijl een te sterk gecommitteerde gereserveerde positie betaalt voor capaciteit die de vraag inmiddels is ontgroeid of onder is gezakt. De spanning is kosten tegen flexibiliteit en verbintenisrisico: gereserveerde capaciteit is het goedkoopst per eenheid maar bindt je vast, spot is nog goedkoper maar kan zonder bericht worden teruggevorderd en on-demand koopt vrijheid met een premie. Neem de huidige verdeling naar kosten mee, de vraagcurve die ze moet dekken en het terugvorderingspercentage en de schadezone van elke spotworkload, zodat de zaal kan zien of onderbreekbaar werk echt onderbreekbaar is. Koppel in omgevingen van onderneming en overheid de gereserveerde verbintenissen aan de aanbestedings- en begrotingscyclus, want meerjarige verbintenissen en savings plans zijn financiële verplichtingen die financiën en audit onderbouwd willen zien tegen voorspelde vraag, niet tegen het gemak van vorig kwartaal.
Wanneer een benoemde piekgebeurtenis eraan komt, wie bezit voorverwarmen, quotaverhogingen, deploymentbevriezingen en de go/no-go-beslissing, en is dat opgeschreven als runbook dat we hebben geoefend? Piekgebeurtenissen zijn de momenten die capaciteitsplanning moet beschermen, en ze falen het vaakst niet omdat het plan fout was maar omdat niemand verantwoordelijk was voor de uitvoering ervan onder druk op de dag zelf. De overwegingen die hier concurreren zijn snelheid en autonomie tegen coördinatie: teams willen blijven opleveren, maar een riskante deployment tijdens het piekvenster kan maanden provisioning ongedaan maken, dus iemand moet de bevoegdheid hebben te bevriezen en de lancering te stoppen. Neem het runbook voor je volgende grote gebeurtenis mee, de doorlooptijden voor quotaverhogingen en bufferpoolopwarming en de registratie van wie elke rol de vorige keer hield en of de overdrachten standhielden. Noem voor een overheidsdeadline die zelfopgelegd, publiek bekend en onverzettelijk is de verantwoordelijke eigenaar en het escalatiepad expliciet, want er is geen optie belasting af te werpen of burgers te vragen later terug te komen, en een piek die niemand bezit is een piek die niemand verdedigt wanneer hij arriveert.

Sectorperspectief

Startup. Je schaarste middel is engineeringaandacht, dus houd capaciteitsplanning goedkoop en schraal en leun op de elasticiteit van de cloudaanbieder voor dagelijkse variatie. Het ene wat je niet kunt overslaan is een geschreven lijst van de harde grenzen die niet autoscalen: de verbindingslimiet van je primaire database, je belangrijkste snelheidslimiet van een derde en de accountquota die je zou raken bij een plotselinge functie- of persgolf. Test de belasting op meerdere malen je normale piek op data van productiegrootte vóór je eerste echte golf, want het kwetsbare vertrouwen dat autoscaling geeft is precies wat breekt wanneer een database verbindingen weigert.

Kleinbedrijf. Je hebt geen capaciteitsspecialist en een krap budget, dus behandel dit als koop-en-configureerprobleem in plaats van een modelleerproject. Geef de voorkeur aan beheerde services die schalen voor je absorberen, stel kostenalarmen en eenvoudige benuttingsdashboards in zodat een op hol geslagen rekening of een verzadigende resource vroeg zichtbaar is en ken de paar benoemde gebeurtenissen (een seizoensdrukte, een grote klant die live gaat) die je jaar bepalen. Reserveer capaciteit voor je stabiele basislijn om de rekening te snijden en weersta voorspellingsmachinerie bouwen die je niet kunt onderhouden wanneer de vraagvorm nauwelijks beweegt.

Grote onderneming. Het probleem is een gedeelde, eindige set pools achter honderden services, dus capaciteit wordt portfoliogovernance: een onderhouden inventaris van harde grenzen, benuttingsdoelen centraal afgeleid uit SLO’s en een bewuste mix van gereserveerde, on-demand- en spotcapaciteit die tegen live prijzen wordt herzien. Standaardiseer de belasting-, stress-, soak- en spiketests zodat elk team op dezelfde manier meet op productieachtige data, en houd capaciteitsreviews volgens een ritme dat krimpende ruimte vangt vóór een incident het doet. Begroot de coördinatie expliciet, want de groei van het ene team kan de andere uithongeren wanneer niemand het hele model houdt.

Overheid. Vraag is vaak wettelijk geconcentreerd in een onverzettelijke, publiek bekende deadline, dus plan specifiek voor die benoemde piek en richt een ruime veiligheidsmarge in, aangezien je geen belasting kunt afwerpen of burgers vragen later terug te komen. Aanbestedingsregels geven provisioning vorm: meerjarige gereserveerde verbintenissen en quotaovereenkomsten met leveranciers moeten worden onderbouwd tegen voorspelde vraag en audit overleven, dus houd de voorspelling, het belastingtestbewijs en de harde-grensinventaris gedocumenteerd en verdedigbaar. Publiceer waar mogelijk realistische verwachtingen, verhoog limieten van aanbieders ruim vóór het venster en leg elke cyclus de echte piek vast, want publieke verantwoording betekent dat een portaal dat bezwijkt onder een deadline die ze zelf stelde een falen is dat het hele land ziet.

Voorbeelden

Startup. Een startup van tien personen draait een consumentenapp op autoscalende cloudinfrastructuur en voelt zich veilig omdat het aantal instanties met de belasting meegroeit. Hun eerste televisiefeature verdrievoudigt het verkeer in een uur, de stateless laag schaalt prachtig en de app valt toch om: elke nieuwe instantie opende databaseverbindingen tot de database haar verbindingslimiet raakte en ze begon te weigeren. De les geeft hun praktijk een nieuwe vorm. Ze voegen een verbindingspooler voor de database toe, schrijven elke harde grens tussen een verzoek en een respons op en testen de belasting op meerdere malen hun normale piek op een dataset van productiegrootte. Ze dekken hun stabiele basislijn met een gereserveerde-capaciteitsverbintenis voor de korting en houden een kleine warme bufferpool zodat de volgende piek klare capaciteit ontmoet. De wijzigingen kosten een week en zetten hun kwetsbare vertrouwen om in een plan dat ze kunnen verdedigen.

Grote onderneming. Een wereldwijde retailer behandelt haar grootste verkoopdag als de capaciteitsgebeurtenis van het jaar. Maanden vooraf bouwt een multidisciplinair team een vraagvoorspelling uit trend en seizoensgebondenheid van voorgaande jaren plus het merchandisingplan, vertaalt de voorspelling via een capaciteitsmodel naar resourcebehoeften en richt in naar de geprojecteerde piek met ruime marge. Ze testen belasting, stress, soak en spike over het volledige pad op productieachtige data, verhogen weken vooraf elk relevant cloudquotum, warmen caches en bufferpools voor en bevriezen riskante deployments voor het omringende venster. Gereserveerde capaciteit dekt de stabiele basislijn voor kosten, on-demand autoscaling absorbeert de dagelijkse curve en onderbreekbaar batchwerk draait op spot. Observeerbaarheid volgt tijdens de gebeurtenis elke beperkte resource in real time tegen haar limiet, met alarmen op geprojecteerde verzadiging in plaats van huidige waarde. De dag verstrijkt zonder drama, precies de uitkomst die de planning kocht.

Overheid. Een nationale belastingdienst draait een aangifteportaal waarvan de vraag wettelijk is geconcentreerd in de dagen voor een onverzettelijke deadline, wanneer een heel land tegelijk aangifte doet. De dienst plant specifiek voor die piek in plaats van voor een jaargemiddelde dat zinloos zou zijn. Ze schat gelijktijdige aangevers uit voorgaande jaren en bevolkingsdata, richt in naar die piek met een ruime veiligheidsmarge omdat er geen optie is belasting af te werpen of burgers te vragen later terug te komen, en test de belasting op de geprojecteerde concurrency op realistische data. Het team houdt een geschreven inventaris van elk quotum en enkelvoudig falenpunt bij, verhoogt limieten bij aanbieders ruim vóór het venster en stelt benuttingsdoelen laag genoeg dat de wachtrijafgrond ver van de deadlinegolf blijft. Na elk aangifteseizoen legt ze de echte piek vast en hoeveel ruimte er overbleef, wat het model van volgend jaar voedt. Het publiek ziet een portaal dat overeind blijft op de dag waarvoor het is ontworpen, wat het hele punt is van de belofte van de instelling.

Zakelijke onderbouwing: motivatie, ROI en TCO

Het rendement van capaciteitsplanning verschijnt als twee vermeden kosten die in tegengestelde richting trekken, wat de discipline waardevol maakt. Onderprovisioning kost uitval, en uitval tijdens piekgebeurtenissen kost het meest: verloren omzet, verloren transacties en reputatieschade precies wanneer het publiek het grootst is. Een retailsite die op haar grootste dag down is of een overheidsportaal dat op de aangiftedeadline instort betaalt jaren planning terug in één slecht uur. Overprovisioning kost de andere kant op, in cloudrekeningen voor capaciteit die ongebruikt zit, en op ondernemingsschaal loopt een paar punten chronische overprovisioning over een vloot op tot miljoenen per jaar. Capaciteitsplanning is de praktijk die het bewuste midden vindt: genoeg om de SLO door pieken te verdedigen, niet meer dan dat.

De adoptiekosten zijn vooral discipline in plaats van tooling. Je bouwt een vraagvoorspelling, schrijft je harde grenzen op, draait belastingtests volgens een ritme, mengt je provisioningstrategieën en houdt reguliere capaciteitsreviews. De total cost of ownership (TCO) verbetert van beide kanten tegelijk: minder door capaciteit veroorzaakte incidenten verlagen de kosten van downtime en noodrespons, en continue dimensionering op maat plus een verstandige mix van gereserveerd en spot verlagen de vaste infrastructuurrekening. Maak de zaak voor leiderschap door capaciteit aan de getallen te koppelen die ze al bekijken. Koppel onderprovisioning aan omzet verloren per uur piekdowntime en aan SLO-schendingen met contractuele boetes, en koppel overprovisioning aan het FinOps-verspillingsrapport uit hoofdstuk 9.4. Het argument is geen abstracte voorzichtigheid. Het is geld aan beide kanten van een knop die je met opzet kunt instellen.

Antipatronen en valkuilen

Autoscaling als plan: vertrouwen op elastische instanties terwijl een databaseverbindingspool, accountquotum of enkelvoudig punt stilletjes het hele systeem begrenst.
Heet draaien om geld te besparen: mikken op 90%-plus benutting en de wachtrijafgrond ontmoeten, waar latentie explodeert en de SLO breekt.
Gemiddelden in plaats van pieken: dimensioneren op gemiddelde belasting zodat het systeem faalt op precies de piekgebeurtenis die het bouwen rechtvaardigde.
Voorspellen uit alleen historie: trend en seizoensgebondenheid extrapoleren terwijl de lancering of campagne wordt gemist waarvan engineering nooit hoorde.
Ongetoetste grenzen: plannen rond een breekpunt dat niemand heeft gemeten en het dan in productie ontdekken op het slechtste moment.
Belastingtests met speelgoeddata: capaciteit meten op onrealistische data en topologie, wat getallen produceert die liegen over het echte systeem.
Geen harde-grensinventaris: quota, pools en enkelvoudige punten beheren uit het hoofd en met hoop in plaats van een geschreven, onderhouden lijst.
Alles reserveren of niets reserveren: te sterk committeren aan gereserveerde capaciteit die de vraag ontgroeit of onder zakt, of volle on-demandtarieven betalen voor een stabiele basislijn.
Capaciteitsreview alleen na incidenten: planning behandelen als reactief brandjes blussen in plaats van een regulier ritme dat vooruit inricht.

Volwassenheidsmodel

Niveau 1, Initiëren: Capaciteit is reactief en ad hoc. Teams voegen resources toe nadat ze op zijn, vertrouwen autoscaling voor alles en hebben geen voorspelling, geen harde-grensinventaris en geen belastingtests. Piekgebeurtenissen worden met hoop tegemoet getreden, en uitval tijdens lanceringen en deadlines wordt als pech behandeld.
Niveau 2, Ontwikkelen: Basispraktijken verschijnen maar variëren per team. Enige bewaking toont benutting, enige belastingtests gebeuren vóór grote gebeurtenissen, belangrijke quota zijn bekend en een ruwe voorspelling bestaat hier en daar, maar het model wordt niet onderhouden, downstreamknelpunten worden vaak gemist en ruimte wordt op vuistregel bepaald in plaats van uit de SLO.
Niveau 3, Standaardiseren: Capaciteitsplanning is een gedocumenteerde discipline die organisatiebreed wordt afgedwongen. Een vraagvoorspelling combineert trend, seizoensgebondenheid, gebeurtenissen en bedrijfsgroei. Een geschreven harde-grensinventaris wordt onderhouden. Benuttingsdoelen leiden uit SLO’s af. Belasting-, stress-, soak- en spiketests draaien volgens een ritme tegen productieachtige data. Provisioning mengt gereserveerd, on-demand en spot bewust. Een permanent kanaal draagt gebeurteniswaarschuwingen van product en marketing naar engineering.
Niveau 4, Beheersen: Capaciteit wordt gemeten en beheerst tegen uitgangswaarden. De voorspelling wordt elke cyclus met de werkelijke vraag vergeleken en de fout wordt gevolgd en teruggedrongen. Benutting, verzadigingssignalen en ruimte tegen elke harde grens worden getrend en gealarmeerd als projecties in plaats van huidige waarden. Piekgebeurtenissen worden achteraf beoordeeld tegen de werkelijk geobserveerde piek. Provisioningmix, dekking van gereserveerde verbintenissen en kosten per SLO worden gerapporteerd als statistieken die go/no-go-beslissingen poorten. Data, niet intuïtie, bepaalt wat je reserveert, verhoogt of afschaft.
Niveau 5, Orkestreren: Capaciteitsplanning wordt continu verbeterd en over de organisatie geïntegreerd. Voorspellingen worden automatisch gevalideerd en verfijnd, verzadiging wordt geprojecteerd en ertegen ingericht voordat ze arriveert, provisioningmixen worden tegen live prijzen geoptimaliseerd, piekgebeurtenissen draaien vanuit gerepeteerde runbooks, en kosten en betrouwbaarheid worden bewust tegen de SLO afgewogen over het hele platform. Het capaciteitsmodel is een gedeeld, adaptief bezit dat de vloot herbalanceert naarmate vraagvorm en prijzen van aanbieders verschuiven.

Ideeën voor discussie

Wat is je huidige benuttingsdoel voor latentiegevoelige services, en kun je het onderbouwen uit je SLO en het wachtrijgedrag in plaats van uit een wens geld te besparen?
Welke van je componenten kunnen helemaal niet autoscalen, en wat gebeurt er met de rest van het systeem wanneer er één verzadigt?
Als je verkeer volgend kwartaal verdubbelde, welke resource raakt als eerste haar plafond, en hoeveel dagen doorlooptijd zou je nodig hebben om die te verhogen?
Hoe beslis je de mix van gereserveerde, on-demand- en spotcapaciteit, en wanneer herzag je die voor het laatst tegen je werkelijke vraagvorm?
Wanneer een piekgebeurtenis eraan komt, wie bezit voorverwarmen, quotaverhogingen en de go/no-go-beslissing, en is dat als runbook opgeschreven?
Gaan je capaciteitsalarmen af op geprojecteerde verzadiging weken vooraf, of alleen op huidige benutting wanneer de muur al dichtbij is?

Belangrijkste inzichten

Capaciteitsplanning stemt aanbod af op voorspelde vraag met bewuste ruimte. Ze verschilt van autoscaling (kortetermijn, binnen de envelop) en performance engineering (goedkopere werkeenheden).
Voorspel uit trend, seizoensgebondenheid, bekende gebeurtenissen en bedrijfsgroei, en haal gebeurteniswaarschuwingen bij product en marketing, want gebeurtenissen hebben geen historie om te extrapoleren.
Respecteer de afgrond van de wachtrijtheorie (hoofdstuk 11.3): latentie explodeert nabij verzadiging, dus stel benuttingsdoelen uit je SLO en houd echte ruimte.
Vind grenzen via belasting-, stress-, soak- en spiketests op productieachtige data, en houd een geschreven inventaris van harde knelpunten die niet autoscalen.
Meng gereserveerde, on-demand- en spotcapaciteit met warme bufferpools, plan benoemde piekgebeurtenissen individueel en beoordeel capaciteit volgens een ritme in plaats van na uitval.

Referenties en verder lezen

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