Was ist eine Statusseite und was gehört darauf

Was auf eine Statusseite gehört

Eine Statusseite hat drei Ebenen, und der größte Teil des Nutzens liegt in den ersten beiden.

Die oberste Ebene ist der aktuelle Zustand jeder von Ihnen aufgeführten Komponente. Komponenten sind die Teile, die ein Kunde auseinanderhalten kann: die Website, die API, das Dashboard, Logins, der Zahlungsablauf, ein Mobile-App-Backend. Der Zustand ist meist eine kurze Skala statt einer binären Aussage, sodass Sie "beeinträchtigt" für einen Dienst sagen können, der langsam ist, aber antwortet, statt zwischen einem grünen Haken, der falsch ist, und einem roten Kreuz, das schlimmer ist, wählen zu müssen.

Die mittlere Ebene ist der Vorfall-Feed. Jeder Vorfall ist ein kurzer Eintrag mit einer Startzeit, einer klaren Beschreibung dessen, was Kunden bemerken werden, und Aktualisierungen, die angehängt werden, während sich die Lage ändert, mit einer abschließenden Lösungsnotiz. Vergangene Vorfälle bleiben sichtbar, was aus der Seite ein Protokoll statt eines Lichtschalters macht.

Die unterste Ebene ist die Historie: Uptime über die letzten 30 oder 90 Tage je Komponente. Sie ist der am wenigsten dringliche Teil und der, der am häufigsten von Menschen gelesen wird, die Sie bewerten.

Öffentlich oder privat

Eine öffentliche Statusseite steht jedem mit dem Link offen, und sie ist die richtige Wahl, wenn Ihre Kunden die allgemeine Öffentlichkeit sind oder wenn Sie eine SLA veröffentlichen. Sie fängt während eines Ausfalls außerdem Traffic von Menschen ab, die gar keine Kunden sind.

Eine private Statusseite ist auf angemeldete Kunden oder ein internes Publikum beschränkt. Teams nutzen sie, wenn die Komponentenliste interne Architektur offenlegen würde, wenn Vorfälle namentlich genannte Enterprise-Kunden betreffen, oder wenn die Seite interne Systeme abdeckt, die kein Außenstehender auflisten sollte. Der Kompromiss ist, dass jeder, der sie nicht erreichen kann, stattdessen den Support kontaktiert.

Für welche Variante Sie sich auch entscheiden, hosten Sie die Seite getrennt von der Infrastruktur, über die sie berichtet. Eine Statusseite, die mit dem Dienst zusammen ausfällt, ist schlimmer als gar keine Statusseite, denn ihr Schweigen während eines Ausfalls wird als Behauptung gelesen, dass nichts falsch sei.

Einen Vorfall schreiben

Ein Vorfalleintrag wird für einen Kunden geschrieben, nicht für die Ingenieure, die ihn beheben. Das heißt: erst das Symptom, die Ursache später, wenn überhaupt.

1. Eröffnen Sie den Vorfall, sobald Sie das Problem bestätigt haben, auch wenn Sie die Ursache noch nicht kennen. "Wir untersuchen Meldungen über Fehler beim Checkout", in Minute zwei gepostet, ist mehr wert als eine vollständige Erklärung in Minute neunzig.
2. Sagen Sie, was ein Kunde sieht und was er dagegen tun kann, einschließlich eines Workarounds, falls vorhanden.
3. Aktualisieren Sie in einem vorab genannten Rhythmus, und posten Sie das Update auch, wenn es "noch keine Änderung" lautet. Schweigen wird als Untätigkeit gelesen.
4. Schließen Sie mit einer Lösungszeit ab und, bei allem Langen oder Schwerwiegenden, einer kurzen Notiz, was danach geschah.

Gleichen Sie den Komponentenzustand mit dem Vorfall ab. Ein offener Vorfall auf einer noch grün angezeigten Komponente ist der schnellste Weg, das Vertrauen in die Seite zu verlieren. Ist die zugrunde liegende Störung ein Server, der Anfragen ablehnt, ist 503 Service Unavailable die Antwort, die Ihre Kunden Ihnen am ehesten zitieren.

Geplante Wartung

Geplante Arbeiten gehören auf dieselbe Seite, im Voraus angekündigt mit einem Zeitfenster und der erwarteten Auswirkung. Sie im Voraus zu posten, macht aus einem Ausfall einen Termin: Kunden, die den Hinweis gesehen haben, erstellen keine Tickets, und die, die ihn nicht gesehen haben, finden zumindest die Erklärung, während es gerade passiert.

Unterscheiden Sie Wartung visuell und im Protokoll von einem Vorfall, und halten Sie das angekündigte Zeitfenster ehrlich ein. Ein Wartungsfenster, das regelmäßig überzieht, trainiert Menschen darauf, das nächste zu ignorieren.

Warum sie die Support-Last senkt

Während eines Ausfalls füllt sich die Support-Warteschlange mit derselben Frage, immer wieder gestellt. Eine Statusseite beantwortet sie einmal, an einer Adresse, auf die Sie von Ihrem Support-Autoresponder, dem Fehlerzustand Ihrer App und Ihren Social-Media-Konten aus verweisen können. Das verwandelt eine Stunde repetitiver Triage in einen Link.

Der zweite Effekt betrifft Vertrauen. Vorfälle zu veröffentlichen, kostet weniger, als es scheint, denn die Kunden, die den Ausfall bemerkt haben, wissen bereits, dass er stattfand. Was sie beurteilen, ist, ob Sie es ihnen gesagt haben.

Woher der Status kommt

Eine Statusseite ist nur so gut wie das Monitoring dahinter. Muss erst ein Mensch einen Ausfall bemerken, bevor sich die Seite ändert, hinkt die Seite immer den Kunden hinterher, die sie lesen, die Komponentenzustände sollten also von Prüfungen angetrieben werden, die kontinuierlich von außerhalb Ihres Netzwerks laufen. HostTracker hostet Statusseiten, gespeist vom eigenen Monitoring, das von über 300 Prüfpunkten in 158 Städten über 13 Monitor-Typen prüft, sodass der Zustand einer Komponente den Prüfergebnissen folgt, statt davon abzuhängen, dass jemand ans Aktualisieren denkt. Wie diese Prüfungen aussehen, sehen Sie in der Anleitung zur HTTP-Prüfung, und die dahinterstehenden Begriffe im übrigen Bereich Monitoring-Konzepte.