3.5 Schaalbaarheid, prestaties en veerkracht

Overzicht en motivatie

Schaalbaarheid, prestaties en veerkracht zijn drie aparte kwaliteiten, en mensen halen ze vaak door elkaar. Prestaties zijn hoe snel het systeem reageert en hoeveel werk het per eenheid middel doet. Schaalbaarheid is hoe goed het prestaties behoudt naarmate de belasting groeit. Veerkracht is hoe goed het blijft werken, of gracieus degradeert, wanneer dingen falen. Een systeem kan snel maar niet schaalbaar zijn (geweldig bij lage belasting, stort in bij hoge), schaalbaar maar broos (verwerkt volume maar valt om wanneer één component faalt) of veerkrachtig maar traag. Een grote organisatie heeft alle drie nodig, vanaf het begin ingebouwd, omdat het achteraf inbouwen van elk daarvan na de lancering duur en ontwrichtend is.

Voor systemen van onderneming en overheid zijn de gevolgen van het fout doen publiek en ernstig. Denk aan een uitkeringsportaal dat bezwijkt op de eerste dag van een nieuwe regeling, een belastingaangiftesysteem dat bij de deadline in een time-out loopt of een betalingsplatform dat uitvalt tijdens de winkelpiek. Dit zijn de falen die de krantenkoppen halen, onderzoeken triggeren en publiek vertrouwen uithollen. Deze systemen krijgen ook te maken met sterk piekerige, vaak wettelijk getimede belasting (aangiftedeadlines, inschrijfperiodes, uitbetalingsdagen) en strenge beschikbaarheids- en herstelverplichtingen. Je moet capaciteit plannen voor voorspelbare pieken, gracieus degraderen onder de onvoorspelbare en binnen gedefinieerde tijd- en dataverlieslimieten herstellen na een ramp. Dit is engineering met een publieke verantwoordingsdimensie.

Dit hoofdstuk behandelt horizontaal tegenover verticaal schalen, statelessness en sharden als enablers van schaal, load balancing, autoscaling en capaciteitsplanning, performance engineering met expliciete budgetten, veerkrachtpatronen en chaos engineering, en disaster recovery over meerdere regio’s gekaderd door RTO, RPO en bedrijfscontinuïteit. De samenbindende boodschap is dat deze kwaliteiten het product zijn van bewust ontwerp en continu testen, niet van hoop.

Zie ook: hoofdstuk 3.3 (gedistribueerde systemen), hoofdstuk 9.1 (site reliability engineering) en hoofdstuk 9.2 (observeerbaarheid en monitoring).

Kernprincipes

Ontwerp voor uitschalen, niet opschalen. Verticaal schalen heeft een plafond en een single point of failure. Horizontaal schalen is hoe je grote, veerkrachtige schaal bereikt.
Statelessness is de enabler van horizontale schaal. Als elk verzoek naar elke instantie kan, kun je vrij capaciteit toevoegen en verwijderen.
Je kunt niet verbeteren wat je niet meet. Prestatiewerk wordt gedreven door profileren en belastingtesten tegen expliciete budgetten, nooit door gokken.
Alles faalt. Ontwerp ervoor. Neem aan dat componenten zullen falen en bouw zo dat het systeem hun falen overleeft.
Gracieuze degradatie verslaat hard falen. Een gedeeltelijk werkend systeem dat niet-essentiële functies afstoot is beter dan een totale storing.
Capaciteit wordt gepland, pieken worden opgevangen. Voorspel voorspelbare belasting. Gebruik autoscaling en marge voor de rest.
Herstelobjectieven zijn bedrijfsbeslissingen. RTO en RPO worden door het bedrijf gekozen tegen kosten en dan ernaartoe geëngineerd.
Test veerkracht bewust. Je weet pas dat een systeem veerkrachtig is wanneer je het met opzet hebt laten falen.

Aanbevelingen

Geef de voorkeur aan horizontaal schalen en ontwerp stateless services

