Incident-postmortems

Wat is een postmortem?

Een postmortem is een geschreven document van een incident waarin het volgende wordt beschreven:

• De impact van het incident.
• De genomen maatregelen om het incident te voorkomen of op te lossen.
• De belangrijkste oorzaak van het incident.
• Genomen vervolgmaatregelen om te voorkomen dat het incident weer optreedt.

Bij Atlassian volgen we alle postmortems met Jira-issues om ervoor te zorgen dat ze worden voltooid en goedgekeurd. Je kunt ervoor kiezen een eenvoudiger systeem te gebruiken, zoals een Confluence-pagina voor iedere postmortem, als je behoeften minder complex zijn.

Waarom voeren we postmortems uit?

Het doel van een postmortem is begrijpen wat alle bijdragende hoofdoorzaken zijn, het incident documenteren voor toekomstige referentie, patronen ontdekken en voldoende voorzorgsmaatregelen invoeren om de impact van het incident te verkleinen, en te voorkomen dat het nog een keer optreedt.

Om effectieve postmortems op te stellen die ervoor zorgen dat incidenten minder vaak voorkomen, moet het beoordelingsproces het team stimuleren hoofdoorzaken te achterhalen en ze op te lossen. De exacte methode hangt af van uw teamcultuur; bij Atlassian hebben we een combinatie van methodes gevonden die werken voor onze incidentresponsteams:

• Fysieke meetings helpen de juiste analyse te achterhalen en het team op één lijn te krijgen over wat er opgelost moet worden.
• Goedkeuringen van postmortems door managers van het leverings- en operationsteam stimuleren teams om ze correct uit te voeren.
• Speciale 'acties met prioriteit' hebben een afgesproken serviceniveaudoel (Service Level Objective (SLO)) van 4 of 8 weken, afhankelijk van de service, met herinneringen en rapporten om ervoor te zorgen dat ze worden voltooid.

Dit proces naleven en ervoor zorgen dat het effectief is, vereist commitment op alle niveaus binnen de organisatie. Onze engineering directors en managers beslissen over de goedkeurders en SLO's voor oplossing van acties in hun gebieden. Dit systeem codeert alleen maar en probeert hun besluiten door te voeren.

Wanneer moet er een postmortem worden uitgevoerd?

We voeren onze postmortems uit voor niveau 1 en 2 incidenten. In alle andere gevallen zijn ze optioneel.

Tijdens of kort na het oplossen van de issue, maakt de verantwoordelijke persoon voor de postmortem een nieuwe postmortemissue.

Wie voltooit de postmortem?

Het leveringsteam van de foutieve service (het team dat de 'Verkeerde service' heeft geleverd van de incidentissue) moet de postmortem uitvoeren. Het team selecteert de verantwoordelijke persoon voor de postmortem en wijst de postmortemissue aan hem/haar toe.

• De verantwoordelijke persoon voor de postmortem verwerkt de postmortem via schetsen en goedkeuring, tot het moment dat deze wordt gepubliceerd. Diegene is verantwoordelijk voor het voltooien van de postmortem.
• Een of meer goedkeurders van de postmortem bekijken de postmortem en keuren deze goed, en er wordt van ze verwacht dat ze vervolgacties prioriteren in hun backlog.

We hebben een Confluence-pagina waarop de goedkeurders van de postmortem (verplicht en optioneel) worden weergegeven per servicegroep, wat over het algemeen overeenkomt met een Atlassian-product (bijvoorbeeld Bitbucket Cloud).

Hoe worden acties voor postmortems gevolgd?

Voor iedere actie die voortvloeit uit de postmortem:

• Maak een Jira-issue aan in het backlog van het desbetreffende team. Alle postmortem-acties moeten worden gevolgd in Jira.
• Koppel ze van de postmortem-issue als 'Actie met prioriteit' (voor oplossingen van hoofdoorzaken) of 'Actie ter verbetering' (voor verbeteringen zonder belangrijke oorzaak).

