Status
Alle Systeme betriebsbereit.
Eine Statusseite ist nur dann etwas wert, wenn sie bereit ist, etwas Schlechtes zu sagen. Diese wird während eines Vorfalls aktualisiert und nicht danach. Das heißt, du siehst neben einer Komponente manchmal wird untersucht, während wir den Grund noch nicht kennen.
Komponenten
| Komponente | Zustand | Ziel | Gerade jetzt |
|---|---|---|---|
| API | Betriebsbereit | 99,9 Prozent Verfügbarkeit | In den letzten 24 Stunden keine Fehler über dem Basiswert |
| Bereitstellung | Betriebsbereit | 99,5 Prozent der bezahlten Bestellungen erreichen ein funktionierendes Profil | Die rollierende Stunde liegt über dem Ziel, Median der Einrichtung 41 Sekunden |
| Zahlungen | Betriebsbereit | Autorisierung und automatische Erstattung in unter 60 Sekunden | Der Zahlungsdienstleister meldet Normalbetrieb und Erstattungen laufen planmäßig |
| Abdeckungsdaten | Betriebsbereit | Veröffentlichte Werte täglich aktualisiert, Mindestgrenze von 25 Messungen eingehalten | Die letzte Aktualisierung ist durch und kein Land ist wegen veralteter Daten ausgeblendet |
| Support | Betriebsbereit | Erste Antwort in unter 60 Sekunden, 24 Stunden am Tag | Die Warteschlange liegt in jeder besetzten Sprache im Ziel |
Betriebsbereit heißt, dass die Komponente ihr Ziel über die rollierende Stunde erreicht. Es ist keine Zusage für die nächste Stunde.
99,5 %
Zielwert für erfolgreiche Bereitstellung
60 s
automatische Erstattung, wenn die Bereitstellung scheitert
30 min
Vorfalldauer, ab der ein öffentliches Postmortem fällig ist
72 h
Frist, um dieses Postmortem zu veröffentlichen
Was die einzelnen Zustände bedeuten
| Zustand | Was er bedeutet | Was wir tun |
|---|---|---|
| Betriebsbereit | Die Komponente erreicht ihr Ziel über die rollierende Stunde | Nichts. Das ist der Normalzustand und keine Zusage für die Zukunft |
| Beeinträchtigte Leistung | Läuft, aber langsamer oder unzuverlässiger als das Ziel | Auf dieser Seite benannt, betroffene Kunden kontaktiert, Gutschriften ohne Nachfrage gebucht |
| Teilausfall | Fällt für eine klar bestimmbare Gruppe aus, etwa einen Anbieter oder eine Region | Die Gruppe wird benannt, Käufe werden dort blockiert, wo sie scheitern würden, Erstattungen laufen automatisch |
| Schwerer Ausfall | Fällt breit aus | Ein Incident Commander wird eingesetzt und mindestens alle 30 Minuten kommt ein Update, bis es behoben ist |
| Wartung | Geplante Arbeiten mit bekanntem Zeitfenster | Mindestens 72 Stunden vorher angekündigt und auf die verkehrsärmste Stunde gelegt |
Es gibt keinen Zustand, der wahrscheinlich in Ordnung bedeutet. Eine Komponente erreicht entweder ihr Ziel oder sie wird auf dieser Seite benannt.
Die Vorfallrichtlinie
Zwei Zusagen tragen das Ganze, und beide sind mit Absicht unbequem. Die erste: Wir informieren betroffene Kunden, bevor sie es merken. Die zweite: Alles über 30 Minuten bekommt ein geschriebenes Postmortem, veröffentlicht innerhalb von 72 Stunden.
Das Postmortem benennt Systeme und Entscheidungen, keine einzelnen Mitarbeitenden. Geschrieben wird es von der Person, die in Rufbereitschaft war, nicht von einer Führungskraft, die über jemand anderen schreibt.
Wenn wir die 72 Stunden reißen, veröffentlichen wir die Verzögerung und den Grund innerhalb dieser 72 Stunden. Eine verpasste Frist, die zu spät angekündigt wird, sind zwei Fehler.
- Die Erkennung läuft automatisch über die Erfolgsquoten bei Bereitstellung und Zahlungsautorisierung. Ein Vorfall beginnt also, wenn sich die Zahlen bewegen, nicht wenn sich jemand beschwert
- Der Zustand der Komponente auf dieser Seite ändert sich innerhalb von fünf Minuten nach der Meldung, bevor die Ursache bekannt ist
- Ein Incident Commander leitet die Reaktion, eine andere Person übernimmt die Kommunikation, damit keine der beiden Aufgaben die andere aushungert
- Betroffene Kunden werden identifiziert und angeschrieben, mit bereits gutgeschriebener Erstattung dort, wo der Dienst beeinträchtigt war, statt sie nur auf Nachfrage anzubieten
- Käufe werden auf jedem Weg blockiert, von dem wir wissen, dass er scheitern würde. Geld anzunehmen, das wir erstatten müssen, ist schlimmer als den Verkauf zu verlieren
- Bei einem schweren Ausfall kommt mindestens alle 30 Minuten ein Update, auch wenn das Update lautet, dass wir es noch nicht wissen
- Innerhalb von 72 Stunden nach der Behebung erscheint ein Postmortem mit Zeitleiste, Kundenauswirkung in Zahlen, Ursache und jeder Maßnahme mit verantwortlicher Person und Datum
Warum das Ziel nicht hundert Prozent ist
Weil ein Netz beteiligt ist und hundert Prozent gelogen wäre. Ein Bereitstellungsziel von 99,5 Prozent sagt laut, dass rund fünf von tausend Bestellungen irgendwo zwischen der Zahlung und dem funktionierenden Profil scheitern werden.
Entscheidend ist, dass der Weg für diese fünf gebaut ist. Die Erstattung läuft in unter 60 Sekunden ohne Ticket, die Nachricht erklärt, was passiert ist und was du stattdessen versuchen kannst, und niemand muss entscheiden, ob der Kunde sie verdient hat.
Dieselbe Logik gilt für die Abdeckung. Wenn ein Partnernetz in einem Gebiet überlastet ist, das wir mit mehr als einem Anbieter versorgen, verschieben wir dich, statt einen Vorfall aufzumachen, und der Hinweis nennt den Wechsel.
Wenn es nur ein Netz gibt und das einen schlechten Tag hat, schreiben wir das auf die Länderseite. Genau deshalb veröffentlichen unsere Abdeckungsseiten den Median, das langsamste Zehntel und die Zahl der Messungen.
Vorfallhistorie
Im laufenden Berichtszeitraum wurde kein Vorfall über 30 Minuten gemeldet.
Dieser Satz ist genau so viel wert wie unsere Bereitschaft, ihn zu ändern. Deshalb steht die Richtlinie oben so ausführlich da. Jedes frühere Postmortem bleibt dauerhaft veröffentlicht, statt nach neunzig Tagen zu verschwinden.