Verticaal schalen (grotere machines) is eenvoudig en soms de juiste eerste stap, maar het raakt een hard plafond, wordt disproportioneel duur aan de top en laat een single point of failure achter. Horizontaal schalen (meer machines achter een load balancer) schaalt veel verder en verbetert beschikbaarheid, omdat het verlies van één instantie overleefbaar is. De voorwaarde is statelessness. Houd geen client- of verzoektoestand op de instantie. Duw haar naar een gedeelde store (database, cache, token). Stateless services kunnen vrij worden toegevoegd, verwijderd, vervangen en load-balanced, wat zowel autoscaling als rollende deployment mogelijk maakt. Waar toestand moet worden gepartitioneerd, shard op een sleutel die belasting gelijk verdeelt en gerelateerde data op dezelfde shard houdt.

Balanceer belasting, schaal automatisch en plan capaciteit

Zet een load balancer voor elke geschaalde laag om verkeer te verdelen en via gezondheidscontroles om ongezonde instanties heen te routeren. Configureer autoscaling om capaciteit toe te voegen wanneer een voorlopende indicator (CPU, wachtrijdiepte, latentie) een drempel overschrijdt en te verwijderen wanneer de belasting daalt. Stem schaalsnelheid en afkoeling af zodat je noch achterloopt op een piek noch heen en weer slingert. Autoscaling is geen vervanging voor capaciteitsplanning. Voorspel voor voorspelbare, bedrijfskritieke pieken (belastingdeadlines, inschrijfperiodes, verkoopevenementen) de belasting, reserveer of verwarm capaciteit vooraf en test de belasting van tevoren tot dat doel. Autoscaling alleen kan niet onmiddellijk reageren op een staprespons, en koude starts voegen latentie toe precies wanneer je het het minst kunt veroorloven. Houd altijd marge. Op 100% draaien laat geen ruimte om pieken of falen op te vangen.

Engineer prestaties tegen expliciete budgetten

Stel prestatiebudgetten vast (concrete doelen zoals p95-API-latentie onder 200 ms, pagina interactief onder 2 seconden of kosten per transactie onder een drempel) en dwing ze af in testen en monitoring zodat regressies de pipeline laten falen in plaats van gebruikers te bereiken. Stuur optimalisatie met meting. Profileer om het werkelijke knelpunt te vinden, dat zelden zit waar je denkt, en test de belasting om te vinden waar het systeem breekt en hoe het zich nabij die grens gedraagt. Richt je op het kritieke pad en de staart (p95/p99), want op schaal domineren staartlatenties de gebruikerservaring. Optimaliseer eerst het grootste knelpunt, meet opnieuw en stop wanneer je het budget haalt. Reeds adequate code overoptimaliseren is verspilde inspanning.

Bouw veerkrachtpatronen in en valideer met chaos engineering

Pas de veerkrachtpatronen uit gedistribueerde systemen toe: time-outs, begrensde herhalingen met backoff, circuit breakers (die snel falen wanneer een afhankelijkheid ongezond is) en bulkheads (die middelenpools isoleren zodat één falen de rest niet kan uitputten), plus gracieuze degradatie (niet-essentiële functies afstoten of vereenvoudigen onder stress: aanbevelingen uitschakelen, gecachete content serveren, niet-urgent werk in de wachtrij zetten) en load shedding (overtollige verzoeken afwijzen of afknijpen om de kern te beschermen in plaats van helemaal in te storten). Elimineer single points of failure door redundantie op elke laag. Valideer veerkracht dan met chaos engineering. Injecteer bewust falen (instanties doden, latentie toevoegen, een afhankelijkheid doorsnijden, een zone laten uitvallen) in gecontroleerde experimenten, beginnend in test en doorgroeiend naar game days in productie, om te bewijzen dat het systeem zich gedraagt zoals ontworpen. Veerkracht die nooit is getest is slechts een hypothese.

Plan multi-regio, disaster recovery en bedrijfscontinuïteit

Besluit de herstelobjectieven expliciet: RTO (Recovery Time Objective, hoe lang je mag uitvallen) en RPO (Recovery Point Objective, hoeveel data je je kunt veroorloven te verliezen). Dit zijn bedrijfsbeslissingen met directe kostengevolgen, en ze sturen de architectuur. Opties lopen uiteen in kosten en snelheid: back-up-en-herstel (goedkoopst, traagst), pilot light, warme stand-by en active-active multi-regio (duurst, bijna nul RTO/RPO). Kies de laag die de kritiek van elk systeem rechtvaardigt. Niet alles heeft active-active nodig. Repliceer data over regio’s in overeenstemming met de gekozen RPO, automatiseer failover en, boven alles, test de failover regelmatig. Niet-geteste disaster recovery faalt betrouwbaar wanneer ze eindelijk nodig is. Wikkel dit alles in een bedrijfscontinuïteitsplan dat mensen, communicatie en handmatige terugvalopties dekt, niet alleen technologie.

