9.6 Kaosteknik och motståndskraftstestning

Översikt och motivation

Kaosteknik är den disciplinerade praxisen att köra experiment på ett system för att bygga tillförsikt till dess förmåga att stå emot turbulenta förhållanden i produktion. Namnet låter hänsynslöst, och det är det första ni ska lära om. Kaosteknik är inte att slumpmässigt förstöra saker och hoppas lära sig något. Det är motsatsen: en kontrollerad, hypotesdriven metod för att injicera realistiska fel så att ni upptäcker svagheter innan era användare gör det. Ni vet redan att ert system kommer att möta fel, eftersom varje verkligt system gör det. Den enda frågan är om ni möter dessa fel en tisdagseftermiddag med en återställning redo, eller klockan tre på natten under er mest hektiska timme utan aning om vad som händer.

För stora team spelar detta roll eftersom komplexiteten har vuxit ifrån någons förmåga att resonera om den genom inspektion. En modern tjänst är ett nät av dussintals eller hundratals komponenter, var och en med egna timeouter, omförsök, cacher och felmönster, och interaktionerna mellan dem ger emergent beteende som inget arkitekturdiagram förutsäger. Ni kan granska koden, rita lådorna och ändå bli överrumplade när ett långsamt beroende utlöser en omförsöksstorm som tar ned en tjänst tre hopp bort. Kaosteknik är hur ni sonderar dessa interaktioner empiriskt, så att er motståndskraft är något ni har verifierat snarare än något ni antar.

Företags- och myndighetssammanhang höjer insatserna och, alltmer, mandatet. Finansiella tillsynsmyndigheter förväntar sig nu att företag testar operativ motståndskraft mot allvarliga men rimliga scenarier och bevisar att de kan hålla kritiska tjänster igång genom störningar. Myndigheter kör övningar för fortsatt drift (continuity of operations) så att väsentliga offentliga tjänster överlever avbrott, katastrofer och cyberattacker. I båda världarna är “vi tror att det håller” inte ett acceptabelt svar till en revisor eller en medborgare. Kaosteknik ger er belägg. Det här kapitlet bygger på site reliability engineering (kapitel 9.1) och motståndskraftsmönstren i kapitel 3.5, och det kopplar tätt till incidenthantering (kapitel 9.3) och katastrofåterställning (kapitel 9.5).

Nyckelprinciper

Bygg tillförsikt, skapa inte kaos. Målet är verifierad motståndskraft, inte spektakel. Varje experiment besvarar en specifik fråga om hur systemet beter sig under stress.
Definiera stabilt tillstånd först. Du kan inte upptäcka ett problem utan en tydlig, mätbar definition av hur “friskt” ser ut.
Formulera en hypotes. Ange vad du förväntar dig ska hända innan du injicerar ett fel. En överraskning är ett fynd. Frånvaron av en är också ett fynd.
Minimera och begränsa sprängradien. Börja smått, skydda verkliga användare och utvidga omfattningen först när tillförsikten växer.
Föredra produktion, försiktigt. Fel beter sig annorlunda under verklig trafik, verklig data och verklig skala. Förtjäna rätten att testa där.
Automatisera mot kontinuerlig verifiering. En svaghet du rättar en gång kan regrediera. Motståndskraft som testas kontinuerligt förblir sann.
Fel är en lärare, inte en dom. Fynd förbättrar systemet. De är aldrig ett skäl att skylla på den som körde experimentet.

Rekommendationer

Etablera förutsättningarna innan du injicerar ett enda fel

Kaosteknik är en kraftmultiplikator för ett moget system och en skuld för ett omoget. Innan ni börjar behöver ni tre saker på plats. För det första observerbarhet, det vill säga de mått, loggar och spår som låter er se vad ert system gör utifrån, eftersom ett experiment ni inte kan observera lär er ingenting. För det andra servicenivåmål eller en motsvarande definition av friskt stabilt tillstånd (kapitel 9.1), så att ni kan skilja ett lyckat experiment från ett skadligt i realtid. För det tredje en snabb och pålitlig väg för återställning eller avbrott, så att ni i samma ögonblick ett experiment hotar verkliga användare kan stoppa det och återställa normal tjänst på sekunder. Om ni inte kan mäta ert system, definiera dess friska tillstånd och dra tillbaka det från randen, kör inte kaosexperiment ännu. Bygg dessa förmågor först. De betalar sig oavsett.

