9.6 Chaos engineering og robusthedstest

Overblik og motivation

Chaos engineering er den disciplinerede praksis at køre eksperimenter på et system for at opbygge tillid til dets evne til at modstå turbulente forhold i produktion. Navnet lyder hensynsløst, og det er det første, I skal aflære. Chaos engineering er ikke at ødelægge ting tilfældigt og håbe at lære noget. Det er det modsatte: en kontrolleret, hypotesedrevet metode til at injicere realistiske fejl, så I opdager svagheder, før jeres brugere gør. I ved allerede, at jeres system vil møde fejl, fordi ethvert reelt system gør det. Det eneste spørgsmål er, om I møder de fejl en tirsdag eftermiddag med en tilbagerulning klar, eller klokken tre om natten i jeres travleste time uden anelse om, hvad der sker.

For store teams har det betydning, fordi kompleksiteten er vokset fra enhvers evne til at ræsonnere om den ved inspektion. En moderne tjeneste er et net af dusinvis eller hundredvis af komponenter, hver med sine egne timeouts, genforsøg, caches og fejlformer, og samspillet mellem dem producerer emergent adfærd, ingen arkitekturdiagram forudsiger. I kan gennemgå koden, tegne boksene og stadig blive overrumplet, når en langsom afhængighed udløser en genforsøgsstorm, der tager en tjeneste tre hop væk ned. Chaos engineering er, hvordan I afprøver de samspil empirisk, så jeres robusthed er noget, I har verificeret, frem for noget, I antager.

Virksomheds- og offentlige sammenhænge hæver indsatsen og, i stigende grad, mandatet. Finansielle tilsynsmyndigheder forventer nu, at virksomheder tester driftsrobusthed mod alvorlige men plausible scenarier og påviser, at de kan holde kritiske tjenester kørende gennem forstyrrelse. Offentlige organer kører øvelser i kontinuitet i driften, så væsentlige offentlige tjenester overlever udfald, katastrofer og cyberangreb. I begge verdener er “vi tror, det holder” ikke et acceptabelt svar til en revisor eller en borger. Chaos engineering giver jer dokumentation. Dette kapitel bygger på site reliability engineering (kapitel 9.1) og robusthedsmønstrene i kapitel 3.5, og det hænger tæt sammen med hændelseshåndtering (kapitel 9.3) og katastrofeberedskab (kapitel 9.5).

Grundprincipper

Byg tillid, skab ikke kaos. Målet er verificeret robusthed, ikke spektakel. Hvert eksperiment besvarer et specifikt spørgsmål om, hvordan systemet opfører sig under belastning.
Definér steady state først. I kan ikke opdage et problem uden en klar, målbar definition af, hvordan “sundt” ser ud.
Form en hypotese. Angiv, hvad I forventer, der sker, før I injicerer en fejl. En overraskelse er et fund; fraværet af en er også et fund.
Minimér og afgræns sprængradius. Begynd småt, beskyt rigtige brugere, og udvid kun omfanget, efterhånden som tilliden vokser.
Foretræk produktion, omhyggeligt. Fejl opfører sig anderledes under reel trafik, reelle data og reel skala. Optjen retten til at teste der.
Automatisér mod kontinuerlig verifikation. En svaghed, I retter én gang, kan regrediere. Robusthed, der testes kontinuerligt, forbliver sand.
Fejl er en lærer, ikke en dom. Fund forbedrer systemet; de er aldrig en grund til at give den skyld, der kørte eksperimentet.

Anbefalinger

Etablér forudsætningerne, før I injicerer en eneste fejl

Chaos engineering er en kraftmultiplikator for et modent system og et ansvar for et umodent. Før I begynder, skal tre ting være på plads. For det første observerbarhed, altså de målinger, logs og spor, der lader jer se, hvad jeres system gør udefra, fordi et eksperiment, I ikke kan observere, lærer jer intet. For det andet servicemål eller en tilsvarende definition af steady-state-sundhed (kapitel 9.1), så I i realtid kan skelne et vellykket eksperiment fra et skadeligt. For det tredje en hurtig og troværdig tilbagerulnings- eller afbrydelsessti, så I i det øjeblik, et eksperiment truer rigtige brugere, kan stoppe det og genoprette normal service på sekunder. Hvis I ikke kan måle jeres system, definere dets sunde tilstand og trække det tilbage fra kanten, så kør ikke chaos-eksperimenter endnu. Byg først de kapabiliteter. De betaler sig uanset.