Afwegingen: voor- en nadelen

Keuze	Voordelen	Nadelen
Verticaal schalen	Eenvoudig, geen codewijziging, lage initiële inspanning	Hard plafond, duur aan de top, single point of failure
Horizontaal schalen	Bijna onbeperkte schaal, verbetert beschikbaarheid	Vraagt statelessness, load balancing, meer operatie
Autoscaling	Stemt kosten af op vraag, handelt variabele belasting af	Reageert met lag. Koude starts. Kan heen en weer slingeren bij verkeerde afstemming
Active-active multi-regio	Bijna nul RTO/RPO, overleeft regioverlies	Hoogste kosten en complexiteit, moeilijke dataconsistentie
Back-up-en-herstel DR	Goedkoopst, eenvoudigst	Lange RTO, groter dataverliesvenster

De centrale afweging is kosten tegenover zekerheid. Elke stap in schaalbaarheidsmarge, prestaties en herstelvermogen kost geld en complexiteit, en de opbrengsten zijn niet-lineair. Van 99,9% naar 99,99% beschikbaarheid gaan, of van een uur RTO naar seconden, kan de kosten vermenigvuldigen. De discipline is elke investering af te stemmen op de werkelijke kritiek van het systeem en de tolerantie van het bedrijf voor downtime en dataverlies, in plaats van reflexmatig alles naar de hoogste laag te engineeren. Een burgergericht betalingssysteem verdient active-active redundantie. Een intern rapportagehulpmiddel niet.

Vragen om met je team te bespreken