Definiera stabilt tillstånd och formulera en verklig hypotes

Varje experiment börjar med att skriva ned hur normalt ser ut i mätbara termer: andel lyckade begäranden över 99,9 procent, kassalatens under 400 millisekunder vid 95:e percentilen, ködjup under en tröskel. Det är er definition av stabilt tillstånd, och den bör spegla användarsynlig hälsa, inte intern rörledning. Ange sedan en hypotes på klarspråk: “Om vi lägger till 300 millisekunders latens i rekommendationstjänsten kommer produktsidan fortfarande att renderas inom sin latensbudget eftersom sidan behandlar rekommendationer som valfria och tar timeout efter 200 millisekunder.” Nu har ni ett falsifierbart påstående. När ni kör experimentet inträffar en av två goda saker. Antingen beter sig systemet som förutsagt och er tillförsikt är förtjänad, eller så gör det inte det och ni har hittat en verklig svaghet billigt, på era villkor, med ingenjörer som tittar på.

Injicera realistiska fel, inte godtyckliga

De fel ni introducerar bör spegla de fel ert system faktiskt upplever. Felinjektion, den medvetna introduktionen av fel för att testa hur ett system svarar, ger er en meny hämtad från verkliga produktionsincidenter. Injicera latens för att simulera ett långsamt beroende eller en mättad nätverkslänk. Injicera fel, som att returnera HTTP 500 eller vägrade anslutningar, för att simulera en fallerande nedströmstjänst. Injicera resursutmattning genom att förbruka CPU, minne, disk eller filbeskrivare för att se hur systemet degraderar under tryck. Injicera beroendefel genom att göra en hel databas, cache, kö eller tredjeparts-API onåbar. I ett distribuerat system, där komponenter körs på separata maskiner och kommunicerar över ett opålitligt nätverk, är dessa de fel som dominerar verkliga avbrott. Latens och partiella fel, inte rena krascher, är det som i praktiken bryter saker, så vikta era experiment mot den röriga mellanvägen.

Verifiera att era motståndskraftsmekanismer faktiskt fungerar

Det är här kaosteknik förtjänar sitt uppehälle. Ert system är fullt av mekanismer som ska skydda er: timeouter som hindrar en anropare från att vänta för evigt, omförsök som släta över övergående hack, kretsbrytare som slutar hamra på ett fallerande beroende och failover som växlar till en standby när den primära dör. Dessa mönster, behandlade i kapitel 3.5, är skillnaden mellan ett begränsat problem och ett kaskadavbrott. Problemet är att de sällan testas under de förhållanden de finns för. En timeout satt till 30 sekunder när anroparens egen tidsgräns är 2 sekunder gör ingenting. Ett omförsök utan backoff förvandlar en kämpande tjänst till en störtflod. En kretsbrytare som aldrig övats kan vara felkonfigurerad och aldrig lösa ut, eller lösa ut hela tiden. Kaosexperiment är hur ni bekräftar att var och en av dessa beter sig som designat när felet den skyddar mot faktiskt anländer. Anta att varje otestad säkerhetsmekanism är trasig tills ett experiment bevisar motsatsen.

Börja med övningsdagar innan ni automatiserar