Definér steady state, og form en reel hypotese

Hvert eksperiment begynder med at skrive ned, hvordan normalt ser ud i målbare termer: forespørgselssuccesrate over 99,9 procent, kasselatens under 400 millisekunder ved 95. percentil, kødybde under en tærskel. Det er jeres steady-state-definition, og den bør afspejle brugersynlig sundhed, ikke intern rørlægning. Angiv så en hypotese i almindeligt sprog: “Hvis vi tilføjer 300 millisekunders latens til anbefalingstjenesten, vil produktsiden stadig gengives inden for sit latensbudget, fordi siden behandler anbefalinger som valgfrie og timeouter efter 200 millisekunder.” Nu har I en falsificerbar påstand. Når I kører eksperimentet, sker der en af to gode ting. Enten opfører systemet sig som forudsagt, og jeres tillid er optjent, eller også gør det ikke, og I har fundet en reel svaghed billigt, på jeres vilkår, med ingeniører der iagttager.

Injicér realistiske fejl, ikke vilkårlige

De fejl, I indfører, bør afspejle de fejl, jeres system faktisk oplever. Fejlinjektion, den bevidste indførelse af fejl for at teste, hvordan et system reagerer, giver jer en menu hentet fra reelle produktionshændelser. Injicér latens for at simulere en langsom afhængighed eller et mættet netværkslink. Injicér fejl, returnér HTTP 500’er eller afviste forbindelser, for at simulere en fejlende nedstrøms tjeneste. Injicér ressourceudmattelse ved at forbruge CPU, hukommelse, disk eller filbeskrivere, for at se hvordan systemet nedgraderes under pres. Injicér afhængighedsfejl ved at gøre en hel database, cache, kø eller tredjeparts-API uopnåelig. I et distribueret system, hvor komponenter kører på separate maskiner og kommunikerer over et upålideligt netværk, er det de fejl, der dominerer reelle udfald. Latens og delvis fejl, ikke rene nedbrud, er det, der ødelægger ting i praksis, så vægt jeres eksperimenter mod den rodede midte.

Verificér, at jeres robusthedsmekanismer faktisk virker

Det er her, chaos engineering tjener sit brød. Jeres system er fuldt af mekanismer, der skal beskytte jer: timeouts, der forhindrer en kalder i at vente for evigt, genforsøg, der dækker over forbigående hik, kredsløbsafbrydere, der holder op med at hamre på en fejlende afhængighed, og failover, der skifter til en standby, når primæren dør. Disse mønstre, dækket i kapitel 3.5, er forskellen mellem et afgrænset problem og et kaskadeudfald. Problemet er, at de sjældent testes under de forhold, de findes for. En timeout sat til 30 sekunder, når kalderens egen deadline er 2 sekunder, gør intet. Et genforsøg uden backoff forvandler én kæmpende tjeneste til en stormløbende flok. En kredsløbsafbryder, der aldrig blev udøvet, kan være fejlkonfigureret og aldrig udløse, eller udløse konstant. Chaos-eksperimenter er, hvordan I bekræfter, at hver af disse opfører sig som designet, når den fejl, de værner mod, faktisk ankommer. Antag, at hver uafprøvet sikkerhedsmekanisme er ødelagt, til et eksperiment beviser andet.

Begynd med game days, før I automatiserer

Begynd ikke med en automatiseret platform, der injicerer fejl kontinuerligt. Begynd med en game day: en planlagt, praktisk øvelse, hvor et team samles, vælger et scenarie, injicerer en fejl i et kontrolleret miljø og iagttager sammen. Før selv det bringer en tabletop-øvelse, hvor I taler et scenarie igennem på en tavle uden at røre systemet, huller i runbooks, alarmering og ejerskab frem til næsten ingen risiko. Game days er jeres indkørselsrampe. De opbygger muskelen til at danne hypoteser, afgrænse sprængradius og læse systemet under belastning, og de opbygger den tillid hos ledelsen og nabotems, I får brug for, før nogen lader jer køre eksperimenter i produktion. De styrker også hændelsesrespons direkte, fordi færdighederne er de samme, jeres vagthavende ingeniører bruger under en reel hændelse (kapitel 9.3). Kør jeres første game days i staging, så i produktion i stille timer med en lille sprængradius, og udvid så.

