Was ist Vorfallkommunikation?

Was ist Vorfallkommunikation?

Vorfallkommunikation heißt, die vom Ausfall Betroffenen zu informieren, solange er andauert: was nicht funktioniert, wer betroffen ist, was Sie tun und wann es das nächste Update gibt. Sie ist getrennt von der Incident Response, der technischen Arbeit, ein Problem zu erkennen, einzugrenzen und zu beheben. Die Response stellt den Dienst wieder her, die Kommunikation kümmert sich um alle, die darauf warten.

Beides läuft parallel und konkurriert um dieselbe Aufmerksamkeit. Deshalb kommt die Kommunikation oft zu kurz: Ein Team mitten im Datenbank-Failover hat keine Lust auf ein Update, genau dann wollen Kunden aber eines.

Die Phasen eines Updates

Die meisten Teams nutzen vier Standardbezeichnungen, die Leser schon kennen:

1. Untersuchung (Investigating): Es gibt ein Problem, die Ursache wird gesucht.
2. Ursache gefunden (Identified): Die Ursache ist bekannt, die Behebung läuft.
3. Beobachtung (Monitoring): Der Fix ist eingespielt, Sie prüfen, ob er hält.
4. Behoben (Resolved): Der Dienst läuft wieder normal.

Jedes Update wird demselben Vorfall hinzugefügt, statt einen neuen zu eröffnen, damit man den Ablauf später der Reihe nach nachlesen kann.

Ein Beispiel

Untersuchung, 14:05 UTC: "Einige Kunden können sich nicht anmelden. Wir prüfen das. Nächstes Update bis 14:30 UTC."
Ursache gefunden, 14:22 UTC: "Ein defekter Datenbankknoten verursacht die Anmeldefehler. Wir wechseln auf ein Replikat. Nächstes Update bis 14:45 UTC."
Beobachtung, 14:41 UTC: "Anmeldungen funktionieren wieder. Wir beobachten die Fehlerraten."
Behoben, 15:10 UTC: "Die Fehlerraten sind wieder normal. Wir veröffentlichen ein Postmortem."

Was ein Update nützlich macht

• Auswirkung in Kundensprache beschreiben. "Anmeldungen schlagen fehl" ist besser als "auth-service liefert 500".
• Sagen, was Sie wissen und was nicht. "Die Ursache ist noch unbekannt" ist ein vollwertiges Update und besser als Schweigen.
• Einen Zeitpunkt für das nächste Update zusagen, nicht für den Fix. Wann Sie wieder schreiben, steuern Sie selbst, wann der Fix wirkt, selten.
• Das erste Update früh posten. Eine kurze Meldung nach zehn Minuten schlägt eine ausführliche nach neunzig.
• Weder Schuld zuweisen noch herunterspielen. Beides kostet Vertrauen, in entgegengesetzter Richtung.

Typische Fehler

• Statusseite auf dem ausgefallenen System betreiben. Sie gehört auf getrennte Infrastruktur, damit sie den Ausfall übersteht.
• Verstummen, sobald der Fix "fast fertig" ist. Den Update-Rhythmus bis zum Status "Behoben" beibehalten.
• Unterschiedliche Aussagen an verschiedenen Orten. Einen Text verfassen und ihn per E-Mail, Chat und Social Media spiegeln.
• Den Eintrag danach löschen. Eine öffentliche Historie vergangener Vorfälle macht eine Statusseite glaubwürdig.
• Darauf warten, dass jemand daran denkt. Wenn ein Mensch das Posten auslösen muss, kommt es spät. Koppeln Sie das erste Update an Ihre Monitoring-Alarme.

Wo Updates erscheinen

Üblich ist eine Statusseite. E-Mail-Abos schicken Updates an Interessierte, ohne dass diese die Seite beobachten müssen. Geplante Arbeiten folgen demselben Muster mit Vorankündigung, siehe geplante Wartung. Vertragliche Verfügbarkeitszusagen behandelt das SLA-Management. Nach einem größeren Vorfall folgt oft ein Postmortem, das ein anderes Publikum und einen anderen Zweck hat als die Live-Updates.

So hilft LoadFocus

Die Statusseiten von LoadFocus ordnen Komponenten Ihren Monitoren zu. Laut Produktseite öffnet ein fehlschlagender Monitor bei aktivierten Auto-Incidents den Vorfall selbst auf der Seite, und Abonnenten werden beim Öffnen und beim Schließen benachrichtigt. Vorfälle haben einen Schweregrad (minor, major, critical) und durchlaufen investigating, identified, monitoring und resolved, danach kann ein Postmortem veröffentlicht werden. E-Mail-Abos nutzen Double-Opt-in, der kostenlose Plan umfasst 1 Seite, 10 Komponenten und 250 Abonnenten, Updates können auch an Slack oder einen Webhook gehen. Eigene Domains und private Seiten benötigen einen kostenpflichtigen Plan. Für das Monitoring dahinter siehe API-Monitoring; mehr zur Praxis in Monitoring Best Practices für DevOps und Entwickler.

Häufige Fragen: Vorfallkommunikation

Worin unterscheidet sich Vorfallkommunikation von Incident Response?

Die Response ist die technische Arbeit, das Problem zu finden und zu beheben. Kommunikation hält die Betroffenen währenddessen auf dem Laufenden. Beides läuft gleichzeitig und braucht meist unterschiedliche Personen.

Wie oft sollte ich während eines Vorfalls Updates posten?

Nennen Sie in jedem Beitrag den Zeitpunkt des nächsten Updates und halten Sie ihn ein, auch wenn es nur "keine Änderung" heißt. Ein verlässlicher Rhythmus zählt mehr als Detailtiefe.

Was gehört in das erste Update?

Dass Sie das Problem kennen, was Kunden sehen und wann das nächste Update kommt. Die Ursache brauchen Sie noch nicht.

Wo sollte die Statusseite gehostet werden?

Getrennt vom beschriebenen Dienst, damit sie auch bei einem Ausfall Ihrer eigenen Systeme erreichbar bleibt.

Sollte ich ein Postmortem veröffentlichen?

Bei größeren Vorfällen ist es hilfreich. Beschreiben Sie, was passiert ist, die Auswirkung, die Ursache und was sich nun ändert. Es entsteht nach dem Ereignis für ein breiteres Publikum als die Live-Updates.