Börja inte med en automatiserad plattform som injicerar fel kontinuerligt. Börja med en övningsdag: en schemalagd, praktisk övning där ett team samlas, väljer ett scenario, injicerar ett fel i en kontrollerad miljö och tittar tillsammans. Före ens det avslöjar en bordsövning, där ni talar igenom ett scenario på en whiteboard utan att röra systemet, luckor i körböcker, larmning och ägarskap med nästan ingen risk. Övningsdagar är er uppfart. De bygger muskeln att formulera hypoteser, begränsa sprängradie och läsa systemet under stress, och de bygger det förtroende hos ledning och angränsande team ni behöver innan någon låter er köra experiment i produktion. De stärker också incidentsvaret direkt, eftersom färdigheterna är samma som era jourhavande ingenjörer använder under en verklig incident (kapitel 9.3). Kör era första övningsdagar i staging, sedan i produktion under lugna timmar med liten sprängradie och expandera sedan.

Begränsa sprängradien medvetet

Den enskilt viktigaste säkerhetspraxisen är att begränsa den potentiella skadan av varje experiment. Börja med den minsta omfattning som kan lära er något: en instans, en procent av trafiken, ett icke-kritiskt beroende, en tillgänglighetszon. Definiera avbrottsvillkoren innan ni börjar, koppla dem till era mått för stabilt tillstånd och gör att stoppa experimentet till en enda åtgärd vem som helst som tittar kan utlösa. Föredra att köra under kontorstid när teamet är alert och bemannat, inte över natten när en överraskning blir en incident utan någon som tittar. Vidga sprängradien först när mindre experiment har körts rent och er tillförsikt genuint är högre. Disciplinen i att begränsa är det som skiljer kaosteknik från ett avbrott ni orsakat själva.

Växa mot kontinuerlig, automatisk verifiering av motståndskraft

Enstaka övningsdagar hittar svagheter, men system ändras varje dag, och en rättelse från förra kvartalet kan i tysthet regrediera. Det mogna slutläget är kontinuerlig verifiering: en kurerad uppsättning motståndskraftsexperiment som körs automatiskt, i en pipeline eller enligt schema, så att en regression i en timeout, en omförsökspolicy eller en failover-väg fångas inom dagar snarare än under nästa verkliga avbrott. Det är här verktyg som Netflix Chaos Monkey, som slumpmässigt avslutar instanser i produktion för att tvinga ingenjörer att bygga tjänster som tolererar förlust av instanser, förtjänade sitt rykte. Automatisera bara de experiment ni redan förstår och litar på från manuella körningar. Kontinuerligt kaos ovanpå ett omoget system är ett sätt att generera incidenter, inte tillförsikt.

Koppla experiment till katastrofåterställning och incidentlärande

Kaosteknik lever inte ensamt. De större, sällsyntare scenarierna, att förlora en hel region, att växla över en databas, att återställa från säkerhetskopia, hör hemma i testning av katastrofåterställning (kapitel 9.5), och en övningsdag är ofta det bästa fordonet för att öva dessa planer i stället för att låta dem ruttna som otestade dokument. På andra sidan bör varje experiment som lyfter fram en svaghet mata samma lärandeslinga som en verklig incident (kapitel 9.3): en skuldfri sammanfattning, en spårad rättelse och ett uppföljningsexperiment som bekräftar att rättelsen håller. När kaosfynd, katastrofåterställningsövningar och incidentgranskningar alla flödar in i en backlogg av motståndskraftsarbete får ni ackumulerande avkastning i stället för spridda engångsövningar.

Avvägningar: för- och nackdelar

Beslut	Fördelar	Nackdelar
Testa i produktion	Verklig trafik, data och skala. Fynden är sanna	Risk för användare om begränsningen fallerar. Kräver mognad
Testa bara i staging	Säkert, låga insatser, lätt att börja	Missar verkligt beteende. Falsk tillförsikt
Manuella övningsdagar	Bygger färdigheter och förtroende. Låg verktygskostnad	Sällsynta. Fynd kan regrediera obemärkt
Kontinuerligt automatiskt kaos	Fångar regressioner fort. Skalar	Behöver mogna verktyg och observerbarhet först
Bred sprängradie	Avslöjar stora systemiska svagheter	Hög risk. Ett misstag blir en incident
Smal sprängradie	Säker och kontrollerbar	Kan missa emergenta fel över tjänster

