Am 24., 25. und 26. Januar 2013 kam es bei PagerDuty zu mehreren Ausfällen. Die Ereignis-API, die unsere Kunden verwenden, um Überwachungsereignisse von Überwachungstools an PagerDuty zu übermitteln, war während der Ausfälle nicht erreichbar. Unsere Webanwendung, die zum Zugriff auf und zur Konfiguration von Kundenkonten verwendet wird, war ebenfalls betroffen und möglicherweise während der Ausfälle nicht verfügbar.

Wir haben diese Nachbesprechung verfasst, um Sie über das Geschehene zu informieren und Ihnen mitzuteilen, was wir tun, um sicherzustellen, dass dies nie wieder passiert. Zu guter Letzt möchten wir uns für diesen Ausfall entschuldigen. Obwohl wir in diesem Zeitraum keinen einzigen längeren Ausfall hatten, glauben wir fest an das Mantra, dass selbst 2 Minuten Ausfallzeit inakzeptabel sind, und wir möchten Sie wissen lassen, dass wir hart daran arbeiten, unsere Verfügbarkeit sowohl kurzfristig als auch langfristig zu verbessern.

Hintergrund

Die PagerDuty Infrastruktur wird in mehreren Rechenzentren (DCs) gehostet. Die Benachrichtigungsversandkomponente von PagerDuty ist über 3 DCs hinweg vollständig redundant und kann einen DC-Ausfall ohne Ausfallzeit überstehen. Wir haben das System so konzipiert, dass es einen verteilten Datenspeicher verwendet, der keinerlei Failover oder Wechsel erfordert, wenn ein gesamtes DC offline geht.

Die Event-API, die von einem Warteschlangensystem unterstützt wird, basiert jedoch immer noch auf unserem alten Legacy-Datenbanksystem, das auf einem herkömmlichen RDBMS basiert. Dieses System verfügt über eine primäre Datenbank, die synchron auf einen sekundären Host repliziert wird. Das System verfügt außerdem über eine tertiäre Datenbank, die asynchron repliziert wird (nur für den Fall, dass sowohl die primäre als auch die sekundäre Datenbank Probleme haben). Wenn der primäre Host ausfällt, besteht unser Standardverfahren darin, auf den sekundären Host umzusteigen. Der Nachteil besteht darin, dass der Umstieg einige Minuten Ausfallzeit erfordert.

Ausfalldetails

Notiz: Alle unten genannten Zeitangaben erfolgen in pazifischer Zeit.

Am 24.1.

• Um 8:25 Uhr fielen sowohl die Event-API als auch die Website aus.
• Um 8:25 Uhr wurden die diensthabenden Techniker von PagerDuty alarmiert.
• Um 8:32 Uhr starteten wir eine Telefonkonferenz zum Schweregrad 1.
• Um 8:36 Uhr begannen wir mit dem Umschaltvorgang von der primären zur sekundären Datenbank.
• Um 8:41 Uhr war der Flip-Vorgang abgeschlossen.
• Um 8:42 Uhr wurden die Event-API und die Website wieder online gebracht.

Später an diesem Tag gab es mehrere Aussetzer:

• Um 16:16 Uhr: kleiner Aussetzer – 1 Minute Ausfall
• Um 22:37 Uhr: kleiner Aussetzer – 1 Minute Ausfall
• Um 22:51 Uhr: kleiner Aussetzer – 1 Minute Ausfall

Den ganzen Tag haben wir an der Untersuchung des Problems und an der Nachbesprechung gearbeitet. Im Rahmen der Untersuchung bemerkten wir eine große Anzahl von Aufrufen einer bestimmten langsamen Abfrage in der Datenbank. Wir haben den Code geändert, um den Aufruf der fehlerhaften Abfrage zu deaktivieren. Zu diesem Zeitpunkt dachten wir, die Ausfälle seien durch eine einzige langsame Abfrage verursacht worden, die wir behoben hatten, sodass wir dachten, das zugrunde liegende Problem sei ebenfalls behoben.

Am 25.1.

• Um 7:05 Uhr: kleiner Aussetzer – 3 Minuten Ausfall

Wir haben den neuen Ausfall untersucht und eine weitere problematische langsame Abfrage gefunden, die wir sofort behoben haben.