We hebben een aantal aangepaste rapporten opgesteld met behulp van de Jira REST API's om te volgen van hoeveel incidenten van ieder niveau de hoofdoorzaken niet zijn opgelost via de acties met prioriteit in de postmortem. De engineering managers van alle afdelingen bekijken de lijst regelmatig.

Postmortemproces

Tijdens het postmortem-proces moet er ook een postmortem-issue worden aangemaakt, een postmortem-meeting worden gehouden, acties worden bepaald, goedkeuring worden verkregen en moet (optioneel) de uitkomst worden gecommuniceerd .

De verantwoordelijke voor de postmortem moet de volgende taken uitvoeren:

1. Maak een postmortem aan en koppel deze aan het incident.
2. Bewerk de postmortem-issue, neem de veldbeschrijvingen door en vul de velden in.
3. Gebruik de techniek van de 'Vijf waaroms' om de belangrijkste oorzaak van het incident te achterhalen en de oorzakelijke verbanden na te gaan totdat je een goede ware belangrijke oorzaak vindt.
4. Plan de postmortem-meeting. Nodig het leveringsteam, betrokken teams en belanghebbenden uit aan de hand van het sjabloon voor uitnodigingen voor meetings.
5. Kom samen met het team en neem de agenda hieronder door.
6. Blijf contact houden met de verantwoordelijke ontwikkelingsmanagers om de commitment te krijgen voor bepaalde acties om dergelijke incidenten te voorkomen.
7. Maak een Jira-issue aan voor iedere actie in de backlogs van de teams die er verantwoordelijk voor zijn. Koppel ze van de postmortem-issue als 'Actie met prioriteit' (voor oplossingen voor hoofdoorzaken) of 'Actie ter verbetering' (voor overige verbeteringen).
8. Zoek de juiste goedkeurders op in Confluence en voeg ze toe aan het veld 'Goedkeurders' in de postmortem.
9. Selecteer de transitie 'Goedkeuring aanvragen' om goedkeuring aan te vragen bij de aangewezen goedkeurders. Er wordt automatisch gereageerd op de issue met instructies voor goedkeurders.
10. Volg de juiste procedures tot de postmortem is goedgekeurd.
11. Als de postmortem is goedgekeurd, wordt er automatisch een conceptversie van de postmortem blog opgesteld in Confluence die je kunt bewerken en publiceren. Door een postmortem in een blog te zetten, kun je de harde lessen die je hebt geleerd, delen met anderen.

Als het postmortem-proces is voltooid, worden de acties op prioriteit ingedeeld door het ontwikkelingsteam als onderdeel van hun normale backlog volgens de SLO van het team.

Postmortemmeetings

Wij vinden dat een teamdiscussie over de geleerde lessen resulteert in een diepere analyse van hoofdoorzaken. Dit gebeurt vaak aan de hand van een videoconferentie, omdat onze teams verspreid zijn, en vindt soms plaats in groepen als er grote groepen mensen bij incidenten zijn betrokken.

De agenda die wij voorstellen:

1. Herinner het team eraan dat het niet de bedoeling is van een postmortem om een schuldige aan te wijzen (en waarom dat zo is)
2. Bevestig de tijdlijn met gebeurtenissen
3. Bevestig de hoofdoorzaken
4. Genereer acties aan de hand van 'open denken': 'Wat kunnen we doen om dergelijke incidenten in de toekomst te voorkomen?'
5. Vraag het team 'Wat er goed ging/Wat er beter had gekund/Waar we geluk mee hebben gehad'

Voorgesteld agendasjabloon:

Ik nodig je graag uit voor een postmortem over , waarbij we .

Het doel van een postmortem is begrijpen wat alle bijdragende hoofdoorzaken zijn, het incident documenteren voor toekomstige referentie, patronen ontdekken en voldoende voorzorgsmaatregelen invoeren om de impact van het incident te verkleinen, en te voorkomen dat het nog een keer optreedt.

Tijdens deze vergadering willen we graag de hoofdoorzaken achterhalen en bepalen welke acties er moeten worden genomen om ze te voorkomen.