Den centrala spänningen är mellan realism och säkerhet. De fynd ni mest vill ha kommer från produktion, eftersom det är den enda plats där ert system möter verklig trafik, verklig data och verklig skala, men produktion är just där ett misslyckat experiment skadar användare. Lösningen är inte att välja sida. Det är att förtjäna er väg mot produktion gradvis: bevisa era förutsättningar, repetera i staging, kör sedan små, väl begränsade experiment i produktion med avbrottsvillkor kopplade till levande mått och vidga omfattningen först när belägg ackumuleras. Den andra återkommande spänningen, manuellt mot automatiskt, löses på samma sätt över tid. Börja manuellt för att bygga förståelse och förtroende och automatisera sedan de experiment ni kommit att förlita er på, så att motståndskraft ni verifierat en gång förblir verifierad.

Frågor att diskutera med ditt team

Är vi faktiskt redo att köra kaosexperiment, och hur skulle vi veta det? Det är frestande att börja injicera fel för att det låter sofistikerat, men kaosteknik på ett oobserverbart system utan tydlig hälsodefinition och ingen snabb återställning är bara självförvållat driftstopp. Ta med ärliga belägg till den här diskussionen: kan ni se andel lyckade begäranden och latens i realtid, har ni en överenskommen definition av stabilt tillstånd och kan ni avbryta ett experiment och återhämta er på sekunder? För ett stort team skiljer sig svaret ofta per tjänst, så det användbara resultatet är en beredskapsribba en tjänst måste klara för att vara berättigad till experiment. I reglerade sammanhang fungerar den beredskapsribban även som en kontroll ni kan visa en revisor. Om det ärliga svaret är att ni inte är redo är det mest värdefulla kaosarbete ni kan göra detta kvartal att bygga de observerbarhets- och återställningsförmågor som gör er redo.
Vad är vår policy för sprängradie, och vem har befogenhet att stoppa ett experiment? Varje kaosexperiment bär viss risk för verkliga användare, och skillnaden mellan ett värdefullt fynd och en incident ni orsakat är hur tätt ni begränsade det. Tala igenom de konkreta gränserna: vilken andel av trafiken, hur många instanser, vilka miljöer, vilka tider på dygnet och vilka måttströsklar som automatiskt avbryter körningen. Avgör i förväg vem som tittar på varje experiment och vem som håller nödbrytaren med en enda åtgärd, eftersom ett experiment ingen snabbt kan stoppa inte är begränsat. För en stor organisation är den policyn det som låter många team experimentera utan att någon av dem av misstag tar ned ett gemensamt beroende. Svaret bör skrivas ned, överenskommas med de team vars tjänster ni kan påverka och behandlas som en förutsättning för att köra något i produktion.
Vilka motståndskraftsmekanismer tror vi skyddar oss, och har vi någonsin faktiskt testat dem? De flesta system är fulla av timeouter, omförsök, kretsbrytare, cacher och failover-vägar som konfigurerades en gång och aldrig övats under det fel de finns för. Gör en lista över de mekanismer ni räknar med och fråga sedan, för var och en, när den senast verifierades fungera under ett verkligt injicerat fel. Den konkurrerande hänsynen är tid: att verifiera varje mekanism kostar ingenjörsinsats, och det finns alltid en funktionsfrist. Ta med motbeläggen till den invändningen, nämligen kostnaden för ett tidigare avbrott som en fungerande kretsbrytare eller en korrekt timeout skulle ha begränsat. Svaret bör förvandla en tröstande lista över antagna skydd till en prioriterad backlogg av experiment, med början i de mekanismer vars fel skulle skada mest.
Vad måste vara sant innan vi kör ett experiment i produktion snarare än staging, och vilka tjänster har förtjänat den rätten i dag? De fynd ni mest vill ha kommer från produktion, eftersom det är den enda plats där ert system möter verklig trafik, verklig data och verklig skala, men produktion är också den enda plats där ett misslyckat experiment skadar faktiska användare. För ett stort team är den ärliga verkligheten att olika tjänster befinner sig på olika beredskapsnivåer, så en generell regel “inget produktionskaos” slösar ert bästa lärande medan ett generellt “ja” inbjuder till självförvållade avbrott. Ta med belägg per tjänst: kvaliteten på dess observerbarhet, om stabilt tillstånd är definierat och går att larma på, hur snabb återställningen är och meritlistan av rena stagingexperiment som skulle motivera att befordra den. I företags- och myndighetssammanhang, knyt produktionsgrinden till en dokumenterad kontroll som namnger vem som godkänner befordran och vilka avbrottsvillkor som är kopplade till levande mått, så att revisorn ser ett medvetet, belagt beslut snarare än ett team som improviserar med verkliga användare.
När ett kaosexperiment lyfter fram en svaghet, vart tar det fyndet vägen, och hur hindrar vi det från att ruttna orört? Ett program som upptäcker svagheter men aldrig rättar dem är värre än inget program, eftersom det bränner insats, urholkar förtroende och lär människor att experiment är teater. Det konkurrerande trycket är alltid produktfärdplanen: en motståndskraftsrättelse känns sällan lika brådskande som nästa release tills avbrottet den skulle ha förhindrat faktiskt anländer. Ta med det nuvarande läget för er motståndskraftsbacklogg till diskussionen: hur många kaosfynd som är öppna, hur gammalt det äldsta är och om fynd från experiment, katastrofåterställningsövningar och incidentgranskningar flödar in i en gemensam kö eller sprids över team. Kom överens om vem som äger varje rättelse och vem som kör uppföljningsexperimentet som bekräftar att den håller. För en stor eller reglerad organisation, namnge forumet som granskar backloggen med fast takt och har befogenhet att prioritera en motståndskraftsrättelse framför en funktion, eftersom ett fynd ingen är ansvarig för att stänga är en risk ni bara har dokumenterat snarare än tagit bort.
Är vi redo att automatisera några av våra experiment till kontinuerlig verifiering, och vilka specifikt? Enstaka övningsdagar hittar svagheter, men system ändras dagligen och en rättelse från förra kvartalet kan i tysthet regrediera, så det mogna slutläget är en kurerad uppsättning experiment som körs automatiskt och fångar regressioner inom dagar. Faran är att automatisera för tidigt: kontinuerligt kaos lagt på ett omoget system med svag observerbarhet genererar incidenter fortare än insikt. Ta med listan över experiment ni har kört manuellt tillräckligt många gånger för att lita helt på dem, de sprängradiekontroller och avbrottsvillkor som skulle styra dem obevakat och den övervakning som skulle fånga en automatisk körning som går fel klockan tre på natten när ingen tittar. För ett stort företag eller en stor myndighet, väg den tillagda granskning som obevakad felinjektion inbjuder till: godkännande i ändringshanteringen, det revisionsspår varje automatisk körning måste lämna och den tydliga ansvarsskyldigheten för ett schemalagt experiment som sammanfaller med en verklig incident. Automatisera bara de experiment ni redan förstår och håll resten manuella tills de förtjänar samma förtroende.

