Wir investieren enorm viel Zeit in die Zuverlässigkeit von PagerDuty und der zugehörigen Infrastruktur. Der Großteil dieser Arbeit läuft unsichtbar ab, verborgen hinter der API und der Benutzeroberfläche, mit der unsere Kunden interagieren. Wenn es jedoch zu Ausfällen kommt, werden diese deutlich spürbar, beispielsweise durch Verzögerungen bei Benachrichtigungen und 500-Fehler an unseren API-Endpunkten. Genau das passierte am Samstag, dem 13. April, gegen 8:00 Uhr pazifischer Zeit. PagerDuty war aufgrund einer Beeinträchtigung in einer bestimmten Infrastruktur nicht erreichbar. Spähpunkt Wird von zwei AWS-Regionen genutzt.

Mit diesem Beitrag möchten wir unsere Kunden darüber informieren, was passiert ist, was wir daraus gelernt haben und was wir unternehmen werden, um alle durch diesen Ausfall aufgedeckten Probleme zu beheben.

Hintergrund

Die Infrastruktur von PagerDuty ist in drei verschiedenen Rechenzentren gehostet (zwei bei AWS und eines bei Linode). Seit einem Jahr arbeiten wir an der Neuarchitektur unserer Software, um den Ausfall eines gesamten Rechenzentrums (einschließlich einer Trennung vom Netzwerk) zu überstehen. Die Fähigkeit, den gleichzeitigen Ausfall zweier Rechenzentren zu überstehen, war jedoch nicht explizit in unsere Planung integriert. So unwahrscheinlich es auch sein mag, genau das ist am Samstagmorgen passiert. Da wir eine AWS-Region als Rechenzentrum betrachten und beide gleichzeitig ausfielen, konnten wir unsere Verfügbarkeit mit dem verbleibenden Rechenzentrum nicht aufrechterhalten.

Wir haben unsere drei Rechenzentren so ausgewählt, dass sie voneinander unabhängig sind und physisch getrennt liegen. Nun haben wir jedoch erfahren, dass zwei der Rechenzentren einen gemeinsamen Peering-Punkt nutzten. Dieser Peering-Punkt war ausgefallen, wodurch beide Rechenzentren offline gingen.

Der Ausfall

Notiz: Alle unten angegebenen Zeiten sind in pazifischer Zeit.

• Laut AWS traten um 7:57 Uhr Verbindungsprobleme aufgrund einer Verschlechterung der Verbindungsbedingungen an einem Peering-Punkt in Nordkalifornien auf.
• Um 8:11 Uhr wird der diensthabende PagerDuty -Techniker über ein Problem mit einem der Knotenpunkte in unserem Benachrichtigungssystem informiert.
• Um 8:13 Uhr wird ein Versuch unternommen, den ausgefallenen Knoten wiederherzustellen, jedoch ohne Erfolg.
• Um 8:18 Uhr meldet unser Überwachungssystem einen Ausfall mehrerer Anbieter bei Benachrichtigungen (verursacht durch Verbindungsprobleme). Zu diesem Zeitpunkt werden die meisten Benachrichtigungen noch zugestellt, jedoch mit erhöhten Latenzen und Fehlerraten.
• Um 8:31 Uhr wurde eine Störung der Stufe 2 ausgerufen und weitere Ingenieure wurden zur Unterstützung angefordert.
• Um 8:35 Uhr verliert PagerDuty aufgrund hoher Netzwerklatenz und des damit verbundenen fehlenden Quorums die Fähigkeit, Benachrichtigungen zu versenden. Sev-1 wird deklariert.
• Um 8:53 Uhr erreichte das PagerDuty -Benachrichtigungssystem das Quorum und begann mit der Verarbeitung aller in der Warteschlange befindlichen Benachrichtigungen.
• Laut AWS endete das Verbindungsproblem am Peering-Punkt in Nordkalifornien um 9:23 Uhr.

Bei der Fehleranalyse stellten unsere Techniker fest, dass eine Fehlkonfiguration unseres Koordinierungsdienstes eine schnelle Wiederherstellung verhinderte. Insgesamt konnte PagerDuty zwischen 8:35 Uhr und 8:53 Uhr 18 Minuten lang keine Benachrichtigungen versenden; unsere Ereignis-API konnte jedoch während dieser Zeit weiterhin Ereignisse empfangen.

Was wir tun werden

Wie immer bei größeren Ausfällen lernen wir etwas Neues über Schwachstellen in unserer Software. Im Folgenden stellen wir einige unserer Pläne zur Behebung der festgestellten Probleme vor.

Kurzfristig

1. Im Rahmen unserer Analyse stellten wir fest, dass unsere Protokollierung für die Fehlersuche in einigen unserer Systeme unzureichend war. Wir haben nun zusätzliche Protokolle implementiert und diese zur besseren Auffindbarkeit in einer zentralen Quelle zusammengeführt.
2. Während des Ausfalls wurden die meisten fehlgeschlagenen Koordinierungsprozesse manuell neu gestartet. Wir werden einen Prozesswächter hinzufügen, um solche Prozesse automatisch neu zu starten.
3. Wir stellten außerdem fest, dass wir keinen guten Überblick über die Verbindungen zwischen den Hosts hatten. Wir werden ein Dashboard entwickeln, das dies visualisiert.

Langfristig

1. Wir haben außerdem festgestellt, dass nicht alle unsere Ingenieure über aktuelle Kenntnisse in Cassandra und ZooKeeper verfügen. Wir werden daher Zeit investieren, um unsere Mitarbeiter in beiden Technologien zu schulen.
2. Prüfen Sie die Möglichkeit eines Umzugs in eine andere AWS-Region. Bei der Auswahl eines neuen Hosting-Anbieters und Rechenzentrums müssen wir sorgfältig vorgehen, um einen Single Point of Failure zu vermeiden.