Chaos Engineering

Einleitung: Die Geburt des Chaos

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Chaos Engineering ist noch eine relativ neue Disziplin innerhalb der Softwareentwicklung. Diese Einführung gibt einen Überblick über die Geschichte, von den bescheidenen Anfängen bis hin zur aktuellen Epoche, in der alle großen Industrien das Verfahren in irgendeiner Form übernommen haben. In den letzten drei Jahren hat sich die Frage von "Sollten wir Chaos Engineering betreiben?" zu "Wie fange ich am besten an, Chaos Engineering zu betreiben?" gewandelt.

Die Geschichte unserer neu entstehenden Disziplin erklärt, wie wir von der ersten zur zweiten Frage gekommen sind. Wir wollen nicht einfach nur eine Geschichte mit Daten und Bewegungen erzählen, um die Fakten richtig zu stellen. Wir wollen die Geschichte erzählen, wie sie entstanden ist, damit du verstehst, warum sie so entstanden ist, wie sie entstanden ist, und wie du von diesem Weg lernen kannst, um das Beste aus der Praxis zu machen.

Die Geschichte beginnt bei Netflix, wo die Autorinnen dieses Buches, Casey Rosenthal und Nora Jones, beide arbeiteten, als das Chaos Team Chaos Engineering definierte und propagierte.¹ Netflix entdeckte einen echten geschäftlichen Nutzen in dieser Praxis, und als andere das erkannten, entstand eine Gemeinschaft, die diese Disziplin in der gesamten Tech-Branche verbreitete.

Managementprinzipien als Kodex

Seit im Jahr 2008 hat Netflix sehr öffentlich gezeigt² den Wechsel vom Rechenzentrum in die Cloud. Im August desselben Jahres konnte Netflix wegen einer großen Datenbankstörung im Rechenzentrum drei Tage lang keine DVDs ausliefern. Das war, bevor Video-Streaming allgegenwärtig war; der DVD-Versand machte den Großteil des Geschäfts aus.

Damals war man der Meinung, dass das Rechenzentrum sie in eine Architektur mit Single Points of Failure, wie z. B. großen Datenbanken, und vertikal skalierten Komponenten einschloss. Die Verlagerung in die Cloud würde horizontal skalierte Komponenten erfordern, was die einzelnen Fehlerquellen verringern würde.

Die Dinge liefen nicht genau wie geplant. Zum einen dauerte es acht Jahre, bis sie sich vollständig aus dem Rechenzentrum zurückgezogen hatten. Und was uns noch mehr interessiert: Die Umstellung auf horizontal skalierte Cloud-Bereitstellungspraktiken brachte nicht den erwarteten Anstieg der Betriebszeit des Streaming-Dienstes mit sich.³

Um das zu erklären, müssen wir uns daran erinnern, dass Amazon Web Services (AWS) im Jahr 2008 deutlich weniger ausgereift war als heute. Cloud Computing war noch keine Massenware und nicht annähernd so selbstverständlich, wie es heute der Fall ist. Der Cloud-Service war damals sehr vielversprechend, und eines dieser Versprechen war, dass Instanzen⁴ gelegentlich ohne Vorwarnung verschwinden würden. In einem Rechenzentrum, in dem große, leistungsstarke Maschinen gut gewartet werden und die Eigenheiten bestimmter Maschinen oft gut bekannt sind, war diese Art von Ausfall selten. In einer Cloud-Umgebung, in der die gleiche Leistung von vielen kleineren Maschinen auf Standard-Hardware erbracht wurde, war dies leider ein häufiges Ereignis.

Die Methoden zum Aufbau von Systemen, die gegen diese Art von Ausfallereignissen gewappnet sind, waren gut bekannt. Man hätte vielleicht ein halbes Dutzend gängiger Praktiken aufzählen können, die dazu beitragen, dass ein System automatisch überlebt, wenn eine seiner Komponenten unerwartet fehlschlägt: redundante Knoten in einem Cluster, Begrenzung der Fehlerdomäne durch Erhöhung der Anzahl der Knoten und Verringerung der relativen Leistung jedes einzelnen Knotens, Einsatz von Redundanzen in verschiedenen Regionen, automatische Skalierung und automatisierte Dienstsuche usw. Es war nicht wichtig, wie man ein System so robust macht, dass es mit dem Verschwinden von Instanzen umgehen kann. Es kann sogar je nach Kontext des Systems unterschiedlich sein. Wichtig war nur, dass es getan werden musste, weil der Streamingdienst aufgrund der hohen Häufigkeit von Instanzinstabilitäten mit Verfügbarkeitsdefiziten zu kämpfen hatte. In gewisser Weise hatte Netflix den Single-Point-of-Failure-Effekt einfach vervielfacht.