Sektorsperspektiv

Startup. Fart och överlevnad dominerar, så lägg ingenting på en kaosplattform. Kör en enda övningsdag på nittio minuter i staging mot det enda beroende vars fel faktiskt skulle döda dig, vanligen betalningar, autentisering eller ditt primära datalager. Injicera felet med en enkel proxy eller en dödad process, se vad som går sönder, rätta den saknade timeouten eller reservlösningen och gå vidare. Hela poängen är att fånga det uppenbara självförvållade avbrottet billigt innan en kund gör det, inte att bygga en disciplin du inte kan bemanna.

Småföretag. Utan tillförlitlighetsspecialist och med snäv budget, behandla motståndskraftstestning som en periodisk, medveten övning snarare än ett program du bemannar. Lita på de felinjektionsfunktioner din molnleverantör eller hanterade verktyg redan innehåller i stället för att köpa en dedikerad plattform och fokusera experiment på de handfull beroenden en kund skulle märka. Ramma in det som försäkring: en eftermiddag som läggs på att bekräfta att dina säkerhetskopior återställs och att din kassa degraderar graciöst är långt billigare än avbrottet som bevisar att de inte gör det.

Storföretag. Problemet är att samordna många team mot gemensamma beroenden i skala, så standardisera beredskapsribban, sprängradiepolicyn och avbrottsvillkorskopplingen varje team måste klara innan de kör i produktion. Dirigera kaosfynd, katastrofåterställningsövningar och incidentgranskningar in i en motståndskraftsbacklogg med tydligt ägarskap och använd kvartalsvisa övningsdagar plus en kurerad uppsättning automatiska experiment för att uppfylla förväntningar på operativ motståndskraft med belägg. Styr vem som får påverka en gemensam tjänst så att ingen enskild teams experiment tar ned infrastruktur andra beror på.

