Sjabloon voor incident-postmortems

Incidentoverzicht

Schrijf een samenvatting van het incident in een paar zinnen. Vermeld wat er is gebeurd, waarom, de ernst van het incident en hoe lang de impact duurde.

VOORBEELD:

Tussen {tijdsbereik van het incident, bijv. 15:45 en 16:35} op {DATUM} hebben {AANTAL} gebruikers {GEBEURTENISSYMPTOMEN} ondervonden.

De gebeurtenis werd veroorzaakt door een {WIJZIGING} om {TIJDSTIP VAN DE WIJZIGING DIE DE GEBEURTENIS VEROORZAAKTE}.

De {WIJZIGING} bevatte {BESCHRIJVING VAN OF REDEN VOOR DE WIJZIGING, zoals een codewijziging om een systeem bij te werken}.

Een bug in deze code veroorzaakte {BESCHRIJVING VAN HET PROBLEEM}.

De gebeurtenis is gedetecteerd door {BEWAKINGSSYSTEEM}. Het team begon aan het evenement te werken door {ONDERNOMEN ACTIES VOOR OPLOSSING}.

Dit incident met {ERNSTNIVEAU} had gevolgen voor {X%} van de gebruikers.

Er was nog meer impact zoals opgemerkt door {bijv. AANTAL INGEDIENDE SUPPORTTICKETS, VERMELDINGEN OP SOCIALE MEDIA, OPROEPEN NAAR ACCOUNTMANAGERS} die werden geuit in verband met dit incident.

Voorbereiding

Beschrijf de volgorde van gebeurtenissen die tot het incident hebben geleid, bijvoorbeeld eerdere wijzigingen die bugs introduceerden die nog niet waren gedetecteerd.

VOORBEELD:

Om {16.00 uur} op {DD-MM-JJ} ({HOEVEELHEID TIJD VÓÓR IMPACT OP DE KLANT, bijv. 10 dagen vóór het incident in kwestie}) werd een wijziging aangebracht in {PRODUCT OF SERVICE} met het oog op {DE WIJZIGINGEN DIE TOT HET INCIDENT HEBBEN GELEID}.

Deze wijziging resulteerde in {BESCHRIJVING VAN DE IMPACT VAN DE VERANDERING}.

Storing

Beschrijf hoe de doorgevoerde wijziging niet werkte zoals verwacht. Voeg, indien beschikbaar, schermafbeeldingen toe van relevante gegevensvisualisaties die de fout illustreren.

VOORBEELD:

{AANTAL} reacties zijn ten onrechte verzonden naar {XX%} van de aanvragen. Dit ging door gedurende {TIJDSPERIODE}.

Impact

Beschrijf hoe het incident interne en externe gebruikers heeft beïnvloed tijdens het incident. Vermeld hoeveel support cases er zijn aangemaakt.

VOORBEELD:

Gedurende {XX uur en XX minuten} tussen {XX:XX UTC en XX:XX UTC} op {DD-MM-JJ} hebben onze gebruikers last gehad van dit incident {SAMENVATTING VAN HET INCIDENT}.

Dit incident had gevolgen voor {XX} klanten (X% VAN DE GEBRUIKERS VAN {SYSTEEM OF SERVICE}), die {BESCHRIJVING VAN DE SYMPTOMEN} ondervonden.

Er zijn {XX AANTAL SUPPORTTICKETS EN XX AANTAL BERICHTEN OP SOCIALE MEDIA} ingediend.

Detectie:

Wanneer ontdekte het team het incident? Hoe wisten ze dat het gebeurde? Hoe kunnen we de tijd tot detectie verbeteren? Overdenk: hoe hadden we die tijd kunnen halveren?

VOORBEELD:

Dit werd gedetecteerd toen het {WAARSCHUWINGSTYPE} werd geactiveerd en {TEAM/PERSOON} werd opgeroepen.

Vervolgens werd {TWEEDE PERSOON} opgeroepen omdat de {EERSTE PERSOON} niet de eigenaar was van de service die naar de schijf schreef, waardoor de respons met {XX MINUTEN/UUR} werd vertraagd.