Netflix war nicht wie andere Softwareunternehmen. Das Unternehmen förderte proaktiv kulturelle Grundsätze, die sich aus einer einzigartigen Managementphilosophie ableiten, die in einem Kulturdeck dargelegt ist. Dies äußerte sich in mehreren Praktiken, die einen großen Einfluss darauf hatten, wie Netflix das Verfügbarkeitsdefizit löste. Zum Beispiel:

• Netflix stellte nur Senior-Ingenieure ein, die bereits Erfahrung in der Funktion hatten, für die sie eingestellt wurden.

• Sie gaben allen Ingenieurinnen und Ingenieuren die volle Freiheit, alles zu tun, was nötig war, um den Auftrag zu erfüllen, und trugen gleichzeitig die Verantwortung für alle Konsequenzen, die mit diesen Entscheidungen verbunden waren.

• Entscheidend ist, dass Netflix den Menschen, die die Arbeit machen, die Entscheidung überlässt, wie die Arbeit gemacht wird.

• Das Management sagte den einzelnen Mitarbeitern nicht, was sie zu tun hatten, sondern stellte sicher, dass die Mitarbeiter die Probleme verstanden, die gelöst werden mussten. Die IKs teilten dem Management dann mit, wie sie diese Probleme lösen wollten, und arbeiteten dann daran, sie zu lösen.

• Hochleistungsteams sind in hohem Maße aufeinander abgestimmt und lose gekoppelt. Das bedeutet, dass weniger Aufwand für Prozesse, formale Kommunikation oder Aufgabenmanagement betrieben werden muss, wenn alle im Team das gleiche Ziel verfolgen.

Diese interessante Dynamik ist einer der Gründe für die Hochleistungskultur von Netflix und hatte eine interessante Konsequenz für die Entwicklung des Chaos Engineering. Da es nicht Aufgabe des Managements war, den ICs vorzuschreiben, was sie zu tun hatten, gab es bei Netflix keinen Mechanismus, mit dem eine Person, ein Team oder eine Gruppe den anderen Ingenieuren vorschreiben konnte, wie sie ihren Code schreiben sollten. Obwohl ein halbes Dutzend gemeinsamer Muster für das Schreiben von Diensten, die robust genug sind, um mit verschwindenden Instanzen umzugehen, niedergeschrieben werden konnten, gab es keine Möglichkeit, einen Erlass an die gesamte technische Organisation zu senden, der verlangte, dass alle diese Anweisungen befolgen.

Netflix musste einen anderen Weg finden.

Der Chaos-Affe ist geboren

Viele Dinge wurden ausprobiert, aber eine Sache funktionierte und blieb bestehen: Chaos Monkey. Diese sehr einfache App ging eine Liste von Clustern durch, wählte zufällig eine Instanz aus jedem Cluster aus und schaltete sie irgendwann während der Geschäftszeiten ohne Vorwarnung ab. Dies geschah an jedem Arbeitstag.

Das klingt grausam, aber die Absicht war nicht, jemanden zu verärgern. Die Betreiber wussten, dass diese Art von Ausfall - das Verschwinden von Instanzen - sowieso irgendwann in jedem Cluster auftreten würde. Chaos Monkey gab ihnen die Möglichkeit, proaktiv die Widerstandsfähigkeit aller Mitarbeiter zu testen, und zwar während der Geschäftszeiten, damit die Mitarbeiter auf mögliche Auswirkungen reagieren konnten, wenn sie die Ressourcen dazu hatten, und nicht um 3 Uhr morgens, wenn die Pager normalerweise losgehen. Wenn du die Häufigkeit auf einmal pro Tag erhöhst, wirkt das wie ein Regressionstest, der sicherstellt, dass die Mitarbeiter/innen nicht in diesen Ausfallmodus abdriften.

Die Netflix-Überlieferung besagt, dass dies nicht sofort beliebt war. Es gab eine kurze Zeit, in der die ICs über den Chaos-Affen murrten. Aber es schien zu funktionieren, so dass mehr und mehr Teams es schließlich übernahmen.

Wir können uns diese Anwendung so vorstellen, dass sie den Schmerz des Problems - das Verschwinden von Instanzen, die die Serviceverfügbarkeit beeinträchtigen - für jeden Ingenieur in den Vordergrund rückte. Sobald sie das Problem direkt vor Augen hatten, taten sie das, was sie am besten können: Sie lösten das Problem.

