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?