Statusmeldungen bei Vorfällen: eine Vorlage und ein Takt

Ziel

Nutzende und interne Stakeholder informiert halten, während die Einsatzkräfte arbeiten, ohne diese in die Beantwortung von Fragen einzubinden, und eine Zeitleiste hinterlassen, die das Postmortem nutzen kann.

Voraussetzungen

Benannte Rollen: Das Google-SRE-Buch (zitiert) beschreibt eine Kommunikationsrolle, deren Inhaberin bzw. Inhaber das öffentliche Gesicht der Incident-Response-Taskforce ist und regelmässig Updates herausgibt; das SRE-Workbook (zitiert) nennt dies die Communications-Lead-Rolle, die dem Incident Commander unterstellt ist. Eine Statusseite oder ein Ankündigungskanal, eine Schweregradskala und vor dem Vorfall vereinbarte Vorlagen.

Schritte

1. Wird ein Vorfall ausgerufen, die Kommunikation einer Person zuweisen, die nicht debuggt. Besteht das Team aus zwei Personen, kommuniziert die Einsatzleitung, während die andere Person untersucht.
2. Das erste Update innerhalb einer festen Zeit nach Ausrufung veröffentlichen, auch wenn es nur besagt, dass ein Problem untersucht wird. Die Auswirkung aus Sicht der nutzenden Person beschreiben («Uploads schlagen seit 09:40 UTC mit einem Fehler fehl»), nicht die vermutete Ursache.
3. Für jedes Update dieselbe Vorlage verwenden: Status (wird untersucht, identifiziert, wird beobachtet, behoben), Auswirkung (wer, was, seit wann), Was bekannt ist, Was unternommen wird, Workaround falls vorhanden, Nächstes Update um eine Uhrzeit mit Zeitzone.
4. Den zugesagten Takt einhalten. Ein Update, das «keine Änderung; nächstes Update um 11:00 UTC» sagt, ist Information; ein ausgelassenes Update ist für die lesende Person ein zweiter Vorfall. PagerDutys öffentlicher Prozess (zitiert) weist nicht der Einsatzleitung, sondern der internen Verbindungsperson zu, der Geschäftsleitung etwa alle dreissig Minuten regelmässige Statusupdates zu liefern; einen Takt je Schweregrad festlegen und schriftlich festhalten.
5. Interne von externer Formulierung trennen. Interne Updates dürfen Systeme, Hypothesen und Personen nennen; externe Updates nennen für Nutzende sichtbare Auswirkungen und Workarounds und vermeiden Spekulation über die Ursache.
6. Bei der Behebung die Uhrzeit angeben, ob Daten verloren gingen oder sich verzögerten, was Nutzende tun müssen (nichts, erneut versuchen, erneut hochladen), und dass ein Postmortem mit Datum folgen wird.
7. Jedes Update wortgetreu aufbewahren; die Abfolge ist die Kommunikationszeitleiste für das Postmortem, neben dem Vorfalldokument, das das SRE-Buch beschreibt.

Erwartetes Ergebnis

Stakeholder hören auf, die Einsatzkräfte nach Neuigkeiten zu fragen, weil sie wissen, wann das nächste Update kommt; das Postmortem verfügt über genaue Zeitstempel dafür, was wann kommuniziert wurde.

Grenzen und Prüfbasis

Vertragliche oder regulatorische Meldepflichten liegen ausserhalb dieses Artikels. Vorlagen können nicht entscheiden, was gefahrlos offengelegt werden kann; das bleibt eine Einschätzung je Vorfall. Die Rollen und die Takt-Angabe stammen aus den zitierten Dokumenten; es wird keine Verkürzung der Vorfalldauer behauptet.