Afgræns sprængradius bevidst

Den vigtigste enkeltsikkerhedspraksis er at begrænse den potentielle skade ved hvert eksperiment. Begynd med det mindste omfang, der kan lære jer noget: én instans, én procent af trafikken, én ikke-kritisk afhængighed, én tilgængelighedszone. Definér afbrydelsesbetingelserne, før I begynder, kobl dem til jeres steady-state-målinger, og gør det at stoppe eksperimentet til en enkelt handling, enhver tilskuer kan udløse. Foretræk at køre i arbejdstiden, når teamet er årvågent og bemandet, ikke natten over, hvor en overraskelse bliver en hændelse uden nogen til at iagttage. Udvid kun sprængradius, når mindre eksperimenter er kørt rent, og jeres tillid reelt er højere. Afgrænsningsdisciplinen er det, der skiller chaos engineering fra et udfald, I selv forårsagede.

Vokse mod kontinuerlig, automatiseret robusthedsverifikation

Lejlighedsvise game days finder svagheder, men systemer ændrer sig hver dag, og en rettelse fra sidste kvartal kan stille regrediere. Den modne sluttilstand er kontinuerlig verifikation: et kurateret sæt robusthedseksperimenter, der kører automatisk, i en pipeline eller efter en tidsplan, så en regression i en timeout, en genforsøgspolitik eller en failover-sti fanges inden for dage frem for under det næste reelle udfald. Det er her, værktøjer som Netflix’ Chaos Monkey, der tilfældigt afslutter instanser i produktion for at tvinge ingeniører til at bygge tjenester, der tåler tab af instanser, fortjente deres omdømme. Automatisér kun de eksperimenter, I allerede forstår og stoler på fra manuelle kørsler. Kontinuerligt kaos oven på et umodent system er en måde at generere hændelser på, ikke tillid.

Forbind eksperimenter til katastrofeberedskab og hændelseslæring

Chaos engineering lever ikke alene. De større, sjældnere scenarier, tab af en hel region, failover af en database, genoprettelse fra backup, hører hjemme i katastrofeberedskabstest (kapitel 9.5), og en game day er ofte det bedste redskab til at udøve de planer i stedet for at lade dem rådne som uafprøvede dokumenter. På den anden side bør hvert eksperiment, der bringer en svaghed frem, fodre den samme læringsløkke som en reel hændelse (kapitel 9.3): en skyldfri gennemgang, en sporet rettelse og et opfølgende eksperiment, der bekræfter, at rettelsen holder. Når chaos-fund, katastrofeberedskabsøvelser og hændelsesretrospektiver alle flyder ind i ét efterslæb af robusthedsarbejde, får I akkumulerende afkast i stedet for spredte engangsøvelser.

Afvejninger: fordele og ulemper

Beslutning	Fordele	Ulemper
Test i produktion	Reel trafik, data og skala; fund er sande	Risiko for brugere hvis afgrænsning fejler; kræver modenhed
Test kun i staging	Sikkert, lav indsats, let at starte	Misser virkelighedens adfærd; falsk tryghed
Manuelle game days	Opbygger færdigheder og tillid; lav værktøjsomkostning	Sjældne; fund kan regrediere uset
Kontinuerligt automatiseret kaos	Fanger regressioner hurtigt; skalerer	Kræver modent værktøj og observerbarhed først
Bred sprængradius	Afslører store systemiske svagheder	Høj risiko; en fejl bliver en hændelse
Smal sprængradius	Sikker og kontrollerbar	Kan overse emergente fejl på tværs af tjenester