{BESCHRIJF DE VERBETERING} zal worden doorgevoerd door {TEAMEIGENAAR VAN DE VERBETERING} zodat {VERWACHTE VERBETERING}.

Reactie

Wie reageerden op het incident? Wanneer hebben ze gereageerd en wat hebben ze gedaan? Let op eventuele vertragingen of obstakels bij het reageren.

VOORBEELD:

Na ontvangst van een oproep om {XX:XX UTC} kwam {TECHNISCH OPAFROEPMEDEWERKER} online om {XX:XX UTC} in {SYSTEEM WAARIN INCIDENTINFORMATIE WORDT VASTGELEGD}.

Deze technisch medewerker had geen ervaring met het {GETROFFEN SYSTEEM}. Daarom werd om {XX:XX UTC} een tweede waarschuwing verzonden naar {ESCALATIE TECHNISCHE OPAFROEPMEDEWERKER}, die de ruimte betrad om {XX:XX UTC}.

Herstel

Beschrijf hoe de service is hersteld en het incident als opgelost werd beschouwd. Geef nauwkeurig aan hoe de service succesvol is hersteld en hoe je wist welke stappen je moest nemen voor herstel.

Beantwoord afhankelijk van het scenario de volgende vragen: Hoe kun je de tijd voor mitigatie verbeteren? Hoe had je die tijd kunnen halveren?

VOORBEELD:

We hebben een drieledige aanpak gebruikt voor het herstel van het systeem:

{BESCHRIJF DE ACTIE DIE HET PROBLEEM HEEFT VERZACHT, WAAROM DEZE ACTIE IS ONDERNOMEN EN WAT DE UITKOMST WAS}

Ter illustratie: de omvang van het BuildEng EC3 ASG vergroten om het aantal nodes te verhogen dat beschikbaar is om de workload te ondersteunen en de kans van plannen op overbevolkte nodes te verkleinen

• De Escalator autoscaler uitgeschakeld om te voorkomen dat de cluster fors naar beneden schaalt
• De Build Engineering scheduler naar de vorige versie terugzetten.

Tijdlijn

Beschrijf de tijdlijn van het incident. We raden aan UTC te gebruiken om te standaardiseren voor tijdzones.

Vermeld alle noemenswaardige gebeurtenissen in de aanloop naar het incident, elke gestarte activiteit, de eerste bekende impact en escalaties. Noteer alle genomen beslissingen of aangebrachte wijzigingen, en geef aan wanneer het incident eindigde, samen met eventuele gebeurtenissen na de impact.

VOORBEELD:

Alle tijden zijn in UTC.

11:48 - K8S 1.9-upgrade van het besturingsvlak is voltooid

12:46 - Upgrade naar V1.9 voltooid, inclusief cluster-autoscaler en de BuildEng-plannerinstallatie

14:20 - Build Engineering meldt een probleem aan KITT Disturbed

14:27 - KITT Disturbed begint met het onderzoeken van storingen van een specifieke EC2-installatie (ip-203-153-8-204)

14:42 - KITT Disturbed blokkeert het knooppunt

14:49 - BuildEng meldt dat het probleem betrekking heeft op meer dan één knooppunt. 86 gevallen van het probleem tonen aan dat storingen meer systematisch zijn

15:00 - KITT Disturbed stelt voor om over te schakelen naar de standaardplanner

15:34 - BuildEng meldt dat 200 pods zijn mislukt

16:00 - BuildEng sluit alle mislukte builds met OutOfCpu-rapporten

16:13 - BuildEng meldt dat de storingen consequent terugkeren bij nieuwe builds en niet van voorbijgaande aard waren.

16:30 uur - KITT herkent de fouten als een incident en voert ze als incident uit.

16:36 uur - KITT schakelt de Escalator-autoscaler uit om te voorkomen dat de autoscaler berekeningen verwijdert om het probleem te verlichten.

16:40 uur - KITT bevestigt dat ASG stabiel is, dat de clusterbelasting normaal is en de impact op de klant is opgelost.

