Wir verbringen enorm viel Zeit mit der Zuverlässigkeit von PagerDuty und der Infrastruktur, auf der es gehostet wird. Der Großteil dieser Arbeit ist unsichtbar, verborgen hinter der API und der Benutzeroberfläche, mit der unsere Kunden interagieren. Wenn sie jedoch ausfallen, machen sie sich als Verzögerungen bei Benachrichtigungen und 500er-Nachrichten an unseren API-Endpunkten bemerkbar. Das ist am Samstag, dem 13. April, gegen 8:00 Uhr pazifischer Zeit passiert. PagerDuty erlitt einen Ausfall, der durch eine Verschlechterung eines Peering-Punkt von zwei AWS-Regionen verwendet.

Wir schreiben diesen Beitrag, um unsere Kunden darüber zu informieren, was passiert ist, was wir gelernt haben und was wir tun werden, um alle durch diesen Ausfall aufgedeckten Probleme zu beheben.

Hintergrund

Die Infrastruktur von PagerDuty wird in drei verschiedenen Rechenzentren gehostet (zwei in AWS und ein weiteres in Linode). Im vergangenen Jahr haben wir unsere Software mit dem Ziel neu konzipiert, dass sie den Ausfall eines gesamten Rechenzentrums (einschließlich seiner Abtrennung vom Netzwerk) überstehen kann. Allerdings war die Fähigkeit, den Ausfall zweier Rechenzentren gleichzeitig zu überstehen, nicht ausdrücklich in unser Design integriert. So unwahrscheinlich das auch sein mag, genau das ist am Samstagmorgen passiert. Da wir eine AWS-Region als Rechenzentrum betrachten und beide gleichzeitig ausfallen, konnten wir mit unserem letzten verbleibenden Rechenzentrum nicht verfügbar bleiben.

Wir haben unsere drei Rechenzentren so ausgewählt, dass keine Abhängigkeiten untereinander bestehen, und haben sichergestellt, dass sie physisch getrennt sind. Inzwischen haben wir jedoch erfahren, dass zwei der Rechenzentren einen gemeinsamen Peering-Punkt hatten. An diesem Peering-Punkt kam es zu einem Ausfall, der dazu führte, dass beide unserer Rechenzentren offline gingen.

Der Ausfall

Notiz: Alle unten genannten Zeitangaben erfolgen in Pacific Time.

• Um 7:57 Uhr, so AWS, begannen Verbindungsprobleme aufgrund der Verschlechterung eines Peering-Punkts in Nordkalifornien.
• Um 8:11 Uhr wird der diensthabende PagerDuty Techniker über ein Problem mit einem der Knoten in unserem Benachrichtigungs-Versandsystem informiert.
• Um 8:13 Uhr wird versucht, den ausgefallenen Knoten wiederherzustellen, jedoch ohne Erfolg.
• Um 8:18 Uhr erkennt unser Überwachungssystem einen Ausfall mehrerer Anbieter für Benachrichtigungen (verursacht durch ein Verbindungsproblem). Zu diesem Zeitpunkt werden die meisten Benachrichtigungen noch übermittelt, allerdings mit erhöhten Latenzen und Fehlerraten.
• Um 8:31 Uhr wurde ein Sev-2-Fall gemeldet und weitere Ingenieure zur Hilfe gerufen.
• Um 8:35 Uhr verliert PagerDuty vollständig die Fähigkeit, Benachrichtigungen zu versenden, da es aufgrund der hohen Netzwerklatenz kein Quorum herstellen konnte. Sev-1 wird erklärt
• Um 8:53 Uhr konnte das PagerDuty Benachrichtigungssystem das Quorum erreichen und begann mit der Verarbeitung aller in der Warteschlange befindlichen Benachrichtigungen
• Um 9:23 Uhr, laut AWS, endet das Verbindungsproblem am Peering Point in Nordkalifornien

Während der Post-Mortem-Analyse stellten unsere Techniker außerdem fest, dass eine Fehlkonfiguration unseres Koordinatordienstes eine schnelle Wiederherstellung verhinderte. Insgesamt konnte PagerDuty zwischen 8:35 Uhr und 8:53 Uhr 18 Minuten lang keine Benachrichtigungen versenden. Während dieser Zeit konnte unsere Event-API jedoch weiterhin Events annehmen.

Was wir tun werden

Wie immer bei größeren Ausfällen erfahren wir etwas Neues über Mängel in unserer Software. Dies sind einige unserer Pläne zur Behebung der entdeckten Probleme.

Kurzfristig

1. Bei unserer Analyse stellten wir fest, dass wir nicht über ausreichende Protokolle verfügten, um Probleme in einigen unserer Systeme zu beheben. Wir haben nun weitere Protokolle hinzugefügt und begonnen, diese in einer einzigen Quelle zusammenzufassen, um die Durchsuchbarkeit zu verbessern.
2. Während des Ausfalls wurden die meisten der ausgefallenen Koordinatorprozesse manuell neu gestartet. Wir werden einen Prozessbeobachter hinzufügen, um solche Prozesse automatisch neu zu starten.
3. Wir haben auch festgestellt, dass wir keine gute Übersicht über die Inter-Host-Konnektivität hatten. Wir werden ein Dashboard erstellen, das dies zeigt.

Langfristig

1. Wir haben auch festgestellt, dass nicht alle unserer technischen Mitarbeiter mit Cassandra und ZooKeeper auf dem neuesten Stand sind. Wir werden Zeit investieren, um unsere Mitarbeiter in beiden Technologien zu schulen.
2. Prüfen Sie, ob Sie aus einer der AWS-Regionen auslagern können. Wir müssen unsere Hausaufgaben machen, wenn wir einen neuen Hosting-Anbieter und ein neues Rechenzentrum auswählen, um einen einzelnen Ausfallpunkt zu vermeiden.