Eine öffentliche Statusseite ehrlich betreiben: Komponenten, Automatisierung und Historie

Worum es geht

Eine öffentliche Statusseite listet die Komponenten eines Diensts mit ihrem aktuellen Zustand auf, kündigt geplante Wartungsarbeiten an und führt eine Historie von Vorfällen mit ihren Aktualisierungen. Sie ist kein internes Monitoring: Sie berichtet, was Nutzende erleben, in deren Worten, und wird am meisten an den Tagen gelesen, an denen der Dienst ausfällt.

Warum es wichtig ist

Nutzende und Support-Personal prüfen die Seite, bevor sie Tickets öffnen; Partnerteams und automatisierte Clients lesen sie oder ihren Feed, um zu entscheiden, ob sie es erneut versuchen oder ihre eigenen Leute alarmieren. Eine Seite, die während eines Ausfalls „alle Systeme betriebsbereit“ meldet, kostet mehr Vertrauen, als gar keine Seite zu haben.

So wird es angewendet

• Die Seite, ihr DNS und ihre Domain bei Anbietern hosten, die nichts mit dem Dienst teilen: anderes Hosting, anderes CDN, im Idealfall eine andere Registrierstelle. Eine Seite, die mit dem Dienst ausfällt, ist Dekoration.
• Komponenten danach wählen, was Nutzende unterscheiden können: Web-App, API, E-Mail-Zustellung, Zahlungen; nicht interne Cluster-Namen. Die Liste kurz genug halten, dass jede Komponente einen eigenen, für Nutzende sichtbaren Fehlermodus hat.
• Die Zustände (betriebsbereit, eingeschränkt, teilweiser Ausfall, grosser Ausfall, Wartung) in Begriffen der Nutzenden definieren und die Definitionen schriftlich festhalten, damit zwei Personen konsistent posten.
• Postingrechte allen im Bereitschaftsdienst geben und Freigabeschritte entfernen. Die erste Aktualisierung darf nur sagen „untersuche Meldungen zu Fehlern in X“ und wann die nächste Aktualisierung kommt.
• Während eines Vorfalls in festem Rhythmus posten, auch ohne Neuigkeiten; Schweigen wirkt wie Aufgeben.
• Die offensichtliche Hälfte automatisieren: Ein externer Sensor, der mehrere Minuten lang fehlschlägt, darf eine Komponente automatisch auf „eingeschränkt“ umschalten, wobei eine Person bestätigt oder korrigiert. „Behoben“ nicht automatisieren; eine Person bestätigt die Wiederherstellung aus Sicht der Nutzenden.
• Wartungsfenster im Voraus ankündigen, mit Beginn, erwartetem Ende und erwarteter Auswirkung in einer benannten Zeitzone, und sie schliessen, wenn die Arbeit erledigt ist.
• Die Vorfallshistorie öffentlich halten, mit einem Link zur Postmortem-Zusammenfassung; sie zeigt, wie der Dienst mit Fehlern umgeht.

Stolpersteine

Komponentenzustände, die eine Region widerspiegeln, während Nutzende anderswo ausfallen. Ein Zustand „eingeschränkt“, der so oft verwendet wird, dass er nichts mehr bedeutet. Historie nachträglich bearbeiten oder löschen. Verfügbarkeitsprozentsätze, die der Seitenanbieter aus Sensordaten berechnet, die nicht der Nutzererfahrung entsprechen. Eine Seite, deren einzige Leserschaft das Team ist, das sie schreibt, weil niemand sie vom Produkt und den Fehlerseiten aus verlinkt hat.