Postmortemproces voor incidenten: volgen, documenteren en verbeteren

Belangrijke leerpunten

• Incident-postmortems helpen teams begrijpen wat er is gebeurd, waarom het is gebeurd en wat er moet veranderen om herhaling van problemen te voorkomen.

• Door Jira Service Management, Confluence en Jira samen te gebruiken, creëer je een verbonden workflow voor de respons, documentatie en follow-up.

• Een consistente postmortemsjabloon maakt het gemakkelijker om incidentevaluaties te documenteren, vergelijken en er in de loop van de tijd van te leren.

• Het omzetten van corrigerende acties in Jira-werkitems met eigenaren en deadlines helpt teams om geleerde lessen om te zetten in echte verbeteringen. 

Wanneer er iets misgaat in de productie, is de oplossing slechts het begin. Net zo belangrijk is begrijpen waarom het is gebeurd en ervoor zorgen dat het niet op dezelfde manier weer gebeurt. 

Een incident-postmortem is een gestructureerde evaluatie van het incident van begin tot eind, waarbij wordt gekeken naar wat er misging, hoe het team reageerde en wat er in de toekomst moet veranderen.

Met een sjabloon voor een incidentresponsplan als leidraad kan je team elk incident op een uniforme manier vastleggen, zodat er niets belangrijks over het hoofd wordt gezien en elke evaluatie tot daadwerkelijke verbeteringen leidt.

Hoe het werkt: incidenten registreren en postmortems vastleggen

Goed incidentmanagement gaat niet alleen over het blussen van branden. Het gaat erom een systeem te bouwen waarbij elk incident terugkoppelt naar betere processen, betere tooling en betere voorbereiding voor de volgende keer. Door Jira Service Management, Confluence en Jira samen te gebruiken krijgt je team een verbonden workflow die de volledige incidentrespons-levenscyclus dekt, vanaf het moment dat een waarschuwing wordt gegenereerd tot en met de evaluatie en de vervolgacties. 

Deze aanpak zorgt voor consistente documentatie bij incidenten en stelt een duidelijke verantwoordingsketen vast. In plaats van dat incidentgegevens verspreid zijn over Slack-berichten, e-mails en iemands geheugen, wordt alles bijgehouden in één geïntegreerd systeem waar het kan worden bekeken, geraadpleegd en waarnaar actie kan worden ondernomen. Die consistentie betekent ook dat je sjabloon voor het incidentresponsplan centraal blijft staan in het proces, in plaats van iets te zijn wat het team invult wanneer ze er tijd voor hebben. 

Zo verloopt het proces in elke fase:

Registreer het incident in Jira Service Management

Jira Service Management is waar je incidentrespons begint. Zodra er een issue binnenkomt, log je deze in JSM, stel je het ernstniveau vast en wijs de juiste respons-medewerkers toe. 

Tijdens het incident kunnen teams JSM gebruiken voor:

• Het volgen van acties, beslissingen en escalaties in realtime

• Het bijhouden van een duidelijk overzicht van wie betrokken was en wat er is gewijzigd

• Het vastleggen van details die later het postmortem zullen ondersteunen

• Het op de hoogte houden van de leiding zonder respons-medewerkers te onderbreken

Omdat JSM integreert met Confluence en Jira, kunnen de gegevens die tijdens het incident zijn verzameld direct doorstromen naar postmortem-documentatie en vervolgacties. Voor teams die JSM gebruiken als onderdeel van een bredere ITSM-software-setup, worden de incidentgegevens ook meegenomen in het bredere beeld van het servicemanagement.

JSM ondersteunt ook sterke Incidentencommunicatie tijdens de respons door teams te helpen bij:

• Het op de hoogte houden van, supportteams en belanghebbenden

• Het verminderen van verwarring tijdens actieve incidenten

• Het bieden van inzicht in de status en impact

• Duidelijker communiceren tijdens gebeurtenissen met hoge urgentie of crisismanagement-scenario's

Tegen de tijd dat het incident is afgesloten, heeft het team al een gedetailleerd overzicht van hoe het is verlopen, wat de postmortem makkelijker maakt om te documenteren en nuttiger voor toekomstige verbeteringen.

Leg de postmortem vast in Confluence

Zodra het incident is afgesloten, documenteer je het terwijl de details nog vers in je geheugen liggen — idealiter binnen 24 tot 48 uur. Hoe langer je wacht, hoe meer context verloren gaat en hoe minder nuttig de postmortem wordt. 

Maak een speciale Confluence-pagina aan met een incident-postmortemsjabloon en werk elk onderdeel door: tijdlijn, analyse van de hoofdoorzaak, impactbeoordeling en geleerde lessen. Het sjabloon voor incidentrespons op deze pagina biedt een compleet raamwerk dat je team kan kopiëren en invullen voor elk nieuw incident, zodat je niet elke keer opnieuw hoeft uit te zoeken wat je moet documenteren.

Het bijhouden van postmortems in Confluence biedt verschillende praktische voordelen:

• Inzicht voor het hele team: iedereen, van de technische afdeling tot het management, kan nagaan wat er is gebeurd zonder dat er contact hoeft te worden opgenomen met de dienstdoende medewerker voor een mondeling verslag..

• Patroonidentificatie: Wanneer elk incident in hetzelfde format wordt gedocumenteerd, wordt het veel gemakkelijker om terugkerende storingen en systemische zwaktes over kwartalen heen te herkennen.

• Blameless documentatie: Een gestructureerd sjabloon voor incidentrespons houdt het gesprek gericht op systemen en processen in plaats van met de vinger te wijzen, wat leidt tot eerlijkere en nuttigere rapportage.

