Ein Post-Mortem wird häufig im Projekt-Management eingesetzt, um zu analysieren, warum ein Projekt nicht erfolgreich abgeschlossen werden konnte. Im Bereich IT Operations habe ich das Konzept als RCA (Root Cause Analysis) kennengelernt.
In der Software-Entwicklung habe ich dieses Konzept bisher noch nicht angetroffen. Auf Störungen im Betrieb wird meistens durch das Erstellen und Bearbeiten von Tickets reagiert.
Wir haben Post-Mortem bei uns vor mehr als einem Jahr eingeführt und pflegen ein Dokument, in dem wir jeden Vorfall eintragen und die daraus abgeleiteten Maßnahmen protokollieren.
| Datum | Anwendung / Server | Welche Funktion hat die Anwendung / der Server | Kritikalität | Ursache der Störung | Verantwortlich | Gelöst am |
|---|---|---|---|---|---|---|
Besonders interessant ist hier, dass wir wiederkehrende Probleme leichter erkennen können und auch feststellen können, an welcher Stelle es vermehrt Probleme gibt.
Damit können wir ein typisches Problem adressieren, welches durch das „Tagesgeschäft“ verursacht wird. Im Tagesgeschäft kümmern wir uns um dringendes, nämlich das akute Problem schnell beheben, bevorzugt in der Weise, dass wir einen „Quick-Hack“ umsetzen und die Lösung des eigentlichen Problems verschieben.
„Ich habe den Server neugestartet, jetzt läuft die Anwendung wieder …“
Denn die eigentliche Lösung ist zwar wichtig, aber nicht dringend.