Am Donnerstag, den 14. Juni, kam es ab 20:44 Uhr pazifischer Zeit zu einem schweren Ausfall von PagerDuty . Die Anwendung war 30 Minuten lang nicht erreichbar, gefolgt von einer Phase hoher Auslastung. Wir nehmen die Zuverlässigkeit unserer Systeme sehr ernst; sie hat für uns oberste Priorität. Wir haben diese Nachbesprechung verfasst, um Ihnen vollständige Offenlegung darüber zu geben, was passiert ist, was schiefgelaufen ist, was wir richtig gemacht haben und was wir tun, um sicherzustellen, dass dies nie wieder passiert.

Wir möchten uns auch für den Ausfall entschuldigen. Er hätte nicht so lange dauern dürfen. Eigentlich hätte er überhaupt nicht passieren dürfen.

Hintergrund

Die PagerDuty Infrastruktur wird von mehreren Anbietern gehostet. Zum Zeitpunkt des Schreibens dieses Artikels ist Amazon AWS unser Hauptanbieter und unser primäres System wird von AWS in der Region US-Ost gehostet.

Wir haben unsere Systeme von Anfang an so konzipiert, dass sie über mehrere Verfügbarkeitszonen (AZs) hinweg fehlertolerant sind. AZs sind im Grunde separate Rechenzentren innerhalb einer AWS-Region. Im Falle eines einzelnen AZ-Ausfalls kann PagerDuty also schnell wiederhergestellt werden, indem auf eine Backup-AZ umgeschaltet wird.

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

Ein weiteres, viel schwerwiegenderes AWS-Ausfall-Szenario ist der Ausfall einer ganzen Region auf einmal. In der Vergangenheit ist dies einige Male vorgekommen. PagerDuty ist auch in diesem Fall fehlertolerant konzipiert. Wir haben ein Hot Backup unseres gesamten Stacks bei einem separaten Hosting-Anbieter (nicht Amazon) eingerichtet. Im Rahmen dessen haben wir einen Notfall-Flip-Prozess entwickelt, der es uns ermöglicht, schnell von AWS zu unserem Backup-Anbieter zu wechseln.

Der Ausfall

Notiz : Alle unten angegebenen Zeitangaben beziehen sich auf die pazifische Zeit.

• Um 20:44 Uhr haben unsere Überwachungstools einen Ausfall der PagerDuty -App festgestellt.
• Um 20:49 Uhr wurde der diensthabende Techniker von PagerDuty kontaktiert. Der diensthabende Mitarbeiter erkannte, dass es sich um einen Vorfall der Schwere 1 handelte, und rief einige andere Techniker zur Hilfe.
• Um 20:55 Uhr wurde entschieden, notfallmäßig auf unseren Backup-Anbieter (der nicht in AWS ist) umzusteigen. Der Grund für diese Entscheidung ist, dass das Reaktionsteam bemerkte, dass die AWS-Konsole ausgefallen war, was sie zu der Annahme veranlasste, dass ein Wechsel zu einer Backup-AZ nicht funktionieren würde.
• Um 21:14 Uhr war die Umstellung auf den Backup-Hosting-Anbieter abgeschlossen. Zu diesem Zeitpunkt waren unsere Systeme voll funktionsfähig, jedoch unter sehr hoher Belastung, da sie einen großen Rückstand an Benachrichtigungen abarbeiten mussten.
• 21:22 Uhr: Der große Rückstand an Benachrichtigungen wurde abgearbeitet. Zu diesem Zeitpunkt waren wir noch immer stark ausgelastet: Neue Benachrichtigungen brauchten 5 bis 6 Minuten, um bearbeitet zu werden.
• Um 10:03 Uhr ging die Belastung zurück und wir waren wieder im Normalbetrieb und verarbeiteten Benachrichtigungen innerhalb von Sekunden.

Was wir falsch gemacht haben

Wir sind nicht zufrieden damit, dass wir 30 Minuten gebraucht haben, um den Notfall-Flip auf unseren Backup-Stack durchzuführen. Außerdem sind wir nicht zufrieden damit, wie wir mit der hohen Belastung nach Abschluss des Flips umgegangen sind. Hier ist 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 erkannt hatte, dass es sich um ein Problem der Schwere 1 handelte, brauchte er mehrere Minuten, um einen Gruppenanruf mit dem Rest des Teams einzurichten. Unser Schweregrad-1-Prozess basiert zum Einrichten des Gruppenanrufs auf Skype. Skype stürzte jedoch einige Male ab, was zu Zeitverschwendung führte.
3. Der Notfall-Flip dauerte zu lange – 20 Minuten. Die Flip-Anleitung ist zu ausführlich und daher im Notfall schwer zu befolgen. Außerdem hatten einige der Personen, die an dem Flip mitgearbeitet haben, noch nie zuvor einen gemacht, was dazu führte, dass der Flip mehr Zeit in Anspruch nahm.
4. Nach dem Umschalten hatten wir Probleme, alle unsere Hintergrundtask-Prozessoren auf volle Kapazität zu bringen.

