Wenn Ihr Anbieter ausfällt
Zuletzt aktualisiert:
Eine Anbieter-Statusseite ist das öffentliche Dashboard, das ein Cloud-, Hosting-, Code- oder Zahlungsanbieter unterhält, um seine eigene Gesundheit zu erklären: ein Gesamtindikator, eine Liste von Komponenten und eine Zeitleiste von Vorfällen, die der Anbieter selbst schreibt, während diese Vorfälle noch laufen. Sie gut zu lesen ist eine Operator-Fertigkeit, denn die Überschrift ist eine Zusammenfassung und die Wahrheit lebt darunter — in welcher Komponente betroffen ist, in welcher Region, mit welcher erklärten Auswirkung und wie weit der Vorfall im eigenen Ablauf des Anbieters fortgeschritten ist. Dieser Artikel lehrt dieses Lesen und endet mit dem, was in den ersten zehn Minuten zu tun ist, wenn der fragliche Anbieter einer ist, von dem Sie abhängen. Beginnen Sie auf dem Statusboard der Anbieter, das die Seiten der großen Anbieter in einer Momentaufnahme sammelt, und behalten Sie während des ganzen Textes die Frage aus ist es ausgefallen, oder sind nur Sie es? im Kopf: Die beiden Werkzeuge beantworten die entgegengesetzten Hälften desselben Zweifels.
Zwei verschiedene Dinge: der Indikator und der Vorfallzustand
Jede reife Statusseite trägt zwei getrennte Signale, die Leser ständig verwechseln. Das erste ist der Gesamtindikator: ein einziger zusammengefasster Zustand für den ganzen Dienst, meist einer von none, minor, major, critical oder maintenance in dem maschinenlesbaren Feed hinter der Seite — das Modell, das in der Statuspage-Entwicklerdokumentation dokumentiert ist und das die meisten großen Anbieter entweder direkt verwenden oder eng nachahmen. Der Indikator ist absichtlich grob. Er existiert, damit ein beschäftigter Leser — oder eine Maschine wie unser Statusboard — in einer Sekunde antworten kann, ob dort etwas nicht stimmt, und er wird aus der am stärksten betroffenen Komponente, dem eigenen Urteil des Anbieters oder beidem berechnet.
Das zweite Signal ist der Vorfall selbst, und er hat seinen eigenen Lebenszyklus, den der Indikator flachdrückt. Ein Vorfall wird mit einem Namen, einer erklärten Auswirkung und einem Zustand aus einem Ablauf eröffnet: wird untersucht (wir sehen Symptome und kennen die Ursache noch nicht), identifiziert (wir kennen die Ursache und arbeiten daran), wird überwacht (eine Behebung ist draußen und wir beobachten, ob sie hält) und behoben (wir glauben, er ist vorbei, vorbehaltlich des Postmortems). Diese Zustände tragen Information, die der Indikator nicht tragen kann. Ein kritischer Vorfall, der seit zwei Stunden überwacht wird, endet in der Regel; ein minor-Vorfall, der vor vier Minuten in die Untersuchung ging, kann noch zu allem werden.
Lesen Sie beides, in dieser Reihenfolge, und lesen Sie die Aktualisierungen dazwischen. Die Zeitleiste kurzer Aktualisierungen unter einem Vorfall ist der Ort, an dem der Anbieter Ihnen die Dinge sagt, die die Überschrift nie sagen wird: welches Teilsystem versagt hat, welche Umgehung es gibt, ob Daten betroffen sind oder nur die Verfügbarkeit, und ob die nächste Aktualisierung in zwanzig Minuten oder zwei Stunden versprochen ist. Ein Vorfall, dessen Aktualisierungen ausbleiben, ist selbst ein Signal — entweder ist das Team überlastet, was mit einem längeren Ausfall korreliert, oder der Vorfall wurde still in einen größeren gefaltet. Operatoren, die die Überschrift abfotografieren und aufhören zu lesen, handeln routinemäßig nach dem am wenigsten informativen Satz auf der Seite.
Warum „alle Systeme betriebsbereit“ trotzdem bedeuten kann, dass Sie ausgefallen sind
Der Indikator fasst den ganzen Dienst zusammen, und moderne Dienste sind nicht eine Sache. Ein Anbieter kann global ehrlich grün sein, während die Region, in der Sie bereitstellen, die einzige Produktoberfläche, die Sie aufrufen, die veraltete API-Version, an die Sie gebunden sind, oder die Steuerungsebene, die Sie für eine Bereitstellung brauchen, für jeden Kunden versagt, der sie berührt. Komponentenlisten existieren genau deswegen: Eine Seite wie die Statusseite von GitHub zerlegt den Dienst in Git-Operationen, API-Anfragen, Actions, Pages und mehr, und jede davon kann eingeschränkt sein, während das Gesamtbanner beruhigend bleibt — oder umgekehrt, mit rotem Banner für eine Komponente, die Sie nie genutzt haben.
Es gibt auch drei leisere Lücken. Erstens die Erklärungsverzögerung: Ein Anbieter erklärt einen Vorfall, wenn er ihn bestätigt hat, nicht wenn der erste Fehler auftrat, also zeigen die ersten Minuten vieler Ausfälle eine grüne Seite und einen brennenden sozialen Feed; die Seite lügt nicht, sie ist nur hintendran. Zweitens Schwellen: Ein Anbieter kann eine Fehlerrate von zwei Prozent auf einer Stufe als normales Hintergrundrauschen behandeln und nie etwas erklären, während sich diese zwei Prozent genau auf Ihr Verkehrsmuster konzentrieren. Drittens der Umfang: Statusseiten beschreiben die Seite des Kabels des Anbieters. Ein DNS-Ausfall, ein Routing-Problem oder ein blockierter Pfad zwischen Ihren Nutzern und einem gesunden Anbieter erzeugt einen Totalausfall für Sie unter einem grünen Indikator — und deshalb muss die Begleitfrage, ob es ausgefallen ist oder nur Sie es sind, von unabhängigen Aussichtspunkten beantwortet werden, nicht von der eigenen Seite des Anbieters.
Die Arbeitsregel lautet, Grün als „kein erklärter Vorfall“ zu behandeln, nie als „bewiesen gesund“. Wenn Ihre eigene Überwachung sagt, dass Nutzer scheitern, und der Anbieter sagt betriebsbereit, glauben Sie Ihrer Überwachung, was Ihre Nutzer angeht, und nutzen Sie die Statusseite für eine andere Arbeit: zu prüfen, ob später eine Erklärung erscheint, die die Ursache rückwirkend bestätigt, und ob die Komponente, von der Sie abhängen, eine Historie von Vorfällen hat, die wie der geformt sind, den Sie gerade durchleben.
Abonnieren Sie Komponenten, nicht Seiten
Die meisten Operatoren abonnieren eine Statusseite so, wie sie einen Newsletter abonnieren: ein Abonnement, jeder Vorfall, für immer — und dann, vorhersehbar, fangen sie an, die Post zu ignorieren, weil ein globaler Feed für einen großen Anbieter ein stetiges Tröpfeln von Vorfällen für Komponenten produziert, die sie nicht nutzen, in Regionen, die sie nicht bedienen. Alarmmüdigkeit ist kein Charakterfehler; sie ist die korrekte Reaktion auf ein schlecht abgegrenztes Signal. Die Behebung ist mechanisch und auf fast jeder reifen Statusseite verfügbar: Abonnieren Sie auf Komponentenebene. Dasselbe Statuspage-Modell, das die Indikatoren definiert, lässt Abonnenten auch nach Komponente filtern, und Anbieter, die ihre eigenen Systeme betreiben, wie die Statusseite von Cloudflare, bieten dieselbe Wahl durch ihre eigenen Abonnement-Abläufe.
Begrenzen Sie jedes Abonnement auf das, was Ihr Verhalten um 3 Uhr nachts tatsächlich ändern würde. Die Komponenten, die Ihr Produktionsverkehr aufruft, gehören auf den lauten Kanal — den, der anruft, Nachrichten schickt oder wenigstens etwas markiert, das Sie innerhalb von Minuten sehen werden. Komponenten, die Sie nur für Builds, Analysen oder interne Werkzeuge nutzen, gehören auf einen leisen Kanal, den Sie zu Arbeitszeiten prüfen. Komponenten, die Sie nicht nutzen, gehören nirgendwohin: Jede Mitteilung, die Sie korrekt ignorieren, macht die nächste leichter zu ignorieren, einschließlich der, die zählt. Sehen Sie die Liste jedes Mal erneut durch, wenn sich der Stack ändert, denn Abonnements verrotten in beide Richtungen — neue Abhängigkeiten, die niemand abonniert hat, und tote, die noch einen Kanal anrufen, den niemand beobachtet.
Bevorzugen Sie maschinenlesbare Feeds, wo Sie können. E-Mail ist der langsamste und am leichtesten ignorierbare Kanal, den eine Statusseite bietet; Webhooks und Feeds können Ihr eigenes Dashboard speisen, ein internes Ticket öffnen oder die vorbereitete Halteseite Ihres Support-Teams umlegen, bevor die erste Nutzerbeschwerde eintrifft. Selbst eine leichtgewichtige Version lohnt sich: Die Momentaufnahme auf unserem Statusboard der Anbieter wird genau aus diesen öffentlichen Feeds gebaut, was beweist, dass die Daten da sind, um programmatisch konsumiert statt in einem Browser-Tab bewundert zu werden, an dessen Öffnen Sie sich erinnern müssen.
Bauen Sie Ihr eigenes Abhängigkeitsverzeichnis
Keiner der obigen Ratschläge funktioniert ohne eine Liste, und die meisten Teams entdecken während eines Ausfalls, dass sie keine haben. Ein Abhängigkeitsverzeichnis ist schlicht die schriftliche Antwort auf eine Frage, die trivial klingt und es nicht ist: Welche externen Dienste, wenn sie heute Nacht stoppten, würden uns stoppen — und welche würden uns bloß blamieren? Bauen Sie es bei ruhigem Wetter. Gehen Sie Ihre Architektur Oberfläche für Oberfläche durch — Hosting, DNS, Code-Hosting und CI, die Datenbank- und Speicheranbieter, den Zahlungsabwickler, die E-Mail- und SMS-Versender, den Identitätsanbieter, den Fehler-Tracker, das Analyse-Tag, die Schriftarten und Skripte, die Ihre Seiten von der CDN eines anderen laden — und schreiben Sie für jeden auf: den Anbieter, die Komponente, die Sie tatsächlich konsumieren, wo seine Statusseite lebt, und was Ihre Nutzer erleben, wenn er versagt.
Stufen Sie jeden Eintrag nach der Form seines Versagens ein, nicht danach, wie sehr Sie den Verkäufer mögen. Manche Abhängigkeiten sind hart: Stoppen sie, stoppen Sie, und die einzige verfügbare Arbeit ist Kommunikation und Warten. Manche sind weich: Die Seite läuft ohne sie, eingeschränkt — keine Analyse, kein Chat-Widget, keine Personalisierung — und für diese sollte das Verzeichnis sagen, wer sie abschalten darf und wie. Und manche sind versteckt: die transitiven Abhängigkeiten, die Sie nicht gewählt haben, wie der Zustand der Cloud-Region, in der Ihre eigene SaaS-Datenbank läuft, oder die Zertifikats- und DNS-Infrastruktur unter allem. Versteckte Abhängigkeiten sind die, die den Ausfall „alles ist unten und nichts, wofür wir zahlen, steht auf der Liste“ erzeugen, und Sie finden sie, indem Sie jeden Verkäufer einmal fragen, wovon er abhängt.
Bewahren Sie das Verzeichnis dort auf, wo ein Vorfall es erreichen kann: im Runbook, neben der Eskalationsliste, nicht auf einer Wiki-Seite, die niemand öffnen kann, wenn der Identitätsanbieter genau das ist, was ausgefallen ist. Eine Seite genügt. Seine Arbeit während eines Ausfalls ist, „etwas stimmt nicht“ in eine Checkliste zu verwandeln — für jede harte Abhängigkeit, oben oder unten, in dreißig Sekunden — und seine Arbeit danach ist, korrigiert zu werden, denn jeder echte Vorfall lehrt Sie etwas über eine Abhängigkeit, die Sie falsch eingestuft hatten. Ein Verzeichnis, das nie korrigiert wird, ist ein historisches Dokument, kein operatives.
Die ersten zehn Minuten eines Anbieterausfalls
Minute null bis zwei: bestätigen und lokalisieren. Prüfen Sie Ihre eigene Überwachung, um sicher zu sein, dass der Ausfall echt ist und Ihrer zu verkünden, und öffnen Sie dann das Statusboard und die Seite des verdächtigen Anbieters. Sie beantworten eine Frage: Gibt es einen erklärten Vorfall, der sich mit dem überschneidet, was Sie nutzen — Komponente, Region, Produkt? Wenn ja, haben Sie Ihre Ursache und Ihre erste Nachricht. Wenn nein, erweitern Sie die Prüfung: ein anderer Anbieter in Ihrem Verzeichnis, Ihre eigene letzte Bereitstellung, Ihr DNS. Die meisten falschen Dramen sterben in diesen zwei Minuten, und die meisten echten bekommen hier ihre Form.
Minuten zwei bis fünf: kommunizieren, klar und früh. Sagen Sie Ihren Nutzern in den Kanälen, die sie tatsächlich lesen, dass ein namentlich genannter vorgelagerter Anbieter einen Vorfall hat, was das für sie in praktischer Hinsicht bedeutet — was nicht funktioniert, was noch funktioniert, ob ihre Daten sicher sind — und wann Sie sie wieder aktualisieren werden. Eine ehrliche Haltenachricht, die in Minute vier geschickt wird, schlägt eine präzise Erklärung, die in Minute vierzig geschickt wird, denn Schweigen ist das, was Nutzer mit ihren schlimmsten Vermutungen und den Namen Ihrer Konkurrenten füllen. Öffnen Sie intern einen einzigen Vorfall-Faden, ernennen Sie eine Person, die spricht, und stempeln Sie alles mit der Zeit; Sie werden sich beim Postmortem dafür danken, und das Support-Team des Anbieters wird es auch, wenn Sie sie brauchen.
Minuten fünf bis zehn: hören Sie auf, es schlimmer zu machen, und bereiten Sie die weichen Landungen vor. Frieren Sie Bereitstellungen ein — eine Änderung, die in einen aktiven vorgelagerten Vorfall hinein gemacht wird, kann nicht bewertet werden und lässt sich womöglich nicht einmal zurückrollen. Schalten Sie aggressive Wiederholungen und unwesentliche Jobs ab, die auf den versagenden Anbieter einhämmern; die Erholung ist messbar langsamer, wenn zehntausend Clients im Gleichschritt erneut versuchen, und manche Anbieter werden Sie in einen zweiten, selbst verursachten Ausfall hinein drosseln. Schalten Sie die weichen Abhängigkeiten ab oder stufen Sie sie herab, die Ihr Verzeichnis als abwerfbar markiert hat, stellen Sie die Halteseite auf, wenn Sie eine haben, und lassen Sie sich dann auf den Rhythmus ein, den der Vorfall vorgibt: Beobachten Sie die Aktualisierungen des Anbieters, aktualisieren Sie Ihre Nutzer zu den versprochenen Zeiten, ob es Neuigkeiten gibt oder nicht, und ändern Sie nichts anderes, es sei denn, die Fakten ändern sich. Der Ausfall wird nach dem Zeitplan des Anbieters enden, nicht nach Ihrem; Ihre zehn Minuten entscheiden, ob Ihre Nutzer ihn als den schlechten Tag ihres Anbieters in Erinnerung behalten oder als Ihren.