Den centrale spænding er mellem realisme og sikkerhed. De fund, I mest ønsker, kommer fra produktion, fordi det er det eneste sted, jeres system møder reel trafik, reelle data og reel skala, og alligevel er produktion netop, hvor et fejlslagent eksperiment skader brugere. Løsningen er ikke at vælge side. Den er at optjene vejen mod produktion gradvist: bevis jeres forudsætninger, øv i staging, kør så små, velafgrænsede eksperimenter i produktion med afbrydelsesbetingelser koblet til levende målinger, og udvid kun omfanget, efterhånden som dokumentation ophobes. Den anden tilbagevendende spænding, manuel versus automatiseret, løses på samme måde over tid. Begynd manuelt for at opbygge forståelse og tillid, og automatisér så de eksperimenter, I er kommet til at stole på, så robusthed, I verificerede én gang, forbliver verificeret.

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

Er vi faktisk klar til at køre chaos-eksperimenter, og hvordan ville vi vide det? Det er fristende at begynde at injicere fejl, fordi det lyder sofistikeret, men chaos engineering på et uobserverbart system uden klar sundhedsdefinition og uden hurtig tilbagerulning er blot selvforskyldt nedetid. Tag ærlig dokumentation med til denne drøftelse: kan I se forespørgselssuccesrater og latens i realtid, har I en aftalt definition af steady state, og kan I afbryde et eksperiment og genoprette på sekunder? For et stort team er svaret ofte forskelligt pr. tjeneste, så det nyttige output er en parathedsoverligger, en tjeneste skal klare for at være berettiget til eksperimenter. I regulerede sammenhænge fungerer den parathedsoverligger også som en kontrol, I kan vise en revisor. Hvis det ærlige svar er, at I ikke er klar, er det mest værdifulde chaos-arbejde, I kan gøre dette kvartal, at bygge de observerbarheds- og tilbagerulningskapabiliteter, der gør jer klar.
Hvad er vores sprængradiuspolitik, og hvem har autoriteten til at stoppe et eksperiment? Hvert chaos-eksperiment bærer en vis risiko for rigtige brugere, og forskellen mellem et værdifuldt fund og en hændelse, I selv forårsagede, er, hvor stramt I afgrænsede det. Tal de konkrete grænser igennem: hvilken brøkdel af trafikken, hvor mange instanser, hvilke miljøer, hvilke tidspunkter på dagen, og hvilke målingstærskler der automatisk afbryder kørslen. Afgør på forhånd, hvem der iagttager hvert eksperiment, og hvem der holder den kill switch med én handling, fordi et eksperiment, ingen hurtigt kan stoppe, ikke er afgrænset. For en stor organisation er den politik, hvad lader mange teams eksperimentere uden, at nogen af dem ved et uheld tager en fælles afhængighed ned. Svaret bør skrives ned, aftales med de teams, hvis tjenester I måske påvirker, og behandles som en forudsætning for at køre noget i produktion.
Hvilke robusthedsmekanismer tror vi beskytter os, og har vi nogensinde faktisk testet dem? De fleste systemer er fulde af timeouts, genforsøg, kredsløbsafbrydere, caches og failover-stier, der blev konfigureret én gang og aldrig udøvet under den fejl, de findes for. Lav en liste over de mekanismer, I regner med, og spørg så for hver, hvornår den sidst blev verificeret til at virke under en reel injiceret fejl. Det modstridende hensyn er tid: at verificere hver mekanisme koster ingeniørindsats, og der er altid en funktionsdeadline. Tag modbeviset mod den indvending med, nemlig omkostningen ved et tidligere udfald, som en fungerende kredsløbsafbryder eller en korrekt timeout ville have afgrænset. Svaret bør forvandle en trøstende liste over antagne beskyttelser til et prioriteret efterslæb af eksperimenter, begyndende med de mekanismer, hvis svigt ville gøre mest ondt.
Hvad skal være sandt, før vi kører et eksperiment i produktion frem for staging, og hvilke tjenester har optjent den ret i dag? De fund, I mest ønsker, kommer fra produktion, fordi det er det eneste sted, jeres system møder reel trafik, reelle data og reel skala, og alligevel er produktion også det ene sted, hvor et fejlslagent eksperiment skader faktiske brugere. For et stort team er den ærlige virkelighed, at forskellige tjenester sidder på forskellige parathedsniveauer, så en bred “ingen produktionskaos”-regel spilder jeres bedste læring, mens et bredt “ja” inviterer til selvforskyldte udfald. Tag dokumentation pr. tjeneste med: kvaliteten af dens observerbarhed, om steady state er defineret og kan alarmeres på, hvor hurtig tilbagerulning er, og rekorden af rene stagingeksperimenter, der ville retfærdiggøre at forfremme den. I virksomheds- og offentlige sammenhænge så bind produktionsporten til en dokumenteret kontrol, der navngiver, hvem der godkender forfremmelsen, og hvilke afbrydelsesbetingelser der er koblet til levende målinger, så revisoren ser en bevidst, dokumenteret beslutning frem for et team, der improviserer med rigtige brugere.
Når et chaos-eksperiment bringer en svaghed frem, hvor går det fund hen, og hvordan forhindrer vi, at det rådner urørt? Et program, der opdager svagheder, men aldrig retter dem, er værre end intet program, fordi det brænder indsats, eroderer tillid og lærer folk, at eksperimenter er teater. Det modstridende pres er altid funktionskøreplanen: en robusthedsrettelse føles sjældent så presserende som den næste release, til det udfald, den ville have forebygget, faktisk ankommer. Tag den nuværende tilstand af jeres robusthedsefterslæb med til drøftelsen: hvor mange chaos-fund er åbne, hvor gammelt er det ældste, og om fund fra eksperimenter, katastrofeberedskabsøvelser og hændelsesretrospektiver flyder ind i én fælles kø eller spredes på tværs af teams. Aftal, hvem der ejer hver rettelse, og hvem der kører det opfølgende eksperiment, der bekræfter, at den holder. For en stor eller reguleret organisation så navngiv det forum, der gennemgår efterslæbet efter en fast kadence og har autoriteten til at prioritere en robusthedsrettelse over en funktion, fordi et fund, ingen er ansvarlig for at lukke, er en risiko, I blot har dokumenteret frem for fjernet.
Er vi klar til at automatisere nogen af vores eksperimenter til kontinuerlig verifikation, og hvilke specifikt? Lejlighedsvise game days finder svagheder, men systemer ændrer sig dagligt, og en rettelse fra sidste kvartal kan stille regrediere, så den modne sluttilstand er et kurateret sæt eksperimenter, der kører automatisk og fanger regressioner inden for dage. Faren er at automatisere for tidligt: kontinuerligt kaos lagt oven på et umodent system med svag observerbarhed genererer hændelser hurtigere end indsigt. Tag listen over eksperimenter, I har kørt manuelt nok gange til at stole fuldt på, de sprængradiuskontroller og afbrydelsesbetingelser, der ville styre dem uden opsyn, og den overvågning, der ville fange en automatiseret kørsel, der går galt klokken tre om natten, når ingen iagttager, med. For en stor virksomhed eller et stort offentligt agentur så vej den ekstra granskning, som fejlinjektion uden opsyn inviterer til: ændringsstyringsgodkendelse, det revisionsspor hver automatiseret kørsel skal efterlade, og den klare ansvarlighed for et planlagt eksperiment, der falder sammen med en reel hændelse. Automatisér kun de eksperimenter, I allerede forstår, og hold resten manuelle, til de optjener den samme tillid.

