Close

De weg naar beter incidentmanagement begint hier

Startpagina incidentmanagement

Incident-postmortems

Bij Atlassian voeren we postmortems uit zonder een schuldige aan te wijzen om ervoor te zorgen dat we begrijpen wat de belangrijkste oorzaak van ieder incident met een niveau 2 of hoger is en dat we deze kunnen oplossen. Hier volgt een beknopte versie van onze interne documentatie waarin wordt beschreven hoe we postmortems uitvoeren bij Atlassian.

Handboek incidentmanagement

Krijg ons handboek fysiek of in pdf

We hebben een beperkt aantal gedrukte exemplaren van ons handboek 'Incidentmanagement', die we gratis verzenden. Je kunt ook een PDF-versie downloaden.


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.

Veld

Instructies

Voorbeeld

Incidentoverzicht

Vat het incident in een paar zinnen samen. Vermeld de ernst van het incident, de reden en hoe lang de impact gevoeld werd.

Tussen op , hadden klanten last va . De gebeurtenis werd getriggerd door een implementatie om . De implementatie omvatte een codewijziging voor . De bug in deze implementatie veroorzaakte .

De gebeurtenis is gedetecteerd door . We hebben het incident opgelost door .

Dit incident heeft invloed gehad op X% klanten.

zijn aangemaakt met betrekking tot dit incident.

Voorbereiding

Beschrijf de omstandigheden die tot het incident hebben geleid, bijvoorbeeld eerdere wijzigingen die verborgen bugs naar boven brachten.

Om op , (), is er een wijziging doorgevoerd in om ... . De wijziging veroorzaakte ... .

Storing

Beschrijf wat er niet zoals verwacht functioneerde. Voeg schermafbeeldingen toe van relevante grafieken of gegevens waarin de fout wordt aangetoond.

reacties zijn per abuis verzonden naar X% van de verzoeken in een periode van .

Impact

Beschrijf wat interne en externe klanten tijdens het incident zagen. Vermeld hoeveel support cases er zijn aangemaakt.

lang tussen op werd er ervaren.

Dit betrof klanten (X% van alle klanten), die hebben ervaren.

Er werden aangemaakt.

Detectie:

Hoe en wanneer ontdekte Atlassian het incident?

Hoe kan het incident sneller ontdekt worden? Hoe zou jij de tijd bijvoorbeeld gehalveerd hebben?

Het incident werd ontdekt toen het werd getriggerd en werd opgepiept. Deze persoon moest oppiepen, omdat hij of zij de niet verantwoordelijk was voor het schrijven van de service naar de schijf, waardoor de respons met werd vertraagd.

wordt ingesteld door zodat .

Reactie

Wie reageerde er en wanneer en hoe? Waren er vertragingen of obstakels in onze reactie?

Nadat de KITT-technicus om 14:34 uur UTC op de hoogte was gesteld, kwam deze om 14:38 uur online in de chatruimte voor incidenten. Deze dienstdoende technicus had echter onvoldoende achtergrondinformatie over de Escalator autoscaler. Om 14:50 uur is daarom nog een melding verzonden en om 14:58 uur was er een senior technicus online in de chatruimte.

Herstel

Beschrijf hoe en wanneer de service hersteld was. Op welke manier bereikte je het punt dat je wist hoe je het probleem moest oplossen?

Aanvullende vragen om te stellen, afhankelijk van het scenario: Hoe kan de tijd om iets op te lossen worden verminderd? Hoe zou jij de tijd bijvoorbeeld gehalveerd hebben?

Herstel was een drieledige reactie:

  • De omvang van het BuildEng EC2 ASG vergroten om het aantal nodes te verhogen dat beschikbaar is voor de workload 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

Geef een uitgebreide incidenttijdlijn, in chronologische volgorde, voorzien van een tijdstempel met tijdzone(s).

Voeg alle lead-ups, begin van impact, detectietijd, escalaties, beslissingen en wijzigingen, en einde van impact toe.

Alle tijden zijn in UTC.

11:48 uur - K8S 1.9 upgrade van besturingsvlak voltooid
12:46 uur - Goliath upgrade naar V1.9 voltooid, inclusief cluster-autoscaler en de BuildEng scheduler-instantie
14:20 uur - Build Engineering meldt een probleem aan de KITT Disturbed
14:27 uur - KITT Disturbed begint fouten te onderzoeken op een specifieke EC2-instantie (ip-203-153-8-204)
14:42 uur - KITT Disturbed zet de specifieke node af
14:49 uur - BuildEng meldt dat het probleem meer dan 1 node betreft. 86 instanties van het probleem laten zien dat fouten meer systematisch zijn
15:00 uur - KITT Disturbed stelt voor over te schakelen naar de standaard scheduler
15:34 uur - BuildEng meldt dat 300 pods niet werken
16:00 uur - BuildEng verwijdert alle mislukte versies met OutOfCpu-rapporten
16:13 uur - BuildEng meldt dat de fouten consequent weer optreden in nieuwe versies en niet alleen maar tijdelijk 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 berekening verwijdert om het probleem te verhelpen.
16:40 uur - KITT bevestigt dat ASG stabiel is, dat de cluster load normaal is en de impact op de klant is opgelost.

