00:00:00Diese Folge von The Stand Up wird etwas ganz Besonderes, denn Casey übernimmt heute das Intro.
00:00:05Casey, worüber sprechen wir heute? Hallo zusammen und willkommen bei The Stand Up. Dem Nummer...
00:00:1245, 6 besten Tech-Podcast auf Spotify laut einer aktuellen Umfrage oder so. Stimmt.
00:00:29Wie auch immer, tut mir leid. Heute bei The Stand Up möchte ich ein Thema anschneiden. Ich werde über den AWS-Ausfall
00:00:34im Oktober sprechen, aber eigentlich geht es mir um ein größeres Thema:
00:00:41Die Sache, ob man etwas wirklich versteht oder nur behauptet, es zu verstehen.
00:00:49Das passiert nämlich oft, besonders bei Leuten, die noch am Anfang
00:00:56ihrer Programmierkarriere stehen, also Junior-Entwickler oder so. Und ich
00:01:01weiß, dass das bei mir definitiv so war: Man will so wirken, als hätte man Ahnung, oder? Man will nicht
00:01:08so rüberkommen, als wüsste man nicht, was läuft. Da herrscht oft ein gewisser Erwartungsdruck,
00:01:14egal ob eingebildet oder echt. Man hat das Gefühl, man müsse so tun, als hätte man alles verstanden,
00:01:21selbst wenn es noch etwas schwammig ist oder man den Faden verloren hat.
00:01:26Auch wenn es gar nicht die eigene Schuld war – vielleicht wurde es schlecht erklärt oder wichtige Details
00:01:33haben gefehlt – man ist trotzdem motiviert, so zu tun, als wüsste man Bescheid,
00:01:39richtig? Weil man dann klüger wirkt oder zumindest nicht wie der totale Anfänger. Aber
00:01:43was ich mit der Zeit und zunehmender Erfahrung als Programmierer gelernt habe,
00:01:50ist, dass ich heute fast schon übertrieben oft nachfrage. Es ist mir
00:01:58völlig egal, ob ich dabei dumm wirke. Ich sage dann: „Moment mal, nochmal zurück. Das habe ich nicht verstanden.“
00:02:03Oder: „Was meinst du damit? Was bedeutet dieser Begriff?“
00:02:06Heute ist mir das einfach egal. Ich mache mir da keinen Kopf mehr.
00:02:12Ich will es wirklich wissen, weil ich es schon so oft erlebt habe, dass ich dachte,
00:02:18ich hätte etwas kapiert (oder es nur vorgab), und dann ging es nach hinten los.
00:02:22Ich will es wirklich verstehen. Wenn mir jemand einen Bug erklärt oder ich eine Vermutung habe,
00:02:28warum das System langsam ist, denke ich mir im Hinterkopf immer:
00:02:33„Wenn ich der Sache nicht wirklich auf den Grund gegangen bin, könnte es auch an etwas anderem liegen.“ Vielleicht
00:02:38versteckt sich die wahre Ursache noch irgendwo und ich weiß es nur nicht, weil ich
00:02:43nicht tief genug gegraben habe. Vielleicht mache ich einfach nur weiter, weil es gerade bequem ist.
00:02:48Der Grund, warum ich über den DynamoDB-Ausfall sprechen wollte, ist die jüngste Serie prominenter Ausfälle.
00:02:55Da war dieser große Ausfall bei Google, und am Ende lag es daran, dass sie
00:03:01ein leeres Feld nicht abgefangen haben, richtig? In ihrem Code lief es wohl so:
00:03:07„Okay, wir haben hier diese Daten, wir laden das JSON, und wenn das JSON leer ist,
00:03:12dann gibt es einen Nullpointer-Fehler oder sowas.“ So simpel war das wohl wirklich.
00:03:17Dann gab es den Vorfall mit CrowdStrike, bei dem sie mit ihren Blue Screens
00:03:23die halbe Welt lahmgelegt haben. Da gab es eine sehr gute, wirklich detaillierte Erklärung.
00:03:28Sie sagten, sie hätten da eine bestimmte Array-Größenberechnung und es gab zu viele Regeln,
00:03:33sodass das Array übergelaufen ist. Das war eine ziemlich solide
00:03:39Root-Cause-Analysis (RCA), also eine Ursachenanalyse. Als sie erklärten,
00:03:45warum das System down war, blieben für mich beim Lesen kaum Fragen offen.
00:03:50Klar, ich kannte nicht die exakte Zeile im Code, weil sie den Code natürlich
00:03:55nicht veröffentlicht haben, aber sie gaben genug Infos, dass ich dachte: „Okay,
00:04:00ich verstehe, wie man diesen Code schreiben konnte, und ich verstehe den dummen Fehler, der dabei passiert ist.“
00:04:05„Alles klar, macht das so nicht nochmal. Verstanden.“ Das war für mich okay.
00:04:10Aber bei DynamoDB – wir hatten das ja schon mal im Podcast erwähnt – da gab es doch
00:04:17diese Story von dem Typen im Guitar Center, der dieses Gespräch im Pub belauscht hat. Richtig?
00:04:24Ja, unglaublich. Hier sehen wir den scheuen Programmierer, eine einfache Kreatur, die die meiste Zeit
00:04:31alleine arbeitet, oft im Dunkeln. Doch was ist das? Jemand im Internet liegt falsch!
00:04:36Unser Coder springt in Aktion und tippt bis zu 120 Wörter pro Minute, bevor eine Website im Light Mode aufblitzt.
00:04:42Der natürliche Feind dieser Code-Liebhaber betäubt unseren Freund. Die Jagd wird abgebrochen.
00:04:46Nächstes Mal klappt es bestimmt. Wenn sie nicht am Computer sitzen, zeichnen sie stundenlang krude Symbole
00:04:53auf sogenannte Whiteboards. Forscher haben tausende Dialekte entdeckt, von denen oft
00:04:58mehr als ein Dutzend in einem einzigen Büro genutzt werden. Der Zweck blieb Linguisten bisher verborgen.
00:05:03Eitle Wesen. Über Jahrtausende haben sich ihre Körper angepasst, um stundenlang in seltsamen Posen
00:05:11auszuharren, während sie sich online selbst betrachten. Oft geschieht dies stundenlang
00:05:16unter dem Vorwand, man warte auf einen Code-Review. Und schließlich, nach einem langen Tag,
00:05:22an dem nicht viel erreicht wurde, bereitet sich unser Tastatur-Krieger aufs Bett vor. Kurz noch was lesen und Licht aus.
00:05:29Gute Nacht, kleiner Coder.
00:05:30Warum ich nachts so gut schlafe? Nun, ich habe Sentry, das mir hilft, Bugs zu eliminieren.
00:05:38Und ich rede nicht von winzigen kleinen Käfern aus South Dakota, die im Winter sterben. Ich rede
00:05:42von riesigen, fiesen Dschungel-Bugs. Vor denen habe ich übrigens keine Angst, aber ich kann sie
00:05:50mit Seer von Sentry einfach zerquetschen. Das hat mich motiviert, mir das mal genauer anzusehen,
00:05:56nach dem Motto: „Mal schauen, wie viele Informationen sie veröffentlicht haben.“ Ich hatte
00:06:02die Zusammenfassung der RCA bereits gelesen, und sie war extrem vage. Die Analyse
00:06:07hat im Grunde gar nichts erklärt. Dann bemerkte ich aber, dass sie eine komplette
00:06:14Präsentation von der re:Invent im Dezember gepostet hatten (oder zumindest ging das Video im Dezember online),
00:06:20in der sie diesen Ausfall behandelten.
00:06:26Also habe ich mir das alles angesehen. Und nachdem ich die gesamte RCA gelesen und die ganze
00:06:32Präsentation verfolgt hatte, saß ich immer noch da und dachte: „Ich sehe hier keine wirkliche Erklärung für den Bug.“
00:06:39Ich versuche herauszufinden, was der eigentliche Fehler war, aber es wurde einfach nie erklärt.
00:06:45Deshalb wollte ich das hier mal thematisieren – aufzeigen, warum ich finde, dass sie den Bug nicht
00:06:51erklärt haben, und das als Beispiel dafür nutzen, dass man nicht einfach sagen sollte: „Ah, okay, jetzt verstehe ich's.“
00:06:56Leute haben mir nämlich geantwortet: „Lass mich dir erklären, was der Fehler war.“ Und dann haben sie
00:07:01einfach dasselbe wiederholt. Dann sage ich: „Das ist nicht der Bug!“ Jeder fühlt sich
00:07:04dazu gedrängt zu sagen: „Ich versteh's, ich hab's ja gelesen.“ Aber nein: Wenn du mir nicht sagen kannst,
00:07:09was der eigentliche Bug war, dann sind wir hier noch nicht fertig. Wir brauchen eine fundierte Erklärung.
00:07:14Ergibt das alles Sinn? Versteht ihr, worauf ich hinaus will?
00:07:18Ja. Erstmal muss ich sagen: Ich wusste sofort, was du meinst, Casey. Von der ersten Sekunde an.
00:07:23Ich dachte direkt: „Okay, ich weiß ganz genau,
00:07:32wovon er spricht.“ Keine Fragen meinerseits, keine Blocker. Danke an alle, ich bin raus, wir sehen uns morgen.
00:07:39Kein Problem. Ich muss sagen, ich höre Casey im Podcast auf Spotify total gerne zu,
00:07:43aber auch gerade jetzt – ich könnte dir stundenlang zuhören. Kurzes Shout-out auch
00:07:47für Spotify. Ich wollte gerade sagen, wenn man auf Spotify hört,
00:07:52ist die Qualität unglaublich. Und man bekommt die Bonus-Inhalte, oder? Das ganze Geplänkel
00:07:59vorher und nachher. Wir posten jetzt längere Versionen auf Spotify, mit mehr Extras.
00:08:08Genau. Weniger Off-Topic-Kram, aber mehr Gequatsche auf Spotify, weil das Live-Publikum das
00:08:15Geplänkel ja auch mitbekommt. Die hören hier alles über Trashs
00:08:19Pokémon-Sucht, wovon ihr wahrscheinlich gar nichts wisst, wenn ihr das hier auf YouTube hört, oder?
00:08:23Da bekommt ihr die ganzen lustigen Sachen gar nicht mit. Das ist auch schwer zu verkaufen,
00:08:26wenn ein YouTube-Video so anfängt. Man kann schlecht sagen: „Schau dir mal an,
00:08:31wie vier Typen 10 Minuten lang über etwas reden, das ich nicht mal verstehe.“ Und es heißt DynamoDB. Yep.
00:08:36Wenn wir schon anfangen, sollten wir vielleicht Adam vorstellen. Oh ja, guter Punkt.
00:08:41Das haben wir völlig vergessen. Hallo! Erzähl uns doch mal kurz,
00:08:45warum du heute im Podcast bist. Weil ich bei TJ zu Hause bin, das ist der Hauptgrund.
00:08:50TJ verlangt von jedem, der ihn besucht, dass er im Podcast auftritt. Das war schon ein paar Mal echt schräg.
00:09:00Ja, absolut. Aber wer bist du wirklich? Außer ein AWS-Hero zu sein?
00:09:07Ich bin nicht mal mehr das. Ich war mal ein AWS-Hero. Ach was.
00:09:13Wirst du aus der Superhelden-Gruppe rausgeschmissen? Wie läuft das? Man wird einfach nicht verlängert.
00:09:18Ich war Hero für eine Amtszeit, und dann hieß es: „Tja...“ Muss man dafür bezahlen?
00:09:24Nein, nein, ich habe mich nur nicht mehr wirklich drum gekümmert. Habe nie drüber geredet.
00:09:28Also dachten sie wohl: „Vielleicht ist er kein Held mehr, sondern jetzt ein Schurke.“ Casey sieht aus,
00:09:34als wäre er Teil eines Krimis. Wie er da steht. Oh Mann, gleich kommt sowas wie...
00:09:39Wie heißt der Typ, der immer diese Zeichnungen am Board macht? Casey Muratori, genau den meinst du.
00:09:43Muratori. Heißt es Muratori oder Muratori? Oh Gott, du fängst jetzt mit Visualisierungen an, oder?
00:09:49Ich sag's ja, das ist der beste Podcast. Es ist wirklich der beste, bei dem man dabei sein kann.
00:09:54In meiner Familie wird es Muratori ausgesprochen, so als wäre da ein Y am Ende.
00:10:01Das ergibt eigentlich keinen Sinn, weil es ein italienischer Name ist. Auf Italienisch wäre es
00:10:06Muratori oder Muratori. Keine Ahnung, wie das „Mur“ da reinkam. Das war wohl so ein
00:10:13italo-amerikanisches Ding bei der Einwanderung. Schätze ich mal. Okay, also folgendes haben sie gesagt:
00:10:23Sie haben diese API-Endpunkte, so nennen sie die. Und das sind im Grunde
00:10:28Domain-Adressen. Wenn man im DNS nachschaut, ist das der Name, an den man seine
00:10:36DynamoDB-Anfragen sendet. Und diese Dinger sehen wohl so aus.
00:10:41Adam kann das sicher bestätigen, er ist (oder war) ja ein Hero.
00:10:47Sie sind ein bisschen im Verzug. Ja, wir hängen ein paar Sekunden hinterher, weil unser Video
00:10:53kurz weg war. Ah, jetzt geht's. Also, sie sehen so aus: dynamodb.us-east-1.api.aws
00:11:00oder so ähnlich. Und es hängt wohl davon ab, ob man IPv6 oder IPv4 nutzt. Sie haben
00:11:06unterschiedliche Namen je nach Fall, oder ob es zum Beispiel für Regierungsbehörden ist.
00:11:14Diese Namen sind also quasi im Programmcode fest hinterlegt. Wenn ich
00:11:19etwas mit DynamoDB machen will, frage ich das hier an. Ergibt das Sinn? Und stimmt das so,
00:11:24Adam? Ich selbst nutze ja kein AWS. Ja, genau so ist es.
00:11:28Man fragt also sowas an und wird dann weitergeleitet. Es gibt natürlich nicht
00:11:34die eine Maschine, die den gesamten DynamoDB-Traffic des Universums abwickelt.
00:11:38Selbst wenn man es nach Regionen unterteilt, wie man hier sieht, muss man eine Region wählen.
00:11:42Man schickt es nicht an eine Hauptadresse, sondern an eine regionale – oder vielleicht gibt es eine Hauptadresse,
00:11:53die das regelt. Keine Ahnung. Jedenfalls spricht man diesen Endpunkt an, und der muss
00:11:59auf ein Load-Balancing-System verweisen. Das Ganze soll auf einen sogenannten DNS-Baum zeigen,
00:12:04obwohl sie die Baumstruktur nie wirklich erklärt haben. Es klang eher wie ein
00:12:09gewichtetes Array, wenn man so will. Man hat einen Haufen Maschinen und wählt diese
00:12:13basierend auf Gewichten aus, um die Last zu verteilen. Wenn eine Maschine überlastet ist,
00:12:19wird ihr Gewicht gesenkt, und wenn sie Kapazitäten frei hat, wird es erhöht. Sie nannten es einen Baum,
00:12:27also nehme ich das mal so hin. Sie haben den Baum-Teil zwar nie erklärt, aber dieser Name soll darauf zeigen.
00:12:32Darf ich kurz unterbrechen? Übrigens hat jemand für diesen „Baum“ eine L6-Beförderung bekommen.
00:12:38Du solltest also beim nächsten Mal wirklich herausfinden, was dieser Baum ist, denn für jemanden war der extrem wichtig.
00:12:44Okay, da waren wohl Ingenieure am Werk. Ich gebe zu: Der Baum ist wahrscheinlich wichtig,
00:12:48nur eben nicht für diesen Bug. Daher finde ich es okay, dass sie nicht erklärt haben, was er genau macht.
00:12:53Aber ich habe auch noch eine kurze Frage. Ja?
00:13:00Heißt er „Baum“ wegen der „Wurzel“-Ursachenanalyse (Root Cause Analysis)?
00:13:05Keine Witze mehr, wir schweifen ab. Entschuldigung. Also, der Endpunkt soll darauf zeigen.
00:13:09Dieses Load-Balancing-Schema für DNS-Einträge haben sie in ihrer Präsentation
00:13:14so beschrieben: Nehmen wir an, es heißt „plan145.ddb.aws“. Das wäre dann
00:13:19die Wurzel dieses Baums – nicht die Fehlerwurzel, sondern der Startpunkt des Baums. Das wäre der
00:13:25Top-Level-Record für eine Reihe von Einträgen, die das Load Balancing ermöglichen.
00:13:29Ich vermute, Route 53 erledigt das. Das lese ich zwischen den Zeilen der Präsentation heraus.
00:13:37Sie haben es nicht explizit gesagt, aber ich nehme an, Route 53 (ihr eigener DNS-Dienst) ermöglicht dieses
00:13:46Load Balancing, indem man dort festlegt, wie die Last aktuell verteilt werden soll. Das System wählt dann
00:13:52die richtige Maschine basierend auf einer gewissen Zufälligkeit und den Gewichten aus. So weit, so gut.
00:14:02Was sie sagten: Dieser Name existiert wirklich, und es gibt wohl diesen Baum. Aber den Namen
00:14:07„plan145“ haben sie nur für die Präsentation benutzt. In Wirklichkeit verwendeten sie keinen
00:14:13lesbaren Namen für diesen Plan. Es war eigentlich ein Hash, also eher sowas wie
00:14:17„0afe129a“ oder so ähnlich. Wenn man also nachgeschaut hätte,
00:14:21hätte man keinen Namen wie „plan145“ gesehen, sondern nur diesen Hash. Die Idee war also:” Ein Nutzer
00:14:26will den Dienst nutzen, fragt diesen Namen an, und Route 53 leitet ihn hierher weiter. Das hier ist
00:14:31ein Load-Balancing-Baum in Route 53, der einen schließlich zur richtigen Maschine führt.
00:14:35Auch das wurde nicht genauer beschrieben. Ich habe keine Ahnung, wie das im Detail funktioniert,
00:14:41da ich Route 53 nie benutzt habe. Aber wir nehmen einfach mal an, dass es so läuft, denn für den Bug
00:14:48ist es egal. Wir haben ja einen AWS-Hero hier. Wenn ihr also verwirrt seid,
00:14:53fragt Adam, er hat sicher mehr Durchblick. Schieß los!
00:15:00Nun, Route 53 bietet viele Möglichkeiten, Traffic zu verteilen. Gewichtung ist eine davon,
00:15:05und das klingt genau nach dem, was sie beschrieben haben. Sie haben also diese Records so aufgesetzt.
00:15:09Sie haben nur nicht gesagt wie, aber irgendeine Baumstruktur hat das erledigt. Meine Vermutung ist,
00:15:15dass der Baum oben ein paar Gewichte hat, die sich dann weiter verzweigen,
00:15:22weil das bei großen Mengen einfacher zu handhaben ist. Wer weiß?
00:15:27Wie auch immer, der Punkt ist: So sollte es normalerweise laufen. Der Name „plan145“
00:15:32(auch wenn es eigentlich ein Hash war) rührt daher, dass das Load Balancing
00:15:38kontinuierlich angepasst werden muss. Die DynamoDB-Maschinen sind ja ständig in Betrieb,
00:15:41werden überlastet, stürzen ab oder was auch immer. Neue Kapazitäten kommen hinzu,
00:15:45andere gehen offline. Das muss also ständig aktualisiert werden. Der Haupt-API-Endpunkt,
00:15:50mit dem man sich verbindet, muss also immer auf einen aktualisierten Baum zeigen.
00:15:54Dazu erstellen sie einen neuen Baum, zu dem sie wechseln wollen – nennen wir ihn „plan146“.
00:15:57Sie bauen den kompletten Baum auf, und wenn er fertig ist, ändern sie den Verweis beim Haupt-Record:
00:16:02Statt auf den alten Plan zeigt er nun auf den neuen. Man erstellt also den neuen und schwenkt um,
00:16:07indem man einfach den Namen ändert. Aus Gründen, die nicht wirklich erklärt wurden,
00:16:11ist dieser Prozess in zwei Teile gesplittet. Es gibt den „Planner“, der quasi berechnet,
00:16:14wie der neue Baum aussehen soll. Stellt euch vor, da ist eine Maschine namens Planner –
00:16:20ob das eine physische Maschine ist oder nur ein Prozess, weiß ich nicht. Aber es gibt diesen Planner,
00:16:24und anscheinend gibt es nur einen davon. Er berechnet ständig den nächsten Plan,
00:16:31zu dem gewechselt werden soll. Er generiert also plan145, dann plan146, plan147 und so weiter.
00:16:38Er produziert Pläne bis in alle Ewigkeit, denn das ist sein Job. Aber er erstellt sie anscheinend nie selbst.
00:16:42Sein Job ist nicht, sie in Route 53 anzulegen, sondern nur zu berechnen, wie sie aussehen müssten.
00:16:49Dann gibt es drei „Enactor“. Diese Enactor holen sich den Plan vom Planner und übertragen ihn nach Route 53.
00:16:56Ergibt das Sinn? Ein Planner, drei Enactor. Warum das so ist, wurde nicht erklärt.
00:17:02Sie sagten, die drei Enactor dienen der Fehlertoleranz, falls einer mal ausfällt. Aber sie haben
00:17:09nicht erklärt, warum man dann nicht auch drei Planner braucht. Wenn der Planner ausfällt,
00:17:18haben die Enactor ja nichts mehr zu tun. Das ergab für mich keinen Sinn. Es gab keine Erklärung,
00:17:24warum die Architektur so aussieht. Für den Bug ist das zwar nicht direkt entscheidend,
00:17:28aber irgendwie dann doch, wie wir noch sehen werden. Mich hat es jedenfalls gewundert, dass sie das nicht begründet haben.
00:17:36Aber gut: Wir haben einen Planner und drei Enactor, die alle versuchen, den Plan umzusetzen.
00:17:44Aus Gründen, die in der Präsentation nur mit „macht es einfacher, das System zu verstehen“
00:17:50begründet wurden – das war die einzige Info dazu –, verwenden diese Enactor Serialisierung.
00:17:56Statt dass sie einfach versuchen, Records zu erstellen (und wenn sie schon da sind, passiert halt nichts),
00:18:00also: Drei Leute wollen denselben Top-Level-Record für plan146 erstellen. Einer ist der Erste,
00:18:06der Nächste sieht, dass er schon da ist, und fertig. Man könnte also drei Leute gleichzeitig
00:18:13an verschiedenen Teilen des Plans arbeiten lassen und theoretisch sollte alles klappen. Ich hatte
00:18:18sogar das Gefühl, dass der Sprecher mir da zustimmen würde – dass sie die Enactor
00:18:25einfach willkürlich hätten laufen lassen können. Aber er sagte, sie nutzen Serialisierung,
00:18:31um es „leichter nachvollziehbar“ zu machen. Das bedeutet: Statt dass die Enactor einfach wild
00:18:40drauflos arbeiten, versuchen sie, ein „Lock“ (eine Sperre) für den Endpunkt zu bekommen, den sie gerade
00:18:50aktualisieren wollen. Wenn also jemand einen dieser Records ändern will – ich hatte das Gefühl,
00:19:06es ging um diesen oder jenen Record, sie haben es nie ganz präzise gesagt, wo genau das Locking
00:19:11stattfand. Aber das Locking funktioniert so: Sie erstellen einen DNS-Record als Sperre.
00:19:18Dabei nutzen sie die atomaren Operationen von Route 53 aus. Sie haben also ein Locking-System
00:19:22gebaut, das DNS-Records als Sperren nutzt. Ergibt das Sinn? Darf ich kurz fragen?
00:19:28Du sagtest, das läuft über Serialisierung? Ich verstehe nicht ganz, was das hier bedeutet.
00:19:33Ich dachte, Serialisierung ist nur das Umwandeln von Datenstrukturen in ein anderes Format. Entschuldigung,
00:19:38falscher Begriff. Ja, das ist auch Serialisierung. Hier meine ich aber die zeitliche Serialisierung,
00:19:43also dass die Enactor ihr Verhalten in eine geordnete Reihenfolge bringen, statt willkürlich zu agieren.
00:19:50Und das machten sie über Locks. Was also passiert: Statt dass ein Enactor einfach umschwenkt
00:19:55auf plan146, versucht er zuerst, das Lock dafür zu bekommen. Wenn er es nicht bekommt,
00:20:04macht er keine Änderung. So kann immer nur ein Enactor zurzeit diesen Endpunkt aktualisieren.
00:20:11Verständlich? Wie gesagt, warum sie das für eine Verbesserung hielten, wurde nicht erklärt.
00:20:18„Einfacher zu verstehen“, hieß es nur. Und witzigerweise ist genau das der Punkt, der den Bug
00:20:26ans Licht bringt. Es war also keine Verbesserung, sondern eher schlecht. Aber Casey,
00:20:29du sagst also, sie haben keinen guten Grund dafür, dass die Enactor quasi nacheinander laufen?
00:20:36Warum haben sie dann überhaupt drei davon? Das verstehe ich nicht. Warum nicht einfach nur einen?
00:20:42Das sagen sie nicht. Wir wissen es nicht. Und sie haben auch nicht erklärt, wie das mit
00:20:48drei gleichzeitigen Enactoren funktioniert, wenn man erwartet, dass einer mal ausfallen kann.
00:20:52Aber sie nutzen ja ein Lock. Was passiert, wenn einer das Lock hat und dann abstürzt?
00:20:57Dazu gab es auch keine Erklärung. Das war alles sehr verwirrend für mich. Ich will mich nicht
00:21:01beschweren, weil es für die eigentliche Ursache nicht so wichtig ist, aber als Präsentation
00:21:08ließ es viele Fragen offen. Ich habe ehrlich gesagt nicht verstanden, warum sie das so gemacht haben.
00:21:15Vielleicht wäre es offensichtlich, wenn ich AWS-Dienste wie Route 53 täglich nutzen würde.
00:21:21Dann wüsste ich vielleicht: „Ah, das liegt daran, dass Locks ein Timeout haben können“ oder so.
00:21:28Jedenfalls machen sie das so. Und was dann passiert – und das ist der Auslöser für den Bug –
00:21:35ist folgendes: Wenn diese Enactor das Lock nicht bekommen, machen sie einen „Backoff“,
00:21:41sie warten also einfach eine Weile und versuchen es erneut. Ein Enactor will das Lock,
00:21:46jemand anderes hat es schon, also wartet er. Dann versucht er es wieder. Immer noch gesperrt.
00:21:56Und sie sagten, sie seien in einen „pathologischen Fall“ geraten, in dem ein Enactor
00:22:02einen Plan umsetzen wollte, der schon ziemlich alt war. Sie nannten Plan 110 als Beispiel.
00:22:08Er will also den API-Endpunkt auf Plan 110 umstellen, bekommt aber das Lock nicht,
00:22:15weil gerade jemand Plan 111 umsetzt (oder Plan 109 vorher). Die anderen Enactor sind also beschäftigt,
00:22:21er kommt nicht zum Zug und wartet. Er versucht es verzweifelt weiter mit Plan 110.
00:22:25Jedes Mal ist besetzt. Und währenddessen haut der Planner ständig neue Pläne raus. Die anderen
00:22:31Enactor sind schon bei Plan 145 oder 146, also weit vor Plan 110. Und unser Typ hängt immer noch
00:22:40fest, weil er einfach nie das Glück hat, das Lock zu ergattern. Bis er irgendwann –
00:22:48nachdem Plan 145 schon längst läuft – endlich das Lock bekommt. Und dann sagt er: „So,
00:22:55jetzt stellen wir alles auf Plan 110 um!“ Jetzt läuft das System also auf einem uralten Plan,
00:23:03aber das sollte ja eigentlich kein Riesenproblem sein. Denn sobald der nächste Enactor dran ist,
00:23:07wird er einen viel aktuelleren Plan (146, 147...) umsetzen und alles wieder auf den neuesten Stand bringen.
00:23:14Man hätte also für ein paar Minuten ein suboptimales Load Balancing, aber dann wäre alles wieder gut.
00:23:21Sie hatten aber für mehr als nur ein paar Minuten Probleme. Ja, richtig. Es war viel schlimmer.
00:23:28Das, was ich gerade beschrieben habe, wäre der Idealfall gewesen – so hätten sie es wohl auch erwartet.
00:23:32Das Problem ist: Sie wollten Route 53 nicht mit all diesen alten Records zumüllen. Sonst hätte man
00:23:38nach drei Monaten 8 Milliarden Einträge in Route 53, weil man ja alle paar Minuten diese riesigen
00:23:42Bäume mit Gewichten dort reinschreibt. Also sagten sie: „Wir müssen diese alten Pläne irgendwann löschen.“
00:23:47Die Enactor suchen also auch nach Plänen, die ein gewisses Alter überschritten haben, und löschen sie.
00:23:52Was also passierte: Unser Enactor bekommt endlich das Lock und stellt alles auf Plan 110 um.
00:23:56Ein anderer Enactor sieht das und denkt sich: „Wow, Plan 110? Das ist ja uralt. Weg damit!“ und löscht ihn.
00:24:02Jetzt zeigt der DynamoDB-Endpunkt auf einen Record, der gar nicht mehr existiert. Er ist nicht mehr auflösbar.
00:24:07Nochmal zur Erinnerung: Es hieß nicht wirklich „Plan 110“, sondern es war ein Hash wie „0afe129a.ddb.aws“.
00:24:13Aber der Endpunkt verwies nun auf diesen Namen, und wenn man den anfragte, kam nichts zurück.
00:24:18Jeder, der versuchte, einen Endpunkt für seine Daten zu finden, bekam einen nicht auflösbaren Namen.
00:24:25Ich weiß nicht genau, was Route 53 in so einem Fall zurückgibt – ob gar nichts oder irgendeinen Datensalat.
00:24:32Aber was auch immer es war: Wenn man versuchte, es zu nutzen, bekam man keine Antwort mehr. Interessant.
00:24:38Liegt das daran, dass AWS nicht genug Rust nutzt? Das klingt doch nach einem Use-after-free-Bug.
00:24:43Rust hätte das sicher gelöst, oder? Wenn man Route 53 komplett in Rust neu schreiben würde,
00:24:47wären all diese Probleme doch aus der Welt. Um genau zu sein, haben sie in der Präsentation
00:24:53gesagt (zwar nicht über Rust, aber über das Verhalten), was konkret passiert. Wenn man den Endpunkt
00:25:02anfragte, bekam man einfach die Meldung „No records found“. Das war das Endergebnis,
00:25:08egal welcher Teil der Kette angefragt wurde. „Keine Einträge gefunden.“ Das bekam man als Antwort,
00:25:14wenn man die API aufrufen wollte. Die DynamoDB-Library meldete dann einfach: „Sorry Kumpel, nichts gefunden.“
00:25:18Wenn man jetzt im Internet fragt, sagen alle: „Ja, sie haben den Bug erklärt! Das ist der Bug!“
00:25:24„Es gab diese Race Condition.“ Sobald die Leute das Wort „Race Condition“ hören, schaltet das Hirn ab.
00:25:29Sie denken: „Ah, okay, eine Race Condition. Alles klar, Fall erledigt.“ Aber nein, sie haben es eben nicht erklärt.
00:25:35Denn überlegt mal, was als Nächstes passieren müsste: Ein neuer Enactor kommt und setzt einen neuen Plan um,
00:25:43oder? Warum ist das nicht passiert? Das ist die eigentliche Ursache, die ich in der RCA sehen wollte:
00:25:51Warum hat der nächste Enactor den Fehler nicht korrigiert? Darf ich was einwerfen?
00:25:57Ist es nicht auch ein Bug, einen so alten Record überhaupt noch zu schreiben, dass er sofort gelöscht werden müsste?
00:26:02Nun ja, das passierte eben, weil der Typ den Plan schon vor langer Zeit erstellt hatte.
00:26:07Aber wenn du fragst, warum sie die Enactor nicht mit besserem Code geschrieben haben – ja, berechtigte Frage.
00:26:13Es wirkt doch so: Wenn man auf etwas aktualisiert, das sofort gelöscht werden sollte,
00:26:19dann liegt das Problem schon viel früher. Da ist doch schon vorher was schiefgelaufen. Absolut.
00:26:23Auch wenn es die grundlegende Struktur nicht heilt: Ein simpler Check im Enactor, nachdem er
00:26:28endlich das Lock bekommt, wäre sinnvoll gewesen. Er hätte prüfen können: „Soll ich hier gerade etwas setzen,
00:26:35das ich nach meinen eigenen Regeln sofort wieder löschen würde?“ Das wäre eine gute Sicherheitsmaßnahme.
00:26:44Aber der Enactor hat doch so hart für diesen Record gearbeitet! Er hat so lange gewartet. Gebt ihm doch die Chance.
00:26:49Wer hat nicht schon mal gewartet... Also, lasst ihn den Record schreiben! Okay, aber jetzt kommt's:
00:26:58In der Präsentation und in der RCA sucht man die Antwort auf das „Warum“ vergeblich. Aber in der
00:27:03Präsentation gibt es ein winziges 12-Sekunden-Segment, das andeutet, wo der eigentliche Bug liegt.
00:27:07Ich erkläre euch das mal: Parallel dazu passiert wohl noch etwas. Wenn man den DynamoDB-Endpunkt
00:27:12auf den neuen Plan umstellt, wird gleichzeitig eine zweite Operation ausgeführt: Es wird ein Rollback-Record gesetzt.
00:27:17Ich glaube, er hieß „ddb.rollback.aws“, ich weiß es nicht mehr genau. Dieser Record wird auf den
00:27:22vorherigen Plan gesetzt. Wenn wir also von Plan 145 auf Plan 110 umschwenken,
00:27:30versucht dieser alte Enactor, die Rollback-Adresse auf den bisherigen Plan (145) zu setzen. Das dient
00:27:36nur dem Debugging oder der Erleichterung für die Admins. Falls man zurückrollen will,
00:27:42kann man dort sehen, was der letzte Plan war. Das war der erste Punkt, der für mich keinen Sinn ergab.
00:27:49Ihr sagt mir, diese Pläne werden jede Minute aktualisiert? Was bringt dann dieser eine Record?
00:27:54Bis man sich überhaupt eingeloggt hat, wurde er doch schon längst wieder überschrieben –
00:28:00vielleicht sogar mit dem Plan, der gerade alles lahmgelegt hat. Das bringt doch nichts!
00:28:08Man bräuchte eine Liste dieser Namen, um sagen zu können: „Wie war der Stand um 12:30 Uhr? Den will ich!“
00:28:13Dieser Rollback-Record erschien mir völlig nutzlos. Er macht nicht das, was man eigentlich will,
00:28:19nämlich zu einem bestimmten Zeitpunkt zurückzukehren, weil danach alles schiefging. Aber gut,
00:28:29das war nicht der Bug an sich. Es war einfach nur eine Aufgabe, die das System erledigen musste.
00:28:34Du sagst also, er kann nur eine Version zurückgehen? Ja, obwohl die anderen Bäume ja noch existieren.
00:28:44Man müsste nur den Namen wissen. Das Ganze ist also nur ein lesbares Etikett für etwas,
00:28:46das einen fast sicher nicht interessiert. Aber Casey, vielleicht können sie nicht so viel speichern?
00:28:51Vielleicht fehlt da die Skalierbarkeit, Adam? Ich hätte einfach einen Zeitstempel genommen,
00:28:56wenn es das ist, was man will. Ich hätte festgehalten: „Wann wurde dieser Plan aktiviert?“
00:29:01In dem Moment, in dem man das Lock bekommt, setzt man den Namen auf den Zeitstempel und aktualisiert das
00:29:07ganz atomar. Dann weiß man: Wenn ich zurück auf den Stand von 13:00 Uhr will, suche ich einfach
00:29:10den letzten Zeitstempel vor dieser Uhrzeit. So hätte ich das gemacht. Aber ich kenne ihr System nicht.
00:29:15Vielleicht ergibt das alles in ihrem Kontext total Sinn. Ich will nicht sagen, dass es schlechte Ideen sind,
00:29:21vielleicht sind sie sogar gut, wenn man den Rest des Systems versteht. Aber jetzt kommt der entscheidende Punkt:
00:29:30Diese Operation – also das Setzen des Rollback-Records auf den alten Plan (der in manchen Fällen
00:29:35sogar neuer sein kann, es ist also nicht zwingend der zeitlich vorherige) – genau diese Tätigkeit
00:29:40führt dazu, dass der Enactor dauerhaft stoppt, wenn der Zielplan nicht mehr existiert (weil er gelöscht wurde).
00:29:44Sobald wir also in diesem Zustand sind: Der Endpunkt zeigt auf einen ungültigen Namen (Plan 110),
00:29:50der bereits gelöscht wurde und nicht mehr aufgelöst werden kann. In diesem Moment
00:29:55crasht jeder Enactor, der versucht, einen neuen Plan umzusetzen, sobald er den Rollback setzen will.
00:30:01Und da alle drei Enactor irgendwann versuchen werden, einen neuen Plan zu aktivieren, werden
00:30:11schließlich alle drei dauerhaft stoppen. Sie wollen den Rollback auf den „alten“ Plan setzen, finden diesen nicht,
00:30:16und das führt zu einem harten Crash. Wahnsinn. Ich dachte, die drei Enactor seien zur Redundanz da.
00:30:20Genau deshalb ärgere ich mich über die Leute online, die schreiben: „Es war eine Race Condition.“
00:30:24Nein, die Race Condition war für den Totalausfall gar nicht nötig! Sie war nur der Grund,
00:30:30warum der Name am Ende nicht mehr auflösbar war. Aber ohne diesen fehlerhaften Code
00:30:36hätte das System einfach weitergearbeitet. Man hätte es kaum bemerkt. DynamoDB wäre vielleicht für eine Minute
00:30:44weg gewesen, aber solche kurzen Aussetzer gibt es sicher ab und zu. Das landet nicht in den Weltnachrichten.
00:30:52In die Nachrichten kommt man, wenn das System dauerhaft down ist. Und bis ein Mensch
00:30:57das Problem findet, alles zurücksetzt und die Enactor neu startet, bleibt es auch down.
00:31:02Das kann Stunden dauern. Und das war hier wohl lang genug für Kaskadeneffekte. Ohne diesen Code-Bug
00:31:08wäre es nur ein winziger Schluckauf gewesen. Wenn Leute kurzzeitig keine Verbindung bekamen,
00:31:11hätten sie es einfach nochmal versucht – wie wenn man mit dem Handy durch einen Tunnel fährt.
00:31:17Ich will wissen: Wie sah dieser Code aus? Wie kann man etwas so schreiben,
00:31:21dass ein ungültiger Name zum Absturz führt? Sogar beim Systemstart, wenn noch nichts vorkonfiguriert ist,
00:31:26würde der Endpunkt auf nichts zeigen. Das ist doch der Standardfall, den man abfangen muss!
00:31:30Wenn man das so baut, muss man damit rechnen, dass die Rollback-Adresse auch mal leer sein kann.
00:31:36Dann setzt man sie halt auf „nichts“ und fertig. Da ist also etwas extrem Seltsames im Code passiert.
00:31:41Und genau das hätte in die RCA gehört! Das ist für mich der eigentliche Bug. Die Race Condition
00:31:49ist nur das Drumherum, wie es dazu kam, dass der Verweis im Leeren landete. Dasselbe wäre passiert,
00:31:56wenn ein Admin versehentlich einen Record gelöscht hätte. „Hoppla, jetzt zeigt es auf nichts.“
00:32:03Laut der Präsentation hätte das denselben fatalen Fehler ausgelöst. Die Ursache ist also nicht die
00:32:13Race Condition, die ist nur Nebensache. Versteht ihr? Kurze Frage: Ich denke gerade darüber nach.
00:32:22Das heißt, der Teil, der den Rollback setzt, erwartet wohl ein Objekt oder einen Speicherbereich,
00:32:30der übergeben wurde, greift darauf zu und – bumm. Oder ist es derselbe Fehler wie
00:32:40damals bei Cloudflare? Dass sie einfach annehmen, dass etwas da ist, und es „unwrappen“?
00:32:49Vielleicht in Rust? Memory-safe Rust, aber man macht ein „unwrap“ und alles explodiert.
00:32:57Ich weiß es wirklich nicht. Ich habe mich gefragt: Was machen Leute oft beim Programmieren,
00:33:03wo ich mich immer frage, warum sie das tun? Meistens, weil sie es so gelernt haben. In Sprachen,
00:33:13die gerne Exceptions für Fehlerzustände werfen, wäre das ein klassisches Beispiel. Man will
00:33:18den DNS-Record holen, auf den der Endpunkt zeigt. In einer vernünftigen Umgebung
00:33:24würde man da keine Exception werfen. Wenn nichts da ist, bekommt man eben „null“ oder „nichts“ zurück.” Und wenn
00:33:29man dann den Rollback-Record setzt, setzt man ihn eben auch auf „nichts“. Das wäre der korrekte Fluss.
00:33:35Wenn man einen so kritischen Basisdienst schreibt, den man fehlertolerant haben will,
00:33:40dann wirft man doch an so einer Stelle keine Exception! Meine Vermutung ist also:
00:33:45Irgendeine Library wirft eine Exception, wenn ein Record nicht existiert, und der Enactor
00:33:53war damit erledigt. Das ist mein Tipp, aber natürlich nur wild geraten. Aber genau deshalb
00:33:59will ich ja die RCA sehen! Was war es wirklich? Es könnte das sein, was Trash meinte,
00:34:04oder was Prime sagte, oder eben meine Vermutung. Aber das ist es, was wir lernen wollen!
00:34:10Die Race Condition zu vermeiden, ist fast nebensächlich. Die hätte da bleiben können, und man hätte sie
00:34:16irgendwann gefixt, um diesen 5-Sekunden-Ausfall pro Jahr zu vermeiden. Aber die echte Lektion ist:
00:34:21Schreib diesen einen Teil nicht so fehleranfällig! Aber wir wissen ja nicht mal, was „dieser Teil“ war.
00:34:26Deshalb war die RCA schlecht. Macht das Sinn? Absolut. In was ist AWS eigentlich hauptsächlich geschrieben, Adam?
00:34:31In Java. Jemand im Chat sagte gerade Scala. Er meinte, er hätte sieben Jahre bei AWS gearbeitet
00:34:36und das meiste sei in Scala. Nun ja, das ist technisch gesehen Java mit Umwegen.
00:34:42Das wird die Scala-Leute jetzt endlos ärgern. Das war's eigentlich von meiner Seite.
00:34:48Ich hatte einfach das Gefühl, dass die eigentliche Erklärung fehlte. Und ich finde es wichtig,
00:34:54weil da irgendwo eine schlechte Programmierpraxis dahintersteckt. Ich will wissen, was es war.
00:34:57Besonders weil ich zwar aktuell wenig Architektur-Schulungen mache, das aber später mal wieder vorhabe,
00:35:04weil da draußen so viel schlechte Architektur existiert. Deshalb achte ich auf solche Dinge:
00:35:09Welche architektonischen Fehler machen die Leute? Und ich wette, das hier war einer davon. Ich
00:35:15würde es gerne wissen. Ich hätte zumindest ein simples, reproduzierbares Beispiel erwartet,
00:35:20warum das Ganze hochgegangen ist – einen kleinen Codeschnipsel. Das ist ja das,
00:35:28was du vorhin meintest: Wie gehen wir an sowas ran? Wenn ich Code reviewe
00:35:32und da sieht was komisch aus, versuche ich immer, das in einer Sandbox zu beweisen.
00:35:36Ich zeige den Leuten dann: „Hier, genau deshalb ist das vermutlich falsch.“ Mit einfachen Schritten.
00:35:40Sowas hätte ich hier auch erwartet. Das hilft beim echten Verständnis. Viele Leute sehen
00:35:45zwar, dass was nicht stimmt, wissen aber nicht warum. Aber man darf da nicht aufhören,
00:35:50man muss es nachbauen und verstehen. Das ist meine Erwartung. Die Ausfälle bei CrowdStrike
00:35:59und Google waren da besser erklärt. Die sagten klipp und klar: „Hier gab es einen Nullpointer-Fehler“
00:36:03oder „Hier gab es einen Array-Überlauf, weil wir mit 20 gerechnet, aber 21 eingetragen haben“.
00:36:11Da weiß ich genau, welche Art von Code das Problem verursacht hat. Und um noch
00:36:18auf den Kommentar von vorhin zurückzukommen: Soweit ich weiß, programmieren alle nur deshalb in Rust,
00:36:26damit sie bei solchen Gelegenheiten sagen können: „Mit Rust wäre das nicht passiert.“
00:36:31Aber hier gab es ja nicht mal genug Informationen für diesen Kommentar! Sie haben ihn wahrscheinlich
00:36:36trotzdem gemacht, aber die Faktenbasis fehlte. Eine Regel für RCAs sollte lauten: Man muss den
00:36:41Rust-Fans genug Infos geben, damit sie fundiert behaupten können, Rust hätte es verhindert.
00:36:50Aber das haben wir hier nicht. Wir wissen nicht, ob Rust geholfen hätte. Keine Ahnung.
00:36:58Wahrscheinlich nicht, aber wir wissen es eben nicht. Naja Casey, die Chancen stehen gut,
00:37:06dass es nie so ausgeliefert worden wäre. Also hätte es den Fehler verhindert. Stimmt.
00:37:11Wir hätten gar keine Enactor, weil wir noch am Design der Enactor säßen. Cloudflare macht
00:37:16das übrigens auch sehr gut. Die zeigen viele Zeilen Code und erklären genau: „Das hier passiert gerade.
00:37:24Auch wenn das Problem eigentlich dort oben liegt, ist hier die Zeile, die aufgrund der Vorbedingungen explodiert ist.“
00:37:32Das war meine Anspielung auf Rust mit dem „unwrap“, was ja eigentlich nicht das echte Problem war.
00:37:36Aber solche Dinge passieren eben. Die machen einen tollen Job. Ich bin überrascht, wie schwach AWS hier war.
00:37:44Es ist auch so eine Sache, die einen unnötig misstrauisch macht. Wenn ich das lese,
00:37:52frage ich mich: „Versteckt ihr was? Habt ihr den Bug gar nicht wirklich gefunden?“ Ihr redet
00:37:57ewig über diese Race Condition, aber sogar nach eurer eigenen Präsentation war die gar nicht so wichtig.
00:38:04Sie war nur der Auslöser dafür, dass der Record auf „nichts“ stand. Aber wen kümmert's? Das ist
00:38:09eine nette Randnotiz in einer RCA, um zu erklären, warum es gerade jetzt passiert ist, aber
00:38:15es ist nicht der eigentliche Bug. Wenn eine RCA den eigentlichen Bug nicht benennt, werde ich stutzig.
00:38:21Völlig unnötigerweise vielleicht – denn wenn ihr ihn gefunden habt, dann sagt es mir doch einfach!
00:38:26Dann weiß ich, dass ihr es im Griff habt. Das schafft Vertrauen bei den Kunden, die wissen wollen:
00:38:32„Kann ich diesem DynamoDB-Ding vertrauen?“ Wenn es so aussieht, als hättet ihr den Fehler gefunden, habe ich mehr
00:38:37Vertrauen. Wenn es so aussieht, als hättet ihr keine Ahnung oder hättet ihn nicht verstanden,
00:38:45dann mache ich mir Sorgen. Das ist ein weiterer Grund, warum eine RCA gut sein muss.
00:38:50Sie gibt den Kunden Sicherheit. Vielleicht wurde Adam deshalb als AWS-Hero gefeuert.
00:38:55Vielleicht hängt das alles zusammen. Er wusste zu viel. Er wusste definitiv zu viel.
00:39:01Könntest du kurz – so in drei Minuten – die Story mit dem Gitarrenladen zusammenfassen?
00:39:07Was kam da raus? Ich versuche mich zu erinnern, da ging es doch um diesen Typen,
00:39:12der ein „Single Point of Failure“ war und auch bei diesem Ausfall seine Finger im Spiel hatte. Wie passt das zusammen?
00:39:18Wir wissen es natürlich nicht. Wir wissen nicht mal, ob uns überhaupt jemand die Wahrheit sagt.
00:39:25Weil diese RCA so schlecht war, habe ich keine Ahnung, was stimmt. Aber ja, das Passwort war „wishbone12“, glaube ich.
00:39:31Da haben wir's. Will mich immer umbringen. So habe ich es jedenfalls in Erinnerung.
00:39:35Die Geschichte war so: Es gab ein Tool, das Konfigurationen kopieren sollte.
00:39:40Und dieses Ding war irgendwie außer Kontrolle geraten und ließ sich nicht mehr stoppen. Es kopierte
00:39:46Konfigurationen völlig fehlerhaft und musste repariert werden. Mehr Informationen haben wir nicht,
00:39:51weil es ja nur ein belauschtes Gespräch war. Passt das zu der jetzigen Story? Ein bisschen,
00:39:56denn diese Enactor klingen schon nach etwas, das Konfigurationen kopiert. Aber andererseits
00:40:03ist ein DNS-Eintrag nicht wirklich eine Maschinenkonfiguration. Die beiden Geschichten passen
00:40:07also nicht perfekt zusammen. Auch deshalb hatte ich gehofft, die offizielle RCA wäre glaubwürdiger,
00:40:12damit ich sicher sein kann, dass die Pub-Story falsch war. Aber nach dieser RCA weiß ich es immer noch nicht.
00:40:19Was, wenn das Tool, das der Typ zum Kopieren der Configs schrieb, einfach der Enactor ist?
00:40:24Vielleicht haben sie es einfach eins zu eins übernommen und seit sieben Jahren nicht angefasst.
00:40:28Das war mein Gedanke beim Verbinden der Punkte. Der Typ dachte sich: „Leute,
00:40:34das war nur ein Test-Skript für meine lokale Umgebung! Und ihr macht daraus drei Enactor für die Produktion?“
00:40:40Keine Ahnung, wie das passieren konnte. Ich hätte da noch andere Vermutungen. Oder war es der Rollback?
00:40:45Der hat ja quasi kopiert: „Hier ist der vorherige Stand.“ Und beim Kopieren
00:40:51passiert dieser Null-Fehler, und das Skript dreht völlig hohl und schreibt immer und immer wieder,
00:40:56bis gar nichts mehr geht. Ich weiß es nicht. Ich weiß nur:
00:41:03Nach ihrer eigenen Erklärung halte ich die Race Condition für irrelevant. Denn
00:41:08schon eine einzige versehentliche Änderung am Route-53-Endpunkt hätte alle drei Enactor sofort
00:41:11lahmgelegt. Laut ihrer Aussage reicht es völlig aus, dass der Endpunkt auf einen nicht auflösbaren Namen zeigt.
00:41:16Wenn das wirklich stimmt, hätte ein simpler Tippfehler eines Admins das Ganze ausgelöst –
00:41:20ganz ohne Race Condition. Deshalb überzeugt mich die RCA auch nicht davon, dass sie über den echten
00:41:25Bug gesprochen haben. Es gibt so viele Wege, genau diesen Zustand auszulösen, die nichts mit
00:41:31dieser Race Condition zu tun haben, auf der sie die ganze Zeit herumgeritten sind. Ich glaube nicht, dass sie es war.
00:41:34Danke, Casey, für diese großartige Präsentation. Ich bin wirklich grün vor Neid,
00:41:38was dein Schreibwerkzeug da angeht. Ich muss herausfinden, wie ich so ein Setup kriege. Das Teil ist fantastisch.
00:41:43Vielen Dank fürs Zuschauen. Für alle, die live dabei waren: Ich hoffe,
00:41:48euch hat das Geplänkel vorher und nachher gefallen. Wenn ihr die Langfassung und all die lustigen
00:41:56Interaktionen hören wollt, die nicht zur Hauptstory gehören: Geht zu Spotify für den vollen Podcast.
00:42:00Da quatschen wir dann drüber, was Trash gerade isst, über Snacks und noch mehr Gequatsche.
00:42:04Wieder mal Casey, TJ und Trash. Fehler auf meinem Schirm, Terminal, Kaffee und ein Traum wird wahr.
00:42:11It was Java. I was about to say someone from the chat said Scala. They said they worked at
00:42:16AWS for seven years and they said most of it's written in Scala. Well, that's technically Java
00:42:21with extra steps. And that will anger all of them endlessly. So that's really it for me.
00:42:34This was a thing where I was like, I don't feel like I saw the explanation. And I actually feel
00:42:38like it's important to hear because there was a bad programming practice at the bottom of this
00:42:42summer. And I want to know what it was, especially because it helps people like me when I, you know,
00:42:46I don't really do a lot of architecture education right now, but at some point I probably would like
00:42:51to do some of that because I think there's a lot of bad architecture out there. And so I kind of
00:42:56try to pay attention to these things. Like what are the kinds of architectural mistakes that people are
00:42:59making? And I bet this was one of them. Right. And so I'd like to know. I'd like to know.
00:43:04Yeah. I think like what I would expect is like at least like one simple reproducible example of like
00:43:10why I blew up like a whole like little code snippet. So like, and this is something you
00:43:16brought up earlier is like kind of like how we approach these type of things. Like if I'm like
00:43:18reviewing someone's code and I see something that looks weird, I will always do my best to make my
00:43:23own little sandbox and like prove my theory out. And then like actually show them the code of like,
00:43:29this is why this is probably wrong. Here's like a small, simple reproducible step. So I would expect
00:43:33something like that. And that also helps me like truly understand. Cause a lot of people, like you
00:43:37said, they'll see something like that looks funny, but I don't know why it looks funny, but I can't
00:43:43stop there. I gotta like actually like build it out and then like understand. So that's what I would
00:43:48expect. And you know, like, like I said, the crowd strike and the Google outages, I thought were better
00:43:55like just telling you that they were like, look, it was a null pointer, D ref in here, or it was an
00:43:59out of bounds array because we thought there was only going to be 20 and we put 21 in the
00:44:03config file. Right. And like, okay, I know exactly what kind of code that, you know,
00:44:08is causing that kind of problem. Right. And furthermore, furthermore, to like an earlier
00:44:14comment, literally, as far as I know, everyone who programs in Rust only does it so that occasionally
00:44:21when they see something like this, they can say, well, if they'd had written in Rust,
00:44:24it wouldn't have happened. They were not given enough information to even make that comment.
00:44:29They probably made it anyway, to be fair, but they were not given it. So you have to give
00:44:34one rule that should be followed in RCAs is you have to give Rustations enough information to,
00:44:41if they so chose, correctly say that it would have been prevented in Rust.
00:44:46And this, we do not have that. We do not know whether this would have been prevented in Rust.
00:44:51We have no idea. It probably wouldn't have, but we don't know. Well, Casey, we do have a pretty
00:44:58good chance because it's like, probably would have never shipped. So it would have prevented it.
00:45:03True. We would have zero enactors because we would be designing set enactors. Yeah.
00:45:09CloudFlare does a really good job at this as well. They like go in and show like a lot of lines of
00:45:17code and say like, this is exactly what's going on. This is, you know, even though the problems up here,
00:45:21this is the line that exploded due to all these previous conditions. That was me making fun of
00:45:24Rust with the unwrap, which actually wasn't truly the problem. Uh, but you know, it's just like all
00:45:28these things kind of happen. So they, they do a really good job. I'm surprised at how poor of a job
00:45:33AWS has done for this one. Well, and the other thing too, is it, it was one of those things
00:45:39where it now it makes me, so it makes me unnecessarily suspicious of you, right?
00:45:44When I read this, I'm like, are you hiding something? Did you not really figure out what
00:45:48the bug was? Like you talked all about this race condition, but even from your own presentation,
00:45:52I can tell the race condition really wasn't important. That was just, that was just what
00:45:56led to the record having been set to nothing, but who cares, right? Like that's, that's like
00:46:00something that's nice to put in the RCA as like an explanation of why this bug occurred now,
00:46:05as opposed to some other time, but it's not the bug. So it's weird to me. Like when I see an RCA
00:46:10that doesn't talk about the bug now I'm suspicious. Right. And unnecessarily so, because if you actually
00:46:15did find it, then just tell me, and now I know you found it. Right. So it's like, I think it also is a
00:46:19confidence boost for the people who are looking from the outside who want to know, can they trust
00:46:24this DynamoDB thing? If it looks like you actually found the bug, I have a little more confidence in
00:46:28you. If it looks like you have no idea what the bug was, or don't seem to understand what the bug was,
00:46:33then I'm, that I'm more concerned. And so I think that's also another reason to do this in your RCA.
00:46:37It, it provides confidence to your customers. Maybe that's where they fired Adam as an AWS hero too.
00:46:43Maybe it's all connected. Could be. They didn't want him exposing these dirty secrets.
00:46:48Yeah. He knew too much. He knew too much. Could you give a, could you give a quick,
00:46:53like three minutes summary of the guitar shop? Like what that, what that was revealing? Because I'm
00:47:00trying to remember what it was because it involved like a single point of failure guy who was out here
00:47:05for this failure as well. So I don't know how to reconcile the two things. And of course we have no
00:47:10idea. We have no idea if either are telling us the truth now, right? Because this was such a bad RCA,
00:47:16I have no idea if it's correct or not, but yes, the password was wishbone 12, I think.
00:47:22There you go. Always try to kill me. That's my recollection anyway.
00:47:26So yeah, that story was that, that there was the, there was a thing that was designed to
00:47:34copy configurations. And that thing had kind of gone rogue and could not be stopped. Like it was
00:47:42just like, it was just copying configurations totally incorrectly and it needed to be like fixed
00:47:47or repaired or something. And we don't have any more information because it was an overheard
00:47:53conversation. Right. And so does that comport with this? Well, a little bit, cause those enactors do
00:48:00sound like the kind of thing that would be running a configuration copy, but on the other hand,
00:48:05it's not really a configuration for machines. It like a DNS entry is a DNS entry. It's not,
00:48:10it's not really a configuration. So I would say the two stories don't line up that well.
00:48:14And so that's another reason why I was kind of hoping that this RCA was a little bit more
00:48:19believable because I wanted to know for sure that the story was false. And I still don't really know
00:48:24based on how bad this RCA. What if, what if the tool that the guy wrote to copy the configs is
00:48:31just literally the enactor? Like they just productionized it and he, and like they haven't
00:48:35changed it in seven years. That was kind of my connecting the dots. There was, he's like, guys,
00:48:42I wrote that as a way for me to test stuff in my local environment. And you just decided to make
00:48:48three enactors and put them next to each other and prod. I don't, how did this happen? I do.
00:48:53I have alternative questions. Yeah. Alternatively, is it the rollback? Because that's the one that
00:48:57did the copying of like, Hey, here's the previous one. Right. And so I'm going to copy the previous
00:49:02one. Then it gets like this null issue going on. And it just like the script never encountered
00:49:07or knowledge just goes rogue and starts writing over and over and over and over again to where you
00:49:11can't, you can't do anything. I don't know. All I know is that like, as far as I can tell from
00:49:19their explanation, going only on what they were providing, I still just don't think the race
00:49:24conditions even relevant because again, literally an accidental update to the route 53 endpoint
00:49:31would have taken down all three and actors immediately. Cause according to them,
00:49:35all that's required to stop them is if the, if the endpoint points at an unresolvable name,
00:49:41that's all you need. And so if that's really true, literally an operator typo could have taken all
00:49:47this down, no race condition necessary. Right. And so again, the RCA just does not do a good job
00:49:52convincing me that you've talked about what the real bug was, because I can think of so many ways
00:49:57that you could have triggered this exact same thing that don't involve this race condition that you
00:50:00spent the entire RCA telling me was the bug, but I don't think it is. So thank you, Casey, for giving
00:50:06us that amazing presentation. I am actually genuinely Greenwood, jealous rage for whatever
00:50:10that writing instrument is. I got to figure out how to set up what you have. That thing is fantastic.
00:50:15Thank you everybody for watching. I, uh, for those that caught it live, I hope you enjoyed
00:50:18the pre banter and probably a little bit of the post banter. If you wish to hear the extended and
00:50:22all the kind of fun interactions, that's not a part of the main story, head on over to Spotify
00:50:27for the full podcast, which is just us yapping about, I don't know what trash is eating and
00:50:31snacks and such the name more yapping, more yapping again, and also Casey TJ and trash.
00:50:42Errors on my screen, terminal coffee and living the dream.