Wenn der Chaos-Affe ihren Dienst jeden Tag lahmlegte, konnten sie keine Arbeit erledigen, bis sie das Problem gelöst hatten. Es spielte keine Rolle, wie sie es lösten. Vielleicht fügten sie Redundanz hinzu, vielleicht Skalierungsautomatisierung, vielleicht architektonische Entwurfsmuster. Das spielte keine Rolle. Wichtig war nur, dass das Problem irgendwie, schnell und mit sofort spürbaren Ergebnissen gelöst wurde.

Diese unterstreicht den Grundsatz "hochgradig ausgerichtet, lose gekoppelt" in der Netflix-Kultur. Chaos Monkey hat alle dazu gezwungen, sich stark auf das Ziel auszurichten, robust genug zu sein, um mit verschwindenden Instanzen umzugehen, aber locker zu sein, was die Lösung dieses speziellen Problems angeht, da es keine Lösung vorschlägt.

Chaos Monkey ist ein Managementprinzip, das im laufenden Code umgesetzt wird. Das Konzept, das dahinter steckt, schien einzigartig und ein bisschen schräg, also bloggte Netflix darüber. Chaos Monkey wurde zu einem beliebten Open-Source-Projekt und sogar zu einem Recruiting-Tool, das Netflix bei potenziellen Bewerbern als kreative Softwareentwicklung und nicht nur als Unterhaltungsunternehmen bekannt machte. Kurz gesagt, Chaos Monkey wurde zum Erfolg. Das war ein Präzedenzfall und trug dazu bei, diese Form der Risikobereitschaft und kreativen Lösungsfindung als Teil der kulturellen Identität von Netflix zu etablieren.

Spule vor auf den 24. Dezember 2012, den Weihnachtsabend.⁵ Bei AWS kam es zu einem Ausfall der Elastic Load Balancers (ELBs). Diese Komponenten verbinden Anfragen und leiten den Datenverkehr an die Recheninstanzen weiter, auf denen die Dienste bereitgestellt werden. Als die ELBs ausfielen, konnten zusätzliche Anfragen nicht bedient werden. Da die Steuerungsebene von Netflix auf AWS lief, konnten die Kunden keine Videos auswählen und mit dem Streaming beginnen.

Das Timing war schrecklich. An Heiligabend hätte Netflix im Mittelpunkt stehen sollen, als die ersten Nutzer ihrer Großfamilie zeigten, wie einfach es ist, aktuelle Filme über das Internet zu streamen. Stattdessen waren die Familien und Verwandten gezwungen, miteinander zu sprechen, ohne die beruhigende Ablenkung durch die Netflix-Inhaltsbibliothek.

Innerhalb von Netflix tat das weh. Es war nicht nur ein Schlag für das öffentliche Image des Unternehmens und für den Stolz der Ingenieure, sondern auch für niemanden ein Vergnügen, an Heiligabend durch einen Paging-Alarm aus dem Urlaub gerissen zu werden, um zu sehen, wie AWS durch den Behebungsprozess stolpert .

Chaos Monkey war erfolgreich eingesetzt worden, um das Problem der verschwindenden Instanzen zu lösen. Das hat in kleinem Maßstab funktioniert. Könnte man etwas Ähnliches bauen, um das Problem der verschwindenden Regionen zu lösen? Würde es auch in einem sehr, sehr großen Maßstab funktionieren?

Groß rauskommen

Jede Interaktion zwischen dem Gerät eines Kunden und dem Netflix-Streamingdienst wird über die Steuerungsebene abgewickelt. Das ist die Funktionalität, die auf AWS bereitgestellt wird. Sobald ein Video gestreamt wird, werden die Daten für das Video selbst über das private Netzwerk von Netflix bereitgestellt, das bei weitem das größte Content Delivery Network (CDN) der Welt ist.

Der Ausfall an Heiligabend hat die interne Aufmerksamkeit auf die Entwicklung einer Aktiv-Aktiv-Lösung für den Datenverkehr in der Steuerungsebene gelenkt. Theoretisch würde der Datenverkehr für Kunden in der westlichen Hemisphäre auf zwei AWS-Regionen aufgeteilt werden, eine an jeder Küste. Sollte eine der beiden Regionen fehlschlagen, würde die Infrastruktur aufgebaut, um die andere Region zu skalieren und alle Anfragen dorthin zu verlagern.