Was wir richtig gemacht haben

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

1. Wir haben sehr schnell auf den Ausfall reagiert.
2. Wir haben die richtige Entscheidung getroffen, AWS notfallmäßig auszuschalten. Dies geschah, nachdem wir bemerkt hatten, dass die AWS-Konsole ausgefallen war.
3. Wir haben häufig über unsere Twitter-Kanäle @pagerduty und @pagerdutyops kommuniziert, um unsere Kunden über den Ausfall auf dem Laufenden zu halten. Nur für den Fall, dass Sie es noch nicht wussten: Unser Twitter-Konto @pagerdutyops ist für Notfallbenachrichtigungen bei Ausfällen reserviert. Sie können es sogar so einrichten, dass Sie bei jedem Update, das wir veröffentlichen, eine SMS erhalten. Weitere Informationen finden Sie unter http://support.pagerduty.com/entries/21059657-what-if-pagerduty-goes-down .
4. Gesamtbild: Unser redundanter Hot-Backup-Stack, der bei einem anderen (nicht Amazon-)Anbieter gehostet wurde, funktionierte sehr gut. Mit diesem Stack konnten wir den Ausfall auf nur 30 Minuten begrenzen. Ohne den Backup-Stack hätte der Ausfall möglicherweise eine Stunde oder sogar länger gedauert.

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

Großes Bild:

Wir migrieren Rechenzentren. Wir ziehen von AWS US-East nach US-West um. Diese Rechenzentrumsmigration war (lange vor dem Ausfall) für den 19. Juni geplant. Der Grund für diese Migration ist, dass viele unserer Kunden (über 20 %) ihre Anwendungen in US-East ausführen. Wenn in der Region Probleme auftreten, verlieren wir Kapazitäten und sind durch unsere Kunden stark ausgelastet. Im Wesentlichen korrelieren unsere Ausfälle mit denen unserer Kunden. Kurzfristig (also morgen) ziehen wir also nach US-West um. Eine kurze Anmerkung: Der Zeitpunkt dieses Ausfalls hätte nicht schlechter sein können: Wir waren nur 5 Tage von unserem geplanten Wechsel nach US-West entfernt, als der Ausfall auftrat.

Langfristig haben wir vor allem zwei Dinge erkannt:

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

Als Ergebnis werden wir zu einem Setup mit drei Hosting-Anbietern wechseln, bei dem das PagerDuty -System auf drei Rechenzentren verteilt ist (zu Beginn drei Rechenzentren, später fünf). Wir wechseln außerdem zu einem verteilten, fehlertoleranten Datenspeicher mit mehreren Knoten (Cassandra), der keine Umschaltungen erfordert, wenn ein Rechenzentrum ausfällt. Dieses Projekt wurde letzten Dezember gestartet und wir haben die Komponente zum Senden von Benachrichtigungen von PagerDuty bereits auf dem neuen Stack laufen.

Einzelheiten:

1. Wir prüfen die Implementierung eines weiteren internen Überwachungstools, das den Bereitschaftsdienst innerhalb von 1–2 Minuten nach Erkennung eines Ausfalls benachrichtigt.
2. Wir werden uns mit der Implementierung einer Alternative zu Skype befassen, um Gruppenanrufe zu starten und Sev-1-Probleme zu lösen. Höchstwahrscheinlich werden wir eine zuverlässige Konferenzschaltung einrichten, es sei denn, wir finden eine bessere Lösung (Leser, wenn Sie diesbezüglich Vorschläge haben, teilen Sie uns diese bitte in den Kommentaren mit.)
3. Wir werden daran arbeiten, den Notfall-Flip-Prozess zu optimieren. In diesem Zusammenhang werden wir das Flip-Handbuch verdichten und gründlich testen. Wir werden uns auch mit der Automatisierung von Teilen des Prozesses befassen.
4. Wir führen Belastungstests an unseren Systemen durch und suchen nach Möglichkeiten, die Hintergrundprozesse, die Benachrichtigungen versenden, zu optimieren. Ziel ist eine schnelle Wiederherstellung nach einem Notfall und die Bewältigung von Szenarien mit hoher Belastung.