Am 1. August 2012 begann die Wall Street ihren normalen Handelswahnsinn, wie ein Unternehmen innerhalb von 45 Minuten $440000000. Durch einen Softwarefehler verlor, das erfährst du in dieser Folge Coding Body, Deinem Podcast rund um Softwareentwicklung und aktueller Technews herzlich willkommen. Herzlich Willkommen zur neuen Folge des Goating Body Podcasts. Schön, dass du wieder eingeschaltet hast, dass wir alle wieder zusammen sind.
Zum einen meine Wenigkeit, Tino und natürlich auch der fantastische Fabi wieder an meiner Seite fabi Grüße dich halli Hallo Tino, Wie geht es dir? Was geht ab? Alles gut bei dir? Ja, ich bin n bisschen müde, weil, also was heißt müde eigentlich bin ich glaub ich nicht müde, aber ich wurde heute echt mies geweckt. Also von was?
Irgendwann heut morgen. Ich weiß auch nicht, weißt du, wenn du so aufwächst mit dem Geräusch von einer Flex oder so von um 7 an und ich bin ungefähr 07:30 Uhr oder so aufgestanden und von um 7 bis 07:30 Uhr denkst du ich will noch schlafen, ich will noch schlafen. Und die ganze Zeit immer in so einem Rhythmus.
Hat irgendjemand dreimal irgendwo draufgehämmert und ich dachte mir, sowas machen die da, lasst mich, das war die eiskalte Realität, die gesagt hat, du musst jetzt langsam wirklich mal aufstehen, wahrscheinlich gibt es jetzt auch ein paar Zuhörer, die sich denken, was halbakt. Aber zu Deiner Verteidigung ist es auch so meine Zeit. Es mag vielleicht daran geschuldet sein, dass wir zusammenarbeiten und so einen
ähnlichen Tagesablauf haben. Ja, aber so eine Flex ist natürlich, wie sagt man super nervig, denn am Morgen ist eine schöne Sache. Ich hatte war nicht heute, aber die Woche. Einfach ein ständiges Klingeln, weil die die Anlage getestet wurde, weil beim Nachbarn die Klingel nicht funktioniert. Und da hat es einfach im Haus ständig geklingelt und auch meine Klingel, quasi weil alle durchgetestet wurden. Da denkst du dir so Leute nicht cool waren. Wirklich nicht cool.
Das war um 7 oder so. Ja kannst du die nicht so ausschalten? Manche kann man ja irgendwie ausschalten, aber ja ich hab sie einfach von der Wand gerissen, sehr gut und hab gesagt wenn du schon mal da bist, kannst du ja später reparieren, meine ist übrigens kaputt. Nein, na gut, OK, das war natürlich nur Spaß, es wurde geklärt und ich war dann auch so eine halbe Stunde später nicht mehr angepisst. Also nach dem Kaffee ging es dann. Tino hat jetzt immer noch tinitus. Genau.
Tino ist auch ständig klingeln. Wow, Fabi, wo kann der denn, Herr Igor? OK, kommen wir mal zum Thema, Wir haben heute wieder was ganz Besonderes vor beziehungsweise wollen wir eine neue Podcast folgen Reihe fortführen die wir angefangen hatten und ich hab extrem Bock auf diese Folge, weil ich das Thema sehr spannend war oder spannend fand so rum und mich sehr gerne da ein bisschen eingelesen habe weil es echt doch ein super geiles Beispiel ist.
Und zwar geht es um unsere Big Fails in der Softwareentwicklungsreihe. Und haben da wieder einen ganz coolen Fall aus dem Jahre 2012. Also es ist noch gar nicht so lange her mitgebracht. Nichts. Wir sind doch mittlerweile im Alter, wo man sagen kann, dass da nichts quasi gestern. Gewesen ist. Genau. Und was da passiert ist, worum es geht, das wollen wir heute mal ein bisschen beleuchten und vor allem auch mal Schlüsse daraus ziehen.
Man soll ja auch ein bisschen was mitnehmen, wo, was man daraus lernen kann. Mhm. Und zwar möchte ich das ganze kurz mal einleiten, es sei denn du sagst jetzt, nee, lass das nicht machen, da brauchen wir jetzt ganz schnell n ersatzthema, aber ansonsten würd ich jetzt mal einleiten und zwar letztes Mal. Hatten wir quasi so um über Raketenstarts gesprochen, im Speziellen um die Ariane 5 über den Fehlstart und wie es dazu
kam. Und dieses Mal möchte ich gerne mit dir in einen anderen Sektor gehen und zwar in den Finanzsektor, quasi in den Finanzdienstleistungsbereich auch. Und zwar geht es dabei um einen sehr berühmten Fall, und zwar um das Unternehmen Nightcapital, damals noch, später dann die Night Capital Group. Warum es eine Group wurde und Investoren reingekommen sind,
das werden wir beleuchten. Und zwar um den Fall, dass die Nightcapital innerhalb von 45 Minuten 440000000 roundabout Dollar verloren hat und Pleitegegangen ist, obwohl es ja eigentlich ein sehr anerkanntes, renommiertes Finanzdienstleistungsunternehmen war. Und warum da ein Softwarefehler Schuld war und der auch in die Geschichte einging als Nightcapital Group Trading Glitch. Das möchte ich gerne mit dir
beleuchten. Heute unbedingt Tino unbedingt und ich glaube, du hast das sogar noch ein bisschen untertrieben, weil die Nightcapital war wirklich. Um das noch mal weiter einzuordnen, eines der führenden Unternehmen im Bereich von einem elektronischen Börsenhandel, auch gerade im Bereich High Frequency Trading sozusagen. Das also dieses Unternehmen hat ungefähr ab bis zu diesem Zeitpunkt ungefähr 20 Jahre einfach die Branche dominiert, was ja wirklich schon also ordentlich ist.
Also. Auch mit ihren Softwarelösungen. Genau, auch mit den Softwarelösungen alles drum und dran, ganz genau. Und da wurden halt Tausende von Transaktionen für verschiedenste und sehr viele Klienten in kürzester Zeit ausgeführt. Also ich weiß nicht, ob das jetzt zum Beispiel jemand eine Zuhörerinnen und Zuhörer kennt, der vielleicht ein bisschen im Thema drin steckt, aber zum Beispiel Vanguard war auch Kunde bei der Nightcapital. Kennt man vielleicht von einem ETF oder woher auch immer.
Also nur mal als kleines Side Note und da wurden halt tradingvolumen von 20 Milliarden Dollar täglich umgesetzt und das ist schon sage ich mal eine Größenordnung, mit der nicht zu sparen. Ist ja so 1 größer von Peanuts quasi. Wie war das 1? Viel 1 Scheiß viel genau. Nein, das ist halt natürlich ne abnormal hohe Summe, also n riesenvolumen halt ne. Was ich aber eigentlich noch sagen wollte, noch ganz kurz, weil mir das auch nicht so klar war.
Also ich nightcapital war mir n Begriff, aber zum Beispiel, dass sie auch. Sehr großer Market Maker waren oder Marktmacher auf Deutsch. Ich find das klingt nur auf Deutsch noch schlimmer als schon auf Englisch. Um mal quasi diese Auswirkung von diesem Unternehmen.
Aufzuzeigen als Market Maker sorgst du ja im Prinzip für die Liquidität am Markt, das heißt, es werden halt super oft und schnell Kauf und Verkaufsorder gestellt, um einfach quasi Geld in den Markt zu spülen, um Liquidität zu schaffen und dafür waren sie halt ein Riesenunternehmen und hatten damit, ich glaube ja zum Beispiel an der New Yorker Börse, glaube ich, einen Anteil von über 10% oder so, das ist
halt krank viel. Und dementsprechend auch eine hohe Auswirkung auf den Markt, je nachdem wie sie agieren. Und das fand ich halt wirklich erstaunlich, dass noch mal so vor Augen geführt zu bekommen und dieses High Frequency Trading, was du angesprochen hattest, wofür sie ja am Ende
ihre Software lösen. Gebaut haben und Marktführer waren ist ja auch ne ne absolut krasse Sache, wenn man so drüber nachdenkt, also das auch profitabel zu gestalten, ne, dass du halt sagst, ich mach halt in, also in so einen kleinen Zeitabschnitt kaufe und verkaufe ich, dass ich die kleinsten Marktschwankungen für mich nutzen kann und mit diesem großen Volumen was sie hatten halt auch wirklich große Profite abschöpfen können damit, und das fand ich halt auch wirklich sehr
erstaunlich, muss ich sagen und zeigt halt auch was für ein schmaler Grat das ist und wie. Soll ich sagen, wie gut diese Software dahinter sein muss, dass das sich auch rechnet und du nicht einfach sagst so Software legt los und es wird da automatisiert gehandelt und du bist halt sag ich mal innerhalb von kürzester Zeit pleite. Oh Moment mal. Genau das ist am Ende ja auch passiert. Und das würde ich nämlich gerne mal jetzt anreißen, was?
Ist eigentlich geschehen. Und warum ist der Erste? August 2012 hat ja schon gesagt, im Jahre 2012 ist das passiert.
So in die Geschichte eingegangen und zwar erzähl mir mal, wie das gewesen wäre, wenn ich live dabei gewesen wäre als Außenstehender. Also man kann sich das so vorstellen, es waren ganz normaler regulärer Handelstag, weil ich dachte mir halt so, naja, vielleicht war es irgendwie ein besonderer Tag oder irgendwas ist in der Welt passiert, aber es war einfach ein ganz normaler regulärer Handelstag, das heißt, die Börse öffnet, ich weiß nicht 9. Uhr. Ich handle nicht an der New
Yorker Börse. Und kurz nach Marktöffnung, wo quasi die Systeme dann gestartet sind. Die Softwarelösungen der Nightcapital sind halt komische Anomalien aufgetreten, das heißt, die Mitarbeiter dachten sich so, irgendwie verhält sich unsere Software komisch, was passiert denn hier sind irgendwie so unkontrollierte Handelsaktivitäten gewesen und die sind halt ins Unermessliche gestiegen, dass Tausende Handelsaufträge fehlerhaft
gestellt wurden. Boden und man so innerhalb von diesen 45 Minuten wirklich die 440000000 US Dollar verloren hatte, was im Prinzip mehr war als die Rücklagen die sie hatten. Und man quasi pleite war nach einer Dreiviertelstunde. Und die Frage ist halt, wie kann ein so innovatives Unternehmen? Das schaffen, dass sie sagen, OK, wir, wir machen seit 20 Jahren machen wir alles richtig blöd gesagt, und diese 45 Minuten heute haben das ganze Unternehmen ruiniert. Wie kann es dazu kommen?
Und so standen nämlich auch die Mitarbeiter da, völlig verdutzen, wussten einfach nicht, was gerade passiert, was ich noch richtig krass fand war, dass als das passiert ist und die Mitarbeiter geschnallt haben, sage ich jetzt mal das gerade so enorme Verluste eingefahren werden. Gab es wirklich welche, die schon bereits angefangen haben, ihre Lebensläufe zu versenden, weil sie dachten, Ende der Woche bin ich arbeitslos? Higher and Fire in den USA.
Also du bist ja dann schneller raus als du gucken kannst. Und die haben quasi gedanklich schon ihren Schreibtisch geräumt. Das ist schon krass. Ich meine gut feiern, feiern hin oder her, aber wenn das Unternehmen einfach nicht mehr da ist, was willst du da machen? So ja, aber ich meine diese Mentalität ist halt einfach da, dass sie sich denken, ach du meine, ist das meine Schuld, oh mein Gott, was ist hier gerade passiert, ich räume schon Moment Schreibtisch. Ja, aber ja.
Wie kam es dazu? Ist ne gute Frage wie es dazu kam. Also im Endeffekt wurde irgendwann sag ich mal Marktlagen verändern sich ja auch ne, also beziehungsweise Anforderungen verändern sich und es wurde sozusagen es es musste etwas Neues her und ein neues Ich saß mal System das Retail Liquidity Programm wurde ins Leben gerufen, das hat im Endeffekt dafür gesorgt oder es war so ein bisschen um das mal grob abzureißen was das ist.
Da ging es darum, dass halt eben nicht nur große Händler, sondern halt auch kleine oder Einzelpersonen genauso handeln konnten. Also fairere Marktpreise
bekommen. Das war ja, glaube ich, eine Initiative von der New Yorker Börse selbst, von da ja genau, und damit das aber auch funktioniert hat, musste halt etwas Neues her und das ist halt genau dieses RLP, dieses Retail equidity Programm, das wurde musste sozusagen softwaretechnisch implementiert und integriert werden, in das sage ich jetzt mal System, was sowieso schon dafür gesorgt hat, diese Trading automatisierte umzusetzen und dieses diese
Software hieß Smars, also wie der Mars bloß mit dem S davor. Und stand eigentlich im Endeffekt schön erklärt, Stand für Smart Market Access Routing System so nur mal so, damit man es auch wirklich noch mal vollständig hat für. All diejenigen, die es jetzt googeln wollen, genau. Und ja, im Endeffekt wurde das in diese Software integriert und dann kommt natürlich irgendwann der Punkt, dass man genau diese dieses Update natürlich auch irgendwann verwenden möchte.
Ne, das heißt es gab halt irgendeinen Zeitpunkt x Stichtag x. Das war der 1.8. Der 1. August 2012 wie du so schön meintest und da wurde dann sozusagen dieses System, dieses adaptierte System dann eingesetzt und verwendet und das wurde erstmal auf die entsprechenden Server Kapazitäten die da waren ausgerollt. Also das System läuft dann nicht nur auf einem Server sondern auf mehreren Servern. Du hast eine. Große, du bist ja, du bist ja Markt.
Wie hast du es so schön genannt, Marktführer, Marktführer, der der der große Big Player in diesem Business und hast natürlich viel Traffic, das heißt du brauchst mehrere Server wo das drauf läuft so und dann wurde erstmal überprüft okay wir haben einen Server und da integrieren wir das neue System und dann kam die. Cleveren Leute, die daran gearbeitet haben, auf die DNRS macht natürlich Sinn, das Ganze irgendwie zu automatisieren, weil nicht, dass wir hinterher
einen Server übersehen. Ne, das heißt im Endeffekt wurde dann n Skript geschrieben. Mit diesem Skript wurde dann das Update eingespielt auf alle Server, die da waren. Genau, und da gab es aber dann im Endeffekt ein kleines Problemchen dabei bei diesem Ausrollen auf diese Server.
Und das hat dazu geführt, dass das System, so wie es eigentlich funktionieren sollte, fehlerhaft war und demzufolge halt aus diesem Fehler, den wir auf dem wir noch näher eingehen werden, dann im Endeffekt dazu geführt hat, dass es eine riesige finanzielle Katastrophe wurde am Ende. Ja, weil was ich ganz spannend fand bei diesem Skript so n paar Quellen haben das n bisschen näher beleuchtet.
Also im Endeffekt war es ja wirklich nur n kleines Skript was gesagt hat geh mal alle Server durch. Genau bauen ne SSH Verbindung auf und Update quasi die Software da drauf. Ne dass halt die richtigen Binaries dann am Ende laufen. Soweit so gut und klingt doch gut erstmal vernünftig, warum nicht automatisieren? Klar weil Menschen machen Fehler Problem an dem Skript war aber soweit ich das gelesen habe und das finde ich halt wieder
spannend. Dass bei einer fehlerhaften Verbindung oder beziehungsweise wenn keine Verbindung aufgebaut werden konnte, einfach zum nächsten Server gegangen wurde und es keine Rückmeldung gab. So nach dem Motto Hier Server 5, hinten rechts in der Ecke, der hat das jetzt nicht bekommen, weil ich konnte keine Verbindung aufbauen, sondern es wurde einfach direkt zu Server 6 gegangen und da weitergemacht mit dem Update sehr. Gefährlich, weil am Ende dachten die Mitarbeiter, es ist ausgerollt.
Alle Server haben den neuen Stand, aber Server 5 hinten rechts in der Ecke. Immer noch den alten stand weil sowie ich das in einem Bericht gelesen habe, war Erwartungen gerade das heißt er war offline und.
Verbindung. Keine Verbindung, die Wartung wird durchgeführt, alles ist OK, der Server fährt wieder hoch mit dem alten Stand und dann hast du nämlich genau das Problem, sagen wir mal 7 Server haben die neue und der achte Nummer 5 hinten rechts in der Ecke. Den alten Stand und das Team denkt, das Update ist ausgerollt, also meldet das
natürlich auch hier alles cool. Die Systeme Server laufen, wir können loslegen, wir sind bereit für den nächsten Handelstag wo es denn läuft, sozusagen mit der neuen Version schon und die haben sich ja glaube ich auch 2 Wochen Zeit genommen, also an der Stelle ist ja eigentlich gar kein Fehler passiert, das wurde ja quasi bewusst in Ruhe gemacht, weil man um diese
Auswirkung wusste. Dass sonst so ein Update ja keine Kleinigkeit. Ist aber das finde ich interessant, weil du meintest, ein Mensch kann ja Fehler machen und das witzige ist ja, dass irgendwo wurde ja dann an dieser Stelle von irgendeinem Menschen ein Fehler gemacht und zwar und das ist eine Sache und ich kann das auch als Softwareentwickler auch irgendwie ein bisschen nachvollziehen, und zwar du denkst an einen bestimmten Fall und sagst okay ich möchte gerne,
dass das alles ausgerollt wird und dein Server läuft, du machst das ganze, es funktioniert, du hast vielleicht noch. Tests im optimalen. Einen Fall hast du automatisierte Tests, die dir sagen okay das und das und das passiert so. Ich hab jetzt glaub ich so n bisschen heraus aus meiner Recherche herausgefunden, dass dieses Skript nicht wirklich gut abgetestet war. Aber vielleicht sind das auch nur Mutmaßungen am Ende ne, also
aus dem Resultat heraus. Das Witzige ist aber, dass ich kann es halt irgendwo nachvollziehen, auf irgendeiner Ebene, weil du halt. Dann in dem Moment, den Happypass betrachtest und nicht daran denkst, du siehst den Wald vor lauter Bäumen nicht und und siehst nicht, dass ein Server
auch aus sein könnte. Weil du gehst ja davon aus, dieser Server ist der Server läuft genau, der ist ja immer an, aber dass man auch wirklich mal vielleicht für Wartungsarbeiten halt einmal kurzen Server neu starten muss und dann genau in diesem Moment das Update sozusagen ausgeführt werden muss im Falle, dass es. Offline ist ist natürlich schon hart, aber und ich stell mir das ungefähr so vor und das ist ja auch immer wieder das gefährliche Mensch sitzt vorm
Rechner, hat irgendwas gemacht oder hat nur n Programm was wo es heißt führ das Mal aus, muss ja nicht der gleiche gewesen sein oder die gleiche Person die das auch geschrieben hat, dieses Skript und eine Person führt das aus und vertraut diesem Rechner, er sagt es wird schon passen und dann hast du vielleicht im Terminal so eine Anzeige oder wo auch immer wo dann steht Server 1, beep, beep, beep Check Server 2 beep beep Check Server 3 Server 4, Server 5. 5. Hinten in der Ecke.
So, und dann kommt einfach nur Check. Du siehst Check, also ist es ja fertig, der Server meldet sich ja nicht und sagt Jo danke ich hab's Update bekommen naja genau und das Problem ist, dass das Skript quasi keine Ausgabe gibt, so nach dem Motto Hier Server 5 konnte nicht erreicht werden und das ist halt das Thema wenn du so schnell ein Skript schreibst weil du sage ich mal das automatisieren willst, dann kann halt sowas vergessen werden und das Skript an sich auch nicht
abgetestet ist also es wird halt nur an den Happy Pass gedacht wie du so schön gesagt hast, weil wenn du anfängst zum Beispiel so ein Script abzutesten. Machst du dir halt auch über andere Pfade, die eintreten können. Gedanken meistens, hoffentlich.
Aber es ist auch verständlich, in der Situation zu sagen, Hey, nee, ich, wir machen jetzt n Skript ey, wenn ich das hier alles per Hand mache, dann vergess ich irgendein Schritt, dann mach ich irgendwas nicht ich code das jetzt und n Skript runter was erledigt werden muss, dann lass ich das laufen und gut ich mein jeder Entwickler kennt diese Vorgehensweise also da kann man dem Entwickler ja nicht mal irgendwie einen Vorwurf machen, das Problem war eher, dass er alleine war und es
keinen zweiten gab der das noch mal gereviewt hat oder geguckt hat ob die Serverstände jetzt passen, ob das Skript passt wo auch immer da diese Überprüfung stattfindet sage ich mal. Das, da kann man sagen, das ist nicht cool gelaufen. Das können wir uns am Ende auf jeden Fall noch mal angucken. Was sind eigentlich die Learnings, die man daraus. Sieht das fassen wir am Ende noch mal zusammen.
Aber was mich, was ich sehr interessant finde, Tino mal angenommen du hast einen Server, also wenn ich das jetzt einmal noch mal zusammenfasse, wir haben einen alten Stand der Software auf diesen Servern laufen, es wird quasi neu erstand wird ausgerollt und auf einem Server. Passiert das nicht so jetzt, könnte man ja davon ausgehen.
Ja gut, OK du hast x Server, da läuft der stand drauf oder x minus ein Server wo der Stand der neue Stand drauf läuft und ein Server wo er nicht der neue drauf stand drauf läuft ne die neue Version so man könnte jetzt davon ausgehen naja ok weiß ich nicht also nimm mal irgendeine Anwendung wie zum Beispiel Skype oder Teams oder was auch immer. Wenn du da ein Update nicht hast oder auf einer älteren Version bist, kannst du immer noch
telefonieren. Also man könnte ja jetzt davon ausgehen und sagen okay alles klar ist. Ein älterer Stand aber hockeys und das ist halt genau der der faszinierende Punkt dabei, wie du schon meinst, jetzt hast du verschiedene Server mit unterschiedlichen Ständen beziehungsweise es gibt 2 Stände, die meisten haben den neuen und zum Beispiel Nummer 5 finden dann rechts in der Ecke, hat noch den alten Stand. Aber der alte Stand lief ja
vorher problemlos Jahre lang. Warum sollte er jetzt auf einmal quasi solche massive. Verluste einfahren, weil man muss ja hier mal anmerken, das ist jetzt kein Stand, der gemixt wurde aus neuer Software und Alter, sondern jeder Server hat an sich ne eigenständige Version. Man geht davon aus die Neue ist Abgetestet und funktioniert. Und die alte lief sowieso jahrelang schon und sollte auch Abgetestet sein. Und die sind ja nicht gemischt.
Ne. Wie du, wie du ja schon meintest, warum zur Hölle ist dann so ein Desaster quasi aufgetreten und das ist jetzt wirklich n extrem cooler Punkt. Also nicht cool fürs Unternehmen, aber n supergeiles Learning, da können wir jetzt mal drauf eingehen und zwar. Warum ist das quasi passiert? Und das geht noch ein paar Jahre zurück. 2005 genau 2005 war das, und zwar wurde 2005 ein sehr umfangreiches Refactoring, erst mal eine super Sache.
Über Refactoring haben wir auch schon eine Folge gemacht, ist ja auch wirklich wichtig das zu tun und in dem Jahr gab es ein sehr umfangreiches Refactoring dieser smars Komponente. Es wurden zum einen die Effizienz wurde gesteigert, es wurden neue Handelsstrategien implementiert, das Routing wurde verbessert etc. Und was dabei aber passiert, ist, dass die Power Pack, so heißt die Komponente beziehungsweise das Modul innerhalb dieses Systems quasi
deaktiviert wurde. Was hat denn das Powerpack gemacht? Erklär das. So wie ich das verstanden hab war das ne Komponente die quasi wenn du jetzt sehr große Handelsvolumen hast wie ja nun mal die Night Capital hatte und jetzt sagt zum Beispiel hier ist n Auftrag über. Betrag X, der einfach riesig ist, hat die 1 Scheißteil, dann hat diese Komponente quasi das gesplittet. Also es hat quasi sozusagen aus dem System ne parent order, also NN Auftrag bekommen.
So das mach bitte und hat das denn so in Child ordern unterteilt? Das heißt zum Beispiel gesplittet in 5, damit die nicht mehr so groß sind und dass sich sozusagen besser handeln lässt, um es mal so. Laienhaft. Auszudrücken also könnte ich mir
das ungefähr so vorstellen. Ich hab ne riesen Packung, keine Ahnung, nimm zweis oder so und sag zu irgendjemand ey, willst du ne Packung m 2 haben, nimm 2 m 2 nimm 2 und der sagt und der sagt Nee Ey ganz ehrlich, so viel ess ich eh nicht so ne das funktioniert nicht, aber wenn du jetzt zum Beispiel diese Packung loswerden willst und zu jemandem gehst und sagst Ey nimm 2 ja klar möchtest du nimm 2 ja klar möchte ich zunimmt 2 ja klar,
dann hast du in kürzester Zeit ist eigentlich die Packung alle und du hast das auch wegbekommen so genau du kriegst es halt besser verteilt. Nimm 2 ist cool als Beispiel oder halt ne riesen Tafel Schokolade. Du sagst ja auch nicht, willst ein Stück Schokolade und gibst sie ihm dann hier so ne 200 Gramm Milka, weißt du. Ja, das sind kleine Teile runter, damit halt auch mehrere Leute davon was haben können. Genau, und zwar diese Komponente
war aber verbunden mit. Mit einer Funktion, die quasi für die Drosselung verantwortlich war, die quasi das überwacht hat und gezählt hat. Wie viele sind denn schon entstanden und wie viele davon sind auch schon gefüllt von diesen Orders, also von diesen Aufträgen. Quasi abgehandelt. Ja, also wenn du 10 Orders hast, quasi also eine große Order wird gesplittet in 10 und dann hast du keine Ahnung. 8. Hast du schon verkauft, also 2 kannst du noch so nach dem Motto
genau. Es hat einfach das quasi evaluierte mitgezogen, mitgezählt und die war halt an diesem Powerpack angeschlossen. Sozusagen. Und das Powerpack hat daher die Information bekommen, wieviel kann ich noch gut, bloß weiter geht es weiter geht es jetzt ist gesättigt sozusagen ich darf nichts mehr machen um einfach genau zu verhindern, dass zu viele Aufträge an den Markt
quasi gestellt werden sozusagen. Und während dieses Refactorings haben sie halt diese Funktion, diese Drosselung innerhalb dieses gesamten Workflows weiter nach vorne gepackt, weil sie sich dachten, Hey, warte mal, das ist alles ineffizient, wir haben eine extrem hohe Systemauslastung, wir müssen doch gar nicht erst anfangen, überhaupt diese Orders stellen zu wollen beispielsweise, wir müssen ja gar nicht erst diesen Prozess einleiten, um am Ende zu sagen, Hey, nee, Moment mal, ist
schon genug. Genau. So also wurde dieser ganze Workflow umgestellt. Diese Drosselungsfunktion ist halt also weiter nach vorne gewandert, das System wurde effizienter und man hat noch gesagt, ja dieses powerpack Modul braucht wir auch gar nicht mehr, das ist. Risiko schwierig also für das Risikomanagement, weil da kann halt schon.
Viel schief gehen, deswegen gab es ja auch diese Anbindung, dieser Drosselungsfunktion. Man könnte finanzielle Verluste erleiden, ja. Und auf jeden Fall wurde dieses Modul deaktiviert. Es wurde auch Geflaggt als Depricated, also als veraltet. Für diejenigen, die jetzt nicht
wissen, was ich damit meine. Das ist eigentlich ein Standard vorgehen, dass du Halt sagst, innerhalb meiner Software gibt es veraltete Funktionen beispielsweise und ich kann sie nicht einfach direkt raus löschen, weil beispielsweise andere Module diese Funktion noch verwenden, dann kann man sie als depreted Flaggen sozusagen, also signalisieren Leute, diese Funktion ist veraltet, wird nicht mehr supported und wird irgendwann entfernt, also bitte, ihr könnt
sie jetzt noch nutzen, aber in 23 Versionen später ist sie weg dann. Sich nämlich die anderen Teams, die jetzt beispielsweise andere Module entwickeln, darauf adaptieren, davon weggehen, vielleicht eine andere Lösung implementieren und dann irgendwann hast du quasi. So sage ich mal sanft diese Software, diese Funktion rausgeschnitten oder quasi abgekapselt.
Genau, und das ist, da muss man sagen, richtiges Vorgehen haben sie gut gemacht, wie gesagt gefleckt die Teams informiert, die haben sich adaptiert und diese Funktion oder dieses Modul wurde nicht mehr verwendet. Letzten Schritt haben sie aber nicht gemacht und zwar dieses Modul zu entfernen oder genau. Also du musst dir das so vorstellen und das ist halt auch so ein bisschen, also das kann man tatsächlich glaube ich auch so ein bisschen an die Software Entwicklung, mal ein bisschen
auf die Hand hauen, weil. Du hast also es wurde quasi dieses Power Pack Modul, was ja sozusagen gefleckt wurde, was nicht mehr eingesetzt werden durfte, was kommuniziert wurde über Deplicated, dass es nicht mehr verwendet werden soll, wurde er wie du meintest nicht rausgenommen, aber aus einem bestimmten Grund und zwar weil das so tief in diese Software,
in dieses Maß verankert war. Verflechtet war, dass man es gar nicht mal soeben mal rausschmeißen konnte, das heißt, es wurde zu wenig modular gearbeitet, das heißt, ich würde jetzt mal einfach mal ein bisschen klugscheißen und sagen, ja, das war alles nicht modular aufgebaut, die Software Architektur war nicht gut und so weiter. Und demzufolge haben Sie sich dann dafür entschieden zu sagen, OK, wir lassen halt einfach das powerpack Modul drin.
Wird ja nicht mehr verwendet. Unsere ganzen Tests, die wir haben, laufen grün, es ist alles in Ordnung, also passt das so was ich noch sagen würde, ganz kurz was ich noch interessant fand als als kleines Side Note so n bisschen technisch ist ja. Dass das war ja ne Konfigurationsdatei, weil dieses Fleck was du meintest mit Establicated oder verfügbar ne, das wurde ja sozusagen war ne Konfigurationsdatei und diese Konfigurationsdatei wurde dann einfach so draufgesetzt, dass du
an dieser Stelle wo stand. Möchtest du das Powerpack nutzen? Ne 0 stand anstatt ne 1 mal blöd gesagt ne so und das war im Endeffekt eigentlich nur so ne
Art bit array, wo du halt so Flex setzen konntest. 0 oder 1 für das ist drin oder nicht so und das wurde auch zum Beispiel jetzt nicht über Jason oder so gemacht, weil da ja wirklich auf Performance gesetzt wurde und Jason an der Stelle, man mag es vielleicht nicht glauben, aber halt einfach zu in Performance war an dieser Stelle. Genau.
Also das ist ja auch eine gängige Strategie zu sagen, wir haben, wir verwenden sozusagen Bitwörter, das heißt, du hast jetzt zum Beispiel. Eine 8 Bit zahl, dann hast du 8 logischerweise 8 Bits da drin und jedes Bit kann zum Beispiel eine so eine Config repräsentieren.
Das ist auch gerade im Embedded Bereich gang und gäbe und auch nicht verwerflich, das ist ja gut, dass sie es so gemacht haben, gerade weil ja. Auch Nanosekunden entscheidend sind bei so nem Technologien was man sich kaum vorstellen kann. Aber wie du schon meintest, dass Jason einfach zu imperformant ist. Und ja, genau, und dann haben Sie gesagt, gut, das Bit für Power Pack ist 0 und nicht 1. Das heißt es ist deaktiviert und wird nicht mehr in der Software
verwendet. Was ich noch spannend fand war, du hattest ja gesagt die es wurde Refected und zum Beispiel wurde dann dieses sag ich mal, dieser Accounting Algorithmus wurde entkoppelt vom Power Pack und so weiter aber da ist ja auch noch was passiert oder? In diesem Zuge. Also wenn du deine Software veränderst und Tests dazu hast, dann passiert ja eventuell mit den Tests. Was genau das ist nämlich jetzt der kritische Punkt dabei und ein absolutes No go. Wie gesagt, diese diese.
Drosselungsalgorithmus war nicht mehr verknüpft mit dem Power Pack, dadurch, dass er quasi weiter vorne in der Ablauf Kette gerutscht ist und. Das ist an sich OK, was aber nicht passiert ist beziehungsweise doch Gott sei Dank ist es passiert. Es sind Tests rot gelaufen, das heißt die Tests für das Powerpack haben gesagt, Hey mein mein Systemfall, also mein meine Funktionsweise stimmt nicht mehr. Und ja, was der Entwickler sich anscheinend dachte, so wie es jetzt übermittelt wurde oder
aufgearbeitet wurde ist. Na ja, du bist eh difficult, also du fliegst eh raus. Was kümmern mich deine Tests und hat einfach die Tests gelöscht? Und das ist halt krass, weil man hätte, wenn die Test drin geblieben wären gesehen hä da stimmt was nicht in unserer Software. Also hab ich doch 2 Möglichkeiten. Eine Möglichkeit ist ich fixe die Tests und kümmere mich um das Thema. Weil immer noch ist das Bestandteil der Software und kann per CONFIG aktiviert
werden, oder? Lösche halt diese Funktion raus und nicht nur die Tests. Also entweder ich ziehe es komplett raus und es kann einfach gar nicht mehr passieren oder ich fixe es aber nicht zu sagen, ja es bleibt drin, weil ich keinen Bock habe das jetzt rauszuschneiden, weil es super aufwändig ist in unserer Architektur. Ich lösche einfach die Tests damit alle Tests wieder grün sind und das ist halt ein riesen no go.
Ich meine, wir witzeln manchmal genau mit diesem Sachverhalt, so nach dem Motto Test des Roten Lösch. Doch den Test ist natürlich etwas, was ein absolutes No go ist und definitiv nichts. In professioneller Softwareentwicklung zu tun hat. Das ist auf jeden Fall super spannend und das hat dann im Endeffekt ja quasi, also da da, das war ja die Situation, ne, das heißt im Endeffekt.
Ist ja also wir haben dieses Maßsystem, wir haben das ganze n bisschen refected, wir haben neue Funktionalitäten reingebracht, wie zum Beispiel das LP. Und so weiter. Und dann wurde das Ganze ausgerollt zum Tag X am 1.8.2012 wurde das in Betrieb genommen und dieses Skript im Vorfeld hat nicht hat es nicht geschafft diese Software, also die neueste Softwareversion überall auszurollen. So was ist denn da passiert an dem einen Server der hinten rechts in der Ecke stand und
nicht genau genau. Das ist die Frage, weil 2005 und 2012 sind natürlich das 7 Jahre dazwischen. Sind das 7 oder? Warum ist es war es so lange nicht relevant? Genau ja. Also die Software liefert das lief ja wie am Schnürchen, die haben Umsätze gemacht im Jahr, das war ja der Wahnsinn, ne und 2012 wenn dieses RLP Update kommt geht auf einmal crashed alles zusammen. Und das ist ein ganz witziger Punkt. Und da kommt wieder diese Config, das config word wieder ins Spiel.
Und zwar mussten sie natürlich jetzt auch dafür sorgen, dass dieses RLP aktiviert werden kann oder deaktiviert werden kann und braucht natürlich jetzt wieder ein Bild. Hatten wir ja gerade erklärt, um es quasi an und ausschalten zu können, richtig und dabei ist aufgefallen, dass kein freies Bild mehr da war, das heißt die Wortlänge war komplett erschöpft, es gab nichts mehr, wo sie noch was setzen konnten und der Entwickler von diesem Update dachte sich.
Naja hier das Powerpack ist doch seit Jahren deprekted, das nutzt eh keiner mehr nachweislich, weil alle Teams haben sich adaptiert auf was anderes. Dann ist doch wieder ein Bit frei, also nehme ich das und hat gesagt so von fortan also ich kann das ja ich kann es auch nachvollziehen, ist es das Aktivierungsbild für RLP und nicht mehr für Power Pack richtig? Ja, und dann wurde es
ausgerollt. Im Prinzip ja gut, das Deployment hat nicht ganz funktioniert, dass es da zu dem Zeitpunkt noch nicht aufgefallen, was nun aber passiert ist an Tag x als. Die Software startete und ELPERLP nicht RLP Entschuldigung. War selbst verwirrt, gerade quasi aktiviert wurde über diese Config ist natürlich passiert, dass auf dem alten System. Auch das Powerpack wieder aktiviert wurde, weil er auf Server Nummer 5 hinten rechts in der Ecke, weil da ja die alte
Software drauf war. So und jetzt kann man sich wiederum denken, ja meine Güte, dann läuft halt Power Pack lief früher auch immer, dann läuft jetzt halt ein bisschen rlp ein bisschen Power Pack, wir werden das schon schnell merken, dass irgendwas vielleicht nicht ganz so cool ist, also dass der Worst case wurde gar nicht so glaube ich wahrgenommen, was das bedeuten könnte. Was jetzt aber am Ende passiert
ist. Dadurch, dass beide Systeme liefen, ist das Power Pack Modul angesprungen und hat ja jetzt wieder quasi diese Order quasi entgegengenommen und wollte die splitten was wir erklärt hatten. Genau so so, so cool. Wie immer hat es damals schon gemacht, aber was war jetzt das Problem? Genau. Also was ich erstmal interessant finde ist, du hast wie du schon meinst auf den beiden Systemen unterschiedliche Sachen laufen an sich erstmal nicht so schlimm.
Aber wenn du zum Beispiel bit 1 hast, was vorher gesagt hat, Aktivier mal Power Pack und jetzt aber dafür zuständig war, dass es RLP aktiviert du die gleiche Config, aber nimmst ne, dann ist ja. Also wird halt einfach Power Pack aktiviert. So genau so und das find ich halt fand ich ich weiß ich hab das gelesen, dacht mir so das ist das ist Wahnsinn weil. Also das das müssen Zufälle sein, die einfach diesen, diesen, diesen einfach, das ist
bescheuert. Aber natürlich ist es natürlich ne krasse Aneinanderreihung von Ereignissen.
Definitiv. Und dann kommst du an den Punkt, wo du sagst, Na ja, gut, OK, pass auf, du hast den alten stand, es wird einfach versehentlich Power Pack wieder aktiviert, Power Pack hat ja aber eigentlich funktioniert, aber wir haben uns erinnert, dass diese Version die da lief ist diese Version die sozusagen Performance optimiert wurde und diese Performance Optimierung hat ja dafür gesorgt, dass wir eigentlich Power Pack entkoppelt haben mit diesem Counting
Algorithmus. Das heißt wenn du jetzt zum Beispiel irgendwie weiß ich nicht für deine Freunde Essen kochst und einer kommt zu spät und du hast 5 Portionen gekocht und einer sagt ja, ich möchte eine Portion alle sagen, Sie möchten eine Portion, Du verteilt die Portion eines noch da, bei einer kommt ja noch eine Person, kommt ja noch.
Jemand sagt, ich könnte noch eine Portion haben und der Algorithmus sagt, 4 von 5 haben wir noch klar so und dann keine Ahnung. 5 von 5 ja egal, haben wir noch so nach dem Motto, das heißt, der Algorithmus sagt ja gut, wir sind zwar schon drüber, aber der Algorithmus würde immer noch sagen, wir haben doch genügend, also es könnte noch 2. Leute kommen und wir hätten noch genügend, aber das war halt nicht so ne.
Das heißt es wurden halt einfach an der Stelle einfach quasi es vor den Order gestellt und diese Order wurde halt einfach immer wieder verkauft, immer wieder, immer wieder oder gestellt, sagen wir mal so, ob es jetzt verkauft, verkaufen, verkaufen
egal. Aber diese Order die dahinter steht, die wurde halt mehrfach quasi dupliziert und es wurde nicht aufgehört weil kein Counting Algorithmus mehr gegriffen hat um zu sagen Halt Stopp, du hast schon genug Order gestellt dafür und das finde ich heftig. Und weißt du, was da richtig spannend bei ist? Weil ich habe mir die Frage gestellt, wie geht das überhaupt, wenn die finanziellen Möglichkeiten gar nicht da sind, so viel zu handeln und habe dabei gelesen, das finde ich
super spannend, das quasi. Unternehmen wie die Nightcapital quasi gar keinen Nachweis durch. Dadurch, dass das so schnell gehandelt wird, wird gar nicht geprüft, ob das Kapital überhaupt vorhanden ist, um das Handeln zu können, die können das einfach. Quasi an der Börse stellen ohne
Überprüfung. Weil wenn du jetzt als Privatperson handelst, dann wird ja gecheckt, quasi ob du überhaupt so viel finanzielle Mittel hast, gerade um so ne so n Auftrag anzulegen und da bei diesen Geschwindigkeiten passiert das aber nicht, sondern es gibt sozusagen ne Art Vertrauensbasis, dass das schon passt.
Also die die Verantwortung, ob das Geld überhaupt da ist, liegt dann komplett bei der Nightcapital und das hat denen ja auch dann das Genick gebrochen, weil das Geld war ja nicht da, was sie jetzt an Aufträgen rausgehauen haben. Das finde ich halt super spannend und auf jeden Fall. Hat ja jetzt dieses Power Pack Modul quasi Gas gegeben und
diese Order gestellt. Die wurden gehandelt und durch diesen riesen Marktanteil den sie hatten haben sie richtige krasse Kursschwankungen ausgelöst und diese wohnen dann quasi gehandelt und haben zu Verlusten geführt im Minutentakt von Millionen. Das ist völlig wahnsinnig und auch nur durch die Kunstschwankung die so extrem waren sind die Unternehmen darauf aufmerksam geworden, dass sie irgendwas nicht stimmt, das quasi.
CEO von Firma A den CEO angerufen hat von Nightcapital, was denn da bitte los ist und dann irgendwie erst geprüft wurde. Hä warte mal hier stimmt. Doch was nicht, weil es gab halt keinen Monitoring oder sowas
gesagt hat. Okay hier also das System hat nicht gemeldet hier gar ne läuft nicht Leute Leute läuft nicht, was ich aber auch interessant finde ist der Punkt, dass du hast ja noch andere Server beziehungsweise andere Algorithmen laufen, das heißt der eine, also diese Algorithmen sind ja. Sensibel darauf umzumerken, kommt es gerade zu einem Markt, also einem Anstieg oder zu einem
Abfall? Welche Order muss ich in diesem Moment stellen, also das sind ja adaptive Algorithmen, die versuchen, möglichst frühzeitig zu erkennen und einen Trend mitzunehmen, und jetzt hast du. Richtig in die Suppe spuckt, worauf andere unter Umständen vielleicht sogar noch falsche Trades ausführen, die eigentlich echt Mist sind an der Stelle.
Und genau das ist ja passiert, weil der Markt manipuliert wurde, und das ist so, das ist so krass, also du kannst es dir so vorstellen, also wenn du jetzt zum Beispiel auf dem Markt gehst, dann denkst du dir ja okay was?
Kaufe ich hier, kaufe ich ah, guck mal Erdbeeren für n Kilo für 5€ oder n erdbeer für Kilo für 100€ denkst du dir so, ich glaub 100€ für n erdbeerpreis ist glaub ich nicht fair, also nehm ich den eher die Erdbeeren für 5,00€ so aber wenn du jetzt quasi also das ist die die Seite des Käufers sag ich mal aber die Seite des Verkäufers ist ja so als würdest du auf als würdest du keine Ahnung. 5 Stände auf dem Markt haben und du gibst
jedem deiner Mitarbeiter, also der den Händlern, den Verkäufern gibst du ein Handbuch und der sagt sich, guck mal hier, das ist das Handbuch so arbeite mal nach diesem Handbuch und einer kriegt ein Handbuch was überhaupt nicht stimmt.
Und er fängt dann auf einmal an, irgendwelche Waren für keine, also Mengen an waren die er hat zu verkaufen für irgendwelche komischen Preise. Kauft auch von anderen andere Händler kaufen von ihm vielleicht und er macht einfach nur irgendein Murks und alle anderen sind sozusagen völlig verwirrt und du denkst dir so hä warte mal. Eben habe ich noch ein Kilo für 5€ bekommen, das kriege ich jetzt gar nicht mehr, jetzt muss ich das für 20 kaufen.
Ach guck mal hier für 10 200. Also das ist halt so. Kann man sich das die genau, dass die Systeme sich dann gegenseitig noch mehr beeinflusst haben, dass es quasi die Schwankungen wurden ausgelöst? Die neuen Systeme haben gesagt, Oh hier ist n Trend, jetzt müssen wir, jetzt müssen wir Aufträge raushauen, weil das müssen wir mitnehmen und die kaputt.
Der kaputte Server hat gesagt du willst einen Auftrag, du kriegst 50, du kriegst 100 und dadurch ist es ja noch viel mehr aufgeschwungen alles völlig irre und noch ein richtig cooles Sidenote. Schlecht fürs Unternehmen, aber auch Sonnenparadebeispiel was? Machst du in dem Moment die Firma hat sich gedacht, es muss das Update sein, alles lief letzte Mal noch und haben quasi innerhalb von diesen 45 Minuten
gesagt. Okay wir revidieren das Update und spielen quasi die alten Version wieder aus, bis zu dem Zeitpunkt übrigens bis zu diesem Zeitpunkt wurden ungefähr 150 Aktien in diesem. Falschen in diesem in diesem katastrophalen Zustand gehandelt, sag ich jetzt mal ne oder in diesem ne so, also 150 verschiedene 150 verschiedene Aktien. Genau. Also das war wirklich ne Riesennummer und der Wiltze ist, dass sie jetzt quasi. Die Version zurückgesetzt haben und. Die Config aber war wie sie war.
Das heißt, RLP war aktiviert und niemand hat da in dem Moment dran gedacht, dass es ja die powerpack Komponente quasi wieder aktiviert und die fehlerhaft ist, weil die Tests waren ja alle Grün, das heißt vorher war nur Nummer 5 der Übeltäter und nach diesem Zurücksetzen ist das ganze Halt noch mal potenziert, das heißt die anderen Server haben dann auch gesagt, so immer raus damit, so dass es quasi abnormal
Anstieg die Verluste und. Am Ende dann quasi den Stecker gezogen hat, weil zu dem Zeitpunkt, wo dann alle auf einmal, also alle Server quasi falsch reagiert haben, wurden nicht nur 150 Aktien, sondern halt fast weltweit alle Aktien von diesem Unternehmen falsch quasi behandelt. Und das ist was für ein Ausmaß das hat. Und weil du gerade gesagt hast, da wurde dann der Stecker
gezogen. Irgendwann wurde halt glaub ich was hast ich glaub das hattest du vorhin auch gesagt, der CEO oder so meinte dann zu dem technischen Bereich ne meinte dann so ja könnt ihr mal bitte den Killswitch betätigen und die haben sich gedacht haben wir nicht wir haben keinen Killswitch die Möglichkeit jetzt drauf ein also eingreifen zu können so auf die Schnelle genau also mit einem Knopfdruck zu sagen okay das war's jetzt sondern halt wirklich dann
nochmal manuell oder nach und nach alle Server einzeln runterzuschalten das ist schon heftig. Ja, und da sind halt sehr, sehr viele. Also wie soll ich sagen, also es sind halt so viele Ereignisse aufeinander gefolgt, die dazu geführt haben, dass man sich denken kann, OK, ist ja echt schon krass unwahrscheinlich,
dass das alles so passiert ist. Aber wenn die sag ich mal, die Wahrscheinlichkeit da ist, dass es passieren kann, sagt man ja so schön, dann passiert es auch und es ist auch in diesem Unternehmen passiert und hat am Ende dafür gesorgt, dass dieses
Unternehmen pleitegegangen ist. Also die Neid Capital gibt es auch nicht mehr in der Form, das heißt, es gab noch so verschiedene Investmentrunden, also Finanzierungsrunden, deswegen ist es auch eine Night Capital Group geworden, weil Investoren versucht haben, das Unternehmen zu retten. Ich glaube, es sind dann wirklich 400000000 Reingeflossen, das hat aber auch nicht gereicht so.
Dass es am Ende zu einer Übernahme kam, von einem anderen Unternehmen und ja, irgendwie quasi diese Grundstruktur nightcapital in einem anderen Unternehmen noch weiter lebt, aber das Unternehmen an sich mit dieser, mit diesem Alleinstellungsmerkmal so dominant gewesen zu sein in diesem Markt, hat halt, sage ich mal in diesem Jahr aufgehört zu existieren, und das finde ich halt extrem krass, wie ein Update dafür gesorgt hat. Vor allem jemand.
Also ein Unternehmen was 20 Jahre Marktführer war mit Softwarelösung, ja mit mit mit Softwarelösung und ein Software Bug hat sie aus dem Leben geschossen, das ist schon krass und ich meine man kann sich jetzt hinstellen und sagen okay aber es sind halt Zufälle passiert so das sind doch also solche Zufälle sind halt Zufälle so blöd gelaufen so hoffentlich passiert es nie wieder, aber ich hoffe, dass man schon einige
Learnings daraus ziehen kann. Ja, und die würde ich auch gerne mal mit dir zusammenfassen, bevor wir die Folge beenden.
Wir haben jetzt auch sehr lange darüber gequatscht, aber ich muss sagen, es ist spannend, ich finde es auch super beeindruckend, also un schockierend zugleich, schockierend zugleich ist ein extrem cooles Beispiel und auch kein Wunder, wenn wir zu den Learnings kommen, dass in dieser ganzen Dev ops Bewegung, wir haben ja auch eine Dev Ops Reihe, liebe Zuhörer und lieber Zuhörer, falls sich die Themen, die wir hier auch thematisieren oder in dieser Folge
angesprochen haben, weiter interessieren, dann hört er gerne mal rein, auf jeden Fall die Dev Ops Bewegung und auch dev Ops Teams nehmen. Quasi diesen Glitch. Von der also diesem Software Bug immer als Beispiel dafür, warum Dev Ops so verdammt wichtig am Ende ist. Weil. Fangen wir mal mit dem Punkt an das Deployment. Wir gehen jetzt mal noch nicht auf die Softwareentwicklung ein. Ich möchte mal erst mal kurz noch mal über das Deployment reden, wenn wir nämlich bei dev
ops sind. Du Rollst das jetzt aus, fängst manuell an, haben wir ja gesagt, da können Fehler passieren, Menschen machen Fehler, da hat sich der Mitarbeiter oder das Team damals gedacht, ja, das können wir so nicht machen, wir müssen das automatisieren. Punkt für Dev Ops ne, haben Sie sich auch gedacht? Ja, wir automatisieren das, haben dann ein Skript geschrieben, was nicht, was quasi das bitte. Was nicht so richtig getestet wurde. Was nicht getestet wurde.
Kein Punkt Richtung Deathrops, da haben Sie es denn halt schon vergeigt. Ne, weil am Ende ist man davon ausgegangen, dass das System den Zustand hat, wie man ihn erwarten würde, aber man konnte es nicht nachweislich sehen, es gab kein Feedback dazu und das ist ja auch genauso dieser dev ops Ansatz, dass du auch ein Feedback kriegst. Hat das alles funktioniert, wurde das automatisiert nochmal geprüft was wir haben wollen, wird quasi nur deployed wenn alles okay ist. Ja.
So, du brauchst einen. Monitoring, um zu sehen, was.
Fehlt hier eigentlich oder was geht schief, wenn was schief geht und eine Art. Observability um zu sagen okay, wenn was fehlgeschlagen ist, dann musst du auch relativ schnell erkennen können, wo ist es denn fehlgeschlagen bei und da sehe ich nämlich auch ein riesen riesen Kritikpunkt an der ganzen Sache, es hat 45 Minuten gedauert um irgendeine Reaktion durchzuführen und das war halt einfach zu lange und hat das Unternehmen quasi in den Ruin getrieben, also wirklich in die
Insolvenz. Bei fehlendem, weil es ja bei fehlendem Monitoring, wenn du wenn du dir anguckst, dass es wurde erst überprüft ob. Lass uns mal experimentelle Systeme abschalten, dann wurde gesagt, OK, dann lass uns. Dann haben die in den Debug Logs nachgeguckt, relativ lange irgendwann nach 20 Minuten 30 Minuten haben die dann mitgekriegt, OK, das ist wirklich dieses Marssystem und
dann haben die es zurückgerollt. Und dann haben Sie nicht mal festgestellt, dass die Konfiguration ja aber noch falsch war im Verhältnis zur alten Version, solche Sachen ja genau, und das ist einfach für so eine Software, die so sensibel ist, weil es wirklich um sehr, sehr viel Geld geht, innerhalb von Bruchteilen einer Sekunde ist das einfach viel, viel zu lange, also wirklich ganz, ganz schlechtes Monitoring
zu der Zeit gewesen. Ich denke, dass es auch in dem Folgeunternehmen oder in dem Zusammenschluss, der jetzt existiert, wahrscheinlich viel, viel besser läuft, weil man daraus gelernt hat, aber zu der damaligen Zeit war das natürlich eine absolute Katastrophe, ich habe auch noch sowas gelesen wie es. Gab noch so ein paar automatisierte Mails, die aber irgendwie im Verteiler untergegangen sind oder im Spam gelandet sind, weil sie nicht hoch priorisiert waren. Wo sowas drin stand wie?
Power Pack activated. Das wirklich? Da kam noch so ne alte Mail von früher, die irgendwie mal so als Monitoring implementiert wurde. So Pass auf hier das alte Modul das an, aber es wurde einfach ignoriert und das find ich halt so krass an der ganzen Sache. Also das sind mal so die Dev ops Punkte die man da quasi von der Infrastruktur auf besonders her
mal ansprechen müsste. Magst du mal mit den Punkten für die Softwareentwicklung an sich weitermachen, wo da so unsere Kritikpunkte wären oder Learnings?
Also es gab ja wohl auch Tests. Wie gesagt, ich frage mich aber zum Beispiel, ob sie auch Test driven entwickelt wurden, weil wenn du zum Beispiel dir im Vorfeld zum Beispiel, nehmen wir mal dieses dieses Skript was auf Server verteilt wurde und du schreibst deine Anforderungen in diesen Tests nieder und sagst okay was passiert denn, wenn jetzt zum Beispiel der Server ordentlich deployed, dann sollte man sich beim Test Driven Development halt eben auch auf Seiten der Tests Fragen als
nächstes, was passiert denn, was sind alles Eventualitäten, was passiert denn, wenn der Server nicht. Also das nicht auf den Server installiert werden kann das Update und dann muss man sich ja im nächsten Zug überlegen. Wenn du diesen Test hast. Was ist denn die Erwartungshaltung, was passiert? Steht dann irgendwo alles klar Server 5 hinten rechts in der Ecke wurde erfolgreich geupdatet oder steht da sowas wie hier? Gab es gerade ein Problem?
Lassen zum Beispiel Sachen, wo ich mir denke das. Kann ja die Software an sich ja nichts für, wenn quasi der Server aus ist, ist er aus, dann passiert er nichts und dann ist ja auch kein Fehler entstanden, sondern eher in diesem ganzen Deployment Schritt wie du meintest. Da muss irgendwie eine Meldung hochkommen.
Konnte nicht alle Server erreicht werden, beispielsweise wenigstens sowas was ganz minimalistisches, dass du einfach nicht das Gefühl von Sicherheit bekommst, obwohl eigentlich was schief gegangen ist? Genau das heißt, du musst dich auf diese Tests verlassen, dann was du meintest Tests löschen, wenn sie rot sind und du aber eigentlich. Dir denkst OK, die Software ist
irgendwie depricated. Genau nachgucken, was lösch ich hier eigentlich, was passiert hier eigentlich, welche Tests fliegen aus meiner Software raus und wenn dann na ja, lösch halt eben auch die entsprechende Software zu diesen Tests tatsächlich raus, ansonsten funktioniert das nicht, dann kommen wir zum nächsten Punkt, hatten wir schon mal ein bisschen angesprochen, sowas wie.
Eine Clean Architecture vielleicht an dieser Stelle, dass du bestimmte Module, die du einbaust, halt eben auch modular, wie es halt eben so schön heißt. Das heißt Ja Power Pack Modul, das sollte man dann auch modular in die Software irgendwie einklinken, wenn du es über einen Fleck ausschalten kannst. Nur mal so als Beispiel und was
du angeschnitten hattest. Vorhin war noch mal so wie was wie Code Reviews oder Peer Reviews, dass du zum Beispiel per Programming arbeitest oder wenigstens bei einem Change. Gerade in solchen Bereichen halt auch wirklich einfach mal ein Code Review machst, am Ende mit wem, wenn du schon alleine daran arbeitest, dann so einer Software. Das sind jetzt so die Punkte, die mir da auf jeden Fall helfen helfen. Einfallen, die da quasi n
bisschen fehlgeschlagen sind. Und wenn du dann vielleicht noch n bisschen weitergehst, könntest du sagen OK Dokumentation vielleicht, was macht was, unter welchen Umständen wird irgendwas getriggert, ist aber gerade auf developerment Ebene bei mir auch irgendwie, zumindest für mich persönlich in den Tests verankert. Ist jetzt nicht, ich rede jetzt nicht von Dokumentation auf Anwendungsebene, sondern auf Entwicklerebene Development. So ein letzter Punkt, den du
vorhin schon angerissen hast. Das finde ich auch noch gut, dass man nochmal zu erwähnen ist. Natürlich auch so eine Art Config Management zu sagen, hey, ich kann aber dieses Konfigurationswort, was wir jetzt gerade verwenden, nicht mit diesem Softwarestand, den ich zurückgesetzt habe, verwenden, also dass man da hätte auch absichern können, dass passend zu dieser Version auf dem Server niemals quasi eine Confinc verwendet werden kann, die das Power Pack Modul aktiviert, das wäre.
Auch eine Maßnahme gewesen. Also selbst wenn der Code noch in der Software bleibt, weil man sagt, es ist zu aufwendig, da muss man wenigstens sicherstellen, dass dieses Modul nicht mehr aktiviert werden kann. Wenn ich schon sage, so Tests sind rot, das ist eigentlich Brick, das ist halt kaputt so das Modul immer blöd gesagt, da muss ich auch sagen, dass das nicht mehr aktiviert werden kann, auch wenn es durch irgendwelchen komischen Zufälle
ist. Aber es darf halt einfach gar nicht mehr möglich sein, richtig?
Genau. Und bevor wir jetzt die Folge einmal noch mal kurz abschließen, weil ich glaube, jetzt haben wir den Fall ziemlich aufgearbeitet, was ich interessant finde, ist und ich glaube, das kann man sich immer fragen, sollte sich jeder Fragen, gerade wenn es um kritische Softwareanwendungen geht, und das hat auch ist so eine Kleine, so ein kleines Learning, was auch als warnendes Beispiel, also genau dieser Fall als warnendes Beispiel für
Handelsunternehmen heutzutage genutzt wird, dass sich und wie gesagt, das kann sich jeder immer bei kritischen Softwareanwendungen fragen, was ist das Schlimmste, was passieren könnte. Diese Frage beantworten und demnach seine Software auch gestalten. Richtig. Und dann kannst du anfangen, deine Software überhaupt zu schreiben.
Guter Punkt, vielen Dank. Paris war hat mir sehr sehr viel Spaß gemacht, ja mir auch, ist auch ein absolut geiler Fall muss ich sagen, ich habe mich auch richtig auf die Folge gefreut. Also ich habe es mir durchgelesen, dachte Wow, was also was kann denn alles noch passieren? Also je mehr du dich da in dieses Thema rein gräbst, desto spannendes. Das eigentlich. Und deswegen hat es mir sehr viel Spaß, diese Folge hier mit dir aufzunehmen und das ganze
Mal einmal darzulegen. Vielen Dank dafür, Tino Bitte und in diesem Sinne würde ich auch sagen, liebe Zuhörerin, lieber Zuhörer, ich hoffe. Oder wir hoffen, dass sie diese Folge natürlich auch wieder gefallen hat. Lass uns auf jeden Fall n like da, wenn es so ist auf den entsprechenden Plattformen, wo du sie gerade hörst.
Und wenn du Anmerkungen zu dieser Folge hast, du vielleicht meinst Ey, das war doch anders, das hab ich anders recherchiert oder anders gelesen, dann lass uns gerne auf jeden Fall diese Informationen auf unserer Podcast Mail zukommen, auch zum Beispiel Feedback, genauso gerne darüber. Und wenn dir dieser Podcast insgesamt gefällt oder dir das Projekt Coding Buddies gefällt, das auch eine kleine Spende da, darüber freuen wir uns, wir können unseren Content weiterhin
verbessern. In dem Sinne empfiehlt den Podcast gerne auch noch 2 deiner Freunde. Wäre der Hammer und in dem Sinne der Hammer. Das würde uns super freuen und in dem Sinne macht's gut bis zur nächsten Folge Eure Coding. Bunnys gemeinsam besser. Was?