Diese Fähigkeit berührt jeden Aspekt des Streamingdienstes. Es gibt eine Ausbreitungsverzögerung zwischen den Küsten. Einige Dienste müssten Dinge ändern, um die Konsistenz zwischen den Küsten zu gewährleisten, neue Strategien für die gemeinsame Nutzung von Zuständen entwickeln und so weiter. Sicherlich keine leichte technische Aufgabe.

Und auch hier gibt es aufgrund der Netflix-Struktur keinen Mechanismus, der vorschreibt, dass sich alle Ingenieure an eine zentralisierte, überprüfte Lösung halten, die einen regionalen Ausfall nachweislich bewältigen würde. Stattdessen koordinierte ein Team, das von der Unternehmensleitung unterstützt wurde, die Bemühungen der verschiedenen betroffenen Teams.

Um sicherzustellen, dass alle diese Teams ihre Dienste zur Verfügung haben, wurde eine Aktivität erstellt, um eine Region offline zu nehmen. AWS erlaubte es Netflix nicht, eine Region offline zu nehmen (wegen anderer Kunden in der Region), also wurde dies simuliert. Die Aktivität trug den Namen "Chaos Kong".

Die ersten Male, als Chaos Kong ins Leben gerufen wurde, war es eine nervenaufreibende Angelegenheit, bei der ein "Kriegsraum" eingerichtet wurde, um alle Aspekte des Streamingdienstes zu überwachen, und es dauerte Stunden. Monatelang wurde Chaos Kong abgebrochen, bevor der gesamte Datenverkehr aus einer Region verschoben werden konnte, weil Probleme festgestellt und an die Betreiber des Dienstes zur Behebung zurückgegeben wurden. Schließlich wurde die Aktivität stabilisiert und in die Zuständigkeit des Traffic Engineering Teams überführt. Chaos Kongs wurden routinemäßig durchgeführt, um zu überprüfen, ob Netflix einen Aktionsplan für den Fall hatte, dass eine einzelne Region ausfiel.

Bei vielen Gelegenheiten, entweder aufgrund von Problemen auf Seiten von Netflix oder aufgrund von Problemen mit AWS, kam es in einer Region tatsächlich zu erheblichen Ausfallzeiten. In diesen Fällen wurde der regionale Failover-Mechanismus, der in Chaos Kong verwendet wird, eingesetzt. Die Vorteile dieser Investition lagen auf der Hand.⁶

Der Nachteil des regionalen Failover-Prozesses war, dass er aufgrund der Komplexität der manuellen Interpretation und der damit verbundenen Eingriffe im besten Fall etwa 50 Minuten dauerte. Unter anderem durch die Erhöhung der Häufigkeit von Chaos Kong, was sich wiederum auf die internen Erwartungen bezüglich des regionalen Failover-Prozesses innerhalb der technischen Organisation auswirkte, konnte das Traffic Engineering Team ein neues Projekt starten, das den Failover-Prozess letztendlich auf nur sechs Minuten reduzierte.⁷

Das bringt uns ungefähr ins Jahr 2015. Netflix hatte Chaos Monkey und Chaos Kong, die an der kleinen Skala der verschwindenden Instanzen bzw. an der großen Skala der verschwindenden Regionen arbeiteten. Beide wurden von der Ingenieurskultur unterstützt und trugen nachweislich zur Verfügbarkeit des Dienstes zu diesem Zeitpunkt bei.

Formalisierung der Disziplin

Bruce Wong gründete Anfang 2015 ein Chaos Engineering Team bei Netflix und überließ Casey Rosenthal die Aufgabe, eine Charta und einen Fahrplan zu entwickeln. Er war sich nicht ganz sicher, worauf er sich eingelassen hatte (ursprünglich war er eingestellt worden, um das Traffic Engineering Team zu leiten, was er gleichzeitig mit dem Chaos Engineering Team fortsetzte), und ging bei Netflix herum, um zu fragen, was die Leute unter Chaos Engineering verstehen.

Die Antwort lautete in der Regel: "Chaos Engineering ist, wenn wir Dinge in der Produktion absichtlich kaputt machen." Das hörte sich cool an und wäre vielleicht eine tolle Ergänzung für ein LinkedIn-Profil, aber es war nicht sehr hilfreich. Jeder bei Netflix, der Zugang zu einem Terminal hatte, konnte Dinge in der Produktion kaputt machen, und die Chancen stehen gut, dass dies dem Unternehmen keinen Nutzen brachte.

