Als Mitglied des Echtzeit-Engineering-Teams von PagerDuty ist es mir ein großes Anliegen, unsere Systeme mit hoher Verfügbarkeit und Zuverlässigkeit zu entwickeln und zu implementieren. Am 30. Mai 2013 hatten wir einen kurzen Ausfall, der zu einer Verschlechterung unserer Alarmzuverlässigkeit führte. Dieser Beitrag fasst zusammen, was passiert ist und was wir in Zukunft tun, um sicherzustellen, dass so etwas nicht wieder passiert.

Auswirkungen

Am 30. Mai 2013 um 22:50 UTC wurden unsere Bereitschaftstechniker wegen eines Problems im Linode Fremont-Rechenzentrum angepiept. In diesem Rechenzentrum gab es Probleme mit der Netzwerklatenz, was Linode etwa 6 Minuten später auf seiner Statusseite bestätigte.

Aufgrund dieses Problems wurden einige unserer Backup-Worker-Prozesse automatisch gestartet. Die Backup-Worker-Prozesse übernehmen das Senden von Benachrichtigungen aus unseren verschiedenen Benachrichtigungswarteschlangen, insbesondere um die Verzögerungen von Workern auszugleichen, die offline sind.

Leider war die Fehlerbehandlung bei diesen Prozessen nicht optimal. Aufgrund des Rechenzentrumsausfalls waren die Fehlerraten natürlich höher als normal. Dies führte zu Verzögerungen bei der Verarbeitung einiger Benachrichtigungen. Während des Ausfallzeitraums wurden 7 % aller ausgehenden Warnmeldungen um eine inakzeptable Zeitspanne verzögert. Alle Benachrichtigungen wurden letztendlich zugestellt und es gingen keine Benachrichtigungen verloren.

Zeitleiste

• Um 22:50 UTC werden unsere diensthabenden Techniker über Netzwerkkonnektivitätsprobleme im Linode Fremont-Rechenzentrum informiert.
• Um 22:56 UTC bestätigt Linode Probleme mit der Netzwerkkonnektivität in seinem Rechenzentrum in Fremont.
• Um 23:07 UTC bemerken unsere Techniker, dass die Verarbeitung des Backup-Workers in einer unserer Benachrichtigungswarteschlangen ins Stocken geraten ist. Daher wird dieser Prozess manuell neu gestartet.
• Um 23:14 UTC wird die Benachrichtigungsverarbeitung wieder normal durchgeführt.
• Um 23:30 UTC bestätigt Linode, dass die Netzwerkkonnektivitätsprobleme behoben sind.

Wie wir das Problem beheben

Der Fehler, der bei diesem Ausfall festgestellt wurde, wurde behoben. Obwohl wir unseren gesamten Code ausführlich testen, wurde dieser Fehler nicht erkannt. Da dieser Codepfad nur bei einem Ausfall des Rechenzentrums kritisch wird, konnten wir das Problem erst erkennen, als es in unserer Produktionsumgebung auftrat.

Wir werden Code, der in Ausnahmesituationen ausgeführt wird, besser testen. Systeme zu entwickeln, die mit Rechenzentrumsausfällen umgehen können, reicht allein nicht aus: Wir müssen kontinuierlich testen, ob sie wie vorgesehen funktionieren.

Obwohl wir in der Produktion kontrollierte Fehlertests durchführen, tun wir dies derzeit nicht oft genug und testen auch nicht genügend Fehlerfälle. Wir werden sehr bald einen regelmäßigen „Failure Friday“ einführen, an dem wir aktiv versuchen, eine umfangreiche Reihe kontrollierter Fehler zu initiieren. Im Laufe der Zeit hoffen wir, dazu übergehen zu können, unsere eigenen Chaos Monkey das diese Bedingungen kontinuierlich und zufällig schafft.