Toen je laatste ernstige incident gebeurde, welke van de drie (prestaties, schaalbaarheid, veerkracht) faalde er werkelijk, en heb je de juiste opgelost? Het hoofdstuk scheidt ze bewust: een systeem kan snel zijn en toch instorten onder belasting, schalen en toch omvallen wanneer één component sterft, of falen overleven terwijl het traag is. Teams stellen vaak een verkeerde diagnose, capaciteit toevoegend aan een veerkrachtprobleem of een systeem verhardend dat gewoon te weinig capaciteit had voor een piek. Loop de laatste twee ernstige incidenten door en noem welke kwaliteit brak en wat de reactie werkelijk verbeterde. Het onderscheid verandert de oplossing: statelessness en sharden voor schaal, redundantie en circuit breakers voor veerkracht, profileren en budgetten voor prestaties. De categorie goed krijgen is het verschil tussen geld uitgeven aan de remedie en aan een symptoom.
Laten prestatieregressies je pipeline falen, of bereiken ze gebruikers voordat iemand het merkt? Een prestatiebudget (p95-latentie, pagina-interactief-tijd, kosten per transactie) beschermt gebruikers alleen als het automatisch wordt afgedwongen, zodat een wijziging die het overschrijdt de build laat falen in plaats van op te leveren. In een groot team met veel bijdragers sluipt latentie binnen via duizend kleine commits, en zonder poort rot de staart langzaam weg tot een lancering hem blootlegt. Neem je huidige budgetten mee en controleer of ze in CI en monitoring zijn gekoppeld, en of ze p95 en p99 targeten in plaats van gemiddelden, want de staart is wat gebruikers op schaal voelen. Waar geen budget bestaat, is er een vaststellen de eerste zet. Handhaving is wat een goede bedoeling verandert in een eigenschap die teamgroei overleeft.
Wat gaat er onder stress als eerste, en heb je die volgorde ontworpen of ontdek je haar in de storing? Gracieuze degradatie en load shedding betekenen dat het systeem niet-essentieel werk opgeeft om de kern te beschermen, maar alleen als je vooraf hebt besloten wat essentieel is. Voor een burgergerichte service is die rangschikking vaak een beleidsbeslissing: het indienen van een belastingaangifte moet overleven ook als statusdashboards en historische opzoekingen uitvallen. Als niemand heeft gekozen, stoot het systeem af wat het eerst faalt, wat precies datgene kan zijn wat gebruikers het meest nodig hebben. Maak een lijst van je functies in prioriteitsvolgorde en bevestig dat de architectuur de laagprioritaire kan laten vallen (gecachete antwoorden, uitgeschakelde aanbevelingen, niet-urgent werk in de wachtrij) zonder het kritieke pad mee te nemen. Test het dan onder echte belasting, want niet-geteste degradatie is slechts een hoop.
Wat zijn voor je meest kritieke systeem de RTO en RPO, wie koos die getallen werkelijk, en wanneer bewees je voor het laatst dat je ze kunt halen? Recovery Time Objective (hoe lang je mag uitvallen) en Recovery Point Objective (hoeveel data je je kunt veroorloven te verliezen) zijn bedrijfsbeslissingen met directe kostengevolgen, maar in een groot team worden ze vaak verzonnen door wie het runbook schreef in plaats van bezeten door de mensen die verantwoordelijk zijn voor de service. De concurrerende trek is kosten tegenover zekerheid: RTO van een uur naar seconden of RPO van minuten naar nul verkleinen kan de infrastructuurrekening vermenigvuldigen, dus het juiste getal is datgene waarvoor het bedrijf werkelijk zal betalen, niet het meest indrukwekkende. Neem de gedocumenteerde objectieven mee, de datum van de laatste echte failovertest en de gemeten tijd en het dataverlies die die test opleverde, want een niet-getest objectief is een wens. In omgevingen van onderneming en overheid kunnen deze getallen bij wet, contract of SLA zijn vastgesteld, dus noem wie ze goedkeurt en of de laatste repetitie aan de verplichting voldeed of die stilletjes miste.
Vertrouw je voor je grootste voorspelbare piek op autoscaling dat in het moment reageert, of heb je de belasting voorspeld, vooraf gereserveerd en getest tot dat doel? Autoscaling reageert met lag en koude starts voegen latentie toe precies wanneer je het het minst kunt veroorloven, dus een bekende staprespons (een aangiftedeadline, een inschrijfperiode, een verkoopevenement) is precies het geval waarin reactief schalen faalt en bewuste capaciteitsplanning wint. De spanning is kosten: capaciteit voorverwarmen voor een piek betekent betalen voor marge die het grootste deel van het jaar ongebruikt blijft, en de verleiding is te hopen dat autoscaling het gratis dekt. Neem de piekgetallen van vorig jaar mee, de voorspelling van dit jaar met groei en de resultaten van een belastingtest gedraaid tot een veelvoud van die voorspelling in plaats van tot het gemiddelde verkeer van vandaag. Voeg voor een overheids- of ondernemingsservice die een wettelijk getimede piek tegemoet ziet het gevolg van fout doen toe, want een uitkeringsportaal of belastingsysteem dat op dag één bezwijkt wordt een publiek onderzoek, niet slechts een trage middag.
Heb je ooit bewust een component in productie laten falen, en komt het redundantieniveau van elk systeem werkelijk overeen met zijn kritiek en zijn kosten? Veerkracht die nooit is getest is een hypothese, en de niveaus die je kunt kopen lopen uiteen van goedkoop back-up-en-herstel via warme stand-by tot duur active-active multi-regio, dus de discipline is zekerheid besteden waar ze gerechtvaardigd is in plaats van alles te vergulden of niets te beschermen. De concurrerende overwegingen zijn schadezone en budget: chaosexperimenten moeten vangrails en een afbreekschakelaar hebben, en active-active voor een intern rapportagehulpmiddel is verspilling terwijl alleen back-up voor een betalingsplatform nalatigheid is. Neem een inventaris mee van je single points of failure, het redundantieniveau van elk kritiek systeem en bewijs van de laatste gecontroleerde falen-injectie en wat die onthulde. Koppel in portfolio’s van onderneming en overheid elk niveau aan een gedocumenteerde kritiekbeoordeling, zodat een auditor kan zien dat het geld het risico volgt en niemand de uitgaven voor het eerst tijdens de storing hoeft te verdedigen.

Sectorperspectief