Als de verantwoordelijke ontwikkelingsmanagers niet aanwezig zijn, spreek dan geen specifieke acties af tijdens de meeting, aangezien dit een slechte context is voor het prioriteren van besluiten. Mensen voelen zich onder druk gezet om in te stemmen en hebben niet alle informatie. Bespreek dit in plaats daarvan na de meeting met de verantwoordelijke managers om afspraken te maken over het uitvoeren van de geïdentificeerde acties met prioriteit.

Velden postmortemissue

Onze postmortem-issue heeft verschillende velden om alle belangrijke details te kunnen verzamelen over het incident voordat de postmortem-meeting wordt gehouden. Hieronder staan een aantal voorbeelden van hoe we deze velden invullen.

Directe oorzaken en hoofdoorzaken

Als je een postmortem schrijft of leest, maak dan onderscheid tussen de directe en hoofdoorzaak.

• Directe oorzaken zijn redenen die rechtstreeks naar dit incident hebben geleid.
• Hoofdoorzaken zijn redenen op een optimale plek in de reeks gebeurtenissen waarbij als er een wijziging wordt doorgevoerd, al deze incidenten worden voorkomen.

Een postmortem zoekt naar hoofdoorzaken en besluit hoe deze het best opgelost kunnen worden. De echte kunst van een postmortem is het vinden van de optimale plek in de reeks gebeurtenissen. Gebruik een techniek als de Vijf waaroms om de 'reeks na te gaan' en hoofdoorzaken te vinden.

Hier volgen een paar specifieke voorbeelden van directe en hoofdoorzaken:

Categorieën hoofdoorzaken en bijbehorende acties

Wij gebruiken deze categorieën voor het groeperen van hoofdoorzaken en om de juiste acties ervoor te bespreken.

Hoofdoorzaken met afhankelijkheden

Als de service een incident heeft omdat een afhankelijkheid faalt, dan hangt de locatie van de fout en hoofdoorzaak af van het feit of de afhankelijkheid intern voor Atlassian is of van een derde, en van de redelijke prestatieverwachting van de afhankelijkheid.

Als het een interne afhankelijkheid betreft, stel dan de vraag 'wat is het Service Level Objective (SLO) van de afhankelijkheid?':

• Heeft de afhankelijkheid inbreuk gedaan op de SLO?
  • De fout ligt bij de afhankelijkheid en de betrouwbaarheid moet worden verbeterd.
• Is de afhankelijkheid binnen de SLO gebleven, maar ging de service toch fout?
  • De veerkracht van de service moet worden verbeterd.
• Heeft de afhankelijkheid geen SLO?
  • Dat is wel nodig!

Als het een afhankelijkheid van een derde betreft, vraag dan 'wat is onze redelijke verwachting* van de beschikbaarheid/wachttijd/etc. van de afhankelijkheid van de derde?'

• Heeft de afhankelijkheid van een derde onze verwachtingen (op een verkeerde manier) overtroffen?
  • Onze verwachtingen klopten niet.
    • Zijn we ervan overtuigd dat het niet weer gebeurt? Bijvoorbeeld We bekijken hun RCA en gaan ermee akkoord. In dit geval is hun RCA de actie.
    • Of moeten we onze verwachtingen bijstellen? In dit geval moeten de acties onze veerkracht vergroten en onze verwachtingen bijstellen.
    • Zijn onze aangepaste verwachtingen onacceptabel? In dit geval moeten we de verschillen tussen vereisten en oplossing op een bepaalde manier oplossen, oftewel een andere leverancier zoeken.
• Is de afhankelijkheid van een derde binnen onze verwachtingen gebleven, maar ging de service toch fout?
  • In dit geval moet de veerkracht van de service vergroot worden.
• Hebben we echt een verwachting?
  • De eigenaar van de afhankelijkheid van een derde moet dit bepalen, en dit met teams delen zodat zij weten welk veerkrachtniveau ze in hun afhankelijke services moeten inbouwen.

*Waarom 'verwachting'? Hebben we geen SLA's met derden? In werkelijkheid zijn contractuele SLA's met derden te laag om fouten en oplossingen te bepalen. AWS publiceert bijvoorbeeld bijna geen SLA voor EC2. Daarom moeten we, als we op services van derden rekenen, een besluit nemen over welke betrouwbaarheid, beschikbaarheid, prestaties of andere belangrijke statistieken we van ze verwachten.

