Latest / M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch / Azure Chaos Studio einfach erklärt: Chaos Engineering, Fehlerinjektion und resiliente Azure-Apps (KI-Synchronfassung)

Transcript

Azure Chaos Studio einfach erklärt: Chaos Engineering, Fehlerinjektion und resiliente Azure-Apps (KI-Synchronfassung) · M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch

0:00
Bereit für 10 Tage voller Microsoft iPhone 65, Co-Pilot, KI, Azure und den Menschen, die die Zukunft der Arbeit gestalten?
0:07
Diesen Januar ist die N365-Con zurück und wir legen noch eins drauf.
0:12
Seien Sie bei Live-Sessions, Praxis-Demos und Expertenwissen von MVPs und Branchenkennern weltweit dabei.
0:18
Keine generischen Folien, kein endloses Buzzword-Bingo.
0:22
Wir gehen echte Herausforderungen an.
0:23
Co-Pilot Studio, KI-Agenten, Fabric, Sicherheit, Governance und Automatisierung.
0:28
Egal ob IT-Profi, Entwickler oder Führungskraft, es gibt Sessions, die speziell für Sie entwickelt wurden.
0:34
An 10 vollen Tagen können Sie zahlreiche Technologien erkunden und sich mit einer globalen Community vernetzen.
0:40
Schauen Sie live zu und nehmen Sie praktische Erkenntnisse mit in Ihr Unternehmen.
0:45
Januar 2027, 10 Tage, eine Microsoft-Community.
0:49
Die Anmeldung ist jetzt geöffnet.
0:51
Gehen Sie auf m365.net und sichern Sie sich noch heute Ihren Platz.
0:55
Das ist m365.net.
1:00
Melden Sie sich jetzt unter m365.net an.
1:02
Wir sehen uns im Januar live.
1:04
Willkommen zu einer weiteren Episode der Microsoft Knowledge Nuggets.
1:07
Ich bin Ihr Gastgeber Mykopeters.
1:08
Was wäre, wenn Sie Ihre eigenen Cloud-Apps absichtlich und kontrolliert kaputt machen könnten, um Sie widerstandsfähiger zu machen?
1:13
Klingt widersprüchlich, folgt aber der gleichen Logik, die Feuerwehrleute beim kontrollierten Abbrennen nutzen.
1:17
Sie legen gezielt kleine Feuer, um trockenes Unterholz zu beseitigen,
1:19
damit bei einem echten Waldbrand nichts mehr übrig bleibt, das brennen kann.
1:22
Genau das macht Azure Car Studio für Ihre Cloud-Apps.
1:24
Am Ende dieser Episode werden Sie verstehen, was der Dienst ist, warum Sie ihn nutzen sollten
1:28
und wie er Ihnen hilft, Systeme zu bauen, die bei Problemen nicht sofort ausfallen.
1:32
Schnappen Sie sich also Ihren Kaffee und fangen wir mit dem Problem an.
1:35
Das Problem.
1:36
Warum traditionelle Tests nicht ausreichen.
1:39
Hier ist die Sache mit herkömmlichen Tests.
1:40
Sie prüfen, ob Ihre Software unter normalen Bedingungen wie vorgesehen funktioniert.
1:44
Sie schreiben einen Test, füllen ihn aus.
1:45
Wenn die Ausgabe übereinstimmt, haben Sie bestanden.
1:47
Großartig, um Fehler zu finden, aber Sie erfassen nicht, wie sich Ihr System verhält,
1:51
wenn etwas Unerwartetes passiert, wie ein Netzwerk-Timeout,
1:53
eine ausfallende VM oder eine komplette Availability-Zone, die offline geht.
1:57
Moderne Cloud-Apps sind nicht mehr einfach.
1:59
Es sind verteilte Systeme, die mit Datenbanken, Caches, Identitätsdiensten,
2:02
Drittanbieter-RPIs und anderen Microservices kommunizieren
2:04
und all diese Teile haben verborgene Abhängigkeiten.
2:06
Ein kleiner Ausfall kann sich wie eine Kaskade durch das gesamte System ziehen.
2:09
Eine Datenbank wird langsam, die App bekommt ein Timeout,
2:11
der Load-Balancer markiert sie als fehlerhaft,
2:12
der Traffic wird umgeleitet, andere Instanzen werden überlastet,
2:14
andere Instanzen werden überlastet und plötzlich ist Ihre Gesamtenung da.
2:17
Herkömmliche Tests erkennen das nicht, weil Sie unter perfekten Bedingungen testen.
2:20
Alles ist verfügbar, null Netzwerklatenz und niemand schaltet während des Testlaufs VMs ab.
2:25
Sie gehen also voller Selbstvertrauen in die Produktion und dann holt sie die Realität ein.
2:28
Und dieses falsche Vertrauen ist gefährlich, denn es ist der Unterschied
2:30
zwischen dem Wissen, dass Ihr System funktioniert und dem Wissen, dass es überlebt.
2:34
Und genau hier kommt Chaos Engineering ins Spiel.
2:36
Was ist Chaos Engineering eigentlich?
2:38
Chaos Engineering ist eine praktische Methode.
2:39
Sie fügen Ihrem System echte, kontrollierte Fehler zu und beobachten, wie es reagiert.
2:43
Dies geschieht nicht in einem Labor oder einer Simulation.
2:46
Es passiert auf Ihren tatsächlichen Ressourcen.
2:47
Die Idee ist einfach.
2:48
Sie beginnen mit einer Hypothese.
2:50
Etwa, wenn wir eine virtuelle Maschine verlieren,
2:52
sollte der Load-Balancer den Datenverkehr weiterhin an die verbleibenden Instanzen leiten.
2:55
Dann führen Sie ein Experiment.
2:56
Sie fahren diese VM herunter und beobachten, was passiert.
2:58
Erfüllt der Load-Balancer seine Aufgabe.
3:00
Bleibt die Andung aktiv?
3:01
Werden Ihre Alarme korrekt ausgelöst?
3:02
Sie messen alles und beheben dann, was kaputt geht.
3:06
Das ist der Punkt.
3:07
Chaos Engineering ist keine willkürliche Zerstörung.
3:08
Es ist kein Entwickler, der in den Serverraum geht und zum Spaßkabel zieht.
3:12
Es ist wissenschaftlich, wiederholbar und sicherheitsorientiert.
3:15
Sie definieren den Wirkungsbereich und kontrollieren genau, was ausfällt, wann und wie lange.
3:19
Und am wichtigsten, Sie lernen daraus.
3:21
Jedes Experiment liefert Ihnen Erkenntnis.
3:22
Entweder war Ihre Hypothese richtig und Ihr System ist resilient,
3:25
oder sie war falsch und Sie haben eine Schwachstelle gefunden, die Sie beheben können.
3:28
So oder so gewinnen Sie.
3:29
Die Herausforderung ist, dass es schwierig ist, eigene Chaos Engineering Tools zu entwickeln.
3:32
Sie müssten Skripte schreiben, um VMs herunterzufahren,
3:34
um CPU-Last zu erzeugen, Netzwerkverkehr zu blockieren und all das sicher und wiederholbar zu orchestrieren.
3:39
Das ist viel Arbeit und genau deshalb hat Azure einen verwalteten Dienst entwickelt, der das übernimmt.
3:43
Wir stellen vor Azure Chaos Studio.
3:45
Azure Chaos Studio ist ein vollständig verwalteter Dienst zur Durchführung von Chaos-Experimenten direkt auf Ihren Azure-Ressourcen.
3:50
Keine benutzerdefinierten Skripte, keine Drittanbieter-Tools, kein Aufbau einer eigenen Plattform zur Fehlerinjektion.
3:55
Es ist alles im Azure-Portal bereit für den Einsatz.
3:57
So funktioniert es.
3:58
Chaos Studio bietet Ihnen zwei Möglichkeiten zur Fehlerinjektion.
4:00
Dienstdirekte Fehler laufen über die Azure-Steuerungsebene selbst.
4:03
Sie weisen Chaos Studio an, eine VM herunterzufahren und dies geschieht über die eigenen APIs von Azure.
4:07
Kein Agent erforderlich.
4:09
Agentbasierte Fehler installieren einen kleinen Agenten innerhalb ihrer virtuellen Maschinen.
4:12
Damit kann er die CPU auf hunderte Prozent auslasten, den Arbeitsspeicher füllen oder einen bestimmten Prozess beenden.
4:17
So können Sie Probleme simulieren, die innerhalb des Betriebssystems auftreten, nicht nur auf Ressourcenebene.
4:22
Das ist eine Analogie.
4:22
Stellen Sie sich vor, Sie besitzen ein großes Bürogebäude.
4:25
Sie möchten wissen, ob Ihre Feuertreppen tatsächlich funktionieren.
4:27
Auf ein echtes Feuer zu warten, ist eine schreckliche Idee.
4:29
Also stellen Sie ein spezielles Katastrophenteam ein.
4:31
Sie kommen herein, sperren ein Treppenhaus ab, simulieren Rauch im dritten Stock und beobachten, wie die Leute reagieren.
4:35
Das ist Chaos Studio.
4:36
Es ist Ihre Katastrophengruppe.
4:38
Sie rufen Sie dazu, Sie führen die Übung durch und Sie erfahren, ob Ihr Gebäude sicher ist, bevor der echte Notfall eintritt.
4:43
Chaos Studio unterstützt eine breite Palette an Azure-Ressourcen.
4:46
Virtuelle Computer, VM-Skalierungsgruppen, Azure Kubernetes Service Cluster, Azure Cosmos DB,
4:52
Azure Cache for Redis, Netzwerksicherheitsgruppen und mehr.
4:56
Die Fehlerbibliothek weiter.
4:57
Egal, ob Sie eine einfache Zwei-Schichten-App oder eine komplexe Microservices-Architektur auf AKS ausführen, Sie können sie testen.
5:03
Ist die gute Nachricht.
5:04
Sie müssen keine eigenen Tools entwickeln.
5:06
Alles ist über das Azure-Portal, die CLI, REST APIs, ARM-Vorlagen oder BICEP verfügbar.
5:11
Sie können Ihre Experimente als Code definieren und in Ihre Bereitstellungsparkplans integrieren.
5:14
Aber greifen wir nicht zu weit vor.
5:16
Lassen Sie uns zuerst aufschlüsseln, wie diese Experimente tatsächlich strukturiert sind.
5:19
Die Bausteine, Ziele, Schritte, Verzweigungen, Aktion.
5:22
Jedes Chaos-Experiment beginnt mit Zielen.
5:24
Was ist ein Ziel?
5:25
Es ist einfach eine Azure-Ressource, gegen die Sie Fehler ausführen möchten.
5:28
Sie öffnen Chaos Studio, suchen Ihre Ressource, eine VM, eine Skalierungsgruppe, einen AKS-Cluster und integrieren sie.
5:33
Das bedeutet, Sie sagen Chaos Studio.
5:35
Diese Ressource steht für Experimente bereit.
5:37
Ist entscheidend.
5:38
Wenn Sie ein Ziel integrieren, wählen Sie auch aus, welche Fehler Sie für diese Ressource zulassen möchten.
5:43
Sie aktivieren nicht alles.
5:44
Bewerben.
5:45
CPU-Auslastung.
5:46
Vollständig runterfahren, die Perfekt.
5:47
Vielleicht nicht in der Produktion.
5:48
Sie entscheiden.
5:49
Sobald Ihre Ziele integriert sind, erstellen Sie ein Experiment.
5:52
Betrachten Sie ein Experiment in seinen Bauplan.
5:53
Es beschreibt genau, welche Fehler eingefügt werden sollen, in welcher Reihenfolge, gegen welche Ziele und für wie lange.
5:58
Sie sagen nicht einfach, mach irgendwas kaputt.
6:00
Sie definieren das gesamte Szenario im Voraus.
6:02
Experimente haben eine einfache Struktur, Schritte, Verzweigung und Aktion.
6:05
Schritte laufen nacheinander ab.
6:07
Schritt 1 ist beendet, dann startet Schritt 2, dann Schritt 3.
6:10
So modellieren Sie eine Zeitleiste.
6:11
Zuerst das Netzwerk drosseln, dann die CPU belasten, dann eine VM herunterfahren.
6:15
Jeder Schritt ist eine Phase in Ihrem Szenario.
6:17
Innerhalb jedes Schrittes können Sie eine oder mehrere Verzweigungen.
6:19
Hier wird es interessant.
6:21
Verzweigungen laufen parallel.
6:22
In Schritt 1 könnten Sie also Verzweigung A haben, die Ihrer Datenbanklatenz hinzufügt,
6:26
und Verzweigung B, die die CPU Ihrer Web-Server hochfährt, beides gleichzeitig.
6:29
Damit können Sie komplexe Multifeller-Szenarien simulieren,
6:32
die reale Vorfälle widerspiegeln.
6:33
Dann haben Sie noch Aktion.
6:35
Aktionen sind die eigentlichen Fehler.
6:36
CPU-Auslastung, Arbeitsspeicherauslastung, VM herunterfahren,
6:39
Netzwerkverzögerung, DNS-Blockade, Prozessorbruch.
6:42
Jede Aktion zielt auf eine bestimmte Ressource oder Ressourcengruppe ab.
6:45
Und noch einmal, Sie können nur Aktionen verwenden, die Sie für das Ziel aktiviert haben.
6:48
Das ist Ihr Sicherheitsnetz.
6:49
Wenn Sie das Herunterfahren der VM für ein Ziel nicht aktiviert haben,
6:52
führt das Experiment diese Aktion nicht aus.
6:53
Der Arbeitsablauf sieht also so aus.
6:55
Onboarding Ihrer Ziele.
6:56
Aktivieren Sie die Fehler, mit denen Sie sich wohlfühlen.
6:58
Erstellen Sie ein Experiment mit Schritten, Verzweigungen und Aktionen
7:02
mit der Ausführung beginnen, gibt es etwas Wichtiges zu verstehen.
7:04
Wenn Chaos-Studio ein Experiment ausführt, simuliert es nichts.
7:07
Es führt diese Dinge tatsächlich an den Ressourcen aus.
7:09
CPU-Auslastung ist echte CPU-Auslastung.
7:11
Ein Verunterfahren ist ein echtes Herunterfahren.
7:13
Genau das ist der Punkt.
7:14
Sie testen, wie sich Ihr System unter tatsächlichen Fehlerbedingungen verhält.
7:16
Und das bedeutet, dass Sie vorsichtig sein müssen.
7:18
Gehen wir also ein echtes Experiment durch und ziehen wir uns an, wie alles zusammenkommt.
7:21
Durchführung Ihres ersten Chaos-Experiments.
7:23
Machen wir es konkret.
7:24
Stellen Sie sich vor, Sie haben eine Web-Anwendung,
7:26
die auf drei virtuellen Maschinen in einer VM-Skalierungsgruppe läuft.
7:29
Jede VM befindet sich in einer anderen Verfügbarkeitszone.
7:32
Sie haben einen Load-Balancer davor, der den Datenverkehr auf alle drei verteilt.
7:35
Die Hypothese ist einfach.
7:36
Wenn wir eine ganze Verfügbarkeitszone verlieren,
7:39
sollte der Load-Balancer den Datenverkehr auf die verbleibenden zwei VMs umleiten,
7:42
sodass die Anwendung verfügbar bleibt.
7:44
Sie entwerfen also ein Experiment mit zwei Schritten.
7:46
Schritt 1. Belasten Sie zwei der drei VMs für fünf Minuten mit 95% CPU-Auslastung.
7:51
Dies simuliert ein neusier Neber-Szenario oder einen außer Kontrolle geratenen Prozess.
7:54
Schritt 2. Fahren Sie abrupt alle VMs in Zone 2.
7:57
Das simuliert einen echten Zone-Ausfall.
8:00
Sie führen das Experiment aus und beobachten, was passiert.
8:02
Hier ist, was Sie sehen würden.
8:03
In den ersten fünf Minuten steigt die CPU-Auslastung von zwei VMs auf 100%.
8:07
Die dritte bleibt normal, da Sie sie nicht als Ziel ausgewählt haben.
8:10
Ihre Überwachungs-Dashboards leuchten auf, Alarme werden ausgelöst,
8:12
der Load-Balancer bemerkt, dass diese beiden VMs Probleme haben,
8:15
aber da sie technisch gesehen noch laufen, sendet er weiterhin Datenverkehr an Sie.
8:18
Ihre App wird langsamer, geht aber nicht offline.
8:19
Das ist interessant.
8:20
Sie haben bereits etwas gelernt.
8:22
Dann setzt Schritt 2 ein.
8:23
Die VMs in Zone 2 werden abrupt heruntergefahren, nicht ordnungsgemäß und ohne Vorwarnung.
8:26
Sie verschwinden einfach.
8:28
Eine dieser beiden belasteten VMs befand sich in dieser Zone, ist also weg.
8:30
Der Load-Balancer stellt fest, dass der Integritätstest-Fehlschläge entfernt die VM aus dem Backendpool
8:34
und leitet den gesamten Datenverkehr an die verbleibenden gesunden V-Auslands.
8:36
Ihre App bleibt verfügbar.
8:37
Die Hypothese bestätigt sie.
8:39
Doch hier ist etwas, womit Sie vielleicht nicht rechnen.
8:41
Die verbleibenden VMs müssen nun 100% des Datenverkehrs bewältigen.
8:43
Wenn Sie nicht genügend Kapazität zur Aufnahme dieser Last hätten, würden Sie Latenzspitzen sehen.
8:47
Vielleicht bleibt die App technisch online, aber die Nutzer spüren die Auswirkungen.
8:50
Das ist ein Erkennen.
8:51
Sie wissen jetzt, dass Sie entweder mehr Spielraum oder eine schnellere automatische Skalierung benötigen.
8:55
Und denken Sie daran, das ist keine Simulation.
8:56
Wenn Chaos Studio dieses Experiment ausführt, erreichen diese VMs tatsächlich eine CPU-Auslastung von 95%.
9:01
Das Herunterfahren von Zone 2 ist ein echtes Erholung.
9:03
Die VM stoppt der Load-Balancer, verteilt die Last neu und ihre Anwendung überlebt entweder oder nicht.
9:07
Genau darum geht es.
9:08
Sie raten nicht.
9:09
Sie beobachten echtes Verhalten unter echten Fehlerbedingungen.
9:12
Sie lernen, ob Ihre App aktiv bleibt oder ausfällt.
9:14
Und wenn sie ausfällt, beheben Sie es, bevor Ihre Kunden es jemals bemerken.
9:18
Doch diese Macht bringt Verantwortung mit sich.
9:20
Sie müssen vorsichtig sein.
9:22
Sicherheit geht vor, um ungeplante Ausfälle zu vermeiden.
9:24
Chaos Studio verfügt über mehrere integrierte Sicherheitsmechanismen.
9:27
Und bevor Sie Ihr erstes Experiment starten, müssen Sie jeden Einzelnen davon verstehen.
9:31
Die erste Sicherheitsebene sind Identität und Berechtigung.
9:33
Jedes Experiment, das Sie erstellen, erhält eine eigene, vom System zugewiesene Verwaltetität.
9:37
Diese Identität beginnt jedoch standardmäßig mit null Berechtigung.
9:39
Sie müssen Ihr explizit Zugriff auf die benötigten Ressourcen gewähren und die minimal erforderlichen Berechtigungen erteilen.
9:45
Wenn ein Experiment nur die CPU von zwei VMs belasten muss, schränken Sie die Berechtigung genau ein,
9:49
anstatt zuzulassen, dass alles in der Ressourcengruppe heruntergefahren wird.
9:53
Dann gibt es noch die Fehlerfreigabe, die ich vorhin erwähnt habe.
9:55
Wenn Sie ein Ziel einbinden, wählen Sie genau aus, welche Fehler Sie zulassen möchten.
9:59
Wenn Sie das Herunterfahren von VMs für eine Produktionsskalierungsgruppe nie aktivieren,
10:03
kann kein Experiment diese VMs abschalten, selbst wenn jemand...
10:05
Es ist eine harte Blockade, die erfordert, dass Sie sich bewusst für jeden Fehlertyp entscheiden.
10:10
Nun, wo fängt man an?
10:11
Die Antwort ist einfach.
10:12
Fangen Sie klein an und beginnen Sie in einer Nicht-Produktionsumgebung.
10:15
Führen Sie Ihre ersten Experimente in der Entwicklungs- oder Staging-Umgebung.
10:18
Testen Sie mit einem einzelnen VM und einem einzelnen Fehler und validieren Sie,
10:21
dass Ihr Monitoring funktioniert, Ihre Alarme ausgelöst werden und Sie das Experiment abbrechen können, wenn etwas schief geht.
10:25
Erst nachdem Sie dieses Vertrauen in einer sicheren Umgebung aufgebaut haben,
10:28
sollten Sie überhaupt darüber nachdenken, die Produktion anzulassen.
10:30
Microsoft hat eine Warnung dazu, die ich direkt teilen möchte.
10:33
Sie nennen es ein lebenslaufgenerierendes Ereignis.
10:36
Wenn Sie ein Chaos-Experiment in der Produktion ohne ordnungsgemäße Sicherheitsvorkehrungen durchführen,
10:39
nur durch Ihre gesamte Anwendung angelegt wird, ist das die Art von Fehler, die zu Ihrer Entlassung fünge.
10:42
Das ist keine Übertreibung.
10:43
Chaos Studio ist leistungsstark, weil es tatsächlich Auswirkungen auf Ihre Ressourcen hat,
10:47
also nutzen Sie diese Macht mit Bedacht.
10:49
Das letzte Sicherheitsnetz ist die Überwachung und der Abbruch.
10:51
Während ein Experiment läuft, können Sie den Fortschritt in Echtzeit verfolgen.
10:55
Sie sehen, welche Schritte abgeschlossen sind, welche Zweige aktiv sind und welche Aktionen ausgeführt werden.
10:59
Wenn etwas nicht stimmt, klicken Sie auf Abbrechen und das Experiment stoppt sofort.
11:03
Die betroffenen Ressourcen verbleiben in Ihrem aktuellen Zustand, aber es werden keine neuen Fehler initiiert.
11:08
Halten Sie also Ihre Dashboards offen und Ihren Finger bereit für den Abbruch.
11:11
Fangen Sie klein an, gehen Sie über den Fonds und respektieren Sie die Leistungsfähigkeit dazu.
11:13
Nachdem Sie nun wissen, wie man sicher bleibt, stellt sich die Frage,
11:16
wo sollten diese Experimente eigentlich durchgeführt werden?
11:19
Shifting Left vs. Shifting Right?
11:21
Wo führen Sie diese Experimente also tatsächlich aus?
11:23
Es gibt zwei Hauptansätze und die meisten Teams nutzen beide.
11:26
Der erste ist das Shifting Left.
11:27
Sie führen Chaos-Experimente früh in Ihrem Entwicklungszyklus durch.
11:32
Sobald Code in einer Testumgebung bereitgestellt wird, belasten Sie ihn mit Fehlern und integrieren dies in Ihre CICD-Pipeline.
11:38
Die Pipeline stellt die App bereit, führt ein Chaos-Experiment zur Belastung durch,
11:41
prüft, ob sie besteht und stuft den Bild erst dann auf die nächste Stufe hoch.
11:44
Betrachten Sie es als Qualitätsprüfung, genau wie Unit-Tests oder Sicherheitsscans.
11:49
Wenn die App in der Staging-Umgebung keinen Farben-Shutdown verkraftet, geht sie nicht in die Produktion.
11:52
Der zweite Ansatz ist das Shifting Right, was bedeutet, Experimente in der Produktion durchzuführen.
11:57
Und ja, das klingt beängstigend, aber hören Sie mich an.
11:59
Sie fangen dort nicht an.
12:00
Sie wechseln erst zum Shifting Right, nachdem Sie Vertrauen in Nicht-Produktionsumgebungen aufgebaut haben.
12:04
Sie beginnen mit kleinen, begrenzten Experimenten.
12:06
Vielleicht belasten Sie die CPU an der Instanz während einer verkehrsarmen Zeit.
12:10
Sie beobachten genau, Sie lernen und dann erweitern Sie das Ganze.
12:12
Vielleicht schalten Sie eine einzelne VM in der Produktion während der Geschäftszeiten ab
12:16
und validieren, dass Ihr Loadbalancer den Datenverkehr umleitet,
12:18
Ihre Benutzer nichts bemerken und Ihr Monitoring alles erfasst.
12:22
Mit der Zeit steigern Sie sich zu aggressiveren Experimenten.
12:25
Es gibt einen dritten Ansatz, der in der Mitte liegt.
12:27
Game Days.
12:27
Ein Game Day ist eine geplante Chaos-Übung, bei der Sie Ihr Entwicklungsteam,
12:31
das Betriebsteam, das Sicherheitsteam und jeden zusammenbringen,
12:33
der an einem echten Vorfall beteiligt wäre.
12:35
Sie führen ein Chaos-Experiment durch und üben Ihre Reaktion auf Vorfälle.
12:38
Wählt die Benachrichtigung.
12:39
Wer trifft die Entscheidung zur Eskalation?
12:40
Wie sieht die Kommunikationskette?
12:41
Wie schnell können Sie das Problem diagnostizieren?
12:43
Game Days testen die Technologie, aber noch wichtiger,
12:45
Sie testen die Menschen und die Prozesse, die Sie umgeben.
12:48
Der Kerngedanke bei allen drei Ansätzen ist,
12:49
dass Chaos-Engineering kein einmaliger Test ist.
12:52
Man führt nicht ein einziges Experiment durch,
12:53
erklärt sein System für Resilient und macht dann rein.
12:55
Systeme ändern sich, Code ändert sich, Konfigurationen ändern sich,
12:58
Abhängigkeiten ändern sich.
12:59
Was letzten Monat noch resilient war, könnte heute bereits anfällig sein.
13:02
Das Ziel ist eine kontinuierliche Validierung der Resilienz.
13:05
Man führt regelmäßige Experimente durch,
13:07
integriert sie in den Release-Prozess
13:08
und macht sie zu einem Teil des operativen Rhythmus.
13:10
Was ist also der wahre Nutzen all dieser Mühen?
13:13
Der wahre Nutzen ist der Aufbau von Vertrauen.
13:15
Chaos-Engineering tut mehr als nur Fehler zu finden.
13:17
Es schafft Vertrauen und das ist etwas völlig anderes.
13:19
Ein Bug ist ein spezifischer Defekt.
13:21
Man behebt ihn und macht weit.
13:22
Aber Vertrauen ist ein Gefühl.
13:24
Es ist das Wissen, dass das System unerwartetes überstehen kann.
13:26
Und das lässt sich nicht allein durch Unit- oder Integrationstests erreichen.
13:30
Man erhält es, indem man beobachtet,
13:31
wie das System einen echten Auswahl bewältigt und wieder funktioniert.
13:33
Dieser Prozess zwingt einen dazu, Dinge zu verbessern,
13:35
die man sonst vielleicht ignorieren kann.
13:37
Zum Beispiel das Monitoring.
13:38
Bei einem Chaos-Experiment stellt man schnell fest,
13:40
ob die Dashboards die richtigen Metriken zeigen,
13:42
ob die Alarme bei den richtigen Schwellenwerten auslösen
13:45
und ob das On-Call-Team rechtzeitig benachrichtigt wird.
13:48
Wenn man den Ausfall nicht sehen kann,
13:49
kann man auch nicht darauf reagieren.
13:51
Chaos-Experimente decken diese Lücken auch.
13:52
Sie enthüllen auch versteckte Annahme.
13:54
Jeder Architekt hat schon einmal gesagt,
13:56
wenn die Datenbank ausfällt,
13:57
sollte die App einfach die letzten bekannten Daten
13:59
zwischenspeichern und weiterlaufen.
14:00
Das klingt auf dem Whiteboard gut,
14:01
aber funktioniert es in der Praxis auch?
14:03
Haben Sie das jemals getestet?
14:04
Chaos-Experimente beantworten diese Frage mit echten Beweisen.
14:07
Man fährt die Datenbank herunter und beobachtet das Messer.
14:09
Vielleicht bewältigt die App es reibungslos.
14:10
Vielleicht schützt sie ab.