Startup. Je kunt niet voorspellen of een lancering vijftig aanmeldingen brengt of vijftigduizend, dus koop schaal in plaats van haar te bouwen: draai stateless services achter een beheerde load balancer en laat het platform autoscalen op verzoeksnelheid. Stel één bescheiden prestatiebudget vast en kies beheerde datastores zodat een piek geen herarchitectuur om 2 uur ‘s nachts afdwingt. Sla multi-regio disaster recovery en chaosprogramma’s voorlopig over. Houd geteste back-ups en besteed je schaarse engineeringaandacht aan het product, niet aan redundantie die je verkeer nog niet rechtvaardigt.

Kleinbedrijf. Zonder betrouwbaarheidsspecialist en met een krap budget helt de keuze kopen tegenover bouwen sterk naar kopen: een beheerd platform of serverlessstack maakt schalen en failover de taak van de leverancier, en één goed gerunde regio is meestal genoeg. Formuleer veerkracht als een klein aantal concrete beloften die je kunt nakomen, zoals een nachtelijke back-up waaruit je werkelijk eenmaal hebt hersteld en een realistisch herstelvenster dat je aan klanten hebt gecommuniceerd. Vermijd betalen voor active-active of continu belastingtesten waarvoor je noch het verkeer noch het personeel hebt.

Grote onderneming. Het probleem is consistentie over veel teams: standaardiseer prestatiebudgetten afgedwongen in CI, een gedeelde bibliotheek met veerkrachtpatronen (time-outs, circuit breakers, bulkheads) en een gedocumenteerd redundantieniveau voor elk systeem gekoppeld aan zijn kritiek. Bewaar active-active multi-regio voor tier-één services, voer een chaosengineeringprogramma uit met vangrails en game days in productie en behandel capaciteitsplanning voor bekende pieken als geplande discipline in plaats van bijgedachte. Bestuur RTO en RPO centraal zodat elk kritiek systeem bezeten, geteste objectieven heeft die een auditor kan verifiëren.

Overheid. Belasting is vaak wettelijk getimed en beschikbaarheidsverplichtingen zijn wettelijk, dus capaciteitsplanning kan niet leunen op autoscaling dat in het moment reageert: voorspel de deadlinepiek, reserveer vooraf en test de belasting ruim boven de voorspelling. Aanbesteding moet RTO, RPO en een schema van geoefende failovers specificeren als contractuele eisen, niet beloften van leveranciers, en moet single-regio-afhankelijkheid voor kritieke services vermijden. Besluit vooraf welk pad wettelijk essentieel is (een aangifte indienen, een uitkering aanvragen) zodat degradatie eerst statusdashboards en opzoekingen afstoot, en wees transparant naar het publiek over storingen en herstel in plaats van te hopen dat niemand het merkt.

Voorbeelden

Startup. Een kleine startup die lanceert op Product Hunt kan niet voorspellen of ze vijftig of vijftigduizend aanmeldingen krijgt, dus houdt ze haar services stateless achter een beheerde load balancer en laat het platform autoscalen op verzoeksnelheid. Ze stelt één bescheiden prestatiebudget vast (pagina’s reageren binnen 300 ms op het 95e percentiel) en kiest een beheerde database zodat een verkeerspiek geen herarchitectuur om 2 uur ‘s nachts afdwingt. Wanneer de piek op lanceringsdag werkelijk komt, wordt de site een beetje trager in plaats van om te vallen, en besteedt het team de dag aan praten met nieuwe gebruikers in plaats van een storing te bestrijden.

Grote onderneming. Een streamingmediabedrijf draait stateless services over meerdere regio’s achter globale load balancing, autoscalend op verzoeksnelheid om de dagelijkse primetimegolf te volgen. Prestatiebudgetten poorten elke release op p99-opstartlatentie. Bij een regionale storing verschuift het verkeer automatisch naar gezonde regio’s, en niet-essentiële functies (gepersonaliseerde artwork, vernieuwing van aanbevelingen) degraderen als eerste om afspelen te beschermen. Het bedrijf draait continu chaosexperimenten in productie, routinematig instanties beëindigend en latentie injecterend, zodat echte falen niet van oefeningen te onderscheiden zijn en geen voor klanten zichtbare storing veroorzaken.