• Snellere opstart voor nieuwe medewerkers: Nieuwe teamleden kunnen eerdere postmortems doorlezen om te begrijpen hoe je systemen zich gedragen onder druk en wat het team al heeft geleerd van eerdere incidenten.

Voor een uitgebreidere gids voor het uitvoeren van productieve postmortem-evaluaties lees je onze handleiding voor incident postmortems.

Volg vervolgacties als Jira-werkitems

Een postmortem is alleen nuttig als er ook een actie uit voortvloeit. Elke corrigerende actie en terugkerende issue die tijdens de beoordeling wordt geïdentificeerd, moet worden omgezet in een Jira-werkitem met een duidelijke eigenaar en een deadline. 

Dit is de stap die teams die daadwerkelijk verbeteren onderscheidt van teams die steeds weer tegen dezelfde problemen aanlopen. Wanneer corrigerende acties bestaan als traceerbare werkitems in Jira, kunnen managers de voortgang monitoren en kunnen teams elkaar verantwoordelijk houden voor het voltooien van de verbeteringen waar ze mee hebben ingestemd. Het helpt ook bij het stellen van prioriteiten. Wanneer incidentgerichte taken naast de rest van je backlog staan, kun je ze gemakkelijker afwegen tegen andere prioriteiten, in plaats van ze stilletjes onderaan de lijst te laten verdwijnen.

De juiste incidentmanagementtools verbinden deze hele workflow van begin tot eind. Wanneer je respons-, documentatie- en opvolgsystemen geïntegreerd zijn, wordt de kloof tussen het detecteren van een probleem en het voorkomen van herhaling aanzienlijk kleiner.

Sjabloon voor incidentrespons

Hieronder staat een sjabloon voor een incidentresponsplan dat je team kan kopiëren en aanpassen voor elk nieuw incident. Het doorloopt elke fase van een postmortem, van de eerste samenvatting en tijdlijn tot de analyse van de hoofdoorzaak, geleerde lessen en corrigerende maatregelen. Het gebruik van een consistente structuur voor elk incident zorgt ervoor dat niets over het hoofd wordt gezien en dat je postmortems gemakkelijk te vergelijken zijn in de loop van de tijd.

De voorbeelden in het sjabloon zijn slechts een uitgangspunt, geen vaststaand draaiboek. Pas de taal en het detailniveau aan zodat deze aansluiten bij hoe je organisatie werkt. Het doel is om voldoende context te documenteren zodat iedereen die de postmortem maanden later leest, precies kan begrijpen wat er is gebeurd en wat het team eraan heeft gedaan.

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 {time range of incident, e.g. 15:45 and 16:35} op {DATE} hebben {NUMBER} gebruikers {EVENT SYMPTOMS} ondervonden. 

De gebeurtenis werd veroorzaakt door een {CHANGE} om {TIME OF CHANGE THAT CAUSED THE EVENT}. 

De {CHANGE} bevatte {DESCRIPTION OF OR REASON FOR THE CHANGE, such as a change in code to update a system}. 

Een bug in deze code veroorzaakte {DESCRIPTION OF THE PROBLEM}. 

De gebeurtenis is gedetecteerd door {MONITORING SYSTEM}. Het team begon aan de gebeurtenis te werken door {RESOLUTION ACTIONS TAKEN}.

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

Er was verdere impact zoals opgemerkt door {e.g. NUMBER OF SUPPORT TICKETS SUBMITTED, SOCIAL MEDIA MENTIONS, CALLS TO ACCOUNT MANAGERS} die zijn geuit met betrekking tot 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} op {MM/DD/YY}, ({AMOUNT OF TIME BEFORE CUSTOMER IMPACT, e.g. 10 days before the incident in question}), werd een wijziging aangebracht in {PRODUCT OR SERVICE} met het oog op {THE CHANGES THAT LED TO THE INCIDENT}. 

Deze wijziging resulteerde in {DESCRIPTION OF THE IMPACT OF THE CHANGE}.

Storing

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

VOORBEELD:

{NUMBER} reacties zijn ten onrechte verzonden naar {XX%} van de aanvragen. Dit ging door gedurende {TIME PERIOD}.

Impact

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

VOORBEELD:

Voor {XXhrs XX minutes} tussen {XX:XX UTC and XX:XX UTC}  op {MM/DD/YY} hebben onze gebruikers last gehad van dit incident {SUMMARY OF INCIDENT}.

Dit incident had gevolgen voor {XX} klanten (X% VAN {SYSTEM OR SERVICE} GEBRUIKERS), die {DESCRIPTION OF SYMPTOMS} ondervonden.

{XX NUMBER OF SUPPORT TICKETS AND XX NUMBER OF SOCIAL MEDIA POSTS} zijn 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 incident werd ontdekt toen het {ALERT TYPE} werd geactiveerd en {TEAM/PERSON} werd opgeroepen. 

Vervolgens werd {SECONDARY PERSON} opgeroepen omdat de {FIRST PERSON} niet de eigenaar was van de service die naar de schijf schreef, waardoor de respons met {XX MINUTES/HOURS} werd vertraagd.

{DESCRIBE THE IMPROVEMENT} wordt opgezet door {TEAM OWNER OF THE IMPROVEMENT} zodat {EXPECTED IMPROVEMENT}.

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 {ON-CALL ENGINEER} online om {XX:XX UTC} in {SYSTEM WHERE INCIDENT INFO IS CAPTURED}. 

Deze technisch medewerker had geen ervaring met het {AFFECTED SYSTEM}. Daarom werd om {XX:XX UTC} een tweede waarschuwing verzonden naar {ESCALATIONS ON-CALL ENGINEER}, 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: 

{DESCRIBE THE ACTION THAT MITIGATED THE ISSUE, WHY IT WAS TAKEN, AND THE OUTCOME} 

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

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