Sektorperspektiv

Startup. Fart og overlevelse dominerer, så brug intet på en chaos-platform. Kør en enkelt halvanden-times game day i staging mod den ene afhængighed, hvis svigt reelt ville dræbe jer, som regel betalinger, autentificering eller jeres primære datalager. Injicér fejlen med en grov proxy eller en dræbt proces, iagttag hvad der går i stykker, ret den manglende timeout eller fallback, og gå videre. Hele pointen er at fange det åbenlyse selvforskyldte udfald billigt, før en kunde gør, ikke at bygge en disciplin, I ikke kan bemande.

Lille virksomhed. Uden en pålidelighedsspecialist og med et stramt budget så behandl robusthedstest som en periodisk, bevidst øvelse frem for et program, I bemander. Støt jer til de fejlinjektionsfunktioner, jeres cloududbyder eller administrerede værktøj allerede indeholder, i stedet for at købe en dedikeret platform, og fokusér eksperimenter på den håndfuld afhængigheder, en kunde ville bemærke. Ram det ind som forsikring: en eftermiddag brugt på at bekræfte, at jeres backups genoprettes, og at jeres kasse nedgraderes elegant, er langt billigere end det udfald, der beviser, at de ikke gør.

Stor virksomhed. Problemet er at koordinere mange teams mod fælles afhængigheder i skala, så standardisér parathedsoverliggeren, sprængradiuspolitikken og afbrydelsesbetingelsernes kobling, som hvert team skal klare, før det kører i produktion. Rut chaos-fund, katastrofeberedskabsøvelser og hændelsesretrospektiver ind i ét robusthedsefterslæb med klart ejerskab, og brug kvartalsvise game days plus et kurateret sæt automatiserede eksperimenter til at opfylde driftsrobusthedsforventninger med dokumentation. Styr, hvem der må påvirke en fælles tjeneste, så ingen enkeltstående teams eksperiment tager infrastruktur ned, andre afhænger af.