Overheid. Een belastingdienst weet dat haar aangiftesysteem elk jaar te maken krijgt met een enorme, wettelijk vastgelegde deadlinepiek. In plaats van op autoscaling te leunen dat in het moment reageert, voorspelt ze de piekbelasting uit eerdere jaren, reserveert ze weken vooraf capaciteit en test ze de belasting tot 150% van de voorspelling. De architectuur is stateless achter load balancers met een warme stand-by tweede regio. RTO en RPO zijn bij beleid vastgesteld (niet meer dan 15 minuten downtime en bijna nul dataverlies voor ingediende aangiftes), en failover wordt elk kwartaal geoefend. Onder extreme belasting worden niet-kritieke functies (statusdashboards, historische opzoekingen) als eerste afgestoten zodat het indienen van aangiftes, het wettelijk essentiële pad, beschikbaar blijft.

Zakelijke onderbouwing: motivatie, ROI en TCO

Schaalbaarheid, prestaties en veerkracht zijn klassieke gevallen waarin de kosten van falen die van voorkoming ver overtreffen. Maar de preventie is zichtbaar op de begroting en het falen alleen potentieel, daarom zijn ze chronisch onderfinancierd tot de eerste ramp. De invoeringskosten zijn echt: redundante infrastructuur, multi-regiocapaciteit, belastingtest- en chaostooling en de engineeringtijd om statelessness en veerkrachtpatronen te bouwen. De kosten van niet investeren zijn een opvallende storing tijdens piekvraag: omzetverlies per minuut voor handel, gemiste wettelijke verplichtingen en publiek onderzoek voor de overheid, boetes voor service-level agreements (SLA) en blijvende reputatieschade.

Formuleer de zaak voor het bestuur met getallen die het bedrijf al begrijpt. Schat de kosten van één uur downtime tijdens de piek (verloren transacties, boetes, herstel, reputatie) en vergelijk die met de jaarlijkse kosten van de redundantie en tests die het voorkomen. Voor kritieke systemen is de preventie bijna altijd een fractie van één groot incident. Koppel RTO en RPO aan expliciet geld: hoeveel omzet of hoeveel transacties per uur downtime, en hoeveel dataverlies wettelijk of commercieel te tolereren is. Presenteer prestaties als omzet- en tevredenheidshefboom, aangezien snellere systemen beter converteren en minder per transactie kosten, en presenteer veerkracht als verzekering waarvan de premie klein is ten opzichte van het gedekte verlies. Het sterkste argument is dat deze kwaliteiten goedkoop zijn om in te ontwerpen en ruïneus om achteraf in te bouwen na de storing die de kwestie afdwingt.

Antipatronen en valkuilen

Sticky sessions en toestand in de instantie. Sessietoestand op de server bewaren, wat vrij horizontaal schalen en veilig vervangen van instanties verhindert.
Autoscaling als capaciteitsplanning. Aannemen dat autoscaling een bekende staprespons zal opvangen waarop het te traag reageert.
Heet draaien zonder marge. Op bijna 100% bezetting werken, zonder ruimte om pieken of falen op te vangen.
Optimaliseren zonder te profileren. Code afstemmen die niet het knelpunt is terwijl het echte onaangeroerd blijft.
De staart negeren. Gemiddelde latentie rapporteren terwijl p99-gebruikers lijden. Gemiddelden verbergen de pijn op schaal.
Niet-geteste disaster recovery. Een DR-plan en back-ups die nooit zijn geoefend en zullen falen wanneer nodig.
Single points of failure. Eén load balancer, één databaseprimaire, één regio: een niet-redundant component dat alles neerhaalt.
Chaos engineering zonder vangrails. Falen injecteren zonder schadezonebeheersing of afbreekschakelaar, wat precies de storing veroorzaakt die je wilde voorkomen.

Volwassenheidsmodel

