Am 28. Juni 2017 feierten wir unser viertes Jubiläum „ Misserfolg am Freitag „ bei PagerDuty. Um es kurz zusammenzufassen: Failure Fridays sind eine Praxis, die wir bei PagerDuty wöchentlich durchführen, um Fehler auf kontrollierte Weise und ohne Auswirkungen auf den Kunden in unsere Produktionsumgebung einzuschleusen. Sie waren für uns von grundlegender Bedeutung, um unsere Bemühungen im Bereich Resilienztechnik zu überprüfen.

Im Laufe der Jahre hat sich unser Prozess weiterentwickelt, manchmal nach Chaos Engineering Prinzipien, manchmal nicht. Aber die Konstante von Failure Friday war schon immer, uns dabei zu helfen, Probleme zu erkennen und zu beheben, bevor sie sich auf unsere Kunden auswirken. Hier sind einige Meilensteine unserer Reise und einige der Lektionen, die wir gelernt haben:

Zeitleiste

2013

• Juni : Der erste Failure Friday!

2014

• Februar : Unser erster sicherheitsorientierter Failure Friday. Anstatt die Fehlerresistenz eines einzelnen Dienstes durch Isolierung, Neustarts und dergleichen zu testen, haben wir auf eine Reihe von Randfällen getestet, wie z. B. dass APIs ungültige Daten gesendet werden und die Firewall falsch konfiguriert ist. Diese Vorgehensweise wird auch heute noch angewendet, wobei bestimmte Failure Fridays nicht dazu dienen, Fehler in einen einzelnen Dienst einzuschleusen, sondern stattdessen auf infrastrukturweite Anti-Patterns zu testen.
• April : Weniger als ein Jahr nachdem wir Failure Fridays gestartet hatten, simulierten wir den vollständigen Ausfall eines der sieben verschiedenen Verfügbarkeitszonen unsere Infrastruktur war damals in Betrieb. Als wir das das erste Mal gemacht haben, haben wir es mit unserer Paranoia ein bisschen übertrieben und es im Laufe von vier separaten Sitzungen akribisch simuliert. Jetzt schaffen wir es normalerweise in etwa einer Sitzung.

2015

• Januar : Nach 18 Monaten und 33 Sitzungen haben wir endlich viele der manuellen Befehle aus dem ursprünglichen Failure Friday-Beitrag automatisiert in ChatOps-basiert Werkzeuge. Indem wir die Schritte zunächst manuell durchführten, konnten wir sie validieren und daraus lernen, ohne im Vorfeld viel Zeit aufwenden zu müssen. Als wir als Unternehmen wuchsen, wurde es immer schwieriger, neue Leute einzuarbeiten, also nahmen wir die Hilfe unseres Unternehmens-Bots in Anspruch:

• Januar : Nachdem wir uns mit dem Gedanken angefreundet hatten, eine einzige Availability Zone zu verlieren, haben wir unser Vorgehen verschärft und eine ganze Region . Normalerweise benötigen wir dafür trotzdem ein paar Sitzungen, da wir dabei immer neue Erkenntnisse gewinnen.
• Marsch : Wir erkannten, dass Failure Fridays eine großartige Gelegenheit waren, Unser Incident Response Prozess , also begannen wir, es als Trainingsgelände für unsere neuesten Einsatzleiter zu nutzen, bevor sie ihren Abschluss machten.
• Mai : Als wir begannen, die Anzahl der Dienste und der sie wartenden Teams zu erhöhen, begannen wir, eine formellere Dokumentation geplanter Fehler, Checklisten für zukünftige Sitzungen, Ergebnisse von Fehlereinfügungen usw. zu führen. „Es ist keine Wissenschaft, wenn man es nicht aufschreibt.“

2016

• April : Ein weiteres Jahr ist vergangen und eine weitere groß angelegte Reihe von Failure Friday-Fehlertests – wir haben begonnen, ein Failover auf unsere Disaster Recovery-Infrastruktur zu simulieren. Während des normalen Betriebs validieren wir unsere DR-Tools mit einem kleinen Prozentsatz des Live-Verkehrs, aber während dieser Szenarien steigern wir diesen Prozentsatz des Live-Verkehrs und achten dabei darauf, unsere Kunden nicht zu beeinträchtigen.
• Juni : Wir haben „Reboot Roulette“ in unsere Automatisierungssuite eingeführt, wobei Hosts nach dem Zufallsprinzip ausgewählt werden (mit Gewichtung für verschiedene Hostkategorien), denen ein Fehler injiziert wird (der Neustart war der erste von mehreren hinzugefügten Fehlern, natürlich wegen der Alliteration).

• September : Bei einem Hackday, Chaos Cat wird vorgestellt , wobei alle vorhandenen Werkzeuge zur Automatisierung der Fehlereinfügung verwendet werden (zu einem anderen Zeitpunkt als in unserem normalen Failure-Friday-Fenster).

2017

• Juli : Wir haben innerhalb von PagerDuty eine interne Gilde von Ingenieuren aus mehreren Teams gegründet, die sich alle für Chaos Engineering interessieren.

Statistiken

Wenn wir unsere Failure Friday-Aufzeichnungen noch einmal durchgehen, sind hier einige Kennzahlen vom 28. Juni 2013 bis zum 28. Juni 2017:

• Misserfolg Freitag Sitzungen: 121
• Erstellte Tickets zur Behebung der am Failure Friday festgestellten Probleme: über 200
• Eingefügte Fehler: 644
• Fehlerinjektionen, die zu einer öffentlichen Postmortem-Analyse führten: 3
• Simulierte vollständige AZ-Ausfälle (Deaktivierung aller Dienste in einer bestimmten AZ): 4
• Simulierte vollständige Regionsausfälle (Deaktivierung aller Dienste in einer bestimmten Region): 3
• Simulierte teilweise Notfallwiederherstellung (den gesamten Datenverkehr in eine andere Region senden): 2
• Verschiedene Dienste innerhalb von PagerDuty , bei denen Fehler eingeschleust wurden: 47

Schlussfolgerungen

Das Einbringen von Fehlern und die kontinuierliche Verbesserung unserer Infrastruktur hat uns nicht nur geholfen, bessere Software zu liefern, sondern auch internes Vertrauen und Empathie aufzubauen. Stresstests unserer Systeme und Prozesse helfen uns zu verstehen, wie wir unsere Abläufe verbessern können – und Du kannst es auch tun .