Am 28. Juni 2017 feierten wir unser viertes Jubiläum mit „ Misserfolgsfreitage „ bei PagerDuty. Kurz zusammengefasst: Failure Fridays sind eine wöchentliche Praxis bei PagerDuty , um Fehler kontrolliert und ohne Kundenbeeinträchtigung in unsere Produktionsumgebung einzuschleusen. Sie waren für uns von grundlegender Bedeutung, um unsere Bemühungen im Bereich Resilienz-Engineering zu überprüfen.

Im Laufe der Jahre hat sich unser Prozess weiterentwickelt, manchmal nach Chaos Engineering Prinzipien, manchmal auch nicht. Die Konstante des Failure Friday war jedoch immer, uns zu helfen, Probleme zu erkennen und zu beheben, bevor sie unsere Kunden beeinträchtigen. Hier sind einige Meilensteine unserer Reise und einige der Erkenntnisse, die wir daraus gezogen haben:

Zeitleiste

2013

• Juni : Der erste Failure Friday!

2014

• Februar : Unser erster sicherheitsorientierter Failure Friday. Anstatt die Ausfallsicherheit einzelner Dienste durch Isolierung, Neustarts usw. zu testen, testeten wir verschiedene Randfälle, wie z. B. das Senden ungültiger Daten an APIs und eine fehlerhafte Firewall-Konfiguration. Diese Praxis wird auch heute noch angewendet, wobei bestimmte Failure Fridays nicht dazu dienen, Fehler in einzelne Dienste einzuschleusen, sondern 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. Beim ersten Mal haben wir es mit unserer Paranoia etwas übertrieben und es in 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 investieren zu müssen. Mit dem Wachstum unseres Unternehmens wurde es immer schwieriger, neue Mitarbeiter einzuarbeiten, daher nahmen wir die Hilfe unseres Unternehmens-Bots in Anspruch:

• Januar : Nachdem wir uns mit dem Gedanken angefreundet hatten, eine einzelne Availability Zone zu verlieren, haben wir unser Spiel verstärkt und eine ganze Region . Normalerweise benötigen wir dennoch mehrere Sitzungen, um diese abzuschließen, da sie uns immer neue Erkenntnisse bringen.
• Marsch : Wir haben erkannt, dass Failure Fridays eine großartige Gelegenheit sind, Sport zu treiben 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, geplante Fehler, Checklisten für zukünftige Sitzungen, Ergebnisse von Fehlerinjektionen usw. formeller zu dokumentieren. „Es ist keine Wissenschaft, wenn man es nicht aufschreibt.“

2016

• April : Ein weiteres Jahr später und eine weitere groß angelegte Reihe von Failure-Friday-Fehlertests – wir haben begonnen, das Failover auf unsere Disaster-Recovery-Infrastruktur zu simulieren. Im Normalbetrieb validieren wir unsere DR-Tools mit einem kleinen Anteil Live-Verkehr. In diesen Szenarien erhöhen wir diesen Anteil jedoch, um unsere Kunden nicht zu beeinträchtigen.
• Juni : Wir haben „Reboot Roulette“ in unsere Automatisierungssuite eingeführt, bei dem zufällig Hosts 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 Tools zur Automatisierung der Fehlerinjektion verwendet werden (zu einem anderen Zeitpunkt als unserem normalen Failure Friday-Fenster).

2017

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

Statistiken

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

• Sitzungen am Freitag mit Fehlern: 121
• Zur Behebung der am Failure Friday festgestellten Probleme erstellte Tickets: ü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 Einfügen von Fehlern und die kontinuierliche Verbesserung unserer Infrastruktur haben 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 .