Zusammenfassung
Am 19. Januar 2026, zwischen 14:02 und 14:28 UTC, schlugen etwa zwei Drittel aller Versuche, sich im Panel anzumelden oder sich gegen die API zu authentifizieren, fehl. Bestehende Sitzungen wurden ebenfalls nach dem Zufallsprinzip ungültig gemacht. Laufende Instanzen, ihre Netzwerke und ihr Datenverkehr waren während des gesamten Zeitraums unberührt. Die Bereitstellung wurde für sechsundzwanzig Minuten angehalten und dann abgearbeitet; keine Bestellung ging verloren.
Zeitleiste
Alle Zeiten UTC, 19. Januar 2026.
| Zeit | Ereignis |
|---|---|
| 14:02 | Schemaänderung für Sitzungs-Token auf die Steuerungsebene angewendet. Rollout als Konfiguration markiert, daher ging es an alle sechs Panel-Knoten gleichzeitig. |
| 14:03 | Anmeldefehlerrate steigt von nahezu null auf einundsechzig Prozent. Automatische Warnmeldung hat ein Zwei-Minuten-Fenster und feuert noch nicht. |
| 14:06 | Alarm feuert. Bereitschaftsingenieur wird benachrichtigt. |
| 14:08 | Erster Helfer online. Sieht eine Fehlerrate, keinen Einsatz im Code-Änderungsprotokoll, und beginnt mit der Datenbank. |
| 14:14 | Zweiter Ingenieur kommt hinzu, prüft das Konfigurationsänderungsprotokoll statt des Code-Protokolls und findet den Eintrag von 14:02. |
| 14:16 | Ursache verstanden: Zwei Knoten validieren Token mit dem vorherigen Reader. |
| 14:19 | Rollback beginnt. |
| 14:24 | Token werden auf allen sechs Knoten korrekt ausgestellt und validiert. Fehlerrate fällt auf null. |
| 14:28 | Warteschlangen-Bereitstellungsjobs werden abgearbeitet. Wiederherstellung abgeschlossen. |
| 15:10 | Statusseite aktualisiert. Zweiundvierzig Minuten zu spät, was ein eigener Fehler ist und weiter unten behandelt wird. |
Ursache
Das Sitzungs-Token hat ein Feld erhalten. Writer haben das neue Format sofort ausgegeben; der Reader auf zwei von sechs Panel-Knoten war nicht neu gestartet worden und hat alles abgelehnt, was das neue Feld trug. Anfragen werden auf alle sechs Knoten verteilt, sodass eine auf einem neuen Knoten ausgestellte Sitzung bei jeder Anfrage ungefähr eine Chance von eins zu drei hatte, von einem alten validiert zu werden. Das Ergebnis wirkte intermittierend, weshalb die ersten sechs Minuten der Diagnose in die Datenbank gingen und nicht in das Einsatzprotokoll.
Die tiefere Ursache ist eine Regel, die wir 2023 geschrieben haben. Änderungen, die eine Schema-Datei statt Anwendungscode betreffen, wurden als Konfiguration eingestuft, und Konfiguration übersprang die Canary-Phase mit der Begründung, dass es sich, Zitat, nur um Werte handele. Diese Regel war vernünftig, als die einzigen Schema-Dateien Feature-Flags waren. Niemand hat sie überarbeitet, als sich die Definition einer Schema-Datei erweiterte, und diese Änderung wurde korrekt unter einer Regel klassifiziert, die leise falsch geworden war.
Es war kein Fehler des Ingenieurs, der sie angewendet hat. Die Klassifizierung wurde genau wie geschrieben befolgt.
Auswirkungen
- Panel-Anmeldungen: einundsechzig Prozent Fehlerrate für sechsundzwanzig Minuten.
- API-Tokens: gleiche Fehlerrate, gleiches Fenster. Idempotenzschlüssel stellten sicher, dass wiederholte Creates nicht dupliziert wurden.
- Laufende Instanzen: nicht betroffen. Kein Paketverlust, keine Neustarts, keine Speicherauswirkungen.
- Bereitstellung: pausiert, nicht fehlgeschlagen. Vier Bestellungen wurden während des Fensters abgeschlossen und alle vier bis 14:28 fertiggestellt.
Was wir geändert haben
- Die Canary-Phase ist jetzt bedingungslos. Alles, was bereitgestellt wird, unabhängig von der Klassifizierung, geht für fünf Minuten mit synthetischem Datenverkehr an einen Knoten, bevor es an andere geht. Fertig am 21. Januar.
- Reader akzeptiert das vorherige Format für dreißig Tage. Token-Validierung ist jetzt explizit mit einem Überlappungsfenster versioniert, sodass eine teilweise ausgerollte Änderung zu gar nichts führt. Fertig am 23. Januar.
- Eine synthetische Anmeldung läuft alle fünfzehn Sekunden von außerhalb unseres Netzwerks in drei Regionen und alarmiert beim zweiten aufeinanderfolgenden Fehler statt nach einem Zwei-Minuten-Durchschnittsfenster. Fertig am 22. Januar.
- Die Statusseite veröffentlicht automatisch, wenn die synthetische Anmeldung zweimal fehlschlägt, ohne auf einen Menschen zu warten, der einen Satz schreibt. Ein menschlicher Satz folgt. Fertig am 26. Januar.
Was wir nicht geändert haben und warum
Wir protokollieren weiterhin keine Client-IPs oder Anforderungstexte für Panel-Verkehr. Hätten wir sie gehabt, wäre die Ein-Drittel-Verteilung über die Knoten sofort sichtbar gewesen und hätte wahrscheinlich neun Minuten gespart. Neun Minuten sind keinen dauerhaften Datensatz darüber wert, von wo sich jeder Kunde anmeldet. Die Aufbewahrungstabelle auf der Protokollseite bleibt unverändert.
Wir haben Sitzungen nicht in einen gemeinsamen standortübergreifenden Speicher verschoben. Ein einzelner Sitzungsspeicher über alle Standorte hinweg hätte das Problem des gemischten Readers vollständig vermieden, indem es nur einen Reader gäbe. Es würde auch genau die zentralisierte, immer heiße Aufzeichnung darüber schaffen, wer worüber verbunden ist, die wir seit sechs Jahren nicht aufbauen.
Wir haben keinen Ausfall-Ankündigungskanal außerhalb der Statusseite hinzugefügt. Mehrere Leute schlugen soziale Medien vor. Die Statusseite ist das einzige, was wir betreiben, bei dem wir uns verpflichten können, es genau zu halten, und eine zweite Oberfläche hinzuzufügen bedeutet eine zweite Oberfläche, die veraltet.
Die Gutschrift
Die SLA deckt Instanzverfügbarkeit ab. Instanzen waren während der gesamten sechsundzwanzig Minuten verfügbar, daher war unter dem Vertrag niemandem etwas geschuldet. Wir haben eine Eintages-Gutschrift auf jedes Konto angewendet, das während des Fensters eine fehlgeschlagene Authentifizierung hatte, was ungefähr dreitausendeinhundert Euro ausmachte, weil Streiten über den Unterschied mit Menschen, die ihre Server nicht erreichen konnten, eine schlechtere Verwendung des Nachmittags aller ist.