Fragen Sie jeden PagerDutonianer, was die wichtigste Anforderung an unseren Service ist, und Sie erhalten immer dieselbe Antwort: Zuverlässigkeit. Unsere Kunden verlassen sich darauf, dass wir sie benachrichtigen, wenn ihre Systeme Probleme haben – pünktlich, jederzeit, Tag und Nacht.

Unser Code wird in drei Rechenzentren und bei zwei Cloud-Anbietern eingesetzt, um sicherzustellen, dass alle Telefon-, SMS-, Push-Benachrichtigungen und E-Mail-Warnmeldungen zugestellt werden. Kritische Pfade in unserem Code verfügen über Backups; und unser Code verfügt über Backups für die Backups. Diese dreifache Redundanz stellt sicher, dass niemand jemals eine Warnung verschläft, eine Textnachricht verpasst oder eine E-Mail nicht erhält.

Wir brauchen mehr als fehlertolerantes Design

Ein fehlertolerantes Design ist zwar großartig, aber manchmal gibt es Implementierungsprobleme, die dazu führen, dass diese Designs nicht wie vorgesehen funktionieren. Beispielsweise können Backups, die nur bei Störungen eingreifen, Fehler oder Code verbergen, der in einer Testumgebung gut funktioniert, aber unter Produktionslast versagt. Beim Cloud-Hosting müssen wir damit rechnen, dass unsere Infrastruktur jederzeit ausfallen kann.

Sogar das Internet selbst ist eine Fehlerquelle. Wir beobachten regelmäßig dramatische Anstiege bei Latenz und Paketverlust zwischen Rechenzentren. Einige dieser Ereignisse lassen sich auf bekannte Probleme wie DDoS-Angriffe zurückführen, einige Ursachen sind jedoch unbekannt. In beiden Fällen können wir nichts gegen diese Ereignisse tun, außer sie technisch zu umgehen.

Rechenzentrumsübergreifende Latenz in Millisekunden

Netflix hat dieses Problem mit seiner Simian Army gelöst: einer Reihe automatisierter Tools, die Anwendungen auf Ausfallsicherheit testen. Chaos Monkey fährt Instanzen herunter, die über Auto-Scaling-Gruppen neu gestartet werden. Latency Monkey führt künstliche Latenz in Netzwerkaufrufe ein. Chaos Gorilla fährt eine ganze Verfügbarkeitszone herunter. Obwohl einige dieser Tools kostenlos verfügbar sind, gehen sie davon aus, dass Ihre Anwendung ausschließlich in AWS mithilfe von Auto-Scaling-Gruppen bereitgestellt wird, während unsere Anwendung über mehrere Anbieter verteilt ist.

Da wir uns nicht mit der Entwicklung eigener gleichwertiger Tools aufhalten wollten, haben wir uns für eine unkomplizierte Methode entschieden. Vereinbaren Sie einfach einen Termin und führen Sie die Tests manuell durch. Wir verwenden für alle unsere Tests gängige Linux-Befehle, sodass der Einstieg ganz einfach ist.

Vorteile von PagerDuty Failure Friday

Wir führen den Failure Friday seit einigen Monaten hier bei PagerDuty durch. Wir haben bereits eine Reihe von Vorteilen festgestellt:

• Deckt Implementierungsprobleme auf die unsere Widerstandsfähigkeit verringern.
• Entdeckt proaktiv Mängel um zu vermeiden, dass diese Diskrepanzen zur Ursache künftiger Ausfälle werden.
• Baut eine starke Teamkultur auf indem sie einmal pro Woche als Team zusammenkommen, um Wissen auszutauschen. Die Betriebsabteilung kann lernen, wie die Entwicklungsteams Produktionsprobleme in ihren Systemen debuggen. Die Entwickler erhalten ein besseres Verständnis dafür, wie ihre Software bereitgestellt wird. Und es ist ein nettes Extra, neue Mitarbeiter im Umgang mit Ausfällen freitags um 11 Uhr statt samstags um 3 Uhr morgens zu schulen.
• Erinnert uns daran, dass es zu Fehlern kommen wird. Ein Ausfall wird nicht mehr als ein Zufallsereignis betrachtet, das ignoriert oder wegerklärt werden kann. Der gesamte Code, den die Entwicklungsteams schreiben, wird jetzt darauf getestet, wie er den Failure Friday übersteht.

Vorbereitung unseres Teams auf den Misserfolg am Freitag

Bevor der Failure Friday beginnt, ist es wichtig, dass wir eine Agenda aller Fehler erstellen, die wir vorstellen möchten. Wir planen ein einstündiges Meeting und arbeiten an so vielen Themen wie möglich.

Das Einbringen von Fehlern kann schwerwiegendere Fehler verursachen, als wir möchten. Daher ist es wichtig, dass alle in Ihrem Team mit der Idee einverstanden sind, Fehler in Ihr System einzubringen. Um das Risiko zu minimieren, stellen wir sicher, dass alle Teammitglieder benachrichtigt werden und mit an Bord sind.

Während wir uns auf den ersten Angriff vorbereiten, deaktivieren wir alle Cron-Jobs, die während dieser Stunde ausgeführt werden sollen. Das Team, dessen Dienst wir angreifen werden, wird mit Dashboards ausgestattet, um seine Systeme zu überwachen, während der Fehler eingefügt wird.