SJABLOON:

XX:XX UTC - INCIDENTACTIVITEIT; ONDERNOMEN ACTIE

XX:XX UTC - INCIDENTACTIVITEIT; ONDERNOMEN ACTIE

XX:XX UTC - INCIDENTACTIVITEIT; ONDERNOMEN ACTIE

Identificatie van hoofdoorzaken: de vijf waaroms

De 'vijf waaroms' is een techniek voor het achterhalen van oorzaken. Hier lees je hoe je de methode kunt gebruiken:

• Begin met een beschrijving van de impact en vraag waarom deze zich heeft voorgedaan.
• Noteer de impact ervan.
• Vraag waarom dit is gebeurd en waarom het de resulterende impact had.
• Blijf waaromvragen stellen totdat je de hoofdoorzaak hebt achterhaald.

Vermeld de 'waaroms' in je postmortemdocumentatie.

VOORBEELD:

1. De toepassing viel uit omdat de database was vergrendeld
2. De database is vergrendeld omdat er te veel schrijfbewerkingen naar de database zijn geweest
3. Omdat we een wijziging in de service hebben doorgevoerd en de verhoogde schrijfbewerkingen niet hadden verwacht
4. Omdat we geen ontwikkelingsproces hebben vastgesteld voor wijzigingen in belastingtests
5. Omdat we nooit van mening waren dat belastingtests nodig waren totdat we dit schaalniveau bereikten.

Hoofdoorzaak

Let op de uiteindelijke hoofdoorzaak van het incident, het geïdentificeerde punt dat moet worden gewijzigd om te voorkomen dat deze incidentklasse opnieuw optreedt.

VOORBEELD:

Een bug in leidde tot gelekte connecties onder foutcondities, gecombineerd met een gebrek aan zichtbaarheid in de verbindingsstatus.

Backlog controleren

Bekijk je technische backlog om erachter te komen of er ongepland werk was dat dit incident had kunnen voorkomen, of op zijn minst de impact ervan had kunnen verminderen.

Een heldere beoordeling van de backlog kan licht werpen op eerdere beslissingen over prioriteiten en risico's.

VOORBEELD:

De backlog bevat geen specifieke items die deze service hadden kunnen verbeteren. Er is een opmerking over verbeteringen in flowtypen, en dit waren lopende taken met bestaande workflows.

Er zijn tickets ingediend voor het verbeteren van integratietests, maar tot nu toe zijn ze niet geslaagd.

Herhaling

Nu je de hoofdoorzaak kent, kun je terugkijken en andere incidenten zien die dezelfde oorzaak kunnen hebben? Zo ja, noteer dan welke mitigatie is geprobeerd bij die incidenten en vraag waarom dit incident zich opnieuw heeft voorgedaan.

VOORBEELD:

Dezelfde hoofdoorzaak resulteerde in incidenten HOT-13432, HOT-14932 en HOT-19452.

Geleerde lessen

Bespreek wat er goed ging in de incidentrespons, wat er verbeterd had kunnen worden en waar mogelijkheden zijn voor verbetering.

VOORBEELD:

• Er is een unittest nodig om te verifiëren dat de rate-limiter voor werk op de juiste manier is onderhouden
• Bulk workloads die niet typisch zijn voor de normale gang van zaken moeten worden bekeken
• Bulk ops moeten langzaam starten en worden gevolgd, en moeten verhoogd worden als servicestatistieken er normaal uitzien

Corrigerende maatregelen

Beschrijf de corrigerende maatregelen die zijn opgedragen om deze klasse incidenten in de toekomst te voorkomen. Let op wie verantwoordelijk is, wanneer deze het werk moet voltooien en waar dat werk wordt getraceerd.

VOORBEELD:

1. Snelheidsbeperking handmatig automatisch schalen tijdelijk ingesteld om fouten te beperken
2. Unittest en herintroductie van snelheidsbeperking taak
3. Introductie van een secundair mechanisme om gedistribueerde snelheidsgegevens te verzamelen rond cluster om schaaleffecten te begeleiden