Offentlig sektor. Upphandlingsregler, transparens och offentlig ansvarsskyldighet formar arbetet. Mandat om fortsatt drift kräver ofta regelbundna övningar ändå, så kör dem som levande övningsdagar som ger genuina fynd snarare än en pärm ingen öppnar och för ett revisionsspår över varje experiment, dess sprängradie och dess utfall. Där felinjektionsverktyg upphandlas, kräv att de passar inom säkerhets- och datahanteringsregler och reservera produktionsexperiment på medborgarvända tjänster för snävt begränsade, godkända fönster. De belägg ett kaosprogram producerar är exakt vad ett tillsynsorgan eller en revisor förväntar sig att se.

Exempel

Startup. Ett startup på femton personer kör en webbapp på en handfull tjänster och beror på ett tredjeparts betal-API. Ingen har tid för en kaosplattform, så teamet kör en övningsdag på nittio minuter i staging. De formulerar en hypotes: om betal-API:et börjar returnera fel bör kassan visa ett tydligt omförsöksmeddelande och köa ordern snarare än krascha. De injicerar 500-svar med en enkel proxy och upptäcker att frontend hänger på obestämd tid eftersom klientanropet saknar timeout. De lägger till en timeout och en vänlig reservlösning, kör om experimentet för att bekräfta rättelsen och skriver en anteckning på två stycken i ett gemensamt dokument. Total kostnad: en eftermiddag och en mycket verklig bugg fångad innan en kund drabbades.

Storföretag. En global bank måste visa operativ motståndskraft för tillsynsmyndigheter mot allvarliga men rimliga scenarier. Dess tillförlitlighetsteam kör ett program med kvartalsvisa övningsdagar plus en uppsättning automatiska experiment i produktion. Ett scenario växlar över den primära transaktionsdatabasen till dess standby under ett lågtrafikfönster, med en strikt begränsad sprängradie och avbrottsvillkor knutna till andelen lyckade transaktioner. Den första körningen avslöjar att en nedströms avstämningstjänst har en omförsökspolicy utan backoff, vilket ger en lasttopp som fördröjer återställningen långt bortom målet för återställningstid i katastrofåterställningsplanen (kapitel 9.5). Fyndet går in i samma backlogg som incidentgranskningarna, omförsökspolicyn rättas med exponentiell backoff och ett uppföljningsexperiment bekräftar att failover nu slutförs inom målet. Hela övningen blir belägg för tillsynsmyndigheten.

Offentlig sektor. En nationell myndighet som driver en medborgarvänd bidragsportal måste upprätthålla fortsatt drift genom störningar. I stället för att behandla sin kontinuitetsplan som en pärm ingen öppnar kör myndigheten en årlig kontinuitetsövning som en levande övningsdag. Teamet simulerar förlusten av ett primärt datacenter och går igenom failover till en sekundär plats, medan de separat injicerar latens i ett identitetsverifieringsberoende för att se om portalen degraderar graciöst. De lär sig att ett otestat övervakningsgap lämnade jourteamet blint för att identitetstjänsten blev långsammare, så larmen utlöstes sent. Myndigheten stänger observerbarhetsgapet, uppdaterar sina körböcker och schemalägger samma övning för nästa år och förvandlar ett regelefterlevnadskrav till genuin, testad motståndskraft för en kritisk offentlig tjänst.