Offentlig sektor. Indkøbsregler, åbenhed og offentlig ansvarlighed former arbejdet. Mandater om kontinuitet i driften kræver ofte regelmæssige øvelser alligevel, så kør dem som levende game days, der producerer ægte fund, frem for en mappe ingen åbner, og hold et revisionsspor over hvert eksperiment, dets sprængradius og dets udfald. Hvor fejlinjektionsværktøj indkøbes, så kræv, at det passer inden for sikkerheds- og databehandlingsregler, og forbehold produktionseksperimenter på borgervendte tjenester til tæt afgrænsede, godkendte vinduer. Den dokumentation, et chaos-program producerer, er præcis, hvad et tilsynsorgan eller en revisor forventer at se.

Eksempler

Startup. Et startup på femten personer kører en webapp på en håndfuld tjenester og afhænger af en tredjeparts betalings-API. Ingen har tid til en chaos-platform, så teamet kører en halvanden-times game day i staging. De danner en hypotese: hvis betalings-API’en begynder at returnere fejl, bør kassen vise en klar genforsøgsbesked og sætte ordren i kø frem for at crashe. De injicerer 500-svar med en simpel proxy og opdager, at frontenden hænger uendeligt, fordi klientkaldet ikke har nogen timeout. De tilføjer en timeout og en venlig fallback, kører eksperimentet igen for at bekræfte rettelsen og skriver en note på to afsnit i et fælles dokument. Samlet omkostning: en eftermiddag og en meget reel fejl fanget, før en kunde ramte den.

Stor virksomhed. En global bank skal påvise driftsrobusthed over for tilsynsmyndigheder mod alvorlige men plausible scenarier. Dens pålidelighedsteam kører et program af kvartalsvise game days plus et sæt automatiserede eksperimenter i produktion. Et scenarie fejler den primære transaktionsdatabase over til dens standby i et lavtrafikvindue, med en strengt afgrænset sprængradius og afbrydelsesbetingelser knyttet til transaktionssuccesraten. Den første kørsel afslører, at en nedstrøms afstemningstjeneste har en genforsøgspolitik uden backoff, hvilket producerer en belastningstop, der forsinker genoprettelsen langt ud over genoprettelsestidsmålet i katastrofeberedskabsplanen (kapitel 9.5). Fundet går i det samme efterslæb som hændelsesretrospektiver, genforsøgspolitikken rettes med eksponentiel backoff, og et opfølgende eksperiment bekræfter, at failover nu fuldføres inden for målet. Hele øvelsen bliver dokumentation for tilsynsmyndigheden.

Offentlig sektor. Et nationalt agentur, der driver et borgervendt ydelsesportal, skal opretholde kontinuitet i driften gennem forstyrrelser. I stedet for at behandle sin kontinuitetsplan som en mappe, ingen åbner, kører agenturet en årlig kontinuitetsøvelse som en levende game day. Teamet simulerer tabet af et primært datacenter og gennemgår failover til et sekundært site, mens det separat injicerer latens i en identitetsverifikationsafhængighed for at se, om portalen nedgraderes elegant. De lærer, at et uafprøvet overvågningshul efterlod vagtholdet blindt for, at identitetstjenesten blev langsommere, så alarmer udløstes sent. Agenturet lukker observerbarhedshullet, opdaterer sine runbooks og planlægger den samme øvelse til næste år og forvandler et compliancekrav til ægte, testet robusthed for en kritisk offentlig tjeneste.