Postmortemacties

Sue Lueder en Betsy Beyer van Google hebben een uitstekende presentatie en artikel over postmortem actie-items, die we bij Atlassian gebruiken om het team te stimuleren.

Neem onderstaande vragen door om ervoor te zorgen dat de PIR oplossingen voor de korte en lange termijn dekt:

'Toekomstige incidenten oplossen' en 'Toekomstige incidenten voorkomen' zijn de meest waarschijnlijke bron voor acties die de hoofdoorzaak aanpakken. Zorg ervoor dat je ten minste één hiervan implementeert.

Goedkeuringen voor postmortems

Atlassian gebruikt een Jira-proces met een goedkeuringsstap om ervoor te zorgen dat postmortems worden goedgekeurd. Goedkeurders zijn over het algemeen service-eigenaars of andere managers met verantwoordelijkheid voor de uitvoering van een service. Goedkeuring voor een postmortem geeft aan:

• Overeenstemming met de resultaten van de beoordeling na het incident, inclusief wat de hoofdoorzaak was; en
• Overeenstemming dat de gekoppelde 'Acties met prioriteit' een acceptabele manier zijn om de hoofdoorzaak aan te pakken.

Onze goedkeurders vragen vaak om aanvullende acties of identificeren bepaalde oorzakelijke verbanden die niet door de voorgestelde acties worden aangepakt. Op deze manier zien we dat goedkeuringen veel waarde toevoegen aan het postmortem-proces bij Atlassian.

In teams met minder incidenten of een minder complexe infrastructuur, hoeven postmortem-goedkeuringen niet nodig te zijn.

Postmortems zonder een schuldige aan te wijzen

Als er zaken fout gaan, zit het in de menselijke aard om een schuldige aan te wijzen. Voor Atlassian is het echter het beste om dit te voorkomen. Als je dus een postmortem uitvoert, ga dan dus bewust niet op zoek naar een schuldige. We gaan er altijd vanuit dat al onze medewerkers de beste intenties hebben en wijzen nooit schuldigen aan voor een fout. De postmortem moet de omstandigheden die tot de fout hebben geleid eerlijk en objectief onderzoeken, zodat we de echte hoofdoorzaak/hoofdoorzaken kunnen achterhalen en ze op kunnen lossen. Een schuldige aanwijzen brengt dit in gevaar, omdat:

• Als mensen bang zijn voor hoe hun collega's tegen ze aankijken of bang zijn voor hun carrièremogelijkheden, heeft dit meestal voorrang boven 'de zakelijke belangen van mijn werkgever' in hun persoonlijke hiërarchie, dus zullen ze de waarheid verdraaien of verbergen om hun basisbehoeften te beschermen.
• Zelfs als iemand een actie heeft uitgevoerd die rechtstreeks tot een incident heeft geleid, moeten we niet vragen 'waarom heeft persoon x dit gedaan', maar 'waarom kom hij of zij dit binnen het systeem doen, of hoe kon hij of zij binnen het systeem denken dat dit het juiste was om te doen'.
• Mensen ergens de schuld van geven is onaardig en als dit vaak genoeg gebeurt, creëert dit een cultuur van angst en wantrouwen.

In onze postmortems gebruiken we deze technieken om persoonlijke veiligheid voor alle deelnemers te creëren:

• Open de postmortem-meeting door te zeggen dat dit een postmortem is zonder schuldvraag en waarom
• Noem mensen bij hun functie (bijv. 'de dienstdoende Widgets-technicus' en niet bij naam (maar blijf wel helder en duidelijk over de feiten)
• Zorg ervoor dat de tijdlijn, oorzakelijke verbanden en oplossingen verwerkt zijn in de context van systemen, proces en rollen, niet individuen.

Onze inspiratie voor postmortems zonder schuldigen en het handige concept van 'tweede verhalen' is afkomstig uit het oorspronkelijke artikel van John Allspaw.