De waarschuwings- en op afroep-functies van Opsgenie zijn nu beschikbaar in Jira Service Management en Compass. Migreer bestaande Opsgenie-gegevens en -configuraties vóór 5 april 2027 met behulp van onze geautomatiseerde migratietool.
Sjabloon voor incident-postmortems
Duidelijke documentatie is essentieel voor effectieve incidentpostmortems. Veel teams gebruiken een uitgebreide sjabloon om consistent details te verzamelen tijdens elke postmortembeoordeling.
Hieronder vind je een voorbeeld van een sjabloon voor incidentpostmortems die is gebaseerd op de postmortem die wordt beschreven in onze Incidentengids. Je kunt deze met knippen en plakken overnemen om je eigen postmortems te documenteren.
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:
De toepassing viel uit omdat de database was vergrendeld
De database is vergrendeld omdat er te veel schrijfbewerkingen naar de database zijn geweest
Omdat we een wijziging in de service hebben doorgevoerd en de verhoogde schrijfbewerkingen niet hadden verwacht
Omdat we geen ontwikkelingsproces hebben vastgesteld voor wijzigingen in belastingtests
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:
Snelheidsbeperking handmatig automatisch schalen tijdelijk ingesteld om fouten te beperken
Unittest en herintroductie van snelheidsbeperking taak
Introductie van een secundair mechanisme om gedistribueerde snelheidsgegevens te verzamelen rond cluster om schaaleffecten te begeleiden
Voor jou aanbevolen
Tutorial
Ontdek incidentcommunicatie met Statuspage
In deze tutorial laten we je zien hoe je incidentsjablonen kunt gebruiken om effectief te communiceren tijdens storingen. Aanpasbaar voor de vele soorten serviceonderbrekingen.
Meer informatie over incidentmanagement
Vind meer handleidingen en bronnen voor incidentmanagement in deze hub.
Het belang van een postmortemproces bij incidenten
Een postmortemincident, ook wel bekend als een beoordeling na een incident, is de beste manier om door te werken wat er tijdens een incident is gebeurd en geleerde lessen vast te leggen.