Affärsnytta: motiv, ROI och TCO

Avkastningen på kaosteknik kommer från avbrott som aldrig inträffar. Ett enda stort avbrott för en stor tjänst kan kosta allt från tiotusentals till miljoner i förlorade intäkter, regulatoriska viten, avhjälpningsarbete och anseendeskada som dröjer sig kvar långt efter att tjänsten återställts. Kaosexperiment omvandlar dessa oförutsägbara, dyra överraskningar till billiga, schemalagda fynd ni rättar på er egen tidslinje med ingenjörer som tittar och en återställning redo. Att hitta en trasig timeout under en kontrollerad övningsdag kostar en eftermiddag. Att hitta den under en verklig incident kostar ett avbrott, en kapplöpning med alla på däck och era användares förtroende. Aritmetiken gynnar övningsdagen med bred marginal.

Total ägandekostnad är blygsam när förutsättningarna väl finns, eftersom kaosteknik återanvänder de investeringar i observerbarhet, larmning och återställning ni behöver ändå. De ärliga kostnaderna är ingenjörstiden för att köra experiment, en del verktyg för att injicera fel och begränsa sprängradie och det kulturella arbetet att få ledningen bekväm med att medvetet introducera fel. Det sista är den verkliga barriären, och vägen igenom är att börja i staging, visa fynd som mappar till pengar eller risk och låta några begränsade produktionsexperiment bygga förtroende. För att driva ärendet inför ledningen, ramma in kaosteknik som en försäkring ni kan mäta: presentera kostnaden för nyliga incidenter, visa vilka av dem ett motståndskraftsexperiment skulle ha fångat och föreslå ett program som börjar smått och expanderar först när det bevisat sig. I reglerade och offentliga sammanhang, lägg till regelefterlevnadsvinkeln, eftersom testning av operativ motståndskraft och kontinuitetsövningar alltmer förväntas, och ett kaosprogram är hur ni uppfyller den förväntan med belägg snarare än papper.

Antimönster och fallgropar

Kaos utan observerbarhet. Att injicera fel i ett system ni inte kan se är gissning med extra steg. Ni orsakar skada och lär er ingenting.
Ingen definition av stabilt tillstånd. Utan ett överenskommet hälsomått kan ni inte avgöra om ett experiment avslöjade ett problem eller orsakade ett.
Ingen hypotes. Att slumpmässigt förstöra saker är inte kaosteknik. Det är vandalism med ett fint namn och inga fynd.
Obegränsad sprängradie. Att hoppa över de små, säkra experimenten och gå direkt till felutbredning i hela produktionen förvandlar ett test till ett självförvållat avbrott.
Ingen avbrottsväg. Ett experiment ni inte kan stoppa omedelbart är inte ett experiment. Det är en incident som väntar på en utlösare.
Att automatisera för tidigt. Kontinuerligt kaos på ett omoget system genererar incidenter fortare än insikter.
Fynd som inte leder någonstans. Att upptäcka en svaghet och aldrig rätta den slösar övningen och urholkar förtroendet för hela programmet.
Skuld efter ett dåligt experiment. Att straffa ingenjören som körde ett experiment som lyfte fram ett verkligt fel garanterar att ingen kör nästa.

Mognadsmodell