Vijf waaroms

Gebruik de identificatietechniek voor hoofdoorzaken.

Begin bij de impact en vraag waarom het is gebeurd en waarom het deze impact heeft. Blijf je afvragen waarom totdat je de hoofdoorzaak hebt achterhaald.

Noteer de 'waaroms' hier of in een diagram in de bijlage van de issue in een lijst.

  1. De service was buiten gebruik omdat de database vergrendeld was

  2. Omdat er te veel naar de database werd geschreven

  3. Omdat er een wijziging werd aangebracht aan de service en de toename onverwacht was

  4. Omdat we geen ontwikkelingsproces hebben ingesteld voor wanneer we testwijzigingen moeten laden

  5. We hebben nog nooit de belasting getest en ervaren een volledige nieuwe schaal

Hoofdoorzaak

Wat was de hoofdoorzaak? Dit is wat er moet veranderen om ervoor te zorgen dat dergelijke incidenten nog een keer voorkomen.

Een bug in de verwerking van een connectiepool heeft geleid tot gelekte connecties onder foutcondities, in combinatie met gebrek aan zichtbaarheid in connectiestaat.

Backlog controleren

Is er iets in de backlog dat dit had kunnen voorkomen of de impact enorm had kunnen verminderen? Zo ja, waarom is dit dan niet gebeurd?

Hier helpt een eerlijke assessment om eerdere beslissingen omtrent prioriteit en risico's te verduidelijken.

Niet specifiek. Verbeteringen aan flow typing waren bekende lopende taken waar standaardprocedures voor waren opgesteld (oftewel voeg flow types toe als je een bestand wijzigt/maakt). Er zijn tickets voor het herstellen van integratietests gemaakt, maar ze waren niet succesvol toen ze werden gebruikt

Herhaling

Is dit incident (met dezelfde hoofdoorzaak) eerder voorgekomen? Zo ja, waarom is het dan weer voorgekomen?

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

Geleerde lessen

Wat hebben we geleerd?

Bespreek wat er goed ging, wat er beter had gekund en waar we geluk mee hebben gehad om verbeterpunten te vinden.

  1. Er is een unittest nodig om te verifiëren dat de rate-limiter voor werk op de juiste manier is onderhouden

  2. Bulk workloads die niet typisch zijn voor de normale gang van zaken moeten worden bekeken

  3. Bulk ops moeten langzaam starten en worden gevolgd, en moeten verhoogd worden als servicestatistieken er normaal uitzien

Corrigerende maatregelen

Wat gaan we doen om ervoor te zorgen dat dergelijke incidenten niet nog een keer voorkomen? Wie voert de maatregelen uit en wanneer?

Maak 'Actie met prioriteit' issue-links naar issues die elkaar volgen.

  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

  4. Grote migraties moeten gecoördineerd worden, aangezien AWS ES niet automatisch schaalt.

  5. Stride-zoekopdracht verifiëren is nog steeds geclassificeerd als Tier-2

  6. Maak een ticket aan tegen pf-directory-service om gedeeltelijk te falen in plaats van volledig te falen als de xpsearch-chat-searcher faalt.

  7. Bekijk de melding in de cloud om een hoog IO-probleem te identificeren op de ElasticSearch cluster


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:

Scenario Directe oorzaak en actie Hoofdoorzaak Hoofdoorzaak

Stride "Red Dawn" squad's services had geen Datadog-monitors en oproepbare meldingen voor hun services, of ze waren niet correct geconfigureerd.

Teamleden hebben monitoring en meldingen voor nieuwe services niet geconfigureerd.

Configureer het voor deze apparaten.

Er is geen proces voor het instellen van nieuwe services, wat onder andere monitoring en meldingen omvat.

Creëer een proces voor het instellen van nieuwe services en leer het team dit proces te volgen.

Stride onbruikbaar op IE11 door een upgrade naar Fabric Editor die niet werkt op deze browserversie.

Een upgrade van een afhankelijkheid.

Maak de upgrade ongedaan.

Gebrek aan compatibiliteitstests tussen browsers.

Automatiseer continue compatibiliteitstests tussen browsers.

Logbestanden van Micros EU bereikten de logservice niet.

De rol die aan micro's was toegewezen om logbestanden te verzenden, was incorrect.

Corrigeer de rollen.

We kunnen niet zien wanneer loggen vanuit een omgeving niet werkt.

Voeg monitoring en meldingen toe aan ontbrekende logbestanden voor alle omgevingen.

Getriggerd door een eerder AWS incident hebben Confluence Vertigo-knooppunten hun connectiepool naar Media uitgeput, wat geleid heeft tot onderlinge bevestiging en mediafouten voor klanten.

AWS fout.

Haal de AWS postmortem op.

Een bug in de verwerking van Confluence connectiepool heeft geleid tot gelekte connecties onder foutcondities, gecombineerd met een gebrek aan zichtbaarheid in verbindingsstatus.

Los de bug op en voeg monitoring toe die vergelijkbare toekomstige situaties detecteert voordat ze een impact hebben.