Casey hat sich mit seinen Teams zusammengesetzt, um Chaos Engineering offiziell zu definieren. Sie wollten vor allem Klarheit über:

• Was ist die Definition von Chaos Engineering?

• Was ist der Sinn davon?

• Woher weiß ich, wann ich es tue?

• Wie kann ich meine Praxis verbessern?

Nachdem sie etwa einen Monat lang an einer Art Manifest gearbeitet hatten, erstellten sie die Principles of Chaos Engineering. Die Disziplin wurde offiziell formalisiert.

Die super-formale Definition, auf die man sich geeinigt hat, lautet: "Chaos Engineering ist die Disziplin des Experimentierens mit einem verteilten System, um Vertrauen in die Fähigkeit des Systems zu schaffen, turbulenten Bedingungen in der Produktion standzuhalten." Damit wurde festgelegt, dass es sich um eine Form des Experimentierens handelt, die sich vom Testen abgrenzt.

Bei geht es in erster Linie darum, Vertrauen aufzubauen. Das ist gut zu wissen, denn wenn du kein Selbstvertrauen brauchst, dann ist das nichts für dich. Wenn du andere Möglichkeiten hast, Vertrauen aufzubauen, kannst du abwägen, welche Methode am effektivsten ist .

In der Definition ist auch von "turbulenten Bedingungen in der Produktion" die Rede, um zu verdeutlichen, dass es nicht darum geht, Chaos zu schaffen. Beim Chaos Engineering geht es darum, das dem System innewohnende Chaos sichtbar zu machen.

In den Principles wird ein grundlegendes Templating für Experimente beschrieben, das sich stark an Karl Poppers Prinzip der Falsifizierbarkeit anlehnt. In dieser Hinsicht ist das Chaos Engineering eher eine Wissenschaft als eine Technik.

Schließlich werden in den Principles fünf fortgeschrittene Praktiken aufgeführt, die den Goldstandard für eine Chaos-Engineering-Praxis darstellen:

• Erstelle eine Hypothese über das Verhalten im stationären Zustand

• Realitätsnahe Ereignisse variieren

• Experimente in der Produktion durchführen

• Automatisiere Experimente, damit sie kontinuierlich laufen

• Explosionsradius minimieren

Jedes dieser Themen wird in den folgenden Kapiteln nacheinander behandelt.

Das Team von Netflix hat ein Zeichen gesetzt. Sie wussten jetzt, was Chaos Engineering ist, wie es funktioniert und welchen Wert es für das gesamte Unternehmen hat.

Die Gemeinschaft ist geboren

Wie bereits erwähnt, stellte Netflix nur erfahrene Ingenieure ein. Das bedeutete, dass man, wenn man Chaos-Ingenieure einstellen wollte, einen Pool von erfahrenen Leuten in diesem Bereich brauchte, aus dem man auswählen konnte. Da sie das Fachgebiet gerade erst erfunden hatten, war das natürlich schwierig zu bewerkstelligen. Es gab keine Senior-Chaos-Ingenieure, die man einstellen konnte, weil es keine Junior-Ingenieure gab, denn außerhalb von Netflix gab es sie nicht.

Um dieses Problem zu lösen, beschloss Casey Rosenthal auf, das Feld zu evangelisieren und eine Community of Practice zu gründen. Zunächst organisierte er im Herbst 2015 eine Konferenz mit dem Namen "Chaos Community Day", zu der nur geladene Gäste kamen. Sie fand im Büro von Uber in San Francisco statt und wurde von etwa 40 Personen besucht. Die folgenden Unternehmen waren vertreten: Netflix, Google, Amazon, Microsoft, Facebook, DropBox, WalmartLabs, Yahoo!, LinkedIn, Uber, UCSC, Visa, AT&T, NewRelic, HashiCorp, PagerDuty, und Basho.

Die Präsentationen wurden nicht aufgezeichnet, damit die Teilnehmer frei über ihre Probleme sprechen konnten, die sie hatten, um das Management davon zu überzeugen, diese Praxis zu übernehmen, und damit sie "Ausfälle" und Störungen inoffiziell diskutieren konnten. Die Referenten wurden im Voraus ausgewählt, um darüber zu sprechen, wie sie Fragen der Ausfallsicherheit, der Fehlerinjektion, des Fehlertests, des Disaster Recovery Tests und andere Themen im Zusammenhang mit Chaos Engineering angehen.

