Kein Deploy ohne Monitor.

Am 29. Mai erreichte eine Funktion für zusätzliche Quota-Policy-Prüfungen Service Control, ohne Feature-Flag und ohne Fehlerbehandlung auf dem neuen Pfad. Am 12. Juni erzeugte eine Policy-Änderung leere Felder, und die Binaries stürzten weltweit mit einem Null-Pointer-Fehler ab. Google schrieb, der erste Incident-Bericht sei etwa eine Stunde nach Beginn der Abstürze erschienen, weil die Infrastruktur von Cloud Service Health selbst ausgefallen war. Außerdem schrieb Google, dass bei manchen Kunden auch die auf Google Cloud betriebene Monitoring-Infrastruktur ausfiel, sodass ihnen jedes Signal des Incidents fehlte.

Was ein Check von außen zeigtDieser letzte Satz begründet externes Monitoring in den Worten des Betreibers: Monitoring auf derselben Plattform fällt mit ihr aus. Perstat prüft von außen, aus bis zu 6 Regionen mit Quorum, und sein Prüfnetz läuft nicht auf der Plattform, die es beobachtet. Eine Statusseite auf getrennter Infrastruktur hätte Ihre Kunden in dieser Stunde informiert.

Quelle: Incident-Bericht von Google Cloud, 2025-06-12 · The Register, 2025-06-16

Ein Skript, das Instanzen einer eingestellten App löschen sollte, erhielt Site-IDs statt App-IDs und löschte ab 07:38 UTC über 23 Minuten ganze Kunden-Sites. Das erste Kundenticket kam um 07:46 UTC, nach 8 Minuten, und der Major-Incident-Prozess begann um 08:17 UTC. Das erste Update der Statusseite kam um 09:03 UTC, nach 85 Minuten, die erste breite öffentliche Stellungnahme in sozialen Medien am 7. April, nach 41 Stunden. Die Wiederherstellung dauerte bis zu 14 Tage und war nur teilweise automatisiert.

Was ein Check von außen zeigtEin HTTP-Check Ihrer eigenen Tenant-URL aus mehreren Regionen meldet den Ausfall nach 2 aufeinanderfolgenden fehlgeschlagenen Checks, ohne auf ein Support-Ticket zu warten. Manche Kunden verloren Statuspage und Opsgenie zusammen mit ihren Sites, deshalb dürfen Statusseite und Alarmierung nicht bei dem Anbieter liegen, dessen Ausfall sie zeigen sollen. Die 14 Tage hätte kein Monitoring verkürzt.

Quelle: Atlassian Post-Incident-Review, 2022-04-29

Der CEO schrieb, das Unternehmen verlängere jedes Jahr Tausende Domains mit Präzision, und doch sei der Auto-Renew-Prozess für die Hauptdomain fehlgeschlagen. Als Ursache nannte die Stellungnahme menschliches Versagen und Prozessfehler. Kunden beschwerten sich öffentlich auf Twitter.

Was ein Check von außen zeigtEin Domain-Check meldet das Ablaufdatum Tage im Voraus, aus einem System, das nicht von der fehlgeschlagenen automatischen Verlängerung abhängt. Ein DNS-Check aus mehreren Regionen hätte den Verlust der Auflösung nach 2 aufeinanderfolgenden fehlgeschlagenen Checks gemeldet. Eine Statusseite auf einer anderen Domain hätte die Nachricht überbracht, während marketo.com nicht auflöste, aber verlängern kann die Domain kein Check.

Quelle: Marketo Knowledge Base (Adobe), P1 July 25, 2017 · The Drum, 2017-07-26

Beim Reparieren der Replikation entfernte ein Ingenieur das Datenverzeichnis auf dem Primary statt auf dem Secondary. Die pg_dump-Backups existierten nicht, weil das Skript pg_dump 9.2 gegen PostgreSQL 9.6 laufen ließ und fehlschlug. GitLab schrieb, Benachrichtigungen über fehlgeschlagene Cron-Jobs seien per E-Mail versandt worden, doch für diese E-Mails sei DMARC nicht aktiviert gewesen, und der Empfänger habe sie abgewiesen. Disk-Snapshots waren für die Datenbankserver nicht aktiviert, und übrig blieb nur ein manueller LVM-Snapshot, 6 Stunden alt.

Was ein Heartbeat zeigtEin Heartbeat arbeitet als Totmannschalter: Der Backup-Job meldet sich nach Erfolg, und Perstat alarmiert, wenn die Meldung ausbleibt, ob eine Fehler-E-Mail ankommt oder nicht. Der Fall zeigt auch, dass Alarmierung nicht an einem Kanal hängen darf, der selbst ausfallen kann, deshalb sollte die Eskalation über mehrere Wege laufen und eine Quittung verlangen. Ob sich das Backup wiederherstellen lässt, prüft ein Heartbeat nicht, das bleibt Aufgabe eines Restore-Tests.

Quelle: GitLab Post-mortem, 2017-02-10 · The Register, 2017-02-01, zu den 5 Backup-Verfahren