Categorieën hoofdoorzaken en bijbehorende acties

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

Categorie

Definitie

Wat moet je doen?

Insect

Een wijziging van code gemaakt door Atlassian (dit is een speciaal soort wijziging)

Test. Speel proefkonijn. Rol stapsgewijs uit en houd in de gaten wat er gebeurt. Gebruik markeringsfuncties. Overleg met de kwaliteitsspecialist.

Wijziging

Een door Atlassian doorgevoerde wijziging (anders dan coderen)

Verbeter de manier waarop je wijzigingen doorvoert, zoals de wijzigingsbeoordelingen of processen voor wijzigingsmanagement. Alles naast 'bug' is hier ook van toepassing.

Schalen

Niet kunnen schalen (zoals blind voor beperkte beschikbaarheid van resources, of gebrek aan capaciteitsplanning)

Wat zijn de beperkingen van de resources voor de service? Worden ze gemonitord en volgen er meldingen? Als je geen capaciteitsplan hebt, stel er dan een op. Als er wel een capaciteitsplan is, met welke nieuwe beperking moet je dan rekening houden?

Architectuur

Ontwerp verkeerde uitlijning met operationele omstandigheden

Bekijk je ontwerp kritisch. Moet je platformen wijzigen?

Afhankelijkheid

Servicefout van derden (niet van Atlassian)

Beheer je de risico's van fouten door derden? Hebben we het zakelijke besluit genomen om een risico te accepteren, of moeten we oplossingen bedenken? Zie 'Hoofdoorzaken met afhankelijkheden' hieronder.

Onbekend

Ondefinieerbaar (actie moet kans om te diagnosticeren vergroten)

Verbeter de observeerbaarheid van het systeem door loggen, monitoren, debuggen en vergelijkbare zaken toe te voegen.


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.

Categorie Te stellen vraag Voorbeelden

Onderzoek dit incident

'Wat heeft dit incident veroorzaakt en waarom?' De hoofdoorzaak achterhalen is het ultieme doel.

Analyse van logbestanden, diagram maken van het verzoektraject, problemen bekijken

Los dit incident op

'Welke maatregelen hebben we onmiddellijk genomen om deze specifieke gebeurtenis op te lossen en te managen?'

Terugdraaien, meest geschikte kiezen, configuraties pushen, communiceren met betrokken gebruikers

Herstel schade van dit incident

'Hoe hebben we directe of indirecte schade als gevolg van dit incident hersteld?'

Gegevens herstellen, machines repareren, omleidingen verwijderen

Ontdek toekomstige incidenten

'Hoe kunnen we meer tijd vrijmaken om op een accurate manier een vergelijkbare fout te detecteren?'

Monitoren, melden, controle van de juistheid van input/output

Los toekomstige incidenten op

'Hoe kunnen we de ernst en/of duur van toekomstige incidenten als deze verhogen?'

'Hoe kunnen we de volgende keer dat het gebeurt het percentage gebruikers dat last heeft van deze fout verminderen?'

Respectvolle afbraak; niet-kritieke resultaten laten vallen; openlijk falen; huidige praktijken aanvullen met dashboards of playbooks; incidentproces wijzigen

Voorkom toekomstige incidenten

'Hoe kunnen we voorkomen dat een dergelijke fout nog een keer voorkomt?'

Stabiliteitsverbeteringen in de codebasis, grondigere unittests, invoervalidatie en robuustheid voor foutcondities, wijzigingen op het gebied van provisioning

We gebruiken ook het advies van Lueder en Beyer over hoe we onze postmortem-acties onder woorden moeten brengen.

Postmortem-acties onder woorden brengen:

De juiste woorden voor een postmortem-actie kunnen het verschil betekenen tussen een eenvoudige afronding en oneindige vertraging als gevolg van niet-haalbaarheid of uitstelling. Een goed doordachte postmortem-actie moet aan de volgende voorwaarden voldoen:

Concreet: Breng iedere actie onder woorden als een zin die met een werkwoord begint. De actie moet resulteren in een bruikbaar resultaat, niet in een proces. 'Som de lijst met kritieke afhankelijkheden op' is bijvoorbeeld een goede actie, terwijl 'Onderzoek afhankelijkheden' dat niet is.

Specifiek: Definieer de omvang van iedere actie zo nauwkeurig mogelijk, en maak duidelijk wat wel en niet onderdeel is van het werk.

Begrensd: Stel iedere actie dusdanig op dat er verteld wordt wanneer het gereed is, in plaats van de actie open te laten of voort te laten slepen.

Van... Tot...

Onderzoek monitoring voor dit scenario.

(Concreet) Voeg meldingen toe voor alle gevallen waarin deze service >1% fouten retourneert.

Los het probleem op dat de onderbreking veroorzaakte.

(Specifiek) Ga zorgvuldig om met postcode in gebruikersadres van input.

Zorg ervoor dat de technicus controleert of het databaseschema geparseerd kan worden voordat er wordt bijgewerkt.

(Begrensd) Voeg een automatische controle voorafgaand aan verzending toe voor schemawijzigingen.


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.