Eines der ausdrücklichen Ziele von Netflix bei der Einführung des Chaos Community Day war es, andere Unternehmen zu inspirieren, speziell für die Rolle "Chaos Engineer" einzustellen. Das hat funktioniert. Im nächsten Jahr fand der Chaos Community Day in Seattle im Blackfoot-Büroturm von Amazon statt. Ein Manager von Amazon verkündete, dass er nach dem ersten Chaos Community Day die Geschäftsführung davon überzeugt hatte, ein Team von Chaos Engineers bei Amazon aufzubauen. Auch andere Unternehmen griffen nun auf den Titel "Chaos Engineer" zurück.

In diesem Jahr, 2016, stieg die Teilnehmerzahl auf 60 Personen. Zu den auf der Konferenz vertretenen Unternehmen gehörten Netflix, Amazon, Google, Microsoft, Visa, Uber, Dropbox, Pivotal, GitHub, UCSC, NCSU, Sandia National Labs, Thoughtworks, DevJam, ScyllaDB, C2, HERE, SendGrid, Cake Solutions, Cars.com, New Relic, Jet.com und O'Reilly.

Auf Anregung von O'Reilly veröffentlichte das Team von Netflix im darauffolgenden Jahr einen Bericht zum Thema Chaos Engineering, der zeitgleich mit mehreren Präsentationen und einem Workshop auf der Velocity-Konferenz in San Jose stattfand.

Auch 2017 organisierten Casey Rosenthal und Nora Jones den Chaos Community Day in San Francisco in der Autodesk-Niederlassung in der Market Street 1. Casey hatte Nora beim letzten Chaos Community Day kennengelernt, als sie bei Jet.com arbeitete. Inzwischen ist sie zu Netflix gewechselt und gehört dort dem Chaos Engineering Team an. Mehr als 150 Personen nahmen teil, darunter die üblichen Verdächtigen der großen Silicon Valley-Unternehmen, die in großem Maßstab arbeiten, sowie verschiedene Start-ups, Universitäten und alles, was dazwischen liegt. Das war im September.

Ein paar Monate später hielt Nora auf der AWS re:Invent-Konferenz in Las Vegas eine Keynote zum Thema Chaos Engineering vor 40.000 Besuchern und weiteren 20.000 Streaming-Teilnehmern. Chaos Engineering war der große Wurf.

Schnelle Entwicklung

Wie du in diesem Buch sehen wirst, entwickeln sich die Konzepte, die sich durch das Chaos Engineering ziehen, schnell weiter. Das bedeutet, dass ein Großteil der Arbeit in diesem Bereich von der ursprünglichen Absicht abgewichen ist. Manches davon mag sogar widersprüchlich erscheinen. Es ist wichtig, sich daran zu erinnern, dass Chaos Engineering ein pragmatischer Ansatz ist, der in einer Hochleistungsumgebung entwickelt wurde, in der es um einzigartige Probleme in großem Maßstab geht. Dieser Pragmatismus ist nach wie vor die treibende Kraft des Fachgebiets, auch wenn ein Teil seiner Stärke aus der Wissenschaft und der akademischen Welt stammt .

¹ Casey Rosenthal hat das Chaos Engineering Team drei Jahre lang bei Netflix aufgebaut und geleitet. Nora Jones trat dem Chaos Engineering Team schon früh als Ingenieurin und technische Leiterin bei. Sie war für wichtige architektonische Entscheidungen über die entwickelten Tools und die Implementierung verantwortlich.

² Yury Izrailevsky, Stevan Vlaovic und Ruslan Meshenberg, "Completing the Netflix Cloud Migration", Netflix Media Center, 11. Februar 2016, https://oreil.ly/c4YTI.

³ In diesem Buch bezeichnen wir die Verfügbarkeit des Systems im Allgemeinen als die wahrgenommene "Betriebszeit".

⁴ In einer Cloud-basierten Bereitstellung ist eine "Instanz" analog zu einer virtuellen Maschine oder einem Server im früheren Branchenjargon.

⁵ Adrian Cockcroft, "A Closer Look at the Christmas Eve Outage," The Netflix Tech Blog, Dec. 31, 2012, https://oreil.ly/wCftX.

⁶ Ali Basiri, Lorin Hochstein, Abhijit Thosar und Casey Rosenthal, "Chaos Engineering Upgraded", The Netflix Technology Blog, Sept. 25, 2015, https://oreil.ly/UJ5yM.

⁷ Luke Kosewski et al., "Project Nimble: Region Evacuation Reimagined," The Netflix Technology Blog, March 12, 2018, https://oreil.ly/7bafg.