Text size
Auf meinem Radar6 Min. Lesezeit

Wenn Dinge kaputt gehen: Vorfälle und unschuldige Nachbeurteilungen

Die Rollen, die Nachrichten und die Postmortem-Vorlage, die ich benutze.

When things break: incidents and blameless postmortems
KI-generierte Illustration

Jedes System bricht irgendwann zusammen. Was gute Teams von schwierigen unterscheidet, ist nicht, ob sie Zwischenfälle haben. Es geht darum, wie sie damit umgehen: ruhig oder chaotisch, und ob sie danach etwas lernen oder einfach weitermachen und auf den nächsten warten.

Hier ist der Vorfallprozess, den ich bevorzuge, und wie man Postmortems schreibt, die tatsächlich Dinge verbessern.

Vor dem Vorfall: Entscheiden Sie, wie Sie arbeiten werden

Vorfälle sind stressig. Stress macht Menschen schlecht im Improvisieren. Entscheiden Sie sich also im Voraus für die Grundlagen:

  • Schweregrad, mit klaren Beispielen.
  • Wer verkündet einen Vorfall, und wie (eine Chat-Anweisung, ein Button, ein Anruf).
  • Wo sich die Leute versammeln: ein spezieller Chat-Kanal pro Vorfall, sowie bei Bedarf ein Anruf.
  • Funktionen, damit jeder weiß, wer was macht.
  • Kommunikationsvorlagen, so dass Updates schnell und konsequent veröffentlicht werden.

Eine einfache Schweregradskala:

Schwere Bedeutung Beispiel
Die Große Auswirkungen auf viele Nutzer oder Kerngeschäft Alle sind ausgegangen.
Die Bedeutende Auswirkungen, eine Umgehungsmethode oder ein teilweiser Ausfall Zahlungsunfähigkeit für einen Anbieter
Die Leichte Auswirkungen, begrenzte Nutzer Ein nicht kritisches Merkmal ist kaputt.

Wenn Sie Zweifel haben, sagen Sie höher. Es ist leicht zu degradieren.

Wer was in einem Vorfall macht

Die wichtigste Rolle ist die Vorfallkommandant (IC)- Ich weiß . Die IC löst das Problem nicht. Sie koordinieren: stellen sicher, dass die richtigen Leute involviert sind, Entscheidungen getroffen werden und nichts durch die Risse fällt.

Weitere gemeinsame Aufgaben:

  • Operationen / SachverständigeDie Leute, die tatsächlich untersuchen und reparieren.
  • Kommunikationsleiter: schreibt Aktualisierungen für Stakeholder und Kunden, damit sich die Ingenieure konzentrieren können.
  • Schreiber: hält eine Zeitleiste von dem, was geschehen ist und was entschieden wurde. (Dies ist in zunehmendem Maße durch KI-Tools unterstützt.)

In einem kleinen Team kann eine Person mehrere Rollen übernehmen. Das ist in Ordnung, solange jemand klar verantwortlich ist.

In einem Zwischenfall ist die gefährlichste Situation, wenn fünf kluge Leute alles gleichzeitig reparieren, ohne dass jemand weiß, was die anderen geändert haben.

Während des Vorfalls

Ein paar Gewohnheiten, die einen großen Unterschied machen:

  • Erst mildern, dann untersuchen. Zurückrollen, umfallen, skalieren, die Feature Flag ausmachen. Finden Sie die Ursache, sobald die Benutzer wieder gesund sind.
  • Sag, was du machst, bevor du es tust.: "Ich werde die Zahlungsarbeiter jetzt neu starten". Es vermeidet widersprüchliche Aktionen.
  • Schreib die Dinge in den Kanal auf.: Beobachtungen, Hypothesen, Maßnahmen, Ergebnisse.
  • Regelmäßige Aktualisierungen"Befinden noch Untersuchungen, nächstes Update in 30 Minuten".
  • Wissen, wann es zu eskalieren ist. Ein anderes Team frühzeitig einzuziehen ist besser als eine Stunde lang allein zu kämpfen.

Eine einfache Status-Aktualisierungsvorlage:

[SEV2] Zahlungsunfähigkeit, Untersuchung. Seit 14:05 Uhr MEZ scheitern rund 10% der Kartenzahlungen. Andere Zahlungsmethoden funktionieren. Wir untersuchen ein mögliches Problem mit unserem Zahlungsanbieter. Nächstes Update um 14:45.

Nach dem Vorfall: Unschuldige Nachbeobachtungen

Eine Leichenuntersuchung ist eine schriftliche Analyse dessen, was passiert ist und wie man es verhindern kann. Unschuldig Das bedeutet, dass der Fokus auf dem System liegt, nicht auf dem, der einen Fehler gemacht hat.

Warum schuldlos? Weil Menschen ständig Fehler machen, und Systeme sollten dafür entwickelt werden. Wenn man sich aus einem Vorfall auskennt: "Alex hätte vorsichtiger sein sollen", ändert sich nichts, außer dass die Leute ihre Fehler verstecken. Wenn der Takeaway lautet: "Unser Bereitstellungsvorgang lässt eine nicht getestete Konfiguration ohne Überprüfung in die Produktion gelangen", können Sie den Prozess beheben.

Fragen zu stellen:

  • Was machte diesen Fehler so leicht?
  • Warum haben unsere Tests, Bewertungen oder Überwachungen es nicht erkannt?
  • Was machte es schwierig, es zu erkennen, zu diagnostizieren oder zu beheben?
  • Was ist gut gelaufen? (Schließe immer das hier mit ein.)

Meine Nachblutvorlage

  1. ZusammenfassungEin Manager kann zwei oder drei Sätze verstehen.
  2. AuswirkungenDie Frage ist, wer betroffen ist, wie und wie lange. Zahlen, wenn möglich.
  3. Zeitplan: Schlüssereignisse mit Zeitstempeln, vom Auslöser bis zur vollen Auflösung.
  4. Ursache und beitragende Faktoren: in der Regel mehrere Faktoren kombiniert, nicht eine einzige Ursache.
  5. ErmittlungWie haben wir das herausgefunden? Wie konnten wir das früher erfahren?
  6. AntwortWas hat uns geholfen, was hat uns verlangsamt.
  7. Was gut gelaufen ist.
  8. Aktionspunkte: spezifisch, mit Eigentümer und Fälligkeitsdatum.
  9. Lernt.

Sicherstellen, dass Aktionspunkte stattfinden

Das häufigste Versagen bei Postmortems: tolle Analyse, eine Liste von Aktionspunkten, und dann passiert nichts. Die Fixes konkurrieren mit den Feature-Arbeiten und verlieren.

Was hilft:

  • Wenige wichtige Aktionspunkte statt einer langen Wunschliste.
  • In der normalen Nachlaufmenge verfolgt, nicht ein separates Dokument.
  • Regelmäßig überprüft, zum Beispiel in einer monatlichen Treffen zur Zuverlässigkeit.
  • Unterstützung der Führung, so dass die Lösung der Ursache eines Vorfalls als echte Arbeit gilt.

Hilfreiche Hilfsmittel

Incident.io, Rootly, FireHydrant, PagerDuty, Jira Service Management und andere automatisieren den Prozess: Erstellen von Kanälen, Zuordnung von Rollen, Zeitplanung, Posting von Statusaktualisierungen und Erstellung von Postmortem-Entwürfen. Nützlich, aber Prozess und Kultur sind wichtiger als Werkzeug.

Also, wo fange ich an?

Einig auf drei Schweregrads, die Rolle des Vorfallkommandanten, und eine Postmortem-Vorlage. Führen Sie einen kurzen Übungsinzident ("Spieltag") durch, damit die Leute den Prozess vor einem echten kennen. Dann, nach dem nächsten echten Vorfall, schreiben Sie eine schuldlose Obduktion und folgen Sie seinen Handlungen.

Meine Meinung: Unfälle werden passieren. Handeln Sie mit ihnen ruhig um, lernen Sie ehrlich daraus und beheben Sie das System, anstatt die Person zu beschuldigen.

Desly