Nivå 1, Initiera: Motståndskraft antas, testas inte. Fel upptäcks i produktion under verkliga incidenter. Det finns inga övningsdagar, ingen felinjektion och ofta ingen tydlig definition av hur friskt ser ut. Teamet lär sig om sina svagheter den hårda vägen, ett avbrott i taget.
Nivå 2, Utveckla: Teamet kör enstaka övningsdagar, vanligen i staging, med ett definierat scenario och en hypotes. Stabilt tillstånd är definierat för några nyckeltjänster och grundläggande observerbarhet finns. Fynd fångas och vissa rättas, men praxisen är inkonsekvent över team och beror på enskilda förkämpar snarare än en etablerad metod.
Nivå 3, Standardisera: Kaosexperiment är en dokumenterad praxis i hela organisationen med upprätthållna sprängradiepolicyer, avbrottsvillkor och beredskapskriterier en tjänst måste klara innan den experimenterar i produktion. Experiment körs i produktion under kontrollerade förhållanden, fynd flödar in i en gemensam motståndskraftsbacklogg tillsammans med incidentgranskningar och katastrofåterställningsövningar och motståndskraftsmekanismer verifieras snarare än antas. Varje team följer samma spelbok.
Nivå 4, Hantera: Programmet mäts och styrs med data mot utgångslägen. Ni följer motståndskraftstäckning (vilka kritiska tjänster och vilka mekanismer, såsom timeouter, omförsök, kretsbrytare och failover, som har verifierats under ett verkligt injicerat fel och hur nyligen), takten med vilken experiment lyfter fram fynd, genomsnittlig tid att stänga ett motståndskraftsfynd och hur ofta en tidigare verifierad mekanism regredierar. Dessa mått granskas med fast takt, produktionsbefordran grindas på belägg snarare än åsikt och experiment prioriteras efter den uppmätta risken hos de mekanismer som fortfarande är overifierade.
Nivå 5, Orkestrera: En kurerad uppsättning experiment körs kontinuerligt och automatiskt och fångar regressioner inom dagar, och programmet anpassas när systemet och dess riskbild förändras. Kaosteknik är integrerad i hela organisationen med leveranspipelines, incidentlärande och katastrofåterställningstestning, så att nya tjänster ärver motståndskraftsverifiering som standard. Motståndskraft är en kontinuerligt verifierad egenskap hos systemet, och ledningen behandlar programmet som standardriskhantering som förfinas på belägg snarare än ett särskilt initiativ.

Idéer för diskussion

Hur avgör ni vilken tjänst i er organisation som först förtjänar rätten att köra kaosexperiment i produktion, och vad måste vara sant innan den gör det?
När ett kaosexperiment lyfter fram en allvarlig svaghet, vem äger rättelsen, och hur hindrar ni det fyndet från att ligga orört i en backlogg?
Var går gränsen mellan ett kaosexperiment, en katastrofåterställningsövning och en övningsdag i ert sammanhang, och spelar skillnaden ens roll för hur ni planerar dem?
Hur skulle ni övertyga en skeptisk chef om att medvetet injicera fel i produktion är säkrare än status quo att vänta på verkliga avbrott?
Vad är det minsta, mest värdefulla första experimentet ert team kunde köra nästa månad, och vad skulle hindra er från att köra det?
Hur bör motståndskraftstestning skilja sig mellan en medborgarvänd offentlig tjänst med ett kontinuitetsmandat och ett internt företagsverktyg med få användare?

Viktigaste punkter

Kaosteknik är disciplinerad, hypotesdriven experimentering för att bygga tillförsikt till motståndskraft, inte slumpmässigt sönderslående.
Etablera observerbarhet, en definition av stabilt tillstånd och en snabb återställning innan du injicerar ett enda fel.
Injicera realistiska fel (latens, fel, resursutmattning, beroendefel) och använd dem för att verifiera att timeouter, omförsök, kretsbrytare och failover faktiskt fungerar.
Börja med bordsövningar och övningsdagar, begränsa sprängradien medvetet och förtjäna din väg mot produktion och automatisering.
Koppla experiment till katastrofåterställningstestning (kapitel 9.5) och incidentlärande (kapitel 9.3) så att fynd ackumuleras i en enda motståndskraftsbacklogg.
Behandla fynd skuldfritt och rätta dem. Ett experiment vars lärdom lämnas obehandlad är värre än inget experiment alls.

Referenser och vidare 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