Am Donnerstag, dem 14. Juni, kam es ab 20:44 Uhr pazifischer Zeit zu einem schwerwiegenden Ausfall von PagerDuty . Die Anwendung war 30 Minuten lang nicht verfügbar, gefolgt von einer Phase hoher Auslastung. Die Zuverlässigkeit unserer Systeme hat für uns höchste Priorität und ist uns sehr wichtig. Mit diesem Bericht möchten wir Ihnen umfassend darlegen, was passiert ist, was schiefgelaufen ist, was wir richtig gemacht haben und welche Maßnahmen wir ergreifen, um ein erneutes Auftreten zu verhindern.

Wir möchten uns außerdem für den Ausfall entschuldigen. Er hätte nicht so lange dauern dürfen. Eigentlich hätte er gar nicht erst auftreten dürfen.

Hintergrund

Die PagerDuty Infrastruktur wird von mehreren Anbietern gehostet. Zum Zeitpunkt der Erstellung dieses Dokuments ist unser Hauptanbieter Amazon AWS, und unser primäres System wird in der Region USA-Ost auf AWS gehostet.

Unsere Systeme sind von Anfang an so konzipiert, dass sie über mehrere Verfügbarkeitszonen (Availability Zones, AZs) hinweg ausfallsicher sind. AZs sind im Prinzip separate Rechenzentren innerhalb einer AWS-Region. Im Falle eines Ausfalls einer einzelnen AZ kann PagerDuty daher schnell auf eine Backup-AZ umschalten und so den Betrieb wiederherstellen.

AWS kann auf verschiedene Arten ausfallen. Der Ausfall einer einzelnen Verfügbarkeitszone ist der einfachste Fall, für den wir vorgesorgt haben, indem wir unseren primären Stack (einschließlich Datenbank- und Webserver) auf mehrere Verfügbarkeitszonen verteilt haben.

Ein weiteres, weitaus gravierenderes AWS-Ausfallszenario ist der gleichzeitige Ausfall einer gesamten Region. Dies ist in der Vergangenheit bereits einige Male vorgekommen. PagerDuty ist auch in diesem Fall fehlertolerant ausgelegt. Wir haben ein Hot-Backup unseres gesamten Stacks bei einem separaten Hosting-Anbieter (nicht Amazon) eingerichtet. Dazu haben wir einen Notfall-Umschaltprozess entwickelt, der es uns ermöglicht, schnell von AWS auf unseren Backup-Anbieter umzuschalten.

Der Ausfall

Notiz Alle unten angegebenen Zeiten sind pazifische Zeit.

• Um 20:44 Uhr stellten unsere Überwachungstools einen Ausfall der PagerDuty App fest.
• Um 20:49 Uhr wurde der diensthabende PagerDuty -Techniker kontaktiert. Dieser erkannte, dass es sich um einen Vorfall der Prioritätsstufe 1 handelte und kontaktierte einige weitere Techniker zur Unterstützung.
• Um 20:55 Uhr wurde beschlossen, im Notfall auf unseren Backup-Anbieter (der nicht zu AWS gehört) umzuschalten. Grund dafür war, dass das Reaktionsteam festgestellt hatte, dass die AWS-Konsole nicht erreichbar war, was zu der Annahme führte, dass ein Wechsel auf eine Backup-Verfügbarkeitszone nicht funktionieren würde.
• Um 21:14 Uhr war die Umstellung auf den Backup-Hosting-Anbieter abgeschlossen. Zu diesem Zeitpunkt waren unsere Systeme zwar voll funktionsfähig, arbeiteten aber unter sehr hoher Last, da sie einen großen Rückstand an Benachrichtigungen abarbeiteten.
• 21:22 Uhr: Der große Benachrichtigungsstau wurde abgearbeitet. Zu diesem Zeitpunkt herrschte weiterhin hohe Auslastung: Die Verarbeitung neuer Benachrichtigungen dauerte 5–6 Minuten.
• Um 10:03 Uhr ging die Last zurück und wir arbeiteten wieder im Normalbetrieb, Benachrichtigungen wurden innerhalb von Sekunden verarbeitet.

Was wir falsch gemacht haben

Wir sind unzufrieden damit, dass die Notfallumschaltung auf unser Backup-System 30 Minuten gedauert hat. Auch der Umgang mit der hohen Last nach Abschluss der Umschaltung hat uns nicht gefallen. Hier die vollständige Liste der Probleme:

1. Unsere Überwachungstools benötigten 5 Minuten, um uns über das Problem zu informieren. Das ist zu lang; ein akzeptabler Wert liegt im Bereich von 1–2 Minuten.
2. Nachdem der diensthabende Techniker erkannte, dass es sich um ein Problem der Priorität 1 handelte, dauerte es einige Minuten, bis er einen Gruppenanruf mit dem restlichen Team einrichtete. Unser Prozess für Priorität 1 sieht die Einrichtung des Gruppenanrufs über Skype vor. Skype stürzte jedoch mehrmals ab, was zu Zeitverlust führte.
3. Der Not-Spiegel dauerte zu lange – 20 Minuten. Die Anleitung zum Spießen ist zu ausführlich und daher in einem Notfall schwer verständlich. Außerdem hatten einige der am Spieß beteiligten Personen noch nie zuvor einen Spieß gespießt, was die Dauer zusätzlich verlängerte.
4. Nach der Umstellung hatten wir Probleme, alle unsere Hintergrundprozesse mit voller Kapazität zu starten.

Was wir richtig gemacht haben

Alles in allem haben wir innerhalb von 30 Minuten nach dem Ausfall einen Notfall-Rechenzentrumsumbau durchgeführt, und der Umbauprozess hat funktioniert. Hier ist die Liste der Dinge, die gut gelaufen sind:

1. Wir haben sehr schnell auf den Ausfall reagiert.
2. Es war richtig, AWS im Notfall abzuschalten. Dies geschah, nachdem wir festgestellt hatten, dass die AWS-Konsole nicht erreichbar war.
3. Wir haben unsere Kunden über unsere Twitter-Kanäle @pagerduty und @pagerdutyops regelmäßig über den Ausfall informiert. Falls Sie es noch nicht wussten: Unser Twitter-Account @pagerdutyops ist ausschließlich für Notfallbenachrichtigungen bei Ausfällen reserviert. Sie können ihn sogar so einstellen, dass Sie bei jedem Update eine SMS erhalten. Weitere Informationen finden Sie hier: https://support.pagerduty.com/entries/21059657-what-if-pagerduty-goes-down Die
4. Im Großen und Ganzen: Unser redundantes Hot-Backup-System, das bei einem anderen (nicht Amazon-)Anbieter gehostet wird, hat hervorragend funktioniert. Dank dieses Systems konnten wir den Ausfall auf nur 30 Minuten begrenzen. Ohne dieses Backup-System hätte der Ausfall möglicherweise eine Stunde oder sogar länger gedauert.

Was wir tun werden, um zu verhindern, dass dies erneut passiert

Das große Ganze:

Wir migrieren unsere Rechenzentren. Wir wechseln von AWS US-East nach US-West. Diese Migration war (lange vor dem Ausfall) für den 19. Juni geplant. Der Grund dafür ist, dass viele unserer Kunden (über 20 %) ihre Anwendungen in US-East betreiben. Bei Problemen in dieser Region verlieren wir Kapazität und sind durch die Auslastung unserer Kunden stark belastet. Unsere Ausfälle hängen also eng mit denen unserer Kunden zusammen. Daher wechseln wir kurzfristig (d. h. morgen) nach US-West. Der Zeitpunkt des Ausfalls hätte übrigens nicht ungünstiger sein können: Wir waren nur noch fünf Tage von unserem geplanten Wechsel nach US-West entfernt, als der Ausfall auftrat.

Langfristig haben wir zwei wesentliche Dinge erkannt:

• Wir können keinem einzelnen Hosting-Anbieter vertrauen.
• Flips sind schlecht: Sie führen immer zu Ausfallzeiten und manchmal funktionieren sie nicht.

Daher werden wir auf ein Hosting-Setup mit drei Anbietern umstellen, bei dem das PagerDuty System auf drei Rechenzentren verteilt ist (zunächst drei, später fünf). Wir migrieren außerdem zu einem verteilten, fehlertoleranten Datenspeicher mit mehreren Knoten (Cassandra), der bei Ausfall eines Rechenzentrums keine Umschaltung erfordert. Dieses Projekt wurde im vergangenen Dezember gestartet, und die Benachrichtigungskomponente von PagerDuty läuft bereits auf der neuen Plattform.

Details:

1. Wir prüfen die Einführung eines weiteren internen Überwachungstools, das den Bereitschaftsdienst innerhalb von 1-2 Minuten nach Feststellung eines Ausfalls alarmiert.
2. Wir werden die Implementierung einer Alternative zu Skype für den Start von Gruppenanrufen prüfen, um Probleme der Prioritätsstufe 1 zu beheben. Höchstwahrscheinlich werden wir eine zuverlässige Konferenzschaltung einrichten, sofern wir keine bessere Lösung finden. (Leser, falls Sie hierzu Vorschläge haben, teilen Sie uns diese bitte in den Kommentaren mit.)
3. Wir werden den Notfall-Flip-Prozess optimieren. Dazu werden wir das Flip-Handbuch kürzen und gründlich testen. Außerdem werden wir prüfen, ob sich Teile des Prozesses automatisieren lassen.
4. Wir werden Lasttests an unseren Systemen durchführen und nach Möglichkeiten suchen, die Hintergrundprozesse, die Benachrichtigungen versenden, zu optimieren. Ziel ist es, nach einem Notfall-Switch schnell wiederherzustellen und auch unter hoher Last handlungsfähig zu bleiben.