Blameless Canvas für Nachbearbeitungen

Diese „blameless" Post-Mortem-Vorlage hilft dir, Informationen über Zwischenfälle in der Produktion zu sammeln. Indem du diesen Prozess befolgst, können Ingenieure, deren Handlungen zu einem Unfall beigetragen haben, einen detaillierten Bericht geben über:

• welche Aktionen sie zu welcher Zeit durchgeführt haben,

• welche Effekte sie beobachtet haben,

• Erwartungen, die sie hatten,

• Annahmen, die sie gemacht hatten,

• ihr Verständnis der Zeitachse der Ereignisse, wie sie sich ereignet haben.

• und dass sie diesen detaillierten Bericht ohne Angst vor Bestrafung oder Vergeltung geben können.

Das Blameless-Postmortem umfasst die folgenden Abschnitte

Schritt 1: Zusammenfassung (vor dem Meeting ausfüllen)

Eine hochrangige Zusammenfassung des Vorgangs, die sich darauf konzentriert, was derzeit bekannt ist und welchen Einfluss dies auf den Kunden hatte. Halte dich an ein bis zwei Sätze.

2. Schritt: Grobe Zeitachse (im Voraus vor dem Meeting ausfüllen)

Ein grober Zeitrahmen des Vorgangs. Je nachdem, wie schnelllebig der Vorgang war, könnte sich diese Zeitachse über einige Minuten, Stunden oder Tage erstrecken. Wenn du den Fokus hauptsächlich darauf legst, die Reaktionszeiten des Teams bei Notfällen zu verbessern, möchtest du das bis auf die Sekunde genau schaffen.

Wenn du die Zeitachse erstellst, vergiss nicht, Folgendes einzubeziehen:

• Wann der Vorgang gemeldet wurde und durch wen/welchen Prozess

• Welche Maßnahmen wurden ergriffen

• Als die Kommunikation ins Team hinein und heraus erfolgte

Abhilfemaßnahmen-Ideen

• Wenn du dich triffst, um den Vorgang zu besprechen, lade alle ein, die an dem Vorgang gearbeitet haben. Das umfasst das Produktionsteam für Support sowie die Mitglieder des Kundensupport-Teams, die eventuell beteiligt gewesen sind.

• Überprüfe die Zusammenfassung, überprüfe den Zeitablauf und füge fehlende Teile hinzu, dann gehe zu den Sanierungsideen über.

• Diese Fragen sind formuliert, um dem Team zu helfen, Verantwortung für das Problem zu übernehmen. Es gibt einige Probleme, die sich anfühlen, als wären sie außerhalb der Kontrolle des Teams (z. B. wenn ein Rechenzentrum den Strom verliert). Aber selbst bei solchen Ereignissen kann das Team seine Reaktion auf die Katastrophe noch verbessern.

3. Schritt: Erkennen – Wie können wir dieses oder ein ähnliches Problem früher erkennen?

Nehmen wir an, dieses Problem oder ein sehr ähnliches Problem wird erneut auftreten. Wie kann das Support-Team dieses Problem schneller erkennen und finden, bevor es ein Kunde tut?

4. Schritt: React – Wie können wir unsere Reaktion auf solche Vorgänge verbessern?

Gehe davon aus, dass der Vorgang gemeldet ist. Wie schnell war die Reaktion? Sind Minuten verloren gegangen, während Personen E-Mails hin und her geschickt haben, um jemanden dazu zu bringen, sich das Problem anzusehen?

Wie kann das Team beim nächsten Auftreten dieses Problems schneller oder organisierter reagieren?

Schritt 5: Schnelle Abhilfe – Wie stoppen wir die Blutung schneller?

Wenn dies erneut passiert, gibt es eine fertige Lösung, die wir dem Kunden anbieten können, um die Auswirkungen des Problems zu verringern?

Wenn dies etwas ist, das sich im Laufe der Zeit verschlimmert (wie ein DDoS-Angriff), haben wir dann eine schnelle Möglichkeit, die Schleusen zu schließen, während wir die Ursache herausfinden?