Kommunikation ist am Failure Friday unerlässlich. Bei PagerDuty verwenden wir einen dedizierten HipChat-Raum und eine Telefonkonferenz, damit wir schnell Informationen austauschen können. Ein Chatroom ist besonders nützlich, da er uns ein mit einem Zeitstempel versehenes Protokoll der durchgeführten Aktionen liefert, das wir mit den erfassten Metriken korrelieren können.

Wir lassen auch unsere PagerDuty Warnmeldungen aktiviert, um zu bestätigen, dass wir Warnmeldungen erhalten, und um zu sehen, wie schnell sie im Verhältnis zum aufgetretenen Fehler eintreffen.

Einführung von Fehlern in unser System

Jeder Angriff auf unseren Dienst dauert fünf Minuten. Zwischen den Angriffen bringen wir den Dienst immer wieder in einen voll funktionsfähigen Zustand und bestätigen, dass alles ordnungsgemäß funktioniert, bevor wir mit dem nächsten Angriff fortfahren.

Während des Angriffs überprüfen wir unsere Dashboards, um zu verstehen, welche Kennzahlen auf das Problem hinweisen und wie sich dieses Problem auf andere Systeme auswirkt. Wir notieren in unserem Chatroom auch, wann wir angepiept wurden und wie hilfreich diese Seite war.

Bei jedem Angriff beginnen wir gerne mit dem Angriff auf einen einzelnen Host. Wenn dieser Angriff wie erwartet verläuft, wiederholen wir den Test mit einem gesamten Rechenzentrum. Bei Diensten, die nur auf AWS gehostet werden, testen wir, ob ein Dienst den Verlust einer gesamten Verfügbarkeitszone überlebt.

Angriff Nr. 1: Prozessfehler

Unser erster Angriff ist ziemlich einfach: Wir stoppen den Dienst für 5 Minuten. Das ist normalerweise genauso einfach wie „sudo service cassandra stop“. Wir erwarten, dass der Dienst als Ganzes trotz des Verlusts dieser Kapazität weiterhin Datenverkehr verarbeitet. Wir werden auch oft feststellen, ob unsere Alarme diesen Dienst korrekt als nicht verfügbar identifizieren. Um ihn wieder zu starten, führen wir „sudo service cassandra start“ aus.

Angriff Nr. 2: Hosts neu starten

Nachdem wir erfolgreich bestätigt haben, dass wir den Verlust eines einzelnen Knotens und eines gesamten Rechenzentrums überleben können, gehen wir dazu über, die Maschinen neu zu starten. Dieser Angriff bestätigt, dass die Maschine beim Neustart alle erforderlichen Dienste korrekt startet. Er hilft uns auch dabei, Fälle zu finden, in denen unsere Überwachung an die Maschine gebunden ist, auf der der Dienst ausgeführt wird, sodass wir keine Warnung erhalten, während sie heruntergefahren ist.

Angriff Nr. 3: Netzwerkisolation

Bei den beiden vorherigen Angriffen wurden die Dienste sauber heruntergefahren und die Boxen dann neu gestartet. Der nächste Angriff prüft, wie widerstandsfähig wir gegenüber unerwarteten Ausfällen sind. Wir blockieren die Netzwerkverbindung über iptables. Wir verwerfen sowohl eingehende als auch ausgehende Pakete. Dieser Test prüft, ob die Clients angemessene Timeouts konfiguriert haben und sich nicht auf saubere Dienstabschaltungen verlassen.

Um die Firewall zurückzusetzen, nachdem wir fertig sind, laden wir sie einfach von der Festplatte neu:

Angriff Nr. 4: Langsamkeit des Netzwerks

Unser letzter Angriff testet, wie der Dienst mit Langsamkeit umgeht. Wir simulieren mit tc einen langsamen Dienst auf Netzwerkebene.

Dieser Befehl verzögert den gesamten Netzwerkverkehr um 400 – 600 Millisekunden. Außerdem geht ein Paketverlust von 5 % einher. Bei diesem Fehler erwarten wir normalerweise eine gewisse Leistungsminderung. Im Idealfall können Clients die Verzögerung umgehen. Ein Cassandra-Client könnte sich beispielsweise dafür entscheiden, mit den schnelleren Knoten zu kommunizieren und den Datenverkehr nicht an den beeinträchtigten Knoten zu senden. Mit diesem Angriff wird getestet, wie gut unsere Dashboards den langsamen Knoten identifizieren. Beachten Sie, dass dies auch Auswirkungen auf alle Live-SSH-Sitzungen hat.

Die Verzögerung kann problemlos rückgängig gemacht werden.

Zusammenfassung

Sobald wir mit Failure Friday fertig sind, veröffentlichen wir eine Entwarnungsmeldung und aktivieren unsere Cron-Jobs erneut. Unser letzter Schritt besteht darin, alle umsetzbaren Erkenntnisse zu erfassen und sie einem unserer Teammitglieder in JIRA zuzuweisen.

Failure Friday ermöglicht uns, Probleme nicht nur zu beheben, sondern sie auch zu verhindern. Die Zuverlässigkeit von PagerDuty ist für uns äußerst wichtig und durch die Teilnahme unseres Teams an Failure Friday können wir sie aufrechterhalten.

Möchten Sie mehr erfahren? Sie können sich Doug Barths Vortrag über Failure Friday ansehen, der hier im PagerDuty Hauptquartier gefilmt wurde!

4 Jahre danach

Schauen Sie sich unbedingt unseren nächsten Blogbeitrag an: „ Failure Fridays: 4 Jahre danach “, um zu sehen, wie sich unser Prozess im Laufe der Jahre entwickelt hat.