Business case: motivation, ROI og TCO

Afkastet af chaos engineering kommer fra udfald, der aldrig sker. Et enkelt større udfald for en stor tjeneste kan koste alt fra titusinder til millioner i tabt omsætning, regulatoriske bøder, afhjælpningsarbejdskraft og omdømmeskade, der hænger ved længe efter, servicen er genoprettet. Chaos-eksperimenter konverterer de uforudsigelige, dyre overraskelser til billige, planlagte fund, I retter på jeres egen tidslinje med ingeniører, der iagttager, og en tilbagerulning klar. At finde en ødelagt timeout under en kontrolleret game day koster en eftermiddag. At finde den under en reel hændelse koster et udfald, en alle-mand-på-dæk-panik og jeres brugeres tillid. Regnestykket favoriserer game dayen med bred margin.

Den samlede ejeromkostning er beskeden, når forudsætningerne er på plads, fordi chaos engineering genbruger de observerbarheds-, alarmerings- og tilbagerulningsinvesteringer, I alligevel har brug for. De ærlige omkostninger er ingeniørtiden til at køre eksperimenter, noget værktøj til at injicere fejl og afgrænse sprængradius og det kulturelle arbejde med at få ledelsen komfortabel med bevidst at indføre fejl. Det sidste er den reelle barriere, og vejen igennem er at begynde i staging, vise fund, der kobles til penge eller risiko, og lade nogle få afgrænsede produktionseksperimenter opbygge tillid. For at fremlægge sagen for ledelsen så ram chaos engineering ind som forsikring, I kan måle: præsentér omkostningen ved nylige hændelser, vis hvilke af dem et robusthedseksperiment ville have fanget, og foreslå et program, der starter småt og kun udvides, efterhånden som det beviser sig selv. I regulerede og offentlige sammenhænge så tilføj complianceaspektet, fordi driftsrobusthedstest og kontinuitetsøvelser i stigende grad forventes, og et chaos-program er, hvordan I opfylder den forventning med dokumentation frem for papirarbejde.

Anti-mønstre og faldgruber

Kaos uden observerbarhed. At injicere fejl i et system, I ikke kan se, er gætværk med ekstra trin; I vil forårsage skade og lære intet.
Ingen steady-state-definition. Uden et aftalt mål for sundhed kan I ikke se, om et eksperiment afslørede et problem eller forårsagede et.
Ingen hypotese. At ødelægge ting tilfældigt er ikke chaos engineering; det er hærværk med et fint navn og ingen fund.
Uafgrænset sprængradius. At springe de små, sikre eksperimenter over og gå direkte til fejl i hele produktionen forvandler en test til et selvforskyldt udfald.
Ingen afbrydelsessti. Et eksperiment, I ikke kan stoppe øjeblikkeligt, er ikke et eksperiment; det er en hændelse, der venter på en udløser.
At automatisere for tidligt. Kontinuerligt kaos oven på et umodent system genererer hændelser hurtigere end indsigt.
Fund, der ikke fører nogen vegne. At opdage en svaghed og aldrig rette den spilder øvelsen og eroderer tilliden til hele programmet.
Skyld efter et dårligt eksperiment. At straffe den ingeniør, der kørte et eksperiment, der afslørede en reel fejl, garanterer, at ingen kører det næste.

Modenhedsmodel

