1 00:00:00,390 --> 00:00:04,590 Diese Folge ist absolutes Chaos, aber das ist gewollt und 2 00:00:04,590 --> 00:00:08,109 kontrolliert unmessbar, denn es geht um Chaos Engineering. 3 00:00:08,109 --> 00:00:10,470 Das ist eine Technik, bei dem man mit Experimenten versucht 4 00:00:10,470 --> 00:00:14,230 festzustellen, wie sich das eigene System bei Ausfällen 5 00:00:14,230 --> 00:00:16,510 aller Art verhält. Lass uns mal anschauen, wie 6 00:00:16,510 --> 00:00:23,640 genau das geht. Und damit herzlich Willkommen 7 00:00:23,640 --> 00:00:28,680 zufolge 92 des to do Developer Podcast mit Robin Manuel Thiel 8 00:00:28,680 --> 00:00:33,640 und Malte Lantin. Das war ein klasse Intro voller 9 00:00:33,640 --> 00:00:36,480 Energie, ich. Bin hellauf. 10 00:00:36,600 --> 00:00:39,160 Begeistert. Absolut. 11 00:00:39,480 --> 00:00:42,920 Und ja, ich begrüße Euch alle herzlich zu dieser Folge hier 12 00:00:42,920 --> 00:00:48,040 aus meinem Hotelzimmerstudio und das Schöne ist, wir beiden, 13 00:00:48,040 --> 00:00:52,120 Robin Wanne und ich sind uns so nah wie lange nicht und das 14 00:00:52,120 --> 00:00:56,160 Romantische ist wir sitzen extra ein paar Kilometer voneinander 15 00:00:56,160 --> 00:01:00,400 entfernt in separaten Räumen, um die bestmögliche Audioqualität 16 00:01:00,400 --> 00:01:03,120 zu gewährleisten. Wir hätten uns gerne gesehen, 17 00:01:03,120 --> 00:01:06,760 aber da der Podcast darunter gelitten hätte, haben wir das 18 00:01:06,760 --> 00:01:10,040 nicht getan, von daher. Größtes Opfer für diesen 19 00:01:10,040 --> 00:01:12,520 Podcast. Aber vielleicht klappt es beim 20 00:01:12,520 --> 00:01:13,960 nächsten Mal auch mit einem persönlichen Treffen. 21 00:01:13,960 --> 00:01:16,520 Wir haben uns ja vor 2 Wochen schon getroffen. 22 00:01:16,710 --> 00:01:20,190 Aber das nächste Treffen steht bestimmt bald an. 23 00:01:20,190 --> 00:01:23,390 Dieses Mal nicht. Also erstmal herzliche Grüße 24 00:01:23,390 --> 00:01:29,190 hier aus München von. Ja, mir malte und Robin Manuel. 25 00:01:29,390 --> 00:01:31,070 Genau. Wir sind zusammen hier und wir 26 00:01:31,070 --> 00:01:34,750 haben aber noch nie auch nur eine einzige Folge zusammen im 27 00:01:34,750 --> 00:01:36,790 gleichen Raum aufgenommen und wir hatten so n bisschen sorge, 28 00:01:36,790 --> 00:01:38,230 dass das mit der Technik nicht funktioniert. 29 00:01:38,510 --> 00:01:40,710 Wir wollen das aber auf jeden Fall irgendwann mal machen und 30 00:01:40,710 --> 00:01:44,030 wir üben mal dran. Aber das war die Folge. 31 00:01:44,030 --> 00:01:47,430 Worden sind diese, das war zu zu Risky das jetzt hier irgendwie 32 00:01:47,430 --> 00:01:49,270 auf kurz vor knapp noch mal zu machen. 33 00:01:49,790 --> 00:01:51,630 Aber ihr solltet eigentlich keinen Unterschied merken. 34 00:01:51,750 --> 00:01:54,870 Und das Thema, was wir heute haben, Chaos Engineering, finde 35 00:01:54,870 --> 00:01:56,590 ich persönlich super spannend. Wir haben uns ja in der 36 00:01:56,590 --> 00:02:00,310 Vergangenheit häufiger mit dem Betrieb von Applikationen in 37 00:02:00,310 --> 00:02:03,110 Cloud Plattformen auseinandergesetzt und gerade da 38 00:02:03,110 --> 00:02:06,750 hat man ja die Infrastruktur. Nicht unter der Kontrolle, da 39 00:02:06,750 --> 00:02:09,949 ist jemand anders für die Infrastruktur verantwortlich und 40 00:02:09,949 --> 00:02:12,110 ich glaub deswegen ist es n super spannendes Thema. 41 00:02:12,110 --> 00:02:15,230 Aber bevor wir einsteigen erstmal natürlich unsere 42 00:02:15,230 --> 00:02:19,750 Danksagung und da auch auf jeden Fall noch mal herzlichen Dank an 43 00:02:19,750 --> 00:02:25,910 Fabian und Chris für diecafe.de und virtuell ausgegeben habt 44 00:02:26,030 --> 00:02:31,270 vielen Dank dafür, das reicht auf jeden Fall für die Zeit bis 45 00:02:31,270 --> 00:02:35,110 zur nächsten Folge vielen Dank. Ja, danke auch von meiner Seite. 46 00:02:35,110 --> 00:02:37,760 Und dann genug. Sagen genug gequatscht. 47 00:02:37,760 --> 00:02:41,950 Jetzt fangen wir auch direkt an. KOS engineering. 48 00:02:42,830 --> 00:02:46,350 Was ist das? Ich fand den Satz ganz cool, den 49 00:02:46,350 --> 00:02:49,070 ich irgendwie in der Vorbereitung gelesen habe, da 50 00:02:49,070 --> 00:02:50,830 hat jemand klingt auch sehr deutsch, aber da hat jemand 51 00:02:50,830 --> 00:02:53,910 geschrieben, das ist hypothesengetriebene 52 00:02:53,950 --> 00:02:57,150 Resilienzverbesserung des eigenen Systems. 53 00:02:57,830 --> 00:03:02,390 Durch systematisches, kontrolliertes Chaos. 54 00:03:02,950 --> 00:03:06,270 Es hört sich so n bisschen so an, als wird das aus einem aus 55 00:03:06,270 --> 00:03:09,830 einem akademischen Paper kommen, das. 56 00:03:10,000 --> 00:03:13,440 Bedeutet, dass wir uns im Vorfeld Gedanken machen, wie 57 00:03:13,440 --> 00:03:17,800 sich unser System verhalten sollte, wenn bestimmte Dinge 58 00:03:17,800 --> 00:03:21,840 passieren, die wir nicht unter Kontrolle haben oder weil Fehler 59 00:03:21,840 --> 00:03:24,560 passieren. Bestimmte Komponenten in unserem 60 00:03:24,560 --> 00:03:32,360 System ausfallen und wir nutzen. Tools dazu, diese Fehler durch 61 00:03:32,760 --> 00:03:37,520 ein automatisiertes System, welches wir gezielt steuern, 62 00:03:37,520 --> 00:03:42,240 deswegen kontrolliert, dass wir diese Ausfälle in unser System 63 00:03:42,400 --> 00:03:46,000 einbringen, bestimmte Komponenten ausfallen lassen und 64 00:03:46,000 --> 00:03:50,560 dann beobachten können, wie sich unser System, unsere Software 65 00:03:51,080 --> 00:03:55,200 unter diesen Ausfällen verhält, um dann eine Gegenüberstellung 66 00:03:55,200 --> 00:03:58,120 zu machen zwischen unserer Annahme im Vorfeld, also wie 67 00:03:58,120 --> 00:04:01,480 sollte sich unser System verhalten und dem wie es sich 68 00:04:01,480 --> 00:04:04,880 tatsächlich verhält. Das heißt, wir gehen davon aus. 69 00:04:05,430 --> 00:04:07,510 Dass irgendwas immer schief gehen wird. 70 00:04:07,750 --> 00:04:09,950 Wir machen uns Gedanken darüber, wie soll sich unser System 71 00:04:09,950 --> 00:04:13,470 verhalten und testen dann, ob sich unser System wirklich so 72 00:04:13,470 --> 00:04:15,430 verhält, wie wir es geplant hatten. 73 00:04:15,430 --> 00:04:17,029 Genau. Ich find den Ansatz eigentlich 74 00:04:17,029 --> 00:04:20,390 spannend, dass man immer von dieser ja Vermutung ausgeht. 75 00:04:20,390 --> 00:04:23,110 Irgendwas wird wahrscheinlich immer irgendwo failen und wir 76 00:04:23,110 --> 00:04:26,110 sind alle nicht nicht perfekt und irgendwo ist immer noch ein 77 00:04:26,110 --> 00:04:30,270 Mensch in dieser Loop mit drin, dass man quasi auch das eigene 78 00:04:30,270 --> 00:04:33,430 System für diese Ausfälle designt und schon von 79 00:04:33,430 --> 00:04:38,040 vornherein. Für Resilienz oder Resiliency? 80 00:04:39,960 --> 00:04:43,440 Aufbaut, so dass man halt einfach sagt Okay, wenn keine 81 00:04:43,440 --> 00:04:46,800 Ahnung, entweder ich einen Fehler mache als developer oder 82 00:04:46,800 --> 00:04:48,960 wenn in meiner Deployment Pipeline irgendwo ein Fehler 83 00:04:48,960 --> 00:04:51,600 passiert oder wenn auf einem Server irgendwo ein Fehler 84 00:04:51,600 --> 00:04:54,360 passiert oder wenn vielleicht sogar irgendwas fehlschlägt, was 85 00:04:54,360 --> 00:04:57,160 ich gar nicht hätte beeinflussen können, zum Beispiel weil du 86 00:04:57,160 --> 00:04:59,880 hast gerade gesagt, ich bei einem Cloud Provider bin und da 87 00:04:59,880 --> 00:05:02,520 meine Anwendung betreibe und auch da passieren Fehler. 88 00:05:04,280 --> 00:05:05,800 Auch die haben eine SLA. Vielleicht. 89 00:05:05,950 --> 00:05:09,630 Die Sie, die sie mir versprechen von 99,99 oder 9 5% 90 00:05:09,630 --> 00:05:14,190 Verfügbarkeit aber auch darüber hinaus gibt es ja ne kleine 91 00:05:14,190 --> 00:05:16,830 Verfügbarkeit die die nicht gewährleistet ist. 92 00:05:17,030 --> 00:05:19,910 Und da kann ich eben gucken, kann meine Anwendung damit 93 00:05:19,910 --> 00:05:22,430 umgehen, wenn. Irgendwo wahrscheinlich n Mensch 94 00:05:22,430 --> 00:05:26,670 in dieser Pipeline einen Fehler macht und das zu testen und das 95 00:05:26,670 --> 00:05:28,710 auch kontinuierlich zu testen und das direkt in den 96 00:05:28,710 --> 00:05:31,310 Denkprozess von meiner Architektur und von meiner 97 00:05:31,310 --> 00:05:33,950 Anwendung mit einzubauen find ich eigentlich ziemlich 98 00:05:33,950 --> 00:05:36,510 spannend. Ich weiß zum Beispiel, dass 99 00:05:36,510 --> 00:05:39,990 Netflix das so macht. Also Netflix hat das mit ihren 100 00:05:39,990 --> 00:05:42,910 Engineering Teams eigentlich so n bisschen diesen Begriff 101 00:05:42,910 --> 00:05:46,950 geprägt und ins Leben gerufen und Netflix lässt sogar in ihren 102 00:05:47,230 --> 00:05:50,070 Productionclustern permanent sogenannte. 103 00:05:50,510 --> 00:05:54,150 Keine Chaos Monkeys laufen und alle Teams wissen, dass es 104 00:05:54,150 --> 00:05:56,710 einfach ein bisschen Chaos gibt, auch in Produktion. 105 00:05:56,790 --> 00:05:58,550 Und die wissen aber nie, wann es sie trifft. 106 00:05:58,550 --> 00:06:00,190 Also man kann sich das vorstellen, das sind so kleine 107 00:06:00,190 --> 00:06:04,430 Äffchen, die im im Cluster, bei denen man Kabel rausrupfen oder 108 00:06:04,430 --> 00:06:07,230 mal irgendwo. Den den Netzwerk Traffic 109 00:06:07,230 --> 00:06:10,350 irgendwie entweder ganz runter, Trottel oder einfach mal kappen 110 00:06:10,550 --> 00:06:15,030 oder da ist mal irgendwo ne Datenbank die ausfällt und alle 111 00:06:15,030 --> 00:06:18,310 Teams wissen, dass es jetzt nicht viel, aber so n bisschen 112 00:06:18,310 --> 00:06:20,910 Chaos immer immer immer in diesem Cluster gibt und das 113 00:06:20,910 --> 00:06:23,310 fängt schon in Death an, aber Netflix zieht das Halt bis zur 114 00:06:23,310 --> 00:06:25,710 Produktion durch, die sind aber auch absolute Profis da drin 115 00:06:25,830 --> 00:06:28,270 können wir keinem empfehlen direkt damit zu starten das in 116 00:06:28,270 --> 00:06:31,990 Produktion auch zu testen, aber das hat halt zur Folge, dass 117 00:06:31,990 --> 00:06:35,750 alle Teams bei Netflix ihre Services direkt Resilienz bauen, 118 00:06:35,750 --> 00:06:37,830 weil sie wissen es könnte sein, dass mich irgendwann dieser 119 00:06:37,830 --> 00:06:41,240 Chaos Monkey trifft. Und die Teams bei Netflix werden 120 00:06:41,240 --> 00:06:44,440 halt daran gemessen, wie verfügbar, wie performant ihre 121 00:06:44,440 --> 00:06:48,000 Anwendungen sind. Und auch rückblickend waren. 122 00:06:48,120 --> 00:06:52,560 Und wenn ich aber weiß, dass das ja vielleicht meine meine 123 00:06:52,560 --> 00:06:54,280 Jahresbewertung beeinflussen kann, wenn ich mich nicht auf 124 00:06:54,280 --> 00:06:57,680 diesen Chaos Monkey da vorbereite, dann baue ich 125 00:06:57,680 --> 00:06:59,880 natürlich direkt meine Anwendung, so dass da auch ruhig 126 00:06:59,880 --> 00:07:04,000 mal was ausfallen darf. So wie ich es gelesen hatte, hat 127 00:07:04,000 --> 00:07:06,680 Netflix damit angefangen, als sie damals von der eigenen 128 00:07:06,680 --> 00:07:10,310 Infrastruktur in. Die Cloud umgezogen sind. 129 00:07:10,510 --> 00:07:14,590 Ich glaub sie laufen auf AWUS und als sie damals diesen 130 00:07:14,590 --> 00:07:17,350 Schritt gemacht haben, haben Sie gesagt, OK, jetzt haben wir 131 00:07:17,350 --> 00:07:19,550 nicht mehr alles unter Kontrolle, jetzt ist der 132 00:07:19,550 --> 00:07:22,070 Zeitpunkt gekommen, wo wir wirklich sicherstellen müssen, 133 00:07:22,070 --> 00:07:24,270 dass wir gegenüber solchen Ausfällen. 134 00:07:25,430 --> 00:07:28,110 Ja, für solche Ausfälle gewappnet sind, dass wir darauf 135 00:07:28,110 --> 00:07:31,070 vorbereitet sind, insbesondere weil wir natürlich einen Dienst 136 00:07:31,070 --> 00:07:35,750 bereitstellen, der erst mal im ganzen Land, aber mittlerweile 137 00:07:35,750 --> 00:07:38,990 natürlich international jederzeit zur Verfügung stehen 138 00:07:38,990 --> 00:07:41,150 muss. Es ist ja keine Business 139 00:07:41,150 --> 00:07:44,070 Applikation, die ich vielleicht irgendwie nur zu bestimmten 140 00:07:44,070 --> 00:07:47,350 Zeiten zur Verfügung stellen muss, sondern 24 / 7 muss diese 141 00:07:47,350 --> 00:07:50,870 Applikation zur Verfügung stehen, um für die Kunden eine 142 00:07:50,870 --> 00:07:54,590 gute Qualität zu liefern und du hattest gerade gesagt. 143 00:07:55,680 --> 00:07:58,160 Solche Cloud Provider bieten mir einen SLA, eine 144 00:07:58,160 --> 00:08:00,360 Verfügbarkeitsgarantie, aber selbst dort ist ja 145 00:08:00,360 --> 00:08:03,840 einkalkuliert, dass es bestimmte Zeiten gibt, die sich teilweise 146 00:08:03,840 --> 00:08:07,680 nur im Bereich von Minuten bewegen, in denen die Software 147 00:08:07,680 --> 00:08:10,320 selbst innerhalb des Versprechens des Anbieters 148 00:08:10,320 --> 00:08:13,480 vielleicht gar nicht verfügbar ist, weil bestimmte Komponenten 149 00:08:13,480 --> 00:08:17,760 ausfallen können, für die der Anbieter dann nicht mal eine 150 00:08:17,760 --> 00:08:20,080 finanzielle Haftung übernimmt, wenn dort dieser Ausfall 151 00:08:20,080 --> 00:08:23,120 stattfindet. Aber ein ganz triviales Beispiel 152 00:08:23,120 --> 00:08:26,870 ist ja etwas, das auch. Bei mir im Eigenbetrieb 153 00:08:26,870 --> 00:08:29,150 passieren kann, was bei einem Dienstleister passieren kann, 154 00:08:29,150 --> 00:08:32,070 was bei dem Hyperscaler passieren kann, ist n Großbrand 155 00:08:32,070 --> 00:08:34,950 im Datacenter hat niemand unter Kontrolle, kann aber mal 156 00:08:34,950 --> 00:08:38,230 passieren und da hilft mir der beste SMA meines Dienstleisters 157 00:08:38,230 --> 00:08:39,990 nicht, dann krieg ich vielleicht Geld zurück, aber trotzdem ist 158 00:08:39,990 --> 00:08:44,310 meine Applikation ausgefallen. Und solche Szenarien sind 159 00:08:44,310 --> 00:08:46,710 natürlich die maximal größte Katastrophe. 160 00:08:46,710 --> 00:08:49,230 Das ist ein komplettes Data Center ausfällt, in der 161 00:08:49,230 --> 00:08:50,750 vielleicht meine Applikation läuft. 162 00:08:50,750 --> 00:08:52,510 Ich kann mich darauf vorbereiten, indem ich 163 00:08:52,510 --> 00:08:55,710 vielleicht in mehreren Regionen oder mehreren Rechenzentren 164 00:08:55,710 --> 00:09:00,710 meine Applikation bereitstelle, aber ich bin nie 100% davor 165 00:09:00,710 --> 00:09:04,710 geschützt, dass irgendwelche Komponenten ausfallen, und sei 166 00:09:04,710 --> 00:09:07,710 es, es gab ja dieses berühmte Beispiel von den Servern, die 167 00:09:07,710 --> 00:09:10,670 jede Nacht ausfielen, weil die Putzkraft immer den Stecker 168 00:09:10,670 --> 00:09:13,110 gezogen hat, um besser staubsaugen zu können. 169 00:09:14,160 --> 00:09:16,680 Und selbst solche trivialen Dinge können natürlich 170 00:09:16,680 --> 00:09:19,080 passieren. Hardwareausfälle, menschliches 171 00:09:19,080 --> 00:09:22,800 Versagen, menschliche Fehler, und das kann halt die komplette 172 00:09:22,800 --> 00:09:25,360 Infrastruktur betreffen, da brauche ich vielleicht 173 00:09:25,360 --> 00:09:28,720 Redundanz, es kann einzelne Komponenten betreffen, aber es 174 00:09:28,720 --> 00:09:31,920 kann natürlich auch die Art und Weise, wie. 175 00:09:33,680 --> 00:09:35,360 Daten zur Verfügung stehen, betreffen. 176 00:09:35,360 --> 00:09:38,280 Es kann einfach eine Verlangsamung der Performance 177 00:09:38,280 --> 00:09:39,440 sein. Ich habe zum Beispiel eine 178 00:09:39,440 --> 00:09:43,080 Überlast von bestimmten Hardware Ressorts oder wie du vorhin 179 00:09:43,080 --> 00:09:45,120 gesagt hattest, dass das Netzwerk ist langsam. 180 00:09:45,910 --> 00:09:49,390 Oder ich hab halt bestimmte andere Probleme in meiner 181 00:09:49,390 --> 00:09:53,310 Applikation. Ne bestimmte Speicherauslastung, 182 00:09:53,310 --> 00:09:55,230 die ich gar nicht eingeplant hatte, weil bestimmte 183 00:09:55,230 --> 00:09:58,110 Komponenten softwaretechnisch nicht so entwickelt wurden, wie 184 00:09:58,110 --> 00:09:59,990 ich es ursprünglich gedacht hatte. 185 00:10:00,110 --> 00:10:03,630 Das heißt, es kann immer etwas passieren und dementsprechend 186 00:10:03,750 --> 00:10:06,630 muss ich mir Gedanken darüber machen, was sind die Szenarien, 187 00:10:06,630 --> 00:10:09,630 auf die ich vorbereitet sein möchte. 188 00:10:09,910 --> 00:10:14,990 Man kann nie 100% sicher sein, dass man gegenüber allen 189 00:10:14,990 --> 00:10:19,640 Eventualitäten. Geschützt ist und von daher muss 190 00:10:19,640 --> 00:10:21,800 man sich, und das finde ich eigentlich so schön, an dieser 191 00:10:22,800 --> 00:10:25,000 Formulierung, die Ihr vorhin genannt hat, man muss bestimmte 192 00:10:25,000 --> 00:10:27,480 Hypothesen aufstellen und bestimmte Szenarien aufstellen 193 00:10:27,480 --> 00:10:30,200 und sagen, okay, das sind die Bereiche, auf die ich mich 194 00:10:30,200 --> 00:10:34,840 vorbereite, weil das sind die wahrscheinlichsten Probleme, die 195 00:10:35,120 --> 00:10:38,320 auftreten können, und da muss ich entsprechend drauf reagieren 196 00:10:38,320 --> 00:10:38,840 können. Genau. 197 00:10:38,840 --> 00:10:40,440 Und auch wenn das jetzt natürlich so in der Welt der 198 00:10:40,440 --> 00:10:44,160 Hyperscaler, also wenn ich jetzt bei Adws, Google Cloud oder 199 00:10:44,160 --> 00:10:47,430 Azure oder irgendwo bin, dann. Sinkt natürlich massiv die 200 00:10:47,430 --> 00:10:49,670 Wahrscheinlichkeit, dass ich, selbst wenn das da n Großbrand 201 00:10:49,670 --> 00:10:52,230 im Rechenzentrum geben sollte. Ich darf von überhaupt irgendwas 202 00:10:52,230 --> 00:10:55,630 mitkriege oder da ist natürlich keine Putzkraft die die nachts 203 00:10:55,630 --> 00:10:59,070 den den den Stecker zieht und auch da sind natürlich ganz viel 204 00:10:59,070 --> 00:11:00,830 auch irgendwie virtualisiert, das heißt, selbst wenn da mal 205 00:11:00,830 --> 00:11:04,550 irgendwie ne Server brennt, dann wird meine wird da meine meine 206 00:11:04,550 --> 00:11:06,750 virtuelle Instanz einfach irgendwo anders hin umgezogen 207 00:11:06,750 --> 00:11:08,430 und ich brich da wahrscheinlich gar nichts mehr mit oder das 208 00:11:08,430 --> 00:11:10,270 passiert innerhalb von Sekunden, dass der Server dann mal 209 00:11:10,270 --> 00:11:13,230 irgendwie neu gestartet wird oder so, aber ich muss ja auch 210 00:11:13,230 --> 00:11:16,710 testen, ob meine Anwendung, selbst wenn mein Anbieter diese 211 00:11:16,710 --> 00:11:21,870 SLS von maximal 5 Minuten im Jahr Ausfall oder sowas einhält, 212 00:11:21,870 --> 00:11:23,480 ob. Meine Anwendungen dann trotzdem 213 00:11:23,480 --> 00:11:25,120 auch. Sobald dann mein Rechenzentrum 214 00:11:25,120 --> 00:11:28,320 wieder online geht, auch wieder online geht, also ob die auch 215 00:11:28,320 --> 00:11:32,400 dann damit umgehen kann auch. Wenn das sich halt um einen 216 00:11:32,400 --> 00:11:35,360 Ausfall von einer Millisekunde handelt, dass sie, dass sie 217 00:11:35,360 --> 00:11:38,160 davon halt irgendwie recovery kann und da gibt es eine ganze 218 00:11:38,160 --> 00:11:42,800 Menge verschiedener Use Cases, warum man das machen will und 219 00:11:43,000 --> 00:11:45,240 ich würde sagen, bevor wir gleich in der Folge beschreiben, 220 00:11:45,240 --> 00:11:47,720 wie man es denn macht, gehen wir damals kurz durch und. 221 00:11:47,870 --> 00:11:50,030 Wir haben uns hier nämlich mal so n Paar aufgeschrieben und den 222 00:11:50,030 --> 00:11:53,350 einen haben wir ja grad schon genannt so SLAS überprüfen also 223 00:11:53,350 --> 00:11:55,310 auch die eigenen ne. Also auch wenn ich irgendwie nen 224 00:11:55,310 --> 00:11:59,750 Service bereitstelle, dann muss ich ja auch meinen Kunden mein 225 00:11:59,750 --> 00:12:02,550 Kundinnen irgendwie sagen, ja, gerade wenn ich den Cloud 226 00:12:02,550 --> 00:12:05,430 Service baue, der hat ne gewisse, Wir garantieren 227 00:12:05,750 --> 00:12:08,470 vertraglich ne gewisse Verfügbarkeit oder überhaupt 228 00:12:08,470 --> 00:12:10,190 garantieren zu können, muss ich natürlich auch mal gucken, wie 229 00:12:10,190 --> 00:12:12,310 verhält sich denn mein System wenn mir mal n Server wegbricht? 230 00:12:12,310 --> 00:12:15,590 Ich kann nicht, da kann ich das weiterhin garantieren oder wenn 231 00:12:15,590 --> 00:12:17,790 das Netzwerk mal langsam ist oder wie auch immer. 232 00:12:18,840 --> 00:12:20,320 Und eine andere Sache, die ich spannend fand, ist so. 233 00:12:22,080 --> 00:12:23,880 Kann ich mal der mal simulieren? Wie verhält sich denn mein 234 00:12:23,880 --> 00:12:26,080 System unter Last? Das kann ja auch Chaos sein, 235 00:12:26,160 --> 00:12:28,600 also funktioniert mein Auto scaling in beide Richtungen, 236 00:12:28,600 --> 00:12:31,080 wenn ich auf einmal viel Last habe, werden automatisch neue 237 00:12:31,080 --> 00:12:33,600 Server dazu gebucht, wenn die Last weggeht geht das 238 00:12:33,600 --> 00:12:37,480 automatisch weg. Diese Server kann ich dann 239 00:12:37,480 --> 00:12:40,800 wieder Kosten sparen. Also dieses wie verhält sich 240 00:12:40,800 --> 00:12:44,000 mein System in verschiedenen Situationen, ohne dass ich 241 00:12:44,000 --> 00:12:47,280 erstmal nen Ausfall gab, aber einfach eine Veränderung, das 242 00:12:47,280 --> 00:12:49,200 finde ich schon mal eigentlich ein ganz ganz spannendes. 243 00:12:50,790 --> 00:12:53,270 Ein Thema, was ich ja gerade schon genannt hat, ist auch halt 244 00:12:53,270 --> 00:12:56,150 disaster Recovery. Wie schnell kann mein System 245 00:12:56,150 --> 00:12:58,550 sich wieder erholen, wenn ich halt auf eine andere 246 00:12:58,670 --> 00:13:01,910 Infrastruktur wechseln muss, weil irgendwie n Datacenter 247 00:13:01,910 --> 00:13:04,430 ausfällt, ob bestimmte Komponenten ausfallen, das heißt 248 00:13:04,430 --> 00:13:07,070 wie reagiert man System da drauf, wie schnell bin ich da 249 00:13:07,070 --> 00:13:10,790 auch zeitlich und ein Punkt den ich persönlich fast am 250 00:13:10,790 --> 00:13:14,550 wichtigsten finde ist, wie verhält sich die menschliche 251 00:13:14,550 --> 00:13:17,190 Komponente, wie verhält sich mein Support Team, mein 252 00:13:17,190 --> 00:13:21,270 Engineering Team wenn solche Incidents auftreten und das sind 253 00:13:21,270 --> 00:13:24,320 ja. Sehr stressige Situationen, 254 00:13:24,520 --> 00:13:27,560 Totalausfall der Applikation oder ein kritischer Ausfall, 255 00:13:27,560 --> 00:13:29,440 dass bestimmt Teile meiner Applikation nicht mehr 256 00:13:29,440 --> 00:13:33,040 funktionieren, habe ich da das richtige System in Place für, 257 00:13:33,120 --> 00:13:37,000 kann ich engineer's Pagen kann ich halt mit den Leuten 258 00:13:37,000 --> 00:13:39,800 arbeiten, wenn tatsächlich ein Großausfall ist. 259 00:13:39,800 --> 00:13:44,920 Ich hab tatsächlich vor einiger Zeit mal so eine so ein Post 260 00:13:44,920 --> 00:13:48,680 mortem gelesen, wo tatsächlich bei einem großen SARS Provider 261 00:13:49,040 --> 00:13:51,640 eine komplette Datenbank gekillt wurde durch einen menschenlichen 262 00:13:51,640 --> 00:13:53,560 Fehler ich glaube wir hatten es mal in einer Folge erwähnt. 263 00:13:54,670 --> 00:13:57,270 Die Situation und wenn so etwas passiert, wie kann ich 264 00:13:57,270 --> 00:13:59,670 sicherstellen, dass ich nicht nur die richtigen Leute 265 00:13:59,750 --> 00:14:02,830 innerhalb von sehr kurzer Zeit zur Verfügung habe, sondern 266 00:14:02,830 --> 00:14:06,150 diese Leute auch konzentriert unter Stress arbeiten können? 267 00:14:06,270 --> 00:14:09,310 Weil am Ende kann ich bestimmte Dinge automatisieren. 268 00:14:10,030 --> 00:14:13,670 Ganz häufig müssen Menschen diese Recovery auch mitsteuern. 269 00:14:13,670 --> 00:14:16,750 Sie müssen eingreifen und bestimmte Dinge sind halt auch 270 00:14:17,030 --> 00:14:20,230 dann vielleicht in der Übung, wenn ich das auf meiner Dev 271 00:14:20,230 --> 00:14:23,910 Testumgebung mache. Easy, da kümmere ich mich drum, 272 00:14:23,910 --> 00:14:26,830 da hab ich keinen Druck. Aber wenn dann wirklich die 273 00:14:26,830 --> 00:14:30,310 Supporttickets Supporttickets Reinlaufen in als 274 00:14:30,310 --> 00:14:34,190 Hunderttausende, dann stellt sich natürlich n ganz anderer 275 00:14:34,190 --> 00:14:37,510 Stress ein und funktioniert mein Team dann trotzdem noch und 276 00:14:37,510 --> 00:14:40,630 daher finde ich wirklich diese Incident drills ganz spannend, 277 00:14:40,630 --> 00:14:43,030 dass ich tatsächlich auch simuliere. 278 00:14:43,510 --> 00:14:47,070 Wir stellen uns vor, dass unser Produktivsystem und wir 279 00:14:47,070 --> 00:14:49,950 reagieren genauso wie wir reagieren würden, wenn es unser 280 00:14:49,950 --> 00:14:52,390 Produktivsystem wäre und holen genau die. 281 00:14:52,390 --> 00:14:56,320 Gleichen Leute rein. Also ganz toll testen, 282 00:14:56,320 --> 00:14:58,240 vielleicht einfach in dem Fall in der Test aber sicherstellen, 283 00:14:58,240 --> 00:14:59,880 dass meine Leute dann halt in diesen stressigen 284 00:14:59,880 --> 00:15:03,640 Autorsituationen in der Produktion richtig reagieren. 285 00:15:03,800 --> 00:15:09,520 Genau einen letzten Punkt, den du hier noch in den Notizen drin 286 00:15:09,520 --> 00:15:12,480 hast, wo wir uns auch darauf vorbereiten müssen, ist das 287 00:15:12,480 --> 00:15:16,240 Thema Zertifikate. Wie oft ist schon eine 288 00:15:16,240 --> 00:15:19,240 Applikation irgendwie offline gegangen, weil ein Zertifikat 289 00:15:19,680 --> 00:15:22,560 ausgelaufen ist? Oder wir haben einen Security 290 00:15:22,560 --> 00:15:25,470 Security. Ein Zertifikat rotieren wie 291 00:15:25,470 --> 00:15:27,310 reagiert meine Applikation da drauf? 292 00:15:27,470 --> 00:15:30,630 Das sind auch so Dinge, die möchte man nicht in Produktion 293 00:15:30,630 --> 00:15:33,350 das erste Mal machen, sondern man möchte darauf vorbereitet 294 00:15:33,350 --> 00:15:38,390 sein und von daher, es gibt ganz viele solche Use Cases die halt 295 00:15:38,390 --> 00:15:42,230 ganz grob in diesem Bereich Chaos Engineering reinfallen, 296 00:15:42,230 --> 00:15:46,390 weil wir durch Chaos Engineering diese Situation simulieren 297 00:15:46,390 --> 00:15:49,030 können. Wir können uns in die Situation 298 00:15:49,030 --> 00:15:52,310 bringen, dass wir mit diesem Problem umgehen müssen, dass wir 299 00:15:52,310 --> 00:15:53,750 das Problem lösen müssen. Genau. 300 00:15:53,750 --> 00:15:55,510 Und das muss natürlich. Also ich habe jetzt hier 301 00:15:55,510 --> 00:15:58,920 Zertifikate. Stellvertreterhaft für alle 302 00:15:58,920 --> 00:16:02,040 möglichen Arten von Security Incidents auch aufgeschrieben. 303 00:16:02,040 --> 00:16:06,000 Das kann, ja kann ja sein, wir haben dann einen Eindringling 304 00:16:06,080 --> 00:16:10,360 und müssen das jetzt irgendwie das System so abschotten, dass 305 00:16:10,360 --> 00:16:12,280 da der Blastradius mit möglichst gering ist. 306 00:16:13,590 --> 00:16:16,030 Aber wie du gerade schon sagst, das muss also Chaos Engineering 307 00:16:16,030 --> 00:16:18,150 muss nicht immer was sein, wir simulieren was wo ein Mensch 308 00:16:18,150 --> 00:16:20,430 dann drauf reagieren muss, dass das Feld jetzt eher so in diese 309 00:16:20,430 --> 00:16:24,510 kack Kategorie Wir schulen unser unser Support Team so geht gegen 310 00:16:24,510 --> 00:16:27,310 Incident, sondern im Idealfall sind das natürlich alles so 311 00:16:27,310 --> 00:16:31,110 Stresstests, von denen sich das ohne mein System mehr oder 312 00:16:31,110 --> 00:16:33,470 weniger automatisch recovered, wahrscheinlich mehr automatisch 313 00:16:33,470 --> 00:16:36,950 recovered, wenn ich eben nicht viel weniger ich selber betreibe 314 00:16:36,950 --> 00:16:39,590 und je mehr ich wirklich halt an einem Hyperscale an Cloud 315 00:16:39,590 --> 00:16:42,830 Provider gebe, aber auch da will ich ja eben diese diese 316 00:16:42,830 --> 00:16:46,120 Validierung haben. Dass mein System auf bestimmte 317 00:16:46,520 --> 00:16:49,840 Szenarien gut oder richtig reagieren kann und was gut und 318 00:16:49,840 --> 00:16:51,560 was richtig ist, das muss ich natürlich für mich selber 319 00:16:51,560 --> 00:16:55,320 definieren, weil Resilience ist natürlich auch immer teuer, das 320 00:16:55,320 --> 00:16:58,920 heißt, ich kann ja sagen, ja, ich möchte eigentlich in jedem 321 00:16:58,920 --> 00:17:02,160 Rechenzentrum der Welt eine Version von meiner Applikation 322 00:17:02,160 --> 00:17:06,720 laufen haben, und wenn jetzt ein Meteorit das Rechenzentrum. 323 00:17:09,000 --> 00:17:11,079 Dann soll das automatisch in B weiterlaufen. 324 00:17:11,160 --> 00:17:13,760 Kann ich mich natürlich gegen schützen technisch. 325 00:17:13,990 --> 00:17:16,030 Ist aber wahnsinnig teuer, weil ich ja natürlich in jedem 326 00:17:16,030 --> 00:17:18,150 Rechenzentrum einmal meine Infrastruktur aufbauen muss. 327 00:17:18,270 --> 00:17:20,710 Deswegen ist es eigentlich immer ganz wichtig, wenn man sich aber 328 00:17:20,710 --> 00:17:23,109 überlegt, OK, was möchte ich also gegen was möchte ich denn 329 00:17:23,109 --> 00:17:26,990 wirklich geschützt sein und bei was ist es mir einfach nicht das 330 00:17:26,990 --> 00:17:30,350 Geld wert, dass ich mich da. Dass ich mich dagegen auch 331 00:17:30,350 --> 00:17:33,710 aufstelle und dann, wenn ich diese Experimente habe oder wenn 332 00:17:33,710 --> 00:17:35,470 ich einfach weiß, OK, das sind, das sind die Dinge, gegen die 333 00:17:35,470 --> 00:17:37,910 ich mich schützen, das und das sind die Parameter, dann kann 334 00:17:37,910 --> 00:17:40,150 ich das einfach kontinuierlich validieren. 335 00:17:40,150 --> 00:17:42,590 Also ich hab mit Teams gesprochen, zum Beispiel die. 336 00:17:43,110 --> 00:17:45,550 Einmal im Quartal ein solches ein. 337 00:17:45,550 --> 00:17:48,390 Ein solches Konto des Chaos laufen lassen. 338 00:17:48,630 --> 00:17:52,230 Ich hab mit Teams gesprochen, die das quasi kontinuierlich 339 00:17:52,230 --> 00:17:55,150 Laufen haben, da gibt es einfach, das wird konstant 340 00:17:55,150 --> 00:17:57,310 gemacht. Ich hab mit ihm gesprochen, die 341 00:17:57,310 --> 00:18:00,910 das als in ihres EICD Pipeline eingebaut haben, die gesagt 342 00:18:00,910 --> 00:18:03,470 haben, wenn immer wenn wir ein Deployment machen machen wir 343 00:18:03,470 --> 00:18:06,510 danach einmal so einen Chaos Test um zu schauen ob die n ob 344 00:18:06,510 --> 00:18:09,790 die Veränderungen die wir gemacht haben immer noch unseren 345 00:18:09,790 --> 00:18:11,990 Anforderungen entspricht. Das heißt, es ist in einem so n 346 00:18:11,990 --> 00:18:14,910 bisschen selber überlassen und wahrscheinlich auch wieder sehr 347 00:18:14,910 --> 00:18:20,280 ja abhängig vom Use Case, aber. Wie macht man es denn jetzt? 348 00:18:20,280 --> 00:18:22,280 Also wenn ich jetzt so, wenn ich jetzt sage, OK, ich möchte, ich 349 00:18:22,280 --> 00:18:24,120 möchte anfangen mit Chaos engineering, ich find das 350 00:18:24,120 --> 00:18:26,600 spannend mein System da zu testen. 351 00:18:28,280 --> 00:18:31,590 Wie gehe ich da vor? Ja, ich fänd gerade die Punkte, 352 00:18:31,590 --> 00:18:32,550 die du genannt hast ganz wichtig. 353 00:18:32,550 --> 00:18:35,030 Warum sich erstmal Gedanken machen, was sind die Szenarien, 354 00:18:35,030 --> 00:18:37,350 auf die ich mich vorbereite und was ist dann die richtige 355 00:18:37,350 --> 00:18:42,150 Strategie um halt so ein Chaostesting oder so ne 356 00:18:42,150 --> 00:18:46,110 Ernstfall Simulation zu machen? Läuft es in bestimmten 357 00:18:46,110 --> 00:18:48,790 Zeitabständen oder läuft es regelmäßig regelmäßig, 358 00:18:48,790 --> 00:18:51,790 vielleicht eher im Sinne von Testen der 359 00:18:51,790 --> 00:18:55,590 Selbstheilungsfunktion meiner Applikation und andere Dinge 360 00:18:55,590 --> 00:18:58,910 vielleicht um unser unser Support Personal zu schulen, das 361 00:18:58,910 --> 00:19:00,790 heißt ich muss mir erstmal jetzt Gedanken machen, was sind die 362 00:19:00,790 --> 00:19:04,680 Szenarien? Welche Applikationen und welchen 363 00:19:04,680 --> 00:19:06,440 Workout möchte ich jetzt eigentlich? 364 00:19:08,200 --> 00:19:10,600 Letzten Endes testen und Resilienter machen. 365 00:19:11,120 --> 00:19:13,800 Dann gehe ich hin, basierend auf meinem Szenario. 366 00:19:15,560 --> 00:19:19,840 Was sind die Komponenten, die ich ausfallen lassen möchte und 367 00:19:20,160 --> 00:19:22,200 wann möchte ich diese ausfallen lassen? 368 00:19:22,200 --> 00:19:25,480 Und wie soll meine Applikation darauf reagieren? 369 00:19:25,760 --> 00:19:28,040 Dann muss natürlich diese Applikation in einer 370 00:19:28,040 --> 00:19:31,830 realistischen Situation sein. Das heißt, ich muss auch 371 00:19:32,750 --> 00:19:34,390 irgendwie n low Test laufen lassen. 372 00:19:34,390 --> 00:19:37,590 Ich muss user Traffic simulieren, ich muss das Ganze 373 00:19:37,590 --> 00:19:40,510 dauerhaft Monitoren um natürlich dann auch nachher die 374 00:19:40,510 --> 00:19:43,030 entsprechenden Informationen, dass man Applikationen haben wie 375 00:19:43,030 --> 00:19:45,590 hat meine Applikation reagiert, wie sie, wie haben sich die 376 00:19:45,590 --> 00:19:50,590 Metriken verändert, wie war die Hardware Nutzung, wie haben 377 00:19:50,590 --> 00:19:52,830 andere Komponenten darauf reagiert als bestimmte 378 00:19:52,830 --> 00:19:54,990 Komponenten ausgefallen sind. Ich meine es kann natürlich auch 379 00:19:54,990 --> 00:20:00,120 sein, ich habe irgendwie. Ohnehin eine Redundanz in meiner 380 00:20:00,120 --> 00:20:01,920 Applikation eingebaut. Aber wie reagieren? 381 00:20:01,920 --> 00:20:06,760 Vielleicht in meinem Cluster? Die einzelnen Komponenten da 382 00:20:06,760 --> 00:20:08,280 drauf. Wenn ich so und so viele VM s 383 00:20:08,280 --> 00:20:11,320 aus dem Cluster einfach rausnehme, weil diese VM s 384 00:20:11,320 --> 00:20:13,440 vielleicht ausgefallen sind. Das heißt wie geht dann die Last 385 00:20:13,440 --> 00:20:17,280 hoch in den anderen Komponenten und nachdem ich das alles 386 00:20:17,760 --> 00:20:22,560 definiert und in die Richtige, in das richtige Setup gebracht 387 00:20:22,560 --> 00:20:25,920 habe, brauche ich natürlich das Tool um das ganze Halt zu 388 00:20:25,920 --> 00:20:30,640 skripten zu automatisieren, je nachdem in unregelmäßigen 389 00:20:30,640 --> 00:20:32,750 Abständen. Oder natürlich jedes Mal, wie du 390 00:20:32,750 --> 00:20:36,270 gerade gesagt hast, innerhalb meiner CI, um bestimmte Dinge 391 00:20:36,270 --> 00:20:38,550 abzudecken. Es ist so ein bisschen so das 392 00:20:38,550 --> 00:20:43,150 Gesamtvorgehen, wie ich jetzt daran gehen würde, wenn man mit 393 00:20:43,150 --> 00:20:44,910 dem Thema neueinsteigt. Genau. 394 00:20:44,910 --> 00:20:47,030 Ich find aber einen ganz wichtigen Punkt ist immer, dass 395 00:20:47,030 --> 00:20:50,990 man wissenschaftlich vorgeht. Was meine ich damit meine ich, 396 00:20:50,990 --> 00:20:54,950 dass man erst eine Hypothese aufstellt, wie sich das System 397 00:20:54,950 --> 00:20:58,510 verhalten sollte bei einem Autogramm, dann lässt man das 398 00:20:58,510 --> 00:21:02,990 Chaos Experiment laufen. Und dann muss man dabei 399 00:21:02,990 --> 00:21:08,310 natürlich die nötigen Analytics einsammeln, um festzustellen, ob 400 00:21:08,310 --> 00:21:11,790 meine Hypothese stimmt. Und dann baue ich, je nachdem, 401 00:21:11,790 --> 00:21:14,230 ob sie stimmt oder nicht, Verbesserung in mein System an. 402 00:21:14,230 --> 00:21:17,470 Und wenn ich diesem Pattern immer Folge, kann ich eigentlich 403 00:21:17,470 --> 00:21:19,630 sehr gut für diese Hypothese, also erst schreibe ich diese 404 00:21:19,630 --> 00:21:22,910 Hypothesen nieder, die ich testen möchte, das ist dann 405 00:21:22,910 --> 00:21:25,030 gleichzeitig auch schon die Szenarien, gegen die ich mich ja 406 00:21:25,030 --> 00:21:27,630 schützen möchte, und dann sage ich okay ich mache das 407 00:21:27,630 --> 00:21:29,990 Experiment, ich sammle die Analytics ein, das ist ein ganz, 408 00:21:29,990 --> 00:21:31,150 ganz, ganz, ganz wichtiger Punkt. 409 00:21:32,200 --> 00:21:34,000 Festzustellen, stimmt man die Hypothese oder nicht und baut 410 00:21:34,000 --> 00:21:36,680 dann die Verbesserung ein, wie du gerade schon gesagt hast. 411 00:21:37,480 --> 00:21:41,200 Diese Experimente haben eigentlich immer dieselben 5 412 00:21:41,200 --> 00:21:43,160 Komponenten. Es gibt einmal die App, also 413 00:21:43,160 --> 00:21:46,240 welcher Workout soll auch die Reserve soll auf seine Resilienz 414 00:21:46,240 --> 00:21:49,520 validiert werden, es gibt die Targets die ich angreifen 415 00:21:49,520 --> 00:21:52,200 möchte, also welche Infrastrukturkomponenten sollen 416 00:21:52,200 --> 00:21:55,480 attackiert werden und in diesem Experiment involviert sein, also 417 00:21:55,480 --> 00:21:58,160 aus Gewissen dieser Blast Radius den ich dann immer im Experiment 418 00:21:58,160 --> 00:22:00,320 mache, dann brauche ich natürlich Traffic, das ist der 419 00:22:00,320 --> 00:22:02,920 dritte Punkt hast du gerade schon gesagt repräsentativ 420 00:22:02,920 --> 00:22:05,160 repräsentativen User Traffic generieren es hilft mir nichts 421 00:22:05,160 --> 00:22:08,160 zu wissen ja wenn. Da 3 User drauf sind, macht es 422 00:22:08,160 --> 00:22:10,440 gar nichts, wenn da mal eine WM ausfällt, sondern es muss halt 423 00:22:10,440 --> 00:22:13,360 repräsentativen Traffic haben und dann der für mich wichtigste 424 00:22:13,360 --> 00:22:16,200 Punkt observability ich brauche Telemetrie, ich brauche 425 00:22:16,200 --> 00:22:18,440 Metriken, vielleicht habe ich ja irgendwo meine Alerts, ich 426 00:22:18,440 --> 00:22:20,550 werde. App Health Monitoring 427 00:22:20,550 --> 00:22:23,750 wahrscheinlich ja irgendwo haben und das zusammen nehm ich dann 428 00:22:23,750 --> 00:22:27,070 in meinen Chaos Experiment und das sind dann zufällige oder 429 00:22:27,070 --> 00:22:31,430 gescriptete Störungen an meinen Tardigits, also an diesen 430 00:22:31,430 --> 00:22:34,230 Infrastrukturkomponenten, die attackiert werden sollen und das 431 00:22:34,230 --> 00:22:38,390 kann ich dann eben abfeuern. Und letztendlich führt das 432 00:22:38,390 --> 00:22:42,070 natürlich zu so einem System der kontinuierlichen Verbesserung. 433 00:22:42,070 --> 00:22:45,510 Ich glaube, wir alle kennen dieses Bild dieser Dev ops 8 und 434 00:22:45,510 --> 00:22:50,190 wenn wir uns jetzt das Ganze erweitern um entsprechende. 435 00:22:51,240 --> 00:22:53,760 Tests der Infrastruktur, um die Resilienz zu erhöhen. 436 00:22:53,760 --> 00:22:56,320 Wir haben ja klassischerweise, wenn wir über diesen 437 00:22:56,320 --> 00:22:59,840 kontinuierlichen Prozess in Dev Ops sprechen, in erster Linie 438 00:22:59,840 --> 00:23:02,880 unsere Software im Blick, das heißt, wir testen dort 439 00:23:02,880 --> 00:23:06,520 regelmäßig, kriegen Feedback, entweder während unserer Tests 440 00:23:06,520 --> 00:23:08,800 oder von den Usern und verbessern dann unsere Software. 441 00:23:09,120 --> 00:23:12,720 Aber jetzt ergänzen wir das um die weitere Ebene der 442 00:23:12,720 --> 00:23:16,440 darunterliegenden Infrastruktur, um unsere Anwendung so resilient 443 00:23:16,440 --> 00:23:19,880 zu machen, dass selbst bei bestimmten Ausfällen bestimmter 444 00:23:19,880 --> 00:23:22,640 Infrastrukturkomponenten unsere Anwendungen. 445 00:23:22,990 --> 00:23:27,110 Weiterhin gut funktioniert und ich glaub wir können kein System 446 00:23:27,110 --> 00:23:30,750 von Anfang an so bauen, dass es auf alle Eventualitäten 447 00:23:30,750 --> 00:23:33,710 vorbereitet ist, die irgendwo realistisch sind, sondern wir 448 00:23:33,710 --> 00:23:35,670 müssen diese Tests laufen lassen. 449 00:23:35,870 --> 00:23:39,310 Wir müssen. Ja, zufällig und deswegen ja 450 00:23:39,310 --> 00:23:43,670 Chaos, bestimmte Komponenten in bestimmten Abständen ausfallen 451 00:23:43,670 --> 00:23:46,550 lassen und schauen, wie reagiert unsere Anwendung dadrauf, um 452 00:23:46,550 --> 00:23:49,430 auch wirklich diese Verbesserung hereinbringen zu können, weil 453 00:23:49,430 --> 00:23:53,390 ich glaube, niemand kann tatsächlich auch auf alle Dinge 454 00:23:53,390 --> 00:23:55,750 von vornherein vorbereitet zu sein und ich glaube, in der 455 00:23:55,750 --> 00:23:58,230 Softwareentwicklung sind wir auch seit vielen Jahren an dem 456 00:23:58,230 --> 00:24:01,710 Punkt, dass wir diese diese Annahme so ein bisschen auch 457 00:24:01,710 --> 00:24:04,750 schon über Bord geworfen werden, dass wir über Bord geworfen 458 00:24:04,750 --> 00:24:08,630 haben, dass wir uns schon bei der Planung der Software auf 459 00:24:08,630 --> 00:24:10,870 alle Eventualitäten vorbereiten können. 460 00:24:11,960 --> 00:24:13,320 Wir müssen wirklich das Ganze testen. 461 00:24:13,320 --> 00:24:16,320 Wir müssen schauen, wie reagiert die Anwendung, um das Ganze dann 462 00:24:16,400 --> 00:24:21,080 zu verbessern, und das sehen wir im Ganzen in bestimmten 463 00:24:21,080 --> 00:24:24,560 Industrien seit vielen Jahren, gerade wenn es jetzt um so 464 00:24:24,560 --> 00:24:27,600 Hardware Nahentwicklung geht. Ich glaube einige von euch sind 465 00:24:27,600 --> 00:24:30,120 natürlich auch in der Embedded Entwicklung, wo es darum geht 466 00:24:30,120 --> 00:24:33,520 irgendwelche Software für Industriemaschinen, für Autos 467 00:24:33,520 --> 00:24:37,600 oder zu entwickeln und dort findet das natürlich seit vielen 468 00:24:37,600 --> 00:24:40,230 Jahren. Hat dort werden bestimmte 469 00:24:40,350 --> 00:24:43,310 Ausfalltests durchgeführt, um zu schauen, wie reagiert meine 470 00:24:43,310 --> 00:24:47,150 Software, wenn eine bestimmte Hardware Komponente in meinem. 471 00:24:47,870 --> 00:24:50,190 Autor in meiner Waschmaschine et cetera ausfällt. 472 00:24:50,190 --> 00:24:53,070 Wie reagiert dann das darauf, insbesondere in 473 00:24:53,070 --> 00:24:56,390 sicherheitskritischen Systemen, wie zum Beispiel im Auto? 474 00:24:56,550 --> 00:24:59,110 Wie reagiert dann meine Software daraus, wenn ein bestimmter 475 00:24:59,110 --> 00:25:01,550 Sensor ausfällt oder wenn bestimmte andere Komponenten 476 00:25:01,550 --> 00:25:03,590 ausfallen? Da kennen wir das schon, weil 477 00:25:03,590 --> 00:25:06,710 wir da aus rein Sicherheitsgründen schon davon 478 00:25:07,350 --> 00:25:10,070 ausgehen müssen, dass wir darauf reagieren müssen, aber das 479 00:25:10,070 --> 00:25:12,310 gleiche können wir natürlich auch bei beliebiger anderer 480 00:25:12,310 --> 00:25:16,470 Software machen, die wir auf komplexer Infrastruktur 481 00:25:16,590 --> 00:25:19,550 betreiben, wenn wir unsere Software vielleicht irgendwie 482 00:25:19,710 --> 00:25:22,670 auf einem ganz simplen System einen Server mit einer 483 00:25:22,670 --> 00:25:25,680 Datenbank. Da gibt es wenig, was da letzten 484 00:25:25,680 --> 00:25:28,720 Endes zufällig passieren kann. Da kann vielleicht der ganze 485 00:25:28,720 --> 00:25:31,320 Server ausfallen oder vielleicht die Datenbank oder der 486 00:25:31,320 --> 00:25:33,880 Webserver, aber am Ende kann nicht so viel passieren, aber 487 00:25:33,880 --> 00:25:36,320 heutzutage ist ja die Infrastruktur, auf der unsere 488 00:25:36,320 --> 00:25:40,120 Software läuft, meist weitaus komplexer, wir haben ganz viele 489 00:25:40,120 --> 00:25:43,040 verschiedene Komponenten und insbesondere wenn wir Cloud 490 00:25:43,040 --> 00:25:46,080 native Applikationen bauen, Applikationen auf solchen 491 00:25:46,080 --> 00:25:49,280 Plattformdiensten in Hyperscaler Cloud haben wir so viele 492 00:25:49,280 --> 00:25:52,430 verschiedene Komponenten. Die unabhängig voneinander 493 00:25:52,710 --> 00:25:55,070 völlig verschiedene Störungen haben können. 494 00:25:55,390 --> 00:25:57,630 Und da ist natürlich dann wichtig, sich entsprechend 495 00:25:57,630 --> 00:26:01,030 darauf vorzubereiten und dafür gibt es glücklicherweise 496 00:26:01,230 --> 00:26:03,790 mittlerweile entsprechende Tools, die wir da nutzen können. 497 00:26:03,790 --> 00:26:05,550 Das heißt, wir sind da nicht komplett auf uns alleine 498 00:26:05,550 --> 00:26:08,510 gestellt, wir brauchen jetzt kein Admin, der dann 499 00:26:08,510 --> 00:26:11,110 irgendwelche Skripte abfeuert, um mal eine Komponente aus dem 500 00:26:11,110 --> 00:26:14,640 System rauszunehmen. Sondern wir haben dort 501 00:26:14,640 --> 00:26:17,200 entsprechende Werkzeuge, auf die wir zurückgreifen. 502 00:26:17,200 --> 00:26:19,320 Können genau da haben wir uns ja in der Vorbereitung ein Paar 503 00:26:19,320 --> 00:26:21,040 angeschaut. Also einmal finde ich es 504 00:26:21,040 --> 00:26:24,080 natürlich spannend, dass zumindest 2 der großen Cloud 505 00:26:24,080 --> 00:26:26,600 Provider haben wir gefunden, dass die quasi schon so ein 506 00:26:26,600 --> 00:26:31,080 Chaos Engineering Tool oder Service mit in ihrer Plattform 507 00:26:31,080 --> 00:26:33,960 eingebaut haben, das einmal bei Microsoft Azure gibt es das 508 00:26:33,960 --> 00:26:38,760 Chaos Studio und bei AWS gibt es den False Injection Service und 509 00:26:38,760 --> 00:26:40,520 die haben natürlich den großen Vorteil, dass die schon eine 510 00:26:40,520 --> 00:26:44,120 tiefe Integration in die eigene Cloud Plattform haben, das heißt 511 00:26:44,120 --> 00:26:47,240 ich kann da so Autages und Slowdowns zum Beispiel von der 512 00:26:47,240 --> 00:26:50,520 gemanagten Datenbank oder auch den Shutdown von der VM oder 513 00:26:50,520 --> 00:26:53,990 sowas. Einfach simulieren, weil ich 514 00:26:53,990 --> 00:26:56,270 natürlich dadurch, dass das tiefe Migration diese Plattform 515 00:26:56,270 --> 00:26:59,240 ist. Da halt auch einfach direkt den 516 00:26:59,240 --> 00:27:01,440 Zugriff drauf habe. Also ich kann zum Beispiel auch 517 00:27:01,440 --> 00:27:05,760 irgendwie Memory oder Disc oder CPU Failiers. 518 00:27:06,230 --> 00:27:09,390 Polieren ich kann den Delay also einfach mal ne langsame 519 00:27:09,390 --> 00:27:14,950 Netzwerkverbindung, wirklich trotteln und die haben natürlich 520 00:27:14,950 --> 00:27:16,750 auch dann ne sehr gute Integration in die eigene 521 00:27:16,750 --> 00:27:18,870 Monitoring Tools oder in die eigenen Services. 522 00:27:18,870 --> 00:27:21,950 Also ich zum ne ist kein Geheimnis, ich arbeite viel wie 523 00:27:21,950 --> 00:27:23,950 mit Microsoft Azure, die haben einen gemanagten kubanetis 524 00:27:23,950 --> 00:27:26,830 Service und da kann ich dann direkt auch in diesem Asia Chaos 525 00:27:26,830 --> 00:27:29,950 Studio in den gemanagten Kubanitus Service rein und dann 526 00:27:29,950 --> 00:27:34,390 da auch welche irgendwelche Fehler simulieren, das heißt da 527 00:27:34,390 --> 00:27:37,070 bei Azure und Adobe AS gibt es einfach schon fertig von der 528 00:27:37,070 --> 00:27:39,870 Plattform einen eigenen Service. Bei Google habe ich jetzt nichts 529 00:27:39,870 --> 00:27:43,280 gefunden. Wenn jemand zuhört und da einen 530 00:27:43,280 --> 00:27:45,320 eigenen Service von Google kennt, könnt ihr das ja gerne 531 00:27:45,320 --> 00:27:46,760 auch irgendwie in den Kommentaren ergänzen. 532 00:27:46,760 --> 00:27:48,640 Dann reichen wir das nächste Folge nach. 533 00:27:50,230 --> 00:27:52,630 Es gibt dann aber auch ganz, ganz viele eigene, so Open 534 00:27:52,630 --> 00:27:55,190 Source Tools, die man selber betreiben kann. 535 00:27:55,190 --> 00:27:58,070 Und ne ich hab mir das kommt alles ja so n bisschen aus 536 00:27:58,070 --> 00:28:01,150 dieser Netflixwelt, die sind ja auch sehr große Verfechter von 537 00:28:01,150 --> 00:28:04,270 Kubanetis, das heißt sie haben nicht nur Chaos Engagement 538 00:28:04,270 --> 00:28:06,470 geprägt, sondern auch direkt ein Tool mitgebracht. 539 00:28:08,560 --> 00:28:13,360 Hier Chaos Monkey ist soweit ich weiß direkt von Netflix und da 540 00:28:13,360 --> 00:28:15,800 drauf hat sich auch noch Chaos Mesh gebildet. 541 00:28:16,080 --> 00:28:18,200 Das ist ein Open Source Experiment, was dann auch der 542 00:28:18,200 --> 00:28:20,920 Cloud Native Computing Foundation übergeben wurde und 543 00:28:21,520 --> 00:28:23,440 was noch mal ein bisschen komplexer ist, aber da kann ich 544 00:28:23,440 --> 00:28:25,480 dann wirklich auch quasi alles wirklich simulieren, was in 545 00:28:25,480 --> 00:28:30,640 meinem Kubanitus Cluster. Quasi fehlschlägt. 546 00:28:30,840 --> 00:28:34,400 Und dann gibt es darüber hinaus aber noch ganz viele Tools, die 547 00:28:34,400 --> 00:28:37,960 eben nicht nur in meinem, also in einer einzelnen Infrastruktur 548 00:28:37,960 --> 00:28:41,200 im Klasse, sondern auch wirklich über so Cloud übergreifend 549 00:28:41,600 --> 00:28:43,640 Experimente durchführen. Du hast dir da glaube ich ein 550 00:28:43,640 --> 00:28:46,840 Paar angeguckt, malte. Wir haben und Netflix hat das im 551 00:28:46,840 --> 00:28:50,640 Laufe der Zeit auch immer mehr erweitert über die 552 00:28:50,880 --> 00:28:54,000 Infrastruktur, Komponenten, den raus hinaus haben sie neben 553 00:28:54,000 --> 00:28:56,960 Chaos Monkey auch ein Tool wie latency months, was halt 554 00:28:56,960 --> 00:28:59,710 latexancy. Einführt oder n Tool was halt 555 00:29:00,190 --> 00:29:04,910 bestimmte Komponenten außerhalb der internen IT Konformität 556 00:29:04,910 --> 00:29:06,990 bringt. Also wie reagiert dann mein 557 00:29:06,990 --> 00:29:08,830 System da draus? Das heißt Sie haben so ne ganze 558 00:29:08,830 --> 00:29:12,470 Familie von Werkzeugen entwickelt, dann gibt. 559 00:29:12,950 --> 00:29:14,750 Natürlich. Monkey ne ist immer irgendwas 560 00:29:14,750 --> 00:29:16,550 Monkey. Genau, also. 561 00:29:16,550 --> 00:29:19,190 Sie nennen es irgendwie Simeon Army. 562 00:29:19,670 --> 00:29:22,830 Ich hab jetzt nicht geschaut, was sich da hinter verbirgt 563 00:29:22,830 --> 00:29:25,270 hinter diesem Begriff, aber sie haben halt wirklich diese ganze 564 00:29:25,270 --> 00:29:29,390 Familie von von Tools. Und darüber hinaus gibt es 565 00:29:29,670 --> 00:29:33,190 tatsächlich noch ganz viel in der Open Source Welt und auch an 566 00:29:33,190 --> 00:29:36,750 kommerziellen Tools. Es gibt halt sowas wie Chaos 567 00:29:36,750 --> 00:29:39,390 Toolkit, was n Open Source Framework ist, was man 568 00:29:39,510 --> 00:29:42,630 tatsächlich für ganz viele verschiedene Szenarien verwenden 569 00:29:42,630 --> 00:29:44,990 kann, auch für verschiedene Cloud Plattformen, wenn man 570 00:29:45,350 --> 00:29:48,950 keine dieser eingebauten Dienste nutzen kann oder möchte. 571 00:29:49,150 --> 00:29:54,750 Es gibt speziell für Docker ausgelegte Tools für Docker 572 00:29:54,750 --> 00:29:58,630 Container, um dort gerade so Netzwerkstörungen reinzubringen, 573 00:29:58,630 --> 00:30:01,830 Container zu stoppen, das Tool ich da gefunden habe, nennt sich 574 00:30:01,830 --> 00:30:06,280 Pamba oder Pumbaa. Dann gibt es noch andere Open 575 00:30:06,280 --> 00:30:08,760 Souls Tools speziell für Cobanitis. 576 00:30:08,760 --> 00:30:13,600 Du hast gerade schon glaube ich erwähnt Cube Monkeys, es gibt 577 00:30:14,120 --> 00:30:17,400 lithmus, also ganz viele Tools, halt speziell in dieser Cloud 578 00:30:17,400 --> 00:30:22,280 native cubinitis Welt und ein ganz populäres Tool für Chaos 579 00:30:22,280 --> 00:30:26,840 Engineering ist auch Gremlin, mit dem ich sehr viel auch 580 00:30:27,240 --> 00:30:30,270 tatsächlich. Machen kann auch visuell 581 00:30:30,270 --> 00:30:32,590 skripten kann, da gibt es auch ne UI wo ich das Ganze 582 00:30:32,590 --> 00:30:35,310 entsprechend vorbereiten kann und auch verschiedene 583 00:30:35,310 --> 00:30:38,390 Komponenten adressieren kann, das heißt sowohl im Open Source 584 00:30:38,390 --> 00:30:41,150 Bereich als auch im Bereich der kommerziellen Tools gibt es 585 00:30:41,150 --> 00:30:44,070 einiges und. Was du jetzt noch in die Liste 586 00:30:44,070 --> 00:30:45,990 mit aufgenommen hast und dass ich ursprünglich gar nicht 587 00:30:45,990 --> 00:30:47,470 gedacht hatte, ist halt das ganze Thema. 588 00:30:47,470 --> 00:30:50,630 Wie mache ich das eigentlich bei Web Applikationen Clientside 589 00:30:51,190 --> 00:30:53,950 dazu gesagt Hier Chrome Developer Tools bringt ja auch 590 00:30:53,950 --> 00:30:57,110 einiges mit, zum Beispiel wie kann ich eine schlecht 591 00:30:57,110 --> 00:31:00,190 Internetverbindung simulieren oder wie kann ich einen CPU 592 00:31:00,190 --> 00:31:03,870 Thread legen oder andere Systemeinschränkungen simulieren 593 00:31:03,870 --> 00:31:08,590 die natürlich auftreten können. Ja, also es sind natürlich nicht 594 00:31:08,590 --> 00:31:10,270 nur Backend Systeme, sondern auch frontends. 595 00:31:10,270 --> 00:31:13,750 Einfach simulier mal. Der User fährt mit seinem iphone 596 00:31:13,750 --> 00:31:15,590 in den Tunnel, mal kurz kein Internet. 597 00:31:15,590 --> 00:31:17,510 Wie verhält sich meine Anwendung, das ist ja auch 598 00:31:17,510 --> 00:31:20,200 spannend im Frontend. Man macht ja einfach einen 599 00:31:20,200 --> 00:31:23,280 Retriever oder gibt es eine große rote Fehlermeldung und 600 00:31:23,280 --> 00:31:26,040 alle meine meine Arbeit ist weg, wir hatten ja vor, ich habe 2 601 00:31:26,040 --> 00:31:29,560 folgen über das Thema offline first gesprochen und da kam mir 602 00:31:29,560 --> 00:31:32,280 das natürlich auch auf und dann wer sich schon ein bisschen 603 00:31:32,280 --> 00:31:34,480 tiefer in die Chrome developer Tools rein gefuchst hat, er hat 604 00:31:34,480 --> 00:31:37,360 auch schon mal gesehen, dass man da auch langsames Internet 605 00:31:37,360 --> 00:31:40,240 simulieren kann, was manchmal fast noch schwieriger ist als 606 00:31:40,240 --> 00:31:43,160 einfach so ein binären Zustand wie online oder offline, wenn 607 00:31:43,160 --> 00:31:45,640 das Internet etwas sehr langsam ist, funktioniert meine 608 00:31:45,640 --> 00:31:47,840 Anwendung noch oder wenn die CPU ist, weil die vielleicht auf 609 00:31:47,840 --> 00:31:49,790 einem schwachen Gerät. Sondern auf dem Gerät, auf dem 610 00:31:49,790 --> 00:31:52,670 der User gerade unterwegs ist. Auch viele andere Sachen 611 00:31:52,670 --> 00:31:55,230 passiert auch das finde ich spannend, aber wie gesagt, keine 612 00:31:55,230 --> 00:31:56,870 Sorge, müsst ihr diese ganzen Tools, die wir gerade genannt 613 00:31:56,870 --> 00:31:59,990 haben, nicht nicht merken. Wir machen uns natürlich die 614 00:31:59,990 --> 00:32:02,670 Mühe und packen euch die ganzen Links dazu in die Shownotes von 615 00:32:02,670 --> 00:32:05,550 der Folge. Aber ich glaub, da gibt es auch 616 00:32:05,550 --> 00:32:07,790 kein bestes Tool. Ich würd sagen, klickt euch da 617 00:32:07,790 --> 00:32:09,990 mal durch, schaut euch an, was euch am besten gefällt und dann 618 00:32:10,030 --> 00:32:13,070 klein anfangen, denn das ist glaub ich das Wichtige, dass man 619 00:32:13,070 --> 00:32:15,710 mal so n Mindestklein anfangen, das ist wie mit Unittest der 620 00:32:15,710 --> 00:32:17,910 erste ist schon fast der Wichtigste, dass man zumindest 621 00:32:17,910 --> 00:32:20,910 mal irgendwie was hat. Und dann, wenn man sich für so n 622 00:32:20,910 --> 00:32:22,950 Tool entschieden hat und wenn man sich diese Szenarien 623 00:32:22,950 --> 00:32:25,950 ausgesucht hat, die man eigentlich abdecken möchte, also 624 00:32:25,950 --> 00:32:28,390 was wogegen möchte mich denn schützen, dann ist die 625 00:32:28,390 --> 00:32:31,230 Vorgehensweise eigentlich immer dieselbe. 626 00:32:31,230 --> 00:32:34,270 Also man macht, ich hab jetzt diese Hypothese, ich hab meine. 627 00:32:34,710 --> 00:32:36,750 Meine Targets und meine App definiert, die ich testen 628 00:32:36,750 --> 00:32:38,950 möchte. Mein blastradius ich hab meine 629 00:32:38,950 --> 00:32:41,870 Analytics an Bord und dann funktioniert es eigentlich immer 630 00:32:41,870 --> 00:32:45,630 gleich, dann macht man dann ist es der erste wichtige Punkt und 631 00:32:45,830 --> 00:32:47,350 es ist witzigerweise auch der Punkt. 632 00:32:48,470 --> 00:32:50,830 Den ich am Anfang, als ich mit dem Thema angefangen hab, halt 633 00:32:50,830 --> 00:32:54,310 vergessen habe, ist, dass man natürlich einmal so diese 634 00:32:54,310 --> 00:32:58,910 Workload Baseline nenn ich das mal ausmacht, also einfach bei 635 00:32:58,910 --> 00:33:01,150 einem bestimmten realistischen User Traffic. 636 00:33:01,190 --> 00:33:03,510 Wie ist denn meine durchschnittliche Response Time, 637 00:33:03,590 --> 00:33:05,910 wie ist denn meine feature Verfügbarkeit, was sind denn 638 00:33:05,910 --> 00:33:08,950 meine Fehlerquoten und was sind denn das sind so die Häufigkeit 639 00:33:08,950 --> 00:33:11,590 meiner Fail frequests damit ich überhaupt mal irgendwas hab 640 00:33:11,590 --> 00:33:13,990 gegen das ich messen kann. Ich hab immer so Chaos 641 00:33:14,110 --> 00:33:17,870 Engineering also Chaos Experimente gestartet also ja 642 00:33:17,870 --> 00:33:20,630 okay ja klar hier meine Verfügbarkeit geht runter. 643 00:33:21,720 --> 00:33:24,160 Was ist denn eine normale Verfügbarkeit für mich? 644 00:33:24,160 --> 00:33:25,840 Was ist denn eine normale Response Time? 645 00:33:25,840 --> 00:33:28,720 Also das einfach einmal messen, also diese Workload baseline 646 00:33:28,720 --> 00:33:32,240 habe ich es genannt, machen dann natürlich das Experiment starten 647 00:33:32,240 --> 00:33:35,600 klar, dann die Telemetrie einsammeln, dann auch ganz 648 00:33:35,600 --> 00:33:39,560 wichtig das Experiment wieder stoppen, auch hier, ich war mal 649 00:33:39,560 --> 00:33:43,400 bei einem Kunden wo wir das eingeführt haben und ja haben 650 00:33:43,400 --> 00:33:45,920 dann am Tag drauf uns gewundert, dass das die Anwendung immer 651 00:33:45,920 --> 00:33:49,600 noch sich nicht erholt hat und irgendwie kaputt ist und alles 652 00:33:49,600 --> 00:33:51,800 super langsam ist und dann um nur um dann feststellen, dass 653 00:33:51,800 --> 00:33:53,840 wir das Experiment nie gestoppt haben und diese Chaos Monkeys 654 00:33:53,840 --> 00:33:55,760 Monkeys da weiter wie wild irgendwelche Stecker raus 655 00:33:55,760 --> 00:33:58,320 gerupft und zufällig zufällig irgendwelche wms runtergefahren 656 00:33:58,320 --> 00:34:00,200 haben das mag jetzt Netflix können, weil die das in 657 00:34:00,200 --> 00:34:03,230 Produktion immer machen. Aber ich sag mal, die wenigsten 658 00:34:03,230 --> 00:34:06,590 Kunden sind jetzt so groß wie Netflix und haben auch irgendwie 659 00:34:06,590 --> 00:34:08,110 das das Team. Also auf jeden Fall auch mal das 660 00:34:08,110 --> 00:34:10,270 Experiment wieder stoppen, gerade wenn man sich noch noch 661 00:34:10,270 --> 00:34:13,030 nicht entschieden hat, dass das n kontinuier n Kontinuum sein 662 00:34:13,030 --> 00:34:16,510 soll. Und dann natürlich Monitoren, ob 663 00:34:16,790 --> 00:34:20,270 und wie schnell das System wieder auf diese Baseline, die 664 00:34:20,270 --> 00:34:22,590 man im ersten Schritt festgestellt hat, zurückfällt, 665 00:34:22,750 --> 00:34:24,469 weil das ist ja auch eigentlich das Spannende. 666 00:34:24,469 --> 00:34:27,750 Ne, ich hab Chaos, mein System mag ja dagegen reagieren, aber 667 00:34:27,750 --> 00:34:31,590 wenn dieses Chaos aufhört und im Idealfall hört es ja irgendwann 668 00:34:31,590 --> 00:34:33,510 auf, skaliert mein Cluster dann wieder runter zum Beispiel oder 669 00:34:33,510 --> 00:34:35,790 bleiben diese WM Star, diese zusätzlich gebuchten wms für 670 00:34:35,790 --> 00:34:39,310 immer stehen und erzeugen Kosten und wie schnell schaffe ich das 671 00:34:39,310 --> 00:34:42,070 denn auf meine Baseline wieder zurückzufallen, weil das ist ja 672 00:34:42,070 --> 00:34:44,310 auch einfach interessant und ich glaube, wenn man diese 673 00:34:44,310 --> 00:34:48,159 Vorgehensweise. Immer macht also Baseline 674 00:34:48,159 --> 00:34:50,239 ausmachen, Experiment starten, Telemetrie einsammeln, 675 00:34:50,239 --> 00:34:51,600 Experiment stoppen und dann Monitoren. 676 00:34:51,600 --> 00:34:53,639 Wie schnell ich auf diese Baseline Zurückfalle, dann hat 677 00:34:53,639 --> 00:34:56,239 man glaube ich schon einen sehr sehr guten Start, das ist so ein 678 00:34:56,239 --> 00:35:00,120 bisschen wie dieses. Arrange Act acert pattern, wenn 679 00:35:00,120 --> 00:35:02,000 ich irgendwelche Unit Tests zum Beispiel schreibe, wo ich 680 00:35:02,000 --> 00:35:04,960 einfach immer nach der gleichen Art und Weise unittests baue, 681 00:35:05,480 --> 00:35:07,400 würde ich das bei Chaos entstehen übrigens einfach immer 682 00:35:07,400 --> 00:35:11,710 nach diesem Pattern bauen. Ihr könnt es gerade im Podcast 683 00:35:11,710 --> 00:35:14,030 nicht sehen und ich glaub, du hast es auch nicht gesehen, wie 684 00:35:14,030 --> 00:35:17,430 ich mich zurückhalten musste, weil ich gerade im Kopf dieses 685 00:35:17,790 --> 00:35:21,350 diesen Film hatte. Wie du mit einem LKW voller 686 00:35:21,350 --> 00:35:24,990 Affen zum Kunden fährst, die auf das Data Center loslässt und 687 00:35:24,990 --> 00:35:27,350 dann mit dem Lkw wieder nach Hause fährst und merkst, die 688 00:35:27,350 --> 00:35:28,710 Affen sind immer noch beim Kunden. 689 00:35:30,440 --> 00:35:32,800 Also das war dieses Bild, was gerade entstand, als so dieses 690 00:35:32,800 --> 00:35:37,240 Szenario beschrieben und einfach einfach großartig. 691 00:35:37,240 --> 00:35:42,160 Wo sind meine Affen vergessen? Sehr schön. 692 00:35:43,880 --> 00:35:47,080 Also ihr wisst jetzt, wie das grundsätzliche Vorgehen ist. 693 00:35:47,240 --> 00:35:51,840 Wie sollten wir jetzt einsteigen oder welche Best Practices gibt 694 00:35:51,840 --> 00:35:52,960 es? Einige haben wir gerade schon 695 00:35:52,960 --> 00:35:56,840 genannt, ich glaube das Wichtigste ist klein anfangen, 696 00:35:56,960 --> 00:36:01,840 andere sagen hier so Crawl Walk run, das heißt, wir sollten eine 697 00:36:01,840 --> 00:36:05,000 Grundlage legen und das Netflix Level, das können wir auch in 698 00:36:05,000 --> 00:36:09,320 ein paar Jahren erreicht haben, dann gehen wir in dem Vorgehen 699 00:36:09,320 --> 00:36:11,230 vor wie. Wir es vorhin beschrieben haben, 700 00:36:11,230 --> 00:36:13,710 wir stellen unsere Hypothesen auf, wir machen unsere Tests, 701 00:36:13,710 --> 00:36:18,430 Wir sammeln Telemetrie, nehmen die Learnings und nutzen diese 702 00:36:18,430 --> 00:36:21,150 Learnings für eine kontinuierliche Verbesserung 703 00:36:21,150 --> 00:36:25,310 unserer Applikationen. Dabei ganz wichtig immer die 704 00:36:25,310 --> 00:36:27,990 Menschen mit einbeziehen, nicht einfach hingehen und so ein 705 00:36:27,990 --> 00:36:30,110 Experiment durchführen, ohne dass das entsprechend 706 00:36:30,110 --> 00:36:34,990 verantwortliche Engineering Team auch weiß, dass wir darauf wert 707 00:36:34,990 --> 00:36:37,750 legen, weil natürlich wir die Leute nicht irgendwie am Ende 708 00:36:37,750 --> 00:36:40,110 bloßstellen wollen, sondern wir wollen dafür sorgen, dass die 709 00:36:40,110 --> 00:36:44,800 Leute ihre Architektur. Testen können, dass die Leute 710 00:36:44,800 --> 00:36:47,320 die Applikationen oder die Komponenten der Applikation, für 711 00:36:47,320 --> 00:36:49,600 die sie verantwortlich sind, kontinuierlich verbessern 712 00:36:49,600 --> 00:36:50,720 können. Das heißt, Wir müssen die 713 00:36:50,720 --> 00:36:53,280 Menschen mitnehmen, wir müssen auch dafür sorgen, dass unser 714 00:36:53,280 --> 00:36:57,040 Support Personal darauf vorbereitet ist, was passiert 715 00:36:57,040 --> 00:36:59,560 oder wie reagiere ich darauf, wenn wir bestimmte Ausfälle 716 00:36:59,560 --> 00:37:03,680 haben. Und zu solchen Incidents können 717 00:37:03,680 --> 00:37:09,080 natürlich auch. Themen wie Sicherheitslücken 718 00:37:09,680 --> 00:37:12,830 gehören, das heißt? Ich muss aufpassen, wenn ich 719 00:37:12,830 --> 00:37:17,270 solche Experimente durchführe, dass ich da nicht irgendwie aus 720 00:37:17,270 --> 00:37:20,270 Versehen einen Backdoktor aufmache oder Zugriffe auf meine 721 00:37:20,270 --> 00:37:23,230 Infrastruktur erlaube, die letzten Endes zu einer 722 00:37:23,230 --> 00:37:25,030 Sicherheitsverletzung führen können. 723 00:37:26,030 --> 00:37:29,830 Ganz viel dieser Tools brauchen natürlich sehr umfangreiche 724 00:37:29,830 --> 00:37:32,910 Rechte auf meine Infrastruktur, um bestimmte Komponenten zu 725 00:37:32,910 --> 00:37:37,030 beeinflussen, bestimmte Services außer Betrieb zu nehmen et 726 00:37:37,030 --> 00:37:38,510 cetera. Da muss ich natürlich genau 727 00:37:38,510 --> 00:37:42,470 drauf achten, welche Rechte hat dieses Tool, wer hat Zugriff auf 728 00:37:42,470 --> 00:37:45,870 dieses Tool, um nicht letzten Endes Außenstehenden zu 729 00:37:45,870 --> 00:37:48,910 umfangreiche Rechte auf meine Infrastruktur über diese Chaos 730 00:37:48,910 --> 00:37:51,750 Tools zu geben, da bin ich natürlich im Vorteil, wenn ich 731 00:37:51,750 --> 00:37:55,550 solche in die Cloud Plattform integrierten Werkzeuge habe, 732 00:37:55,550 --> 00:37:59,470 weil sie genau dieses Role Based Access Control der Plattform mit 733 00:37:59,470 --> 00:38:02,510 übernehmen, aber immer wenn ich irgendwelche externen Tools 734 00:38:02,510 --> 00:38:05,680 verwende, die dann. Umfangreiche Rechte auf meine 735 00:38:05,680 --> 00:38:08,280 Infrastruktur haben, muss ich darauf achten, dass ich nicht 736 00:38:08,480 --> 00:38:11,200 durch mein Chaos testing irgendwelche Sicherheitslücken 737 00:38:11,200 --> 00:38:16,240 in meine Infrastruktur reinbringe oder sogar 738 00:38:16,240 --> 00:38:19,360 Datenschutzverletzungen begehe, weil dann Leute, die diese Tests 739 00:38:19,360 --> 00:38:21,480 durchführen, plötzlich Zugriff auf irgendwelche Daten haben, 740 00:38:21,480 --> 00:38:23,840 die Sie nicht sehen sollten. Das heißt, das muss ich 741 00:38:23,840 --> 00:38:26,750 entsprechend berücksichtigen. Auch ganz wichtig, das Ganze 742 00:38:26,750 --> 00:38:30,030 entsprechend zu dokumentieren, an Hypothesen zu dokumentieren, 743 00:38:30,030 --> 00:38:33,230 meine Experimente zu dokumentieren und auch zu 744 00:38:33,230 --> 00:38:35,910 dokumentieren, welche Verbesserungen ich daraus 745 00:38:35,910 --> 00:38:39,910 abgeleitet habe, damit wir auch langfristig daraus lernen 746 00:38:39,910 --> 00:38:41,510 können. Und auch dieses Wissen dann 747 00:38:41,510 --> 00:38:45,030 weitergegeben, kann. Weitergegeben werden kann an 748 00:38:45,030 --> 00:38:50,150 andere Leute, die vielleicht später das Unternehmen im 749 00:38:50,150 --> 00:38:54,830 Unternehmen dazu kommen oder vielleicht neu ins Team dazu 750 00:38:54,830 --> 00:38:57,830 kommen und das Experiment selber auch nicht so miterlebt haben, 751 00:38:57,830 --> 00:39:00,190 aber trotzdem die Learnings mitbekommen. 752 00:39:01,550 --> 00:39:04,510 Das ist doch ne super. Zusammenfassung ich würd noch 753 00:39:04,510 --> 00:39:06,990 einen Satz gerne, bevor wir die Folge abschließen hinzufügen, 754 00:39:06,990 --> 00:39:10,670 nämlich einfach. Der Hauptgrund, warum ich Chaos 755 00:39:10,670 --> 00:39:14,790 Engineering als wichtig erachte, ist, ich will nicht zum ersten 756 00:39:14,790 --> 00:39:17,910 Mal einen Ausfall erleben, wenn der in Produktion passiert, 757 00:39:17,910 --> 00:39:20,070 mitten in der Nacht und nicht aus dem Bett geklingelt werde, 758 00:39:20,350 --> 00:39:24,270 sondern ich will einfach wissen, wie mein System drauf reagiert 759 00:39:24,350 --> 00:39:26,710 und dafür ist genau diese Schritte, die malte auch gerade 760 00:39:26,710 --> 00:39:28,150 noch mal sehr gut zusammengefasst hat. 761 00:39:29,880 --> 00:39:32,200 Dass ich halt einfach nicht zum allerersten Mal wie Ochs vorm 762 00:39:32,200 --> 00:39:33,520 Berg stehe. Wenn jetzt irgendwas nicht 763 00:39:33,520 --> 00:39:35,960 funktioniert, sondern ich habe das schon mal in einer 764 00:39:36,000 --> 00:39:38,760 hoffentlich kontrollierten Umgebung erlebt und ich weiß 765 00:39:38,760 --> 00:39:41,280 einfach sehr genau, wie ich reagiere und ich weiß, ich kenne 766 00:39:41,280 --> 00:39:43,440 auch mein System und weiß auch, wie mein System reagiert. 767 00:39:46,270 --> 00:39:48,630 Macht ihr Chaos Engineering schon? 768 00:39:48,630 --> 00:39:50,750 Das würde mich eigentlich mal interessieren, weil ich finde 769 00:39:50,750 --> 00:39:54,870 immer, ich weiß nie ob das so ne Bubble ist, weil alle sind immer 770 00:39:54,870 --> 00:39:56,510 sehr interessiert wenn man drüber redet, ich kenn aber gar 771 00:39:56,510 --> 00:39:58,990 nicht so wahnsinnig viele Teams die es wirklich machen. 772 00:39:59,630 --> 00:40:02,430 Von daher machen wir mal ne kleine Umfrage, zumindest wenn 773 00:40:02,430 --> 00:40:04,350 ihr auf Spotify uns hört unter die Folge, da könnt ihr mal 774 00:40:04,350 --> 00:40:07,110 abstimmen, ob das bei euch, also ob es nicht interessant ist oder 775 00:40:07,110 --> 00:40:10,950 ob das wirklich schon bei euch zum Einsatz kommt, das da, da 776 00:40:10,950 --> 00:40:13,670 bin ich mir einfach immer unsicher, ich find es aber. 777 00:40:13,910 --> 00:40:15,230 Irre spannend. Ich muss aber auch sagen, ich 778 00:40:15,230 --> 00:40:17,750 mache es aber auch nicht immer selber und. 779 00:40:19,560 --> 00:40:21,160 Lass uns generell auch mal irgendwie n Kommentar da und 780 00:40:21,160 --> 00:40:22,920 lass uns wissen, wie euch die Folge gefallen hat. 781 00:40:23,000 --> 00:40:24,800 Wenn sie euch gut gefallen hat, dann lasst natürlich auch gerne 782 00:40:24,800 --> 00:40:27,240 ne gute Bewertung, da freuen wir uns auch immer sehr, wenn ihr 783 00:40:27,240 --> 00:40:32,400 uns nen Kaffee ausgebt. Da gibt's nen Link zu unten in 784 00:40:32,400 --> 00:40:34,920 den Show Notes zu bei mir Coffee, da freuen wir uns immer 785 00:40:34,920 --> 00:40:37,440 sehr oder wenn ihr zu eurem eigenen Kaffee vielleicht die 786 00:40:37,440 --> 00:40:40,160 passenden Nerd Tasse haben wollt, schaut auch gern mal in 787 00:40:40,160 --> 00:40:42,880 unserem kleinen Shop vorbei. Beide Links findet ihr in der 788 00:40:42,880 --> 00:40:45,640 Beschreibung von der Folge und auf jeden Fall würden. 789 00:40:45,640 --> 00:40:48,480 Wir uns natürlich freuen, wenn ihr auch in 2 Wochen wieder 790 00:40:48,480 --> 00:40:51,880 reinhört, wenn es eine neue Folge des to do Developer 791 00:40:51,880 --> 00:40:56,400 Podcasts gibt. Alle 2 Wochen Montagmorgen eine 792 00:40:56,400 --> 00:40:59,760 neue Folge wir freuen uns, wenn ihr dabei seid, bis dahin habt 793 00:40:59,760 --> 00:41:00,640 eine Gute. Zeit. 794 00:41:01,480 --> 00:41:03,920 Und schreibt ganz viel. Kommt bis dann.