Schritt 6: Verhindern – Wie können wir solche Vorgänge in Zukunft verhindern oder deren Auswirkungen verringern?

Dies ist oft die einzige Frage, die Teams in einem Postmortem stellen. Es ist eine wichtige Frage und du solltest viel Zeit hier verbringen. Wenn du dich jedoch nur darauf beschränkst, zu fragen, wie ein Vorgang verhindert werden kann, übernimmst du keine Verantwortung für die Dinge, die in deinem Einflussbereich liegen (wie du einen Vorgang erkennst, darauf reagierst oder ihn schnell behebst).

Während du Ideen entwickelst, beschränke dich nicht nur auf technische Lösungen. Bessere Überwachung, bessere Kommunikationswege, besseres Training, dafür sorgen, dass die Personen im Kundensupport die Personen im Produktionssupport namentlich kennen usw.

Schritt 7: Weitere Risikobereiche – Welche anderen Bereiche weisen dieselbe Verwundbarkeit auf?

Jeder Vorgang ist ein Hinweis darauf, wo Ihr System Schwachstellen hat. Wahrscheinlich gibt es für jeden gefundenen Vorgang Dutzende, die im Verborgenen lauern und noch entdeckt werden müssen.

So als ob du eine Maus in deiner Küche siehst. Du hast kein "Maus"-Problem, sondern ein "Mäuse"-Problem.

Es gibt wahrscheinlich andere Teile des Systems, die die gleichen Designannahmen teilen oder in einigen Fällen den gleichen Code verwenden (nicht, dass jemand jemals Code kopieren/einfügen würde).

Verbringe ein paar Minuten damit, zu brainstormen, welche anderen Orte auf ähnliche Weise anfällig sind.

Wenn Teams gestresst und überarbeitet sind, lassen sie diesen Schritt aus. Ich finde, dass dies die wichtigste Frage ist, um das Team zu einem proaktiven Denken zu bewegen und die Häufigkeit von Problemen in der Zukunft zu reduzieren.

Schritt 8: Nächste Schritte (Aktionen)

Nachdem du alle möglichen Maßnahmen zur Verbesserung der Erkennung, Reaktion, schnellen Behebung und Vermeidung von Vorgängen identifiziert hast und die anderen Bereiche deiner App, die Aufmerksamkeit benötigen, gefunden hast, gehe dazu über, zu entscheiden, welche Schritte unternommen werden sollen.

Die Art und Weise, wie du diese priorisierst, liegt bei dir. Aber ich habe ein paar Ratschläge.

Vor dem Verlassen des Meetings solltest du für jede Aktion, die du umsetzen möchtest, einen Namen und ein Datum festlegen.

Wenn jemand im Meeting begeistert davon ist, eine der Aktionen durchzuführen, ermutige ihn dazu, auch wenn du denkst, dass es vielleicht nicht das Wichtigste ist, das behoben werden muss.

Namen und Daten

Im Allgemeinen habe ich festgestellt, dass Teams diese Übung genießen (vorausgesetzt, du kannst eine schuldfreie Umgebung für das Meeting schaffen). Sie mögen es, das Problem zu analysieren und Lösungen zu brainstormen. Jeder fühlt sich jedoch beschäftigt und überarbeitet. Wenn dieses Meeting nicht mit Eigentümern und Terminen für die zu erledigenden Aufgaben endet, ist die Wahrscheinlichkeit groß, dass keine der Verbesserungen umgesetzt wird.

Was passieren wird, ist, dass in 3 Wochen das gleiche Problem erneut in der Produktion auftaucht (diesmal in größerem Maßstab) und jemand sagen wird: "Oh ja, wir haben darüber gesprochen, das zu beheben." Kein großartiger Ort zum Verweilen.

Um dem entgegenzuwirken, stelle einfach sicher, dass neben jeder Aktion, die die Gruppe durchführen möchte, ein Name und ein Datum stehen.

Basierend auf dem David Frink Blameless Postmortem Canvas.