Am 26.1.

• Um 2:28 Uhr fielen die Event-API und die Website aus.
• Um 2:28 Uhr wurden die diensthabenden Techniker angepiept.
• Um 2:38 Uhr waren sowohl die Event-API als auch die Website wiederhergestellt.

An diesem Punkt kamen wir zu dem Schluss, dass es das Beste wäre, die Datenbankmaschine auf einen größeren Host zu aktualisieren. Die Ingenieure arbeiteten die ganze Nacht durch, um alle neuen Datenbankmaschinen (primäre, sekundäre und tertiäre) auf besserer Hardware zu bauen.

Gegen 6 Uhr morgens glaubten wir, der Aufbau der neuen Maschinen sei abgeschlossen. Von 6:15 Uhr bis 9:14 Uhr versuchten wir ein paar Mal, die Datenbank auf eine neue primäre Maschine umzustellen, jedes Mal erfolglos. Jeder dieser Versuche verursachte ein paar Minuten Ausfallzeit.

An diesem Punkt haben wir es aufgegeben, auf die neue Maschine umzusteigen. Der Grund dafür, dass der Wechsel nicht funktionierte, war, dass der Daten-Snapshot auf der neuen Maschine nicht richtig hochgeladen wurde, da die Techniker extrem müde und ausgebrannt waren, nachdem sie die ganze Nacht an den Upgrades gearbeitet hatten.

Nach einer Ruhepause von etwa 12 Stunden begannen die Ingenieure von Grund auf mit dem Aufbau neuer Datenbankmaschinen. Die frisch ausgeruhten Ingenieure richteten eine neue Primärdatenbank ein. Ein paar Stunden später richteten sie auch eine aktualisierte Sekundärdatenbank und eine aktualisierte Tertiärdatenbank ein.

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

Kurzfristig

Wir werden eine strenge Überwachung für langsame Abfragen in unserem Datenspeicher einrichten [bereits erledigt]. Wir werden auch den Aufbau eines neuen Datenbankservers über Chef automatisieren. Der DB-Server war eine der letzten Komponenten unserer Infrastruktur, die mit Chef bearbeitet wurde, und am 26. und 27.1. haben wir die DB-Maschinen von Hand neu aufgebaut, anstatt Chef zu verwenden, was ein zeitaufwändiger und fehleranfälliger Prozess war.

Wir werden außerdem einen strengeren Entwicklungsprozess einführen, bei dem neue Funktionen und Änderungen an der Codebasis im Rahmen des regelmäßigen Codeüberprüfungsprozesses [bereits durchgeführt] auf ihre Datenbankleistung hin überprüft werden müssen.

Wir werden außerdem bessere Hostmetriken für den Datenbankserver einrichten, damit wir frühzeitig erkennen können, ob und wann wir an unsere Kapazitätsgrenze kommen, und den Server ordnungsgemäß aktualisieren können.

Langfristig

Wir werden die Abhängigkeit unserer Event-API von unserer Haupt-RDBMS-Datenbank entfernen. Um etwas mehr Kontext zu geben: Unsere Event-API wird durch eine Warteschlange unterstützt: Eingehende Ereignisse werden in die Warteschlange gestellt und Hintergrundarbeiter verarbeiten in die Warteschlange gestellte Ereignisse. Der Grund dafür ist, dass wir so große Mengen an Event-Verkehr ordnungsgemäß handhaben und verarbeiten können.

Derzeit ist diese Warteschlange von unserer Haupt-SQL-Datenbank abhängig. Wie oben erläutert, ist diese Datenbank mit 2 Backups in 2 Rechenzentren vollständig redundant, erfordert jedoch ein Failover, wenn die Hauptdatenbank (primäre Datenbank) ausfällt.

Als Ergebnis dieser Obduktion werden wir ein Projekt beschleunigen, um die API-Warteschlange und die Worker für Ereignisse so umzustrukturieren, dass sie unseren neueren verteilten Datenspeicher verwenden können. Dieser Datenspeicher ist auf 5 Knoten und 3 unabhängige Rechenzentren verteilt und so konzipiert, dass er den Ausfall eines gesamten Rechenzentrums ohne Failover-Prozess und ohne jegliche Ausfallzeit übersteht.