Pre-Mortems zur Verhinderung von Post-Mortems: Proaktive Technik

Systeme versagen. Unsere Systeme hier bei FloQast sind fehleranfällig, ebenso wie die Systeme in Ihrem Unternehmen und sogar die Systeme dort drüben. Angesichts der Tatsache, dass Systeme ständig ausfallen, und zwar scheinbar zu den ungünstigsten Zeitpunkten, ist es ein Wunder, dass in unserer modernen Welt überhaupt etwas funktioniert!

Der Grund dafür, dass in unserer modernen Welt überhaupt etwas funktioniert, liegt darin, dass die Menschen sich auf diese Misserfolge vorbereitet haben.

Diese Vorbereitungen werden manchmal nicht genutzt und bleiben oft unbemerkt, aber sie sind vorhanden und wichtig. Verteilte Systeme, Notfallpläne, Backups, Redundanz - all das sind Vorbereitungen, auf die wir uns verlassen, um uns von einem Systemausfall zu erholen.

Ein weiterer Bestandteil dieses Werkzeugkastens ist die Pre-Mortem-Methode, eine Planungsmethode, die uns zwingt, darüber nachzudenken, wie unsere Projekte scheitern können.

Ein Pre-Mortem zum Projektumfang kann uns dabei helfen, Eventualitäten in unsere Entwicklungssprints einzubeziehen, während ein Pre-Mortem für eine Codebereitstellung uns dabei helfen kann, Risiken im Zusammenhang mit besonders heiklem Code zu erkennen. Auf diese Weise reduzieren wir das Chaos und die Verwirrung, die ein Fehler in der Produktion - eine ohnehin schon stressige Situation - so leicht mit sich bringen kann.

Mit anderen Worten: Ein Pre-Mortem hilft uns, ein Post-Mortem zu vermeiden.

Bei FloQast haben wir vor kurzem ein Pre-Mortem für ein Projekt durchgeführt, bei dem wir einen kritischen, zeitkritischen Prozess geändert haben, der in regelmäßigen Abständen läuft. Wir hielten diese Details in einem Dokument fest, damit wir sie leicht mit anderen Teammitgliedern teilen konnten. (Und es erwies sich als nützlich, als die Dinge anfingen, sich abnormal zu verhalten. Aber das ist ein Blogbeitrag für einen anderen Tag...)

Hier sind die Überlegungen, die wir in unserem Pre-Mortem aufgenommen haben:
(und ein Beispiel am Ende dieser Seite)

Überblick über das Projekt

Eine kurze Beschreibung des Was und Warum ist immer ein guter Einstieg. Wie würden wir jemanden, der zum ersten Mal von diesem Thema hört, auf den neuesten Stand bringen?

• Was genau wird durch das Projekt verändert?
• Warum ist die Änderung notwendig?
• Gibt es einen historischen Kontext, der für uns nützlich wäre, um ihn zu teilen?
• Wie würden wir das Risikoniveau für die Änderungen beschreiben?

Voraussichtlicher Zeitplan und Personen

So können wir auf einen Blick feststellen, wie weit die Arbeiten fortgeschritten sind und wer bei den einzelnen Schritten die richtigen Ansprechpartner sind, falls Fragen auftauchen. Wenn verschiedene Aktionen gleichzeitig stattfinden, können wir das hier ebenfalls vermerken.

• Wann sollen die Feierlichkeiten beginnen (z. B. Startzeit)?
• Wer ist an dem Projekt beteiligt, und welche Rollen/Verantwortlichkeiten haben sie? Wer wird die Systeme überwachen, und welche Systeme sollen überwacht werden?
• Wie lange wird es dauern, bis die Änderungen des Projekts wirksam werden? Arbeiten wir innerhalb eines engen Zeitfensters?

Es ist in Ordnung, wenn wir hier ungefähre oder relative Zeiten verwenden, auch wenn es sich um grobe Schätzungen handelt. Wir suchen nur nach einer schnellen Möglichkeit, ein Gefühl dafür zu bekommen, wie die Dinge voranschreiten.

Was ist der glückliche Weg?

Bereiten Sie sich auf das Schlimmste vor... aber erwarten Sie das Beste!

Wie sähe es aus, wenn alles genau nach Plan verliefe?

Wir können die Übersicht als Ausgangspunkt verwenden, die uns einen Überblick über die beteiligten Schritte gibt. Als Nächstes fügen wir Details zu jedem der Schritte hinzu, einschließlich technischer Aufschlüsselungen des Codes und der Systeme, die auf dem Weg dorthin beteiligt sind.

Es ist hilfreich, diese Informationen wie ein Skript darzustellen, denn so können wir uns auf das konzentrieren, was wir erwarten, dass es passiert. Abweichungen vom Drehbuch könnten ein Hinweis darauf sein, dass wir uns in die Gefahrenzone begeben.

Was kann schiefgehen?