Niveau 1, Opstart: Robusthed antages, ikke testes. Fejl opdages i produktion under reelle hændelser. Der er ingen game days, ingen fejlinjektion og ofte ingen klar definition af, hvordan sundt ser ud. Teamet lærer om sine svagheder den hårde vej, ét udfald ad gangen.
Niveau 2, Udvikling: Teamet kører lejlighedsvise game days, som regel i staging, med et defineret scenarie og en hypotese. Steady state er defineret for nogle få nøgletjenester, og basal observerbarhed findes. Fund indfanges, og nogle rettes, men praksis er inkonsistent på tværs af teams og afhænger af individuelle ildsjæle frem for en etableret metode.
Niveau 3, Standardisering: Chaos-eksperimenter er en dokumenteret praksis i hele organisationen med håndhævede sprængradiuspolitikker, afbrydelsesbetingelser og parathedskriterier, en tjeneste skal klare, før den eksperimenterer i produktion. Eksperimenter kører i produktion under kontrollerede forhold, fund flyder ind i et fælles robusthedsefterslæb sammen med hændelsesretrospektiver og katastrofeberedskabsøvelser, og robusthedsmekanismer verificeres frem for antages. Hvert team følger den samme håndbog.
Niveau 4, Styring: Programmet måles og styres med data mod baselines. I følger robusthedsdækning (hvilke kritiske tjenester og hvilke mekanismer, såsom timeouts, genforsøg, kredsløbsafbrydere og failover, der er verificeret under en reel injiceret fejl og hvor for nylig), raten hvormed eksperimenter bringer fund frem, gennemsnitlig tid til at lukke et robusthedsfund og hvor ofte en tidligere verificeret mekanisme regrederer. Disse målinger gennemgås efter en fast kadence, produktionsforfremmelse lukkes på dokumentation frem for mening, og eksperimenter prioriteres efter den målte risiko ved de mekanismer, der stadig er uverificerede.
Niveau 5, Orkestrering: Et kurateret sæt eksperimenter kører kontinuerligt og automatisk og fanger regressioner inden for dage, og programmet tilpasser sig, efterhånden som systemet og dets risikobillede ændrer sig. Chaos engineering er integreret på tværs af organisationen med leveringspipelines, hændelseslæring og katastrofeberedskabstest, så nye tjenester arver robusthedsverifikation som standard. Robusthed er en kontinuerligt verificeret egenskab ved systemet, og ledelsen behandler programmet som standard risikostyring, der forfines på dokumentation, frem for et særligt initiativ.

Idéer til drøftelse

Hvordan afgør I, hvilken tjeneste i jeres organisation der først optjener retten til at køre chaos-eksperimenter i produktion, og hvad skal være sandt, før den gør?
Når et chaos-eksperiment bringer en alvorlig svaghed frem, hvem ejer rettelsen, og hvordan forhindrer I, at det fund sidder urørt i et efterslæb?
Hvor går linjen mellem et chaos-eksperiment, en katastrofeberedskabsøvelse og en game day i jeres kontekst, og betyder skellet overhovedet noget for, hvordan I planlægger dem?
Hvordan ville I overbevise en skeptisk leder om, at bevidst at injicere fejl i produktion er sikrere end status quo med at vente på reelle udfald?
Hvad er det mindste, mest værdifulde første eksperiment, jeres team kunne køre næste måned, og hvad ville forhindre jer i at køre det?
Hvordan bør robusthedstest adskille sig mellem en borgervendt offentlig tjeneste med et kontinuitetsmandat og et internt virksomhedsværktøj med en lille brugerbase?

Vigtigste pointer

Chaos engineering er disciplineret, hypotesedrevet eksperimentering for at opbygge tillid til robusthed, ikke tilfældig ødelæggelse.
Etablér observerbarhed, en steady-state-definition og en hurtig tilbagerulning, før I injicerer en eneste fejl.
Injicér realistiske fejl (latens, fejl, ressourceudmattelse, afhængighedsfejl), og brug dem til at verificere, at timeouts, genforsøg, kredsløbsafbrydere og failover faktisk virker.
Begynd med tabletop-øvelser og game days, afgræns sprængradius bevidst, og optjen vejen mod produktion og automatisering.
Forbind eksperimenter til katastrofeberedskabstest (kapitel 9.5) og hændelseslæring (kapitel 9.3), så fund akkumulerer til ét robusthedsefterslæb.
Behandl fund skyldfrit, og ret dem; et eksperiment, hvis lektie forbliver uadresseret, er værre end intet eksperiment.

Referencer og videre læsning

Casey Rosenthal, Nora Jones, Chaos Engineering: System Resiliency in Practice
Russ Miles, Learning Chaos Engineering: Discovering and Overcoming System Weaknesses Through Experimentation
Mikolaj Pawlikowski, Chaos Engineering: Crash Test Your Applications
Ali Basiri et al., Chaos Engineering (IEEE Software, 2016)
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, Site Reliability Engineering: How Google Runs Production Systems
Michael T. Nygard, Release It! Design and Deploy Production-Ready Software
Principles of Chaos Engineering, principlesofchaos.org