Niveau 1: Initiëren. Ad hoc en reactief. Enkele instantie of verticaal geschaald, met toestand op de server. Geen belastingtesten, geen prestatiebudgetten en geen disaster recovery buiten af en toe back-ups waaruit niemand ooit herstelde. Elk componentfalen veroorzaakt een volledige storing, en schaalproblemen worden in productie ontdekt.
Niveau 2: Ontwikkelen. Basispraktijken verschijnen maar verschillen van team tot team. Sommige services zijn horizontaal geschaald en stateless achter een load balancer, met basale autoscaling op een paar ervan. Belastingtesten gebeurt voor grote lanceringen maar niet routinematig, en back-ups bestaan terwijl disaster recovery is gedocumenteerd maar zelden geoefend. Wat het ene team goed doet is bij een ander nog niet begonnen.
Niveau 3: Standaardiseren. Praktijken zijn gedocumenteerd en organisatiebreed gehandhaafd. Capaciteit wordt gepland voor bekende pieken met marge, prestatiebudgetten worden in CI afgedwongen zodat regressies de build laten falen, en veerkrachtpatronen (time-outs, begrensde herhalingen, circuit breakers, bulkheads) plus gracieuze degradatie zijn de standaard. RTO en RPO zijn per systeem gedefinieerd, redundantieniveaus zijn naar kritiek toegewezen en disaster-recovery-failover wordt volgens een vast schema over teams getest.
Niveau 4: Beheersen. De kwaliteiten worden gemeten en gestuurd aan de hand van uitgangswaarden. Teams volgen p95- en p99-latentie, foutenbudgetten en bezetting en marge tegenover voorspelling, en alarmeren op overschrijdingen in plaats van ze bij de lancering te ontdekken. Geteste failovertijden worden vergeleken met de doel-RTO en -RPO, degradatie- en load-sheddingdrempels worden gevalideerd met statistieken en go/no-go-beslissingen over releases en capaciteit worden door data gedreven. Waar getallen van de uitgangswaarde afdrijven is de kloof zichtbaar en bezeten in plaats van verborgen achter gemiddelden.
Niveau 5: Orkestreren. Schaalbaarheid, prestaties en veerkracht worden continu verbeterd en zijn over de organisatie geïntegreerd. Active-active multi-regio wordt gebruikt overal waar kritiek het rechtvaardigt, chaos engineering draait continu inclusief game days in productie en capaciteitsvoorspelling voedt direct planning en inkoop. Veerkracht wordt doorlopend gevalideerd, herstelobjectieven worden consistent gehaald en bewezen en de architectuur past zich aan naarmate belastingpatronen en het risicobeeld verschuiven, gekoppeld aan bedrijfscontinuïteits- en risicoplanning.

Ideeën voor discussie

Welke van je services houden nog toestand op de instantie, en wat belet je ze stateless te maken?
Wat zijn voor je meest kritieke systeem de RTO en RPO, wie stelde ze vast en wanneer bewees je voor het laatst dat je ze kunt halen?
Beschermt autoscaling je werkelijk tegen je grootste bekende piek, of reken je erop dat het iets doet wat het niet kan?
Waar is je resterende single point of failure, en wat is het plan om het te verwijderen?
Meet en budgetteer je p99-latentie, of verberg je je achter gemiddelden?
Heb je ooit bewust een component in productie laten falen? Zo niet, hoe weet je dat je veerkracht werkt?

Belangrijkste inzichten

Onderscheid prestaties, schaalbaarheid en veerkracht. Een groot systeem heeft alle drie nodig, vanaf het begin ingebouwd.
Horizontaal schalen en stateless services zijn het fundament van schaal, beschikbaarheid en veilige deployment.
Combineer autoscaling met echte capaciteitsplanning en marge voor voorspelbare, bedrijfskritieke pieken.
Stuur prestaties met profileren en belastingtesten tegen expliciete budgetten, gericht op het kritieke pad en de staart.
Bouw veerkracht met time-outs, circuit breakers, bulkheads, gracieuze degradatie en redundantie, en valideer haar dan met chaos engineering.
Stel RTO en RPO vast als bedrijfsbeslissingen, engineer DR naar de kritiek van elk systeem en test failover regelmatig.

Referenties en verder lezen

Martin Kleppmann, Designing Data-Intensive Applications
Michael Nygard, Release It!: Design and Deploy Production-Ready Software
Betsy Beyer et al. (Google), Site Reliability Engineering and The Site Reliability Workbook
Casey Rosenthal and Nora Jones, Chaos Engineering
Brendan Gregg, Systems Performance: Enterprise and the Cloud
John Allspaw, The Art of Capacity Planning
Ilya Grigorik, High Performance Browser Networking
Nassim Nicholas Taleb, Antifragile