Post mortems voor een betrouwbaar platform

Hoe zorg je ervoor dat de grote verstoringen nooit meer kunnen voorkomen?
Zelfs met een grondige voorbereiding van de vele releases kunnen er dingen fout gaan, ook op een live platform zoals Floriday (dat we i.s.m. Royal FloraHolland ontwikkelen) met ruim 4000 actieve gebruikers. Wanneer er iets echt fout gaat is de eerste prioriteit om alles zo snel mogelijk weer werkend te krijgen, maar daarna willen we dit zorgvuldig dichttimmeren. Ons geheime wapen om deze storingen te voorkomen heeft Leon al eerder kort aangestipt, de post mortem.
In dit stuk wil ik wat dieper ingaan op wat een post mortem inhoudt en waarom wij bij jem-id hier zo fan van zijn.

Wat is een post mortem?
Hoewel het een beetje luguber klinkt vind ik “post mortem” wel een gepaste term. Na een storing, na de dood van de storing dus eigenlijk, onderzoeken we wat er tijdens de storing precies is gebeurd en hoe dit heeft kunnen gebeuren. Ik begeleid samen met de andere storingscoordinatoren deze post mortems. Hierbij worden niet alleen de ontwikkelaars betrokken maar eventueel ook de support- en communicatie teams. We hebben voor de post mortems altijd dezelfde structuur:

• Algemene informatie zoals wat, wanneer, hoe lang;
• Korte aanvullende beschrijving van de storing;
• Impact beschrijving van de storing;
• Signalering en opvolging in een tijdlijn;
• De snelle oplossing tijdens de storing;
• Constructieve oplossing(en) om het te kunnen voorkomen;
• Review op onze communicatie naar de getroffen gebruikers;
• Actielijst per team.

Wat is er precies gebeurd?
We starten altijd met een uitgebreide tijdlijn, in ieder geval vanaf het begin van de storing en het liefst al vanaf de oorzaak. Deze tijdlijn trekken we door tot aan het moment dat de gebruikers op de hoogte werden gesteld dat alles weer naar behoren werkt. We verspreiden deze tijdlijn voor de post mortem bijeenkomst zodat iedereen goed is voorbereid. Oorzaken en gevolgen kunnen zo in het overleg goed gepinpoint worden en ook de keuzes die op dat moment genomen zijn kunnen beoordeeld worden op waarom ze wel of niet hebben gewerkt.

Blameless!
Een post mortem werkt alleen als hij blameless wordt uitgevoerd. Tijdens de post mortem worden namelijk niet de personen beoordeeld maar de manier waarop we onze processen op dat moment hadden ingericht en hebben opgevolgd in die specifieke situatie. Er wordt dus niet gekeken naar wie en waarom iemand een fout heeft gemaakt maar waarom er überhaupt ruimte was om die fout te laten gebeuren. Door hem blameless te houden vergroot je de kans dat alles boven tafel komt, er moet geen schaamte zijn om bepaalde fouten toe te geven.

Wat levert een post mortem ons dan op?
Als we de oorzaken van het probleem hebben gevonden kunnen we die afvangen met de juiste lange termijn oplossingen. Deze oplossingen worden dan omgezet in een concrete actielijst voor de betrokken teams, met per punt een deadline die we later nog kunnen nalopen. Dit zijn vaak technische punten maar kunnen ook afspraken zijn die tussen support, operationele teams of de ontwikkelaars worden gemaakt. Denk hierbij aan het vroegtijdig signaleren van mogelijke storingen of een vaste checklist om storingen extern te communiceren. Het afvinken van die actielijst levert dan echt een beter platform op. Hierdoor hebben we eigenlijk steeds minder vaak de “grote” post mortem nodig.

Binnen Floriday zijn de verschillende onderdelen namelijk ondergebracht in zogenaamde losstaande services met elk hun eigen taak binnen het grote geheel. Wanneer een enkele service problemen heeft ondervonden proberen we de verbeteringen meteen breder te trekken voor alle componenten binnen Floriday. Een storing die bijvoorbeeld afgelopen april de service heeft geraakt die het aanbod omvatte heeft ervoor gezorgd dat we onze catalogus-, verkooporder-service hebben kunnen verbeteren.

Uiteindelijk geen post mortem meer nodig?
Je zou bijvoorbeeld als iets bijna fout is gegaan nog een “post (near) mortem” kunnen doen en je interne processen alsnog op die manier aanscherpen. Verder zou je bij spannende projecten of wijzigingen ook een “pre mortem” kunnen doen. Dan doe je net of iets fout zal gaan en kijk je vooraf al hoe je dit zou kunnen opvangen, oplossen of voorkomen.

Ook wat voor jouw organisatie?
Wij vinden het wel belangrijk om een strak post mortem stappenplan klaar te hebben liggen voor als er een storing heeft plaatsgevonden, zelfs als het bijna niet meer gebeurt. Als je zelf interesse hebt in zo’n stappenplan zijn er online veel templates te vinden, maar neem gerust contact met ons op om een indruk te krijgen over hoe wij hier invulling aan geven en hoe we met de post mortem onze processen en producten blijven verbeteren!

Interessante linkjes:

• Template van Atlassian;
• Voorbeeld van een openbare post mortem van Moneybird.