Jetzt kommt der spaßige Teil: Zeit für ein Brainstorming, was für Probleme auftreten können!

In typischer Brainstorming-Manier gibt es keine falschen Antworten - wir sollten alles nennen, was die Dinge durcheinander bringen könnte.

Es ist wichtig, dass wir diese Probleme konkret benennen und allzu allgemeine Formulierungen vermeiden (z. B. "das Warteschlangensystem reagiert nicht mehr" im Gegensatz zu "es funktioniert nicht"), denn wir wollen bei dieser Gelegenheit auch darüber nachdenken, wie wir diese Probleme abmildern oder sogar verhindern können.

• Wie lautet eine kurze Beschreibung des Problems?
• Was sind die Symptome? Wie erkennen wir, ob wir uns in diesem Zustand befinden?
• Was sind die Auswirkungen auf den Endverbraucher?
• Sind die Daten überhaupt betroffen?
• Welche Maßnahmen können wir ergreifen, um dies zu vermeiden? Können wir das Problem ohne eine Code-Einführung beheben?
• Wenn wir das Problem beheben, gibt es danach zusätzliche Aufräumarbeiten?

Wenn wir diese Probleme aufzählen, lassen sich oft Muster erkennen. Vielleicht können wir sogar einige von ihnen in Gruppen zusammenfassen, wenn sie ähnliche Symptome oder Lösungen aufweisen.

Dies ist sehr nützlich, wenn wir auf einen Fehler stoßen, den wir in der Voruntersuchung nicht erwartet hatten; er könnte in eine der Gruppen passen, die wir bereits identifiziert haben, was uns einen Vorsprung bei der Suche nach einer Lösung verschafft!

Überlegungen zum Rollback

Leider können wir nicht alle Probleme einfach beheben oder umgehen. In solchen Situationen müssen wir überlegen, wie wir unsere Arbeit rückgängig machen können. Dies könnte zum Beispiel das Zusammenführen einer Revert-PR für eine Codebereitstellung, das Anhalten eines Dienstes oder sogar das Löschen von Daten sein, die während des Ereignisses erstellt wurden.

Wir wollen uns auf diese Situation im Voraus vorbereiten, denn die Wahrscheinlichkeit ist groß, dass wir sie zu einem Zeitpunkt heraufbeschwören, zu dem sich alle bereits auf andere Details konzentriert haben. Infolgedessen ist es eine Zeit, in der man leicht Fehler machen kann. Im Rahmen unserer jüngsten Voruntersuchung hatten wir eine Rückgängigmachungs-PR vorbereitet und überprüft, bevor wir loslegten. (Letztendlich haben wir uns dafür entschieden, sie nicht zu implementieren, aber es war trotzdem eine gute Absicherung. )

• Unter welchen Bedingungen sollten wir eine Rücknahme von Änderungen in Betracht ziehen?
• Wie wird ein Rollback durchgeführt?
• Wer muss das Rollback durchführen? (z. B. jemand mit merge Genehmigungen?)

Achten Sie auf die Lücke

Die wichtigsten Teilnehmer einer Pre-Mortem sind die Personen, die die Veranstaltung koordinieren. Dazu gehören Produktvertreter und andere Teammitglieder, die den Finger am Puls der User Experience haben. Es ist weniger wahrscheinlich, dass wir versehentlich etwas übersehen, wenn wir eine Vielzahl von Ideen und eine Vielzahl von Standpunkten aus verschiedenen Ebenen des Tech-Stacks haben.

Aber die Dokumentation hilft nur, wenn sie auch gelesen wird.

Daher sollten wir die Vorlieben unserer Teammitglieder berücksichtigen und das Dokument an ihre Bedürfnisse und ihren Stil anpassen.

Bei FloQast herrscht eine ziemlich lockere Atmosphäre, die sich in vielen unserer Dokumentationen widerspiegelt - einfache Sprache und ein entspannter Ton, mit einer hohen Wahrscheinlichkeit von GIFs.

Manche Teams fühlen sich jedoch mit einem strukturierten Format wohler: Sie verwenden einen förmlichen Ton oder eine technisch präzisere Sprache. Ebenso kann es sein, dass wir den allgemeinen Tenor bestimmter Themen kontrollieren wollen, um die Dinge auf Kurs zu halten.

Es kann eine Herausforderung sein, das richtige Gleichgewicht zu finden, aber das Wichtigste ist, dass es für alle einfach ist, den Pre-Mortem zu lesen und dazu beizutragen. Auf diese Weise können wir sicherstellen, dass alle auf der gleichen Seite stehen, wenn es hart auf hart kommt.

Joseph Miller

Joe ist Senior Software Engineer bei FloQast und trägt zur direkten ERP Integrationen bei und unterstützt andere Teams. In seiner Freizeit spielt er gerne Videospiele mit seinen Kindern und spielt Videospiele ohne seine Kinder.