Zum Inhalt

Post-Mortems

Ein Post-Mortem ist eine schriftliche Auswertung eines Incidents. Ihr Zweck ist herauszufinden, was passiert ist, warum es möglich war und was sich ändert, damit es nicht wieder passiert. Es geht nicht darum, jemanden zu finden, dem man die Schuld gibt.

Schreibe eines für jeden Incident mit Severity 1, für jeden Major Incident (Incident Management) und für jeden anderen Incident, aus dem das Team etwas gelernt hat, das es wert ist, geteilt zu werden. Ein vernünftiges Ziel ist ein Entwurf innerhalb von fünf Arbeitstagen. Teile ihn mit dem betroffenen Kunden oder den betroffenen Workload-Teams. Im Managed-Modell schreibt das Plattform-Team (XMMS) ihn und der Kunde prüft ihn. Im Eigenbetrieb schreibt dein eigenes Plattform-Team ihn für seine Stakeholder.

Prinzipien

  • Ohne Schuldzuweisung. Beschreibe, was die Beteiligten damals wussten und entschieden haben. Frag, was im Prozess oder im Tooling den Fehler ermöglicht hat.
  • Erst die Fakten. Eine Timeline mit Zeitstempeln vor den Schlussfolgerungen. Verwende eine Zeitzone und nenne sie.
  • Ursache und beitragende Faktoren. Es gibt selten nur eine Ursache. Benenne den Auslöser und die Bedingungen, die ihn ermöglicht oder verschlimmert haben.
  • Aktionen haben einen Owner und ein Datum. Eine Aktion ohne Owner passiert nicht. Verfolge die Aktionen im selben Backlog wie andere Plattformarbeit und prüfe sie im operativen Meeting.
  • Halte kundenidentifizierende Daten aus der geteilten Kopie heraus (Namen von Personen, IDs, interne Links). Verwende Rollen und Ressourcentypen.

Auswirkungsskala

Verwende eine feste Skala, damit Berichte vergleichbar sind. Ein Beispiel:

Auswirkung Bedeutung
Critical Keine funktionierende Verbindung oder kein funktionierender Service für Produktion. Mehrere Anwendungen unbenutzbar
Severe / High Eine Produktionsanwendung oder ein Service ist unbenutzbar, oder eine Ressource wurde zerstört oder hat Daten verloren
Medium Kurze Unterbrechungen, die in Logs sichtbar waren, aber keine Beschwerden von Nutzern
Low Keine sichtbare Auswirkung. Beinahe-Vorfall

Template

Kopiere dies in eine neue Seite, eine Seite pro Incident. Nenne sie <date> | <short description>.

# <date> | <short description>

## Summary
Two to five sentences: what happened, what was the impact, how it was fixed.

## Impact
Level (see the impact scale), who was affected, for how long.

## Timeline
All times in <time zone>.

| Time | What happened | Who |
|---|---|---|
| hh:mm | Incident reported / detected | reporter / monitoring |
| hh:mm | ... | ... |
| hh:mm | Service restored | ... |

## Root cause
The trigger, and why the platform or the process allowed it. If the cause is not
confirmed, say so and say what is assumed.

## What went well
What worked and should be kept.

## Learnings
What the team would do differently, and what it did not know.

## Actions
| Action | Owner | Due | Status |
|---|---|---|---|
| ... | ... | ... | Open / Done |

Beispiel-Erkenntnisse

Die folgenden Erkenntnisse sind aus Post-Mortems echter Incidents auf Managed Platforms verallgemeinert. Sie sind Beispiele für das Format und für die Art von Erkenntnis, die es wert ist, festgehalten zu werden. Die Details, einschließlich Namen und Zahlen, wurden entfernt.

Eine WAF-Einstellung verursachte 403-Fehler auf Produktionsanwendungen
Auswirkung Severe: Mehrere Produktionsanwendungen hinter dem Application Gateway waren nicht erreichbar
Auslöser Zwei Tage zuvor wurde eine WAF-Einstellung (Prüfung des Request Body) eingeschaltet, weil ein Dokumentations-Review fragte, warum sie aus war, und das Einschalten wie eine naheliegende Härtung aussah. Sie wurde nicht getestet, und es gab keinen Change-Eintrag
Erkennung Ein Nutzer meldete 403 Forbidden. Die WAF-Logs zeigten zutreffende Regeln
Behebung Die zutreffenden Regeln wurden vorübergehend deaktiviert. Danach wurde die Einstellung ausgeschaltet und die Regeln wieder aktiviert. Etwa drei Stunden von der Meldung bis zur Lösung
Beitragende Faktoren Keine Testumgebung für WAF-Änderungen. Der Kunde wurde über die Änderung nicht informiert. Der Incident wurde zunächst als Service-Anfrage und nicht als P1 behandelt, obwohl Anwendungen ausgefallen waren

Erkenntnisse:

  • Teste WAF- und firewall-Änderungen zuerst in der Plattform-Umgebung canary, mit realen Verkehrsmustern, bevor sie auf prod gehen. Siehe Application Gateway und Change-Workflow.
  • Jede Änderung an der Plattform hat einen Change-Eintrag, auch eine „kleine“ Einstellung. Unangekündigte Änderungen machen Incidents schwerer zu diagnostizieren.
  • Registriere einen Incident mit Produktionsauswirkung als P1, was auch immer die erste Meldung sagt.

Eine große firewall-Änderung lief in das Apply-Timeout, und die Behebung machte es schlimmer
Auswirkung Medium: kurze Verkehrsunterbrechungen in den firewall-Logs sichtbar, keine Beschwerden von Nutzern. Gleichzeitig wurde ein zweiter, unabhängiger Fehler gemeldet
Auslöser Eine Produktionsänderung, die in einem Deployment 16 firewall rule collections hinzufügte und 8 zerstörte
Was passiert ist Der canary-Lauf war bereits in das Terraform-Timeout gelaufen. Das Team machte auf prod trotzdem weiter. Azure akzeptiert keine gleichzeitigen Updates mehrerer Regelsätze, daher wurden die Updates in eine Warteschlange gestellt, und das Apply wurde durch das Timeout abgebrochen. Einige Collections waren in Azure erstellt worden, fehlten aber im state. Ein erneuter Lauf scheiterte mit „already exists“. Um die restlichen Regeln schnell einzuspielen, zerstörte das Team bestehende Collections und erstellte sie neu
Beitragende Faktoren Die 8 Destroys liefen zuerst, sodass der Verkehr bereits ohne Regeln war, während die Adds erneut versucht wurden. Ein fehlender privater DNS-Eintrag verursachte gleichzeitig 502-Fehler, wodurch der Incident größer wirkte als die firewall-Änderung

Erkenntnisse:

  • Ein Timeout auf canary ist ein Stoppsignal. Mache die Änderung rückgängig, teile sie in kleinere pull requests auf und deploye diese einzeln nacheinander.
  • Wenn eine Regel durch eine neue ersetzt wird, deploye zuerst die neue Regel und entferne die alte in einer späteren Änderung.
  • Bei „already exists“-Fehlern importiere die Ressource in den state (terraform import). Zerstöre keine Produktionsressourcen, nur damit der state passt. Lies zuerst den Plan (Firewallregeln).
  • Sag dem Kunden vor der Änderung, dass kurze Unterbrechungen möglich sind, und gib während des Deployments Updates.
  • Prüfe, ob zwei Symptome wirklich dieselbe Ursache haben (Incident Management).

Eine Site-to-Site-VPN-Verbindung zeigte connected, ließ aber keinen Verkehr durch
Auswirkung Critical: keine funktionierende Verbindung zwischen Produktions-Workloads on-premises und in Azure
Auslöser Unbekannt. Logs auf der Azure-Seite zeigten nichts. Der Status der Verbindung war connected
Behebung Ein Major-Incident-Call mit dem On-Premises-Netzwerkpartner. Die Verbindung wurde auf beiden Seiten zurückgesetzt (den Link bearbeiten und ohne Änderungen speichern). Der erste Reset half nicht; ein zweiter auf der Azure-Seite stellte den Verkehr einige Minuten später wieder her
Ursache Nicht bestätigt. Vermutlich eine kurze Störung auf einer Seite, die den Verkehr unterbrach und den Tunnel nicht richtig neu startete

Erkenntnisse:

  • Betreibe, wo möglich, zwei Verbindungen, damit ein Fehler kein Ausfall ist.
  • Alarmiere auf fließenden Verkehr, nicht nur auf eine Statusänderung. Nimm das in deine Monitoring-Regeln auf.
  • Lege vorher fest, wer welche Seite in welcher Reihenfolge zurücksetzen darf.

Weitere Erkenntnisse in Kürze

  • Eine Benennung, die die Umgebung doppelt enthält, führt zu falschen Löschungen. Auf einer Managed Platform war ein Konfigurationssatz nach einer Umgebung benannt, sodass die von ihm erstellte VM diese Umgebung doppelt im Namen trug. Der falsche Satz wurde entfernt und eine Daten-Disk zerstört. Halte Umgebungsnamen aus den Namen von Konfigurationssätzen heraus, vergleiche den Plan mit den tatsächlichen Ressourcen, bevor du ein Destroy anwendest, und bitte den Owner, die genaue Ressource zu bestätigen, bevor du löschst. Das Vier-Augen-Prinzip funktioniert nur, wenn die zweite Person die tatsächlichen Ressourcen prüft, nicht nur den Code.
  • Ein Destroy, das auf halbem Weg fehlschlug, hinterlässt eine halb gebaute Ressource. Wenn ein Destroy fehlschlägt, zum Beispiel weil eine VM gestoppt war und ihre Extensions nicht entfernt werden konnten, prüfe, was noch da ist und was der erneute Lauf neu erstellt. Eine neu erstellte Daten-Disk ist leer und nicht angehängt.
  • Probleme, die erst nach Wochen auffallen, sind teuer. Prüfe das Ergebnis einer Behebung am echten Service (Mounts, Daten, Verkehr), nicht nur an einer grünen pipeline.