Transcript
Kai Ole Hartwig: Hallo und willkommen zurück zu Secrets Not Included, wie immer mit Daniel und Ole.
Kai Ole Hartwig: Dieses Mal zur schon 21.
Kai Ole Hartwig: Folge.
Kai Ole Hartwig: Wir haben vergessen, Kuchen zu backen, letzte Woche.
Kai Ole Hartwig: Also backt ihn euch selber, wenn ihr die letzte Folge gehört habt oder holt es schnell nach.
Kai Ole Hartwig: Und in dieser Woche soll es um das beliebte Thema Monitoring, ich kann schon wieder nicht sprechen, also um Monitoring gehen.
Kai Ole Hartwig: Perfekt, keine Fremdsworte heute, Daniel, ja?
Daniel Langemann: Ich versuch's, ich versuch's.
Kai Ole Hartwig: Also du die Fremdsworte, ich dann ohne Fremdsworte.
Daniel Langemann: Also das Aufzeichnen von Events, genannt auch Monitoring.
Daniel Langemann: Nein.
Daniel Langemann: Ja, also wir hatten uns das Thema Monitoring herausgesucht.
Daniel Langemann: Ich habe keine Ahnung, wo wir gehen, oder wir haben keinen Plan, wo wir hinwollen, thematisch.
Daniel Langemann: Das ist schon mal gut, aber vielleicht stecken wir erst mal ab, was ist denn, also, wo sehen wir Monitoring oder was ist Monitoring?
Daniel Langemann: Weil ich zum Beispiel, ich bin jemand, der in Projekten gerne das auch durcheinander oder mischt, so Alerting mit Monitoring vermische ich gerne.
Daniel Langemann: Also, wenn ich darüber rede und rede von Monitoring, meine aber Alerting, und das eine ist ja nicht das andere.
Kai Ole Hartwig: Jetzt steckst du direkt so tief in diese Grundsatzdefinition ein.
Daniel Langemann: Ja, keine Fachwörter, aber...
Daniel Langemann: Und deswegen hätte ich jetzt gesagt, wir reden erstmal nur über Logging, heißt, was heißt das für dich?
Daniel Langemann: Also sind das Applikations-Events, die zum Beispiel irgendwo, wo jemand reingucken kann, sagen kann, guck mal, die Kunden kaufen, kaufen, kaufen.
Daniel Langemann: Oder ist das nur für das System darunter, dass der Admin reinguckt und sagt, guck mal, CPU ist bei 80%, wir müssen ein bisschen skalieren.
Daniel Langemann: Festplatte ist toll.
Kai Ole Hartwig: Ja.
Daniel Langemann: Also es gibt ja super viel, was du loggen kannst und auch viel zu viel.
Kai Ole Hartwig: Loggen ist aber ja auch wieder was anderes als Monitoring.
Kai Ole Hartwig: Und was jetzt gerade komplett gefehlt hat, eigentlich eins meiner Lieblingsthemen, nämlich was macht man denn eigentlich mit dem ganzen Spaß Richtung Data-Driven Decisions?
Kai Ole Hartwig: Also aus dem Monitoring, Alerting, Logging oder Logging, Monitoring, Alerting Richtung datengetriebene Entscheidungen treffen, um jetzt nochmal eine sinnvolle Reihenfolge vielleicht festzulegen, wo man gedanklich einsteigt.
Daniel Langemann: Richtig, wenn nichts passiert, dann passieren die Events halt woanders.
Daniel Langemann: Keine nächtlichen Einsätze.
Kai Ole Hartwig: Also man muss ja keine Gedanken sich über das Alerting machen, wenn man kein Monitoring hat, wenn man kein Logging hat.
Kai Ole Hartwig: Ja, also ich meine, dann ist das E-Learning auch sehr ruhig.
Kai Ole Hartwig: Also, ich sehe Vorteile.
Kai Ole Hartwig: Also, ja, Logging.
Kai Ole Hartwig: Also ich sage jetzt mal, Daten haben ist erstmal besser als Daten brauchen.
Daniel Langemann: Ja.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Jetzt gibt es natürlich verschiedene Ebenen.
Kai Ole Hartwig: Ich würde grundsätzlich immer in der Applikation loggen.
Kai Ole Hartwig: was Fehler angeht.
Kai Ole Hartwig: Je schwerwiegender die Fehler sind, je eher würde ich es loggen.
Kai Ole Hartwig: Also eine Info- oder ein Deprecated hat hoffentlich im Log vom Produktivsystem nichts zu suchen, zumindest mal was die Applikation angeht.
Kai Ole Hartwig: Das sollte, also meiner Meinung nach, sollte man Deprecated Functions auch nie in einem Produktivsystem haben.
Kai Ole Hartwig: Aber das ist vielleicht ein anderes Thema.
Daniel Langemann: Ja, je nachdem, was du nutzt, kannst du das ja gar nicht rausschmeißen.
Daniel Langemann: Sagen wir, du hast eine LTS-Version von irgendeinem Framework oder so.
Daniel Langemann: Da sind ja auch schon Meldungen mit drin, wo du sagst, wenn ich die wegmache, bin ich dann auf der nächsten Version.
Daniel Langemann: Aber ich kann noch gar nicht upgraden oder irgendwelche Constraints verhindern das gerade.
Daniel Langemann: Also... Hm.
Kai Ole Hartwig: Ja, ich sage ja, das ist ein Thema für, wir lagern das mal aus in eine andere Folge.
Kai Ole Hartwig: Ich glaube, da können wir sehr lange drüber gehen.
Kai Ole Hartwig: Meine Vision ist immer, keine Deprecated-Meldungen zu haben.
Daniel Langemann: Das ist das Ziel.
Daniel Langemann: Message Queue.
Daniel Langemann: Asynchron.
Kai Ole Hartwig: So, jetzt aber zurück zum Logging.
Kai Ole Hartwig: Und dann haben wir natürlich noch ganz viele andere nette Komponenten neben der Applikation.
Kai Ole Hartwig: Also fangen wir beim Web-Server an, dann haben wir noch die Firewall, dann vielleicht auch eine Web-Application-Firewall, dann haben wir sicherlich noch Systeme wie eine Datenbank rumfliegen oder wie ein Key-Value-System.
Kai Ole Hartwig: Message Queue, ja, so irgendein Suchserver, eine Vektordatenbank.
Kai Ole Hartwig: Mir fallen viele Dinge ein, die da noch ringsherum fliegen.
Kai Ole Hartwig: Und aus einer Sicht sollten die erst einmal alle loggen.
Kai Ole Hartwig: Und auch so loggen, dass diese Daten am Tagesende aggregiert, aggregierbar sind, wenn wir aufs Logging schauen.
Kai Ole Hartwig: Heißt, ich schreibe die vielleicht an eine Stelle, das ist absichtlich sehr offen, wo ein anderer Dienst darauf zugreifen könnte, wenn er denn existiert.
Daniel Langemann: In Minecraft.
Daniel Langemann: Sorry.
Kai Ole Hartwig: Ja, meinetwegen schreibe auch die Logdaten alle nach Minecraft weg.
Kai Ole Hartwig: Ich wüsste spontan nicht, wie das geht.
Daniel Langemann: Da gibt es bestimmt jemanden, der auch da was baut.
Daniel Langemann: Also...
Kai Ole Hartwig: Aber wir können ja mal die KI fragen, was es da an Möglichkeiten gibt.
Daniel Langemann: Bestimmt.
Daniel Langemann: Je nach... Ja.
Daniel Langemann: Ja.
Kai Ole Hartwig: Baut es dann automatisch die Steine da?
Kai Ole Hartwig: Steine.
Kai Ole Hartwig: Ich habe aber gelernt, die Minecraft-Welt... Meine Kinder spielen ja Minecraft, beide.
Kai Ole Hartwig: Die Minecraft-Welt endet am Max-Integer-Wert.
Kai Ole Hartwig: Fand ich enttäuschend.
Kai Ole Hartwig: Und dann bricht die auch zusammen.
Kai Ole Hartwig: Das fand ich auch sehr spannend.
Daniel Langemann: Echt?
Daniel Langemann: Also so weit bin ich gekommen, aber cool.
Daniel Langemann: Tö, tö.
Kai Ole Hartwig: Ja, dann geht immer mehr kaputt.
Kai Ole Hartwig: Also du kannst diese Barriere wohl überwinden.
Kai Ole Hartwig: Ich glaube nicht auf der Switch, aber auf dem Rechner.
Kai Ole Hartwig: Und dann geht tatsächlich diese Welt nach und nach kaputt, weil die ganze Mathematik kaputt geht.
Kai Ole Hartwig: Logischerweise, das Datenbankfeld ist zu klein.
Kai Ole Hartwig: Ich kenne da ja eine einfache Möglichkeit, das zu beheben.
Kai Ole Hartwig: Anyway, falsches Thema.
Daniel Langemann: Hmm.
Kai Ole Hartwig: Oder vielleicht auch nicht.
Kai Ole Hartwig: Es gehört ja auch zum Monitoring festzustellen, hey, wir haben jetzt so viele Einträge in der Datenbank in einem bestimmten Feld, dass wir keine weiteren Einträge mehr schreiben können.
Kai Ole Hartwig: Das Datenbankfeld ist zu klein geworden.
Kai Ole Hartwig: Das hatten wir nämlich tatsächlich schon mal.
Kai Ole Hartwig: Das ist ein lustiges Phänomen in so einem CMS, wenn deine Datenbank auf einmal keine neuen Seiten anlegt oder keine neuen Inhaltselemente mehr und die immer verschwinden.
Kai Ole Hartwig: Ja, wir nennen nennen die da direkt höhere.
Daniel Langemann: Die Moderatoren waren bestimmt sehr begeistert.
Daniel Langemann: Oder Redakteure.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ja, und da war es tatsächlich so, es gab kein Monitoring darauf.
Kai Ole Hartwig: Es hat einfach niemand mitbekommen.
Kai Ole Hartwig: Jetzt muss man dazu sagen, da war klare Trennung von Verantwortlichkeiten.
Kai Ole Hartwig: Wir stellen die Applikation bereit, der Betrieb macht jemand anderes, inklusive Monitoring, Alerting und hast du nicht gesehen.
Kai Ole Hartwig: Ja.
Daniel Langemann: Aber das ist ein gutes Beispiel.
Daniel Langemann: Was ist das jetzt genau?
Daniel Langemann: Weil, also für mich wäre das Logging, dass entweder die Datenbank oder irgendwo eine Exception fliegt und das in einem Log landet, somit hier, guck mal, konnte nicht speichern, weil, Fehler, bla bla bla, Datenbank hat gemeldet.
Daniel Langemann: Das wäre ja so das Logging.
Daniel Langemann: Das Monitoring würde das ja irgendwo sichtbar machen.
Kai Ole Hartwig: Genau.
Daniel Langemann: Entweder gibt es dann zum Beispiel, weiß ich nicht, irgendein Dashboard, wo dann Sachen aufploppen, wo es sagt, weiß ich nicht, x Fehler in den letzten 5 Minuten, wo du so ein High-Level-View drauf hast und sagen kannst, guck mal, da sind die Punkte, wo es Probleme gibt.
Daniel Langemann: Oder wie ist das für dich?
Kai Ole Hartwig: Ja, genau.
Kai Ole Hartwig: Jetzt müssen wir vielleicht nochmal, das ist so ein klassisches Ding, wo ich sage, naja, das ist so eine DevOps, SRE-Rolle irgendwo, die sich genau um so Themen kümmert.
Kai Ole Hartwig: Und damals, das ist jetzt auch schon ein bisschen her, war es noch so, das war halt klassische Betriebsdenke.
Kai Ole Hartwig: Da gibt es Ops und da gibt es Entwicklung, also Dev.
Kai Ole Hartwig: Und das ist getrennt und die reden nur miteinander, wenn Dinge nicht funktionieren.
Daniel Langemann: Und wenn man sich sicher ist, dass die anderen schuld sind.
Kai Ole Hartwig: Genau.
Kai Ole Hartwig: Und ansonsten redet man nicht miteinander.
Kai Ole Hartwig: Und es gab halt kein, weiß ich nicht mehr, ob es Logging gab.
Kai Ole Hartwig: Ich glaube nicht in der Form für die Datenbank, weil sonst hätte man ja mitbekommen, da ploppt was.
Kai Ole Hartwig: Also sonst hätte man mitbekommen können, da ploppt was.
Kai Ole Hartwig: Und Monitoring gab es nämlich auch nicht so.
Kai Ole Hartwig: Für mich ist nämlich das erstmal Schreiben, das Logging, logischerweise klingt das so, das Aggregieren und Zusammenführen
Kai Ole Hartwig: ist dann für mich klassisches Monitoring.
Kai Ole Hartwig: Ich kann auf Daten draufschauen, wenn ich das möchte und die werden auch zusammengeführt.
Kai Ole Hartwig: Ich finde, das ist immer ganz wichtig.
Kai Ole Hartwig: Ich finde, wenn man die Daten nicht zusammenführt, dann ist es für mich noch kein Monitoring.
Kai Ole Hartwig: Wenn jeder Service oder jeder Server auf Eintal alleine vor sich hinschreibt und diese Daten landen nirgendwo, die werden nirgendwo zusammengeführt, dann ist das
Daniel Langemann: Du musst zum Beispiel in 20 unterschiedlichen Logdateien oder irgendwo nachgucken, um dann Sachen zusammenzufinden, ja.
Kai Ole Hartwig: Genau, dann ist das für mich noch klassisches Logging und noch kein Monitoring.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ich sage mal, bei Monitoring habe ich halt irgendwie ein Elk-Stack und ein Grafana oder meinetwegen ein Loki oder so.
Kai Ole Hartwig: Da stehen irgendetwas in der Richtung, wo die Daten zusammenfließen, wo ich sie durchsuchen kann, wo ich sie mir anschauen kann und im Zweifelsfall, wenn es schön ist, auch noch netterweise vielleicht ein bisschen grafisch aufbereiten kann und ein Dashboard habe, wo ich
Daniel Langemann: was zum Beispiel beim Debugging noch echt sehr angenehm ist, wenn du dann Sachen hast, also wenn die Sachen aufbereitet werden und zum Beispiel eine Request-ID durch mehrere Systeme durch verfolgbar ist.
Kai Ole Hartwig: Ja.
Daniel Langemann: Also das habe ich ein paar Mal erleben dürfen, oder selber noch nicht gebaut, aber immer erleben dürfen.
Daniel Langemann: Das ist super, dass du dann sagen kannst, ich habe hier einen Fehler, irgendwo taucht ein Fehler auf und du schmeißt diese Request-ID irgendwo rein und siehst dann auf einmal wieder, also diese eine Request durchs ganze System geporzelt ist.
Daniel Langemann: Und dann hast du... Also das ist, denke ich mal, das, was du mit aggregieren meinst.
Kai Ole Hartwig: Ja, ich meine, das ist quasi die Komfortfunktion für mich mit schöner Wohnen.
Kai Ole Hartwig: Da habe ich auch schon echt Diskussionen darüber geführt, ob denn so eine Request-ID nicht vielleicht ein personenbezogenes Datum ist und einen Nutzer identifizierbar macht.
Daniel Langemann: Nee, weil der nächste Request hat ja wieder eine andere.
Daniel Langemann: Und Und ich die nicht in Verbindung miteinander bringen kann.
Daniel Langemann: Also, na...
Daniel Langemann: Wollen wir Ragebait machen?
Daniel Langemann: Komm Ole, es platzt gleich aus dir heraus.
Daniel Langemann: Ja.
Kai Ole Hartwig: Ich möchte da jetzt nicht tiefer drauf eingehen.
Kai Ole Hartwig: Meine Meinung ist, so eine Request-ID ist das Mittel der Wahl.
Kai Ole Hartwig: Und ich bin auch der Meinung, Entwickler haben Zugriff auf so etwas.
Kai Ole Hartwig: Auch das ist eine Meinung, die nicht alle teilen auf dieser Kugel, wo wir uns bewegen.
Kai Ole Hartwig: Es gibt Menschen, die der Meinung sind, dass Logdaten ja nichts für Entwickler sind.
Kai Ole Hartwig: Anyway, darauf möchte ich jetzt auch gar nicht eingehen, weil dann nachher werde ich böse.
Daniel Langemann: Nee, wir wollen keinen bösen Ole.
Daniel Langemann: Hm?
Daniel Langemann: Ah, du hast einen Namen, Name-Dropping.
Kai Ole Hartwig: Ja, das ist eine gute Entscheidung grundsätzlich.
Daniel Langemann: Herrlich.
Kai Ole Hartwig: Aber genau, also mit aggregieren meine ich, die Logs, also die Daten aus dem Logging, werden von den unterschiedlichen Services abgeholt und werden erst einmal jetzt zum Beispiel in so ein Elastic reingeschrieben und dann zusammengeführt.
Kai Ole Hartwig: Ja, Name-Dropping.
Kai Ole Hartwig: So, perfekt.
Kai Ole Hartwig: Elastic ist, glaube ich, Open-Source-Produkt.
Kai Ole Hartwig: Also Open-Source-Produkte,
Daniel Langemann: Mhm.
Kai Ole Hartwig: supporte ich gerne viel und ich habe ja auch Open-Source-Pakete selber.
Kai Ole Hartwig: Wer sich ein bisschen Mühe macht, findet alle, sage ich jetzt mal, wo ich mitgewirkt habe.
Kai Ole Hartwig: Viel Spaß dabei.
Kai Ole Hartwig: Dann sind die Daten da drin und dann kann ich halt darüber suchen und
Kai Ole Hartwig: kann mir auch, wenn ich keine Request-ID habe, ja an einem von Zeitstempeln was zusammenreimen, so ein bisschen.
Kai Ole Hartwig: Wenn ich eine Request-ID habe, dann bin ich natürlich in der Premium-Kategorie für Debugging drin.
Daniel Langemann: Ja.
Kai Ole Hartwig: Dann kann ich so einen Request durch alle Systeme nachverfolgen nachverfolgen und kann dann viel leichter verstehen, was ist denn passiert.
Kai Ole Hartwig: Das ist für mich aber so eine Sache, wo ich sage, okay, wenn man jetzt sich diesen Observer
Kai Ole Hartwig: diesen Beobachtungs-Stack aufbaut?
Kai Ole Hartwig: Ich hab's heute nicht mit Englisch.
Kai Ole Hartwig: Sorry, not sorry.
Kai Ole Hartwig: Irgendwo ist mein Sprachzentrum noch nicht gebootet heute.
Kai Ole Hartwig: Das mag daran liegen, dass unsere Kaffeemaschine immer noch nicht funktional ist, da ich der Einzige bin, der in diesem Haushalt Kaffee trinkt.
Kai Ole Hartwig: Hat das für die anderen Menschen in diesem Haushalt keine so höhere Priorität wie für mich.
Daniel Langemann: Also abonniert unseren Kanal, damit Ole endlich sich eine Kaffeemaschine holen kann.
Daniel Langemann: Eine neue.
Kai Ole Hartwig: Ja, und sponsert den Kanal hier.
Kai Ole Hartwig: Also eigentlich brauche ich nur Spezialwerkzeug, um mal reinzuschauen, ob es nur ein Dichtungsring ist, der kaputt gegangen ist.
Kai Ole Hartwig: Ich sage jetzt mal, aus der Auffangschale den Kaffee immer rauszufischen, ist jetzt nicht so geil, dass ich da Bock drauf habe.
Kai Ole Hartwig: Deswegen lieber keinen Kaffee.
Kai Ole Hartwig: Anyway, das ist ein völlig anderes Problem.
Kai Ole Hartwig: Aber wir müssen das abonnieren und liken und teilen und sponsoren.
Kai Ole Hartwig: Wo war ich jetzt?
Kai Ole Hartwig: Jetzt denkt mein Kopf die ganze Zeit Kaffee.
Daniel Langemann: Bitte sehr, du warst beim Aggregierenden und der Observer-Architektur.
Daniel Langemann: Das du.
Kai Ole Hartwig: Perfekt.
Kai Ole Hartwig: Ich habe doch gesagt, du machst die Fremdworte.
Kai Ole Hartwig: Genau, also wir haben eine Architektur, die holt halt den ganzen Shit ab, packt das zusammen und wir können dann durchsuchen und in der Premium-Variante haben wir bitte eine Request-ID und dann haben Entwickler und Ops und meinetwegen auch POs Zugriff auf den ganzen Shit und können reinschauen und schauen.
Kai Ole Hartwig: Und dann, damit wir alle noch ein bisschen schöner wohnen,
Kai Ole Hartwig: machen wir uns dann schön mit grafana noch schönes dashboard wo wir dann halt sowas treten wie 500 meinetwegen auch
Kai Ole Hartwig: jeden anderen Chip, der uns so einfällt, Reaktionszeiten der einzelnen Services, CPU-Auslastung, RAM-Auslastung, IOTimes.
Kai Ole Hartwig: IOTimes finde ich auch gerade, wenn man geteilte Volumes hat, enorm wichtig, weil manchmal ist ein seltsamer Fehler einfach eine IOTime, die schlecht ist.
Daniel Langemann: Aber genau, solche Sachen siehst du halt, also, und das ist dann wieder der Unterschied zwischen Logging und Monitoring, ne, also Logging wäre einfach, dass die Dienste ihre Daten irgendwo ablegen und dass du in irgendeiner Textdatei, sagen wir mal, greppen müsstest, um da Sachen zu sehen und Monitoring ist halt dieses schöne Dashboard, was die Sachen zusammenführt, wo du dann, ne, wieder bei, sind wir wieder bei schöner Wohnen, was ich zum Beispiel mag, ist, wenn dann noch markiert wird, wann Deployments stattgefunden haben, weil du
Daniel Langemann: dann ganz schnell sehen kannst und sagen wir mal, wenn du ein Deployment machst und bei mir war es jetzt so, hast du einen Online-Shop, wo richtig viel los ist, Deployment und du kannst einfach die 10 Minuten, 15 Minuten danach drauf schauen, ob alles ruhig bleibt oder ob du auf den Button drückst, ich rolle mal schnell wieder zurück, weil was kaputt gegangen ist, solche Sachen.
Kai Ole Hartwig: ja, ich finde, ins Logging, damit es dann im Monitoring auftaucht, gehört auch immer schon eine Versionsnummer vom jeweiligen Service.
Daniel Langemann: Ja, dass du............
Kai Ole Hartwig: Weil dann kann ich halt zum Beispiel, wenn ich so Dinge fahre wie Blue-Green-Deployments oder Continuous-Update etc., dann kann ich halt sehen, ah, jetzt ist
Kai Ole Hartwig: aber das war während dem Deployment, während diese Pots umgeschaltet haben und da war halt ein Seiteneffekt drin.
Kai Ole Hartwig: Ja, weiß ich nicht, Datenbank-Schema hat sich geändert.
Kai Ole Hartwig: So, und dann ist halt beim alten Service dann doch ein Seiteneffekt aufgetreten.
Kai Ole Hartwig: So, dann weiß ich aber auch, hey, okay, da muss ich mich jetzt gar nicht mehr so richtig drum kümmern.
Daniel Langemann: Ja, ja.
Kai Ole Hartwig: Ja, ich weiß, okay, da ist was aufgetreten, das hat sich dann kümmern.
Kai Ole Hartwig: dann ist es okay.
Kai Ole Hartwig: Und dann sind wir auch schon wieder ganz heiß nah dran am Alerting.
Kai Ole Hartwig: Hm.
Daniel Langemann: Ja, also es geht Hand in Hand, weil wenn du solche Dashboards hast, also um das Spiel weiterzuspielen, bei dem Online-Shop war es zum Beispiel auch so, dass wir ein Alerting hatten, dass wenn 30 Minuten, also während den Geschäftszeiten, sage ich mal, tagsüber, konntest du davon ausgehen, dass es keine 5 Minuten ohne Kauf gab, da haben wir ein Alerting gehabt, dass ein Alarm losgegangen ist, wenn 30 Minuten kein Kauf passiert ist, weil wir mal den Fall hatten,
Daniel Langemann: Deployment, irgendwas ist kaputt gegangen, der Checkout-Prozess war kaputt.
Daniel Langemann: Das ist natürlich als Online-Shop der Super-GAU.
Daniel Langemann: Es war jetzt halb so schlimm, wie es sich anhört für uns, aber genau das ist wieder der Punkt, warum Monitoring so super wichtig wird, weil
Daniel Langemann: Die Architekturen werden immer abstrakter.
Daniel Langemann: Also es geht immer mehr in Message-Queues, immer asynchroner und gerade da siehst du viel weniger als Entwickler, weil das Event wird getriggert und das kann jetzt ausgeführt werden, in zwei Minuten, in zehn oder in 15, je nachdem wie voll die Queue ist.
Kai Ole Hartwig: Ja.
Daniel Langemann: Vielleicht blockiert da gerade irgendwas und da dreht sich was im Kreis.
Daniel Langemann: Das kriegst du so ja gar nicht mehr mit als Entwickler.
Daniel Langemann: Und da ist auch kein Kunde, der dann sagt, guck mal, ich habe beim Support angerufen oder schreib eine böse E-Mail oder eine böse Bewertung.
Daniel Langemann: Das ist ja auch so indirektes Monitoring oft.
Daniel Langemann: Aber bei Message Cues kriegst du das ja gar nicht mit.
Daniel Langemann: Und deswegen finde ich das super wichtig.
Daniel Langemann: Also ist das Monitoring immer wichtiger, weil auch immer kleinere Applikationen immer mehr asynchron machen.
Daniel Langemann: Und dann mit dem Alerting, also wenn du schon das Monitoring hast, dann bist du schon kurz davor zu sagen, komm, ich schicke da mal eine E-Mail raus, wenn irgendein Zustand X oder Y eingetreten ist.
Kai Ole Hartwig: Das Modul jetzt zusätzlich zu konfigurieren, ist, glaube ich, im Gegensatz zu erst mal die ganze Aggregation zu bauen, echt nicht mehr relevant jetzt so in Zeit gemessen.
Daniel Langemann: Ja, ja.
Kai Ole Hartwig: Teil.
Kai Ole Hartwig: Was ich auch sagen muss, ist, je mehr unterschiedliche Teams dran sind und je mehr Services du hast, je wichtiger ist ein gutes Monitoring.
Daniel Langemann: Hmm.
Kai Ole Hartwig: Ich saß mal im Projekt
Kai Ole Hartwig: dann hat man ein Produkt mitgebaut, so das trifft es eher, wo wir halt wirklich auch an die Auslastungsgänzen von Elastic gekommen sind.
Kai Ole Hartwig: Ja, weil einfach so viele Services liefen mit so vielen Daten und wo halt einfach auch tageweise
Kai Ole Hartwig: gekostet hat wo man halt dann auch sagen muss man weiß ja auch nicht was tun denn jetzt gerade die anderen und da ist total hilfreich so ein system zu haben wo man dann halt sieht okay wir haben auf einmal ein problem und acht guck an bei denen hat sich die versionsnummer geändert haben wir jetzt vielleicht irgendeinen seiten effekt davon
Daniel Langemann: Oh ja.
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Kai Ole Hartwig: oder wenn du dann schon siehst, im anderen Team geht schon das Alerting los und du weißt, oh, wenn deren Service jetzt fehlt, dann geht in fünf Minuten unser Alerting los, weil wir nachher abhängig davon sind und wir auch eine Metrik haben mit, unsere Message-Queue läuft voll, weil da wird der Shit nicht abgearbeitet.
Kai Ole Hartwig: So.
Kai Ole Hartwig: Ähm.
Kai Ole Hartwig: Und gerade wenn man halt natürlich jetzt, wie bei mir in dem Fall, das Team ist, was irgendwie die Startseite mit allem verantwortet und alle Inhaltsseiten verantwortet, du bist halt, wenn bei dir was schiefläuft, sind alle anderen geliefert, mehr oder weniger.
Kai Ole Hartwig: Außer jemand kommt über die Suche auf eine Seite, die nicht betroffen ist, auf so ein Produkt direkt drauf.
Kai Ole Hartwig: Okay, dann nicht.
Kai Ole Hartwig: Aber wenn dein Ding steht und kaputt ist,
Kai Ole Hartwig: dann sorgst du dafür, dass kein Umsatz stattfindet.
Kai Ole Hartwig: Oder signifikant weniger Umsatz stattfindet.
Daniel Langemann: Ja, oft ist es, es findet gar nichts mehr statt.
Daniel Langemann: Also die Signifikant weniger ist ja selten erlebt.
Kai Ole Hartwig: Naja, das kommt ja natürlich dann darauf an, wie dein Traffic zu dem Zeitpunkt ist und wie...
Kai Ole Hartwig: Läuft gerade noch Radiowerbung, Fernsehwerbung, ist gerade 12 Uhr mittags oder 18 Uhr abends.
Kai Ole Hartwig: Also ist es vielleicht der Zeitpunkt, wo du selber sagst, so, ich gehe jetzt mal essen, jetzt passiert ja nichts mehr oder jetzt sollte nichts laufen.
Daniel Langemann: Aber aus Erfahrung muss ich sagen, da bin ich wieder so der Freund von Message Cues.
Kai Ole Hartwig: Ja.
Daniel Langemann: Ich mag das, weil, also bei dem einen Beispiel war es so, da sind alle Messages in die Dead Letter Queue gelaufen.
Daniel Langemann: Also es war nicht super, es war nicht geil, aber wir hatten einfach Zeit als Entwickler.
Daniel Langemann: Also diese 30 Minuten haben gereicht, dass wir ins Monitoring reingeguckt.
Daniel Langemann: Also wir haben leider nicht durch Alerting Infos gekriegt, aber haben ins Blogging reingeguckt, haben einen Fix gefunden, den deployed.
Daniel Langemann: Und dann einfach nur auf Redrive gedrückt, alle Messages wieder zurückgekippt und es ist keine Bestellung verloren gegangen.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja.
Daniel Langemann: Also ich habe aus anderen Projekten zum Beispiel immer noch so ein bisschen PTBS, wo man sagt, man geht durch das Lok.
Daniel Langemann: Man greppt dann alle Kundennummern, alle Bestellungen und versucht dann möglichst alle Bestellungen irgendwie wieder herzustellen, wo du dann tagelang arbeitest, weil du möchtest natürlich auch den Umsatz nicht liegen lassen und du möchtest auch den Kunden glücklich machen, weil der wollte das ja haben.
Daniel Langemann: Da hast du so viel Nacharbeit, deswegen, also bei MessageQ, das ist schon... Ja, ja.
Kai Ole Hartwig: eben, es ist sehr geschickt, Dinge an zuverlässige Services zu schicken, das einfach nur mal aufschreiben, quasi notieren und weitergeben.
Kai Ole Hartwig: So, das nimmt auch viel Stress raus, gerade wenn dann auch sowas mal wieder ist, wie das SAP wird deployed.
Kai Ole Hartwig: Und das geht immer schief.
Kai Ole Hartwig: Jetzt bin ich sehr böse, aber bei uns ging es regelmäßig schief, wenn da deployed wurde, dass dann irgendwie Dinge nicht weitergegeben wurden nach der Bestellung, dass sie tatsächlich dann abgearbeitet wurden im Lager.
Daniel Langemann: Nimm mal.
Daniel Langemann: Nimm mal.
Kai Ole Hartwig: So, und dann bist du natürlich in der schönen Situation, dass du sagen kannst, okay, cool, ihr habt jetzt 48 Stunden keine Bestellung angenommen oder verarbeitet, weitergegeben.
Kai Ole Hartwig: Hier kommt 2 Millionen Umsatz für euch.
Kai Ole Hartwig: Viel Spaß!
Daniel Langemann: Das haben wir auch schon geschafft, dass wir dann das SAP, also dass das einfach mit der Flut der Messages nicht mehr klarkommt.
Daniel Langemann: Also das ist dann auch wieder, dieses Redrive ist dann auch ein Problem, weil du dann DDoS auf die nächsten angelegenen Systeme machst.
Kai Ole Hartwig: Ja, ich stemme und die das auf, die Mitarbeiter, ne?
Kai Ole Hartwig: Die im Lager ja picken müssen.
Daniel Langemann: Ja, das auch.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Und das kommissionieren und rausschicken müssen.
Kai Ole Hartwig: Ich stelle mir dann auch vor, was so Mitarbeiter denken, wenn dann zwei Tage lang quasi nichts reingekommen ist und auf einmal kommt, pfumm!
Daniel Langemann: kommen die gar nicht mehr hinterher mit dem Papier in den Drucker nachlegen für die ganzen Titelisten.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: So, also.
Kai Ole Hartwig: Gut, da war ich zum Glück noch nicht in so einem Lager nach so einem Ding, aber eigentlich würde es mich mal wirklich interessieren, wie das dann abläuft.
Kai Ole Hartwig: Also wie
Kai Ole Hartwig: wie da dann die Prozesse laufen.
Kai Ole Hartwig: Aber das ist reine Neugier.
Kai Ole Hartwig: Vielleicht auch in einem Projekt, wo ich nicht beteiligt bin, damit man immer sagen kann, hey Freunde, ich bin hier just for, mich interessiert das hier einfach nur, wie das bei euch so läuft.
Daniel Langemann: Ich bin der Grund dafür, dass du so scheiße Arbeitsbedingungen hast.
Daniel Langemann: Hm.
Daniel Langemann: Hm.
Kai Ole Hartwig: Ich bin jetzt kein SAP-Entwickler, der das kaputt gemacht hat.
Kai Ole Hartwig: Jetzt bin ich ja böse SAP-Bashing, so schlimm ist es ja gar nicht, hoffe ich.
Kai Ole Hartwig: Aber natürlich, wenn man Monitoring, Alerting und so auf diese ganzen Schlüsselfunktionen schon mal hat, dann kannst du natürlich viel ruhiger schlafen als Entwickler,
Kai Ole Hartwig: glaube, auf allen anderen Ebenen auch, weil du halt weißt, hey, das ist cool.
Kai Ole Hartwig: Das ist genauso.
Kai Ole Hartwig: Dann hing auch ein Dashboard, ein Grafana-Dashboard in der Teeküche, wo man die aktuellen Umsätze gesehen hat.
Daniel Langemann: Oh, das ist cool, ja.
Kai Ole Hartwig: Ja, wo man dann auch, also auch mit Tagesvergleich, Wochenvergleich und so, wo man dann halt gesehen hat, wo steht man denn.
Daniel Langemann: Mhm.
Kai Ole Hartwig: rot aufploppte, wir haben ein Problem.
Daniel Langemann: Ja.
Kai Ole Hartwig: Ja, es war halt quasi für jeden, der in diesem Bereich tätig war, war halt sichtbar, wie läuft es denn gerade?
Daniel Langemann: Das finde ich gut.
Daniel Langemann: Also weniger als Fingerpointing, sondern du hast ja so immer wenig Feedback, sagen wir mal, von dem, was man macht.
Daniel Langemann: Also es rappelt, klappert ja nichts oder es macht keine Geräusche, es qualmt nicht.
Daniel Langemann: So als Entwickler siehst du ja, machst du was, kommittest, gehst an die Kaffermaschine, spürst ja nichts mehr.
Kai Ole Hartwig: Ja.
Daniel Langemann: Und so hast du so ein bisschen visuelles Feedback.
Daniel Langemann: Das finde ich eigentlich ganz gut.
Daniel Langemann: Also wenn es nicht ein Fingerpointing nachher ausartet, dass so dein Name dann aufploppt mit, guck mal, Daniel hat als letzter committed, mit Bild am besten...
Kai Ole Hartwig: Nee, nee, das ja nicht.
Kai Ole Hartwig: Also wirklich als cross-funktionales Ding, wo alle, die irgendwie daran beteiligt sind, als es noch erlaubt war, heute geht das ja alles nicht mehr mit extern und hast du gesehen, nicht gesehen, aber wo wirklich alle Beteiligten im Prinzip auf ein, zwei Etagen, eineinhalb Etagen verteilt waren und halt da den Blick drauf hatten, wie geht es denn dem, was wir hier alle zusammen gerade schaffen.
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Kai Ole Hartwig: sichtbar.
Kai Ole Hartwig: Aber es war eines der besten Produkte, an denen ich beteiligt war.
Daniel Langemann: Du nicht mehr beteiligt warst.
Kai Ole Hartwig: Bis zu dem Punkt, wo
Daniel Langemann: Alles super.
Daniel Langemann: Aber...
Kai Ole Hartwig: Nee, nee, wo dann nachher halt ja die ganzen Externen raus mussten, also nicht mehr da sitzen durften, nicht mehr so eingebunden sein durften, ja, diese ganze Scheinselbstständigkeitsdiskussion und so.
Kai Ole Hartwig: Und Fremddienstleisterrichtlinien, die gekommen sind, die dann natürlich auch dazu beigetragen haben, dass solche Arbeiten in der Form nicht mehr möglich sind.
Kai Ole Hartwig: Und darunter hat dann tatsächlich
Kai Ole Hartwig: messbar die qualität des produkts gelitten weil dann auch keine dicken
Daniel Langemann: Also ich lache, weil es für mich offensichtlich ist, aber anscheinend für andere nicht.
Daniel Langemann: Also ja, schade.
Daniel Langemann: Es ist schade, aber gerade dieses Thema Scheinselbstständigkeit, es macht vieles kaputt.
Daniel Langemann: Also ich finde das Gesetz nicht falsch.
Daniel Langemann: Also es ist dafür da, die Schwächsten zu schützen, aber nicht in der IT.
Daniel Langemann: Also es
Kai Ole Hartwig: Ja, so.
Kai Ole Hartwig: Aber das betraf nicht nur Freelancer, sondern das betraf alle Fremddienstleister.
Kai Ole Hartwig: Alle mussten da raus.
Kai Ole Hartwig: Und man hat dann an den Zahlen gesehen und man hat auch am Kommunikationsverhalten gesehen.
Kai Ole Hartwig: Wenn dann intern und externe nicht mehr direkt miteinander kommunizieren dürfen, dann gab es halt auch so Sachen wie, dass dieses Thema einfach ausgefallen sind.
Kai Ole Hartwig: durften.
Kai Ole Hartwig: Und dann halt einfach längere Ausfallzeiten da waren.
Daniel Langemann: wenn man sich das leisten kann.
Daniel Langemann: Also, es ist ja schön, wenn man sowas über Monitoring dann, oder, ne, wenn man das dann nachher sehen kann.
Daniel Langemann: Und das ist ja auch so ein Thema, muss ich zugeben, das habe ich bis jetzt noch seltener erlebt, dieses, was du anfangs meintest, ne, dieses Decision-Making auch noch.
Daniel Langemann: Also, dass man zum Beispiel auch mit diesen Daten arbeitet.
Daniel Langemann: Das ist ja nicht nur für Entwickler gut, sondern, dass man genau, wenn man solche Sachen blockt, also zum Beispiel Tagesumsätze, ne,
Daniel Langemann: pro Stunde, wie auch immer, wo man sagen kann, guck mal, an den Stunden, an den Tagen ist viel los im Shop, an den und den Zeiten ist wenig los im Shop.
Daniel Langemann: Wir haben ein risikoreiches Deployment, wo man als Entwickler sagt, da könnte es eine Downtime geben.
Daniel Langemann: Ja, perfekt.
Daniel Langemann: Und wenn ich dann solche Daten habe, kann ich direkt einen Finger drauflegen und sagen, guck mal, das ist eine Uhrzeit, da ist seltenst was los.
Daniel Langemann: Also mache ich es doch da, bevor ich dann zu der Uhrzeit mache, wo alle da sind.
Daniel Langemann: Oder
Kai Ole Hartwig: ja genau sollte aber auch einfach mal performance ja wie schnell läuft denn meine applikation wir haben zum beispiel auch ganz hart
Daniel Langemann: Was zum Beispiel, habe ich auch schon ein paar Mal erlebt, ist auch eine nette Geschichte, das war so ein Feature, was unbedingt gebaut werden musste, wurde auch viel Zeit reingesteckt, so eine Wunschliste.
Daniel Langemann: Da hat man im Nachhinein rausgefunden, ich glaube im ersten Monat haben das keine 4000 Leute genutzt, also hat sich gut gerechnet.
Kai Ole Hartwig: entsprechende Performance-Metriken nachher erfasst von den Applikationen selber und dann halt auch Performance-Optimierung gemacht, weil wir dann einfach auch Daten dazu hatten.
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Welcher Request verbraucht denn wie viel RAM, wie viel CPU, wo hängt es denn, wo läuft es denn öfter durch, wo müssen wir denn optimieren.
Kai Ole Hartwig: Dann weiß man auch, warum auf einmal Caching ein Bottleneck sein kann.
Kai Ole Hartwig: Was es schneller machen soll, macht es auf einmal langsamer.
Kai Ole Hartwig: Und wenn du solche Sachen natürlich zusätzlich erfasst, ja, das geht ja über das normale Logging irgendwie aus, dann kannst du nämlich wirklich einfach mal Entscheidungen, also als Entwickler, ja, da sind die Umsätze vielleicht, die sind eher PO-relevant, denke ich mir immer so ein bisschen.
Daniel Langemann: Das ist ein super Thema, was du gerade ansprichst, ja.
Kai Ole Hartwig: Ja, aber dann hat man halt dieses...
Kai Ole Hartwig: auf datenbasiert Entscheidungen treffen, kann man halt auf alle Ebenen ausrollen.
Kai Ole Hartwig: Ja, klar, Umsätze sind super wichtig, gar kein Ding, aber das ist auch vielleicht wichtig, um zu entscheiden, welches Feature bekommt welche Priorität.
Daniel Langemann: Jede Abteilung hat unterschiedliche KPIs.
Kai Ole Hartwig: Aber für ein genau
Daniel Langemann: Also es ist ein ganz großer Reibungspunkt.
Daniel Langemann: Also das Thema, was du gerade ansprichst, triggert mich auch extrem, weil ich als Entwickler möchte, dass die Applikation stabil, kontinuierlich, gleichmäßig läuft.
Daniel Langemann: Andere Abteilungen, andere Personen haben ganz andere KPIs.
Daniel Langemann: Also es gibt zum Beispiel Umsatz als KPI.
Daniel Langemann: Es gibt, also berechtigterweise, es ist nicht so eins richtig, eins falsch, sondern jede Abteilung hat ihre KPIs.
Daniel Langemann: Ops hat zum Beispiel Inzidenz einfach, wo die sagen, guck mal, es gibt keine Inzidenz, keine Downtimes, fertig, das ist unser Ding.
Daniel Langemann: Und dann müssen wir vielleicht noch Betriebskosten irgendwie reduzieren.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Mhm.
Daniel Langemann: Entwickler haben wieder andere KPIs und das führt dazu, dass du richtige Reibungen hast.
Daniel Langemann: Zum Beispiel war das in einem Projekt, war zwar eine KPI, Reaktionszeiten der Seite, also im Median, ja, aber es gab eine alte Schnittstelle, die gescrapt wurde und die hat XML in gefühlt Gigabyte größer ausgekotzt.
Daniel Langemann: Natürlich hat die über drei oder vier oder fünf Sekunden Ladezeiten gehabt und hat natürlich den Median komplett versaut für den Checkout.
Kai Ole Hartwig: Ja.
Daniel Langemann: Und da war ich dann immer am argumentieren, lass doch entweder das Ding ausschließen oder wir segmentieren das auf gewisse Bereiche, zum Beispiel, dass der Checkout, also wir suchen uns den Checkout raus, suchen welche Requests da passieren und fassen diese zusammen und bauen daraus ein Median, wo ich sage, das ist gut.
Daniel Langemann: Und da hast du viele Probleme auch, also können viele Reibungen entstehen.
Daniel Langemann: Und trotzdem finde ich es super wichtig, als Entwickler, wie du sagst, sagen zu können, und das hatten wir auch, wir haben uns hingesetzt und gesagt, guck mal, es ist, also auch wenn wir darüber geschimpft haben, es ist Mist, wir wollen es besser machen.
Daniel Langemann: Und haben uns dann Sachen einfallen lassen, haben die eingebaut und du konntest auch mal sehen, Deployment, also wirklich so ein Haken und über mehrere Tage, dass das runtergegangen ist oder Arbeitsspeicherverbrauch.
Daniel Langemann: Wir sind immer wieder an die Grenzen gestoßen, als wir out of memory waren.
Daniel Langemann: Dann machst du eine größere Kiste hin.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja, aber...
Daniel Langemann: Die ist natürlich teurer.
Daniel Langemann: Ende vom Lied war, wir haben uns irgendwo hingesetzt und haben gesagt, guck mal, wenn wir das, das, das und so und so machen und nicht vielleicht komplette Objekte loggen, die serialisiert werden müssen,
Daniel Langemann: Arbeitsspeicher halbiert, was dann auch wieder Kosten reduziert, was andere KPIs, Gesundheit.
Daniel Langemann: Aber ich finde das super interessant, es macht Spaß und es ist super konfliktbehaftet, weil jede Abteilung so sein eigenes Ding hat oder eigene Richtung gehen will.
Daniel Langemann: Mhm.
Kai Ole Hartwig: dann haben wir zwei Sichten noch völlig vorgelassen.
Kai Ole Hartwig: Also die DevSecOps-Sicht oder DevOps-Sicht.
Kai Ole Hartwig: Als erstes Pipeline-Logging und Monitoring.
Kai Ole Hartwig: Ja, wie ist denn da die Performance?
Daniel Langemann: Oh ja.
Daniel Langemann: Okay, muss ich zugeben, habe ich noch nie gemacht.
Kai Ole Hartwig: Ja.
Daniel Langemann: Es lag an mir, nicht an GitLab.
Daniel Langemann: Genau.
Kai Ole Hartwig: Und ja, GitLab hat einen Endpoint dafür.
Kai Ole Hartwig: Also es gibt Endpunkte dafür, du kannst es machen.
Kai Ole Hartwig: Wenn du jetzt GitLab CI nutzt,
Kai Ole Hartwig: Das war ja nur die Seiteninformation, dass es an dir liegt.
Kai Ole Hartwig: Ich muss sagen, das handeln wir auch relativ tiefmütterlich.
Kai Ole Hartwig: Das ist so dieses, okay, es kommt schnell genug an oder nicht.
Kai Ole Hartwig: Aber Runner-Performance ist eigentlich auch eine wichtige Metrik, zumindest wenn du viel deployst und viel laufen hast, auch viel automatisiert laufen hast mit Renovate und anderen Sachen.
Daniel Langemann: Laufzeit, ja.
Daniel Langemann: Hm.
Daniel Langemann: Hm.
Kai Ole Hartwig: Und natürlich auch Security kannst du monitoren.
Kai Ole Hartwig: Wir haben nämlich den ganzen CVEs.
Kai Ole Hartwig: Was ist denn so in der S-Bomb drin?
Kai Ole Hartwig: OVAPS hat auch ein neues Tool im Übrigen jetzt rausgebracht als Beta-System, aber natürlich kannst du auch deine S-Bomb-Metrik, also die S-Bomb als Metrik benutzen und schauen, welche Versionen sind da drin und regelmäßig prüfen, gibt es denn jetzt da neue Sicherheitslücken, also im Prinzip...
Kai Ole Hartwig: Und ich schaue, wie viele bekannte Sicherheitslücken haben wir aktuell im System?
Kai Ole Hartwig: Und dann siehst du ja, okay, das geht hoch, dann läuft dein hoffentlich Renderweight los und sagt, ich habe hier Pages, ich spiele das ein.
Daniel Langemann: Das ist auch nicht gut.
Kai Ole Hartwig: Die Pipelines sind grün, die laufen schnell und dann siehst du, okay, das wird ausgerollt, verteilt und dann geht halt dein Metric für bekannte Sicherheitslücken wieder runter.
Kai Ole Hartwig: Nur als ein Easy-Going-Beispiel, ja, da kannst du noch viel, viel mehr natürlich loggen, nämlich wie schnell reagierst du denn tatsächlich darauf, also wann wurde es veröffentlicht, wann wurde erkannt, dass da ein Update ist und wann ist es denn jetzt tatsächlich angekommen.
Daniel Langemann: Und dann ist es auf Pod.
Daniel Langemann: Ich mag solche Metriken, weil die belohnen Entwickler.
Daniel Langemann: Also die belohnen das Team, weil du dann auch sagen kannst, guck mal, als Team haben wir geschafft, dass diese Metrik runtergegangen ist.
Daniel Langemann: Also so war es halt in den letzten Teams immer.
Daniel Langemann: Und Ladezeiten wurden besser.
Daniel Langemann: Und das ist nicht so eine Metrik, die auf ein Individuum gemünzt ist, sondern wirklich als Team.
Daniel Langemann: Und das hat sich auch gut angefühlt.
Daniel Langemann: Man war stolz darauf, dass man sagen konnte dann in einem Meeting, guck mal, wir haben das geschafft, das zu reduzieren.
Kai Ole Hartwig: Genau, und du kannst halt auch damit zum Beispiel sehen, okay, dieses Investment in Automatisierung hat sich gelohnt, weil jetzt sind wir x Prozent schneller damit.
Daniel Langemann: Ja.
Kai Ole Hartwig: Also unser Deployment, das Schließen von Sicherheitslücken und so weiter und so fort.
Kai Ole Hartwig: Oder auch, dass wir Infrastructure as Code betreiben und entsprechende Systeme,
Kai Ole Hartwig: oder, oder, oder, es gibt ja tausend oder eine Variante, Betreiben und Nutzen hat dazu beigetragen, dass unsere Systeme stabiler laufen, dass wir schneller ausrollen, dass wir nach dem, was wir wissen, sicherer unterwegs sind.
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Kai Ole Hartwig: So, jetzt Sicherheit ist immer eine schwierige
Kai Ole Hartwig: denn davon ganz Phänometriken, weil die verwischen nichts und die verwaschen nichts.
Kai Ole Hartwig: Also die sind relativ klar.
Kai Ole Hartwig: Und da finde ich andere KPIs in dem Sicherheitsbereich immer schwieriger.
Kai Ole Hartwig: Aber es gibt ja, wenn man jetzt mal auf diese ISO-Geschichten schaut, tausend und zwei Dinge, die eigentlich damit reingehören, die jetzt aber vielleicht für uns gar nicht so spannend sind.
Daniel Langemann: Ja, also genau, man muss so seine Metrik ein bisschen finden.
Daniel Langemann: Und dann auch gucken, was man da rein interpretiert.
Daniel Langemann: Nur weil da eine Zahl dran steht, heißt das ja nicht, dass sie eine sinnvolle Zahl ist oder eine gute Bedeutung hat.
Kai Ole Hartwig: Ja.
Daniel Langemann: Das ist schwer.
Kai Ole Hartwig: Ich finde auch zum Beispiel ein Alerting auf, es gibt neue Critical CVEs sinnvoll.
Kai Ole Hartwig: Oder auch High finde ich auch noch wichtig, weil manchmal haben wir jetzt ja auch die Situation, die Sicherheitslücke wird bekannt, es gibt aber noch keinen Patch.
Kai Ole Hartwig: Da muss ja jemand quasi zum Beispiel für NixOS die Mitigation reinmachen und deployen lassen.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Oder
Kai Ole Hartwig: Und dann bekommt man es aktiv mit.
Kai Ole Hartwig: Ja, und dann wird man auch nicht, wenn man nämlich nur über die eigenen Pakete ja quasi drüber geht, die man ja durch die S-Bomb erfasst hat, dann hast du nicht diesen Lärm aus Sicherheitslücken um dich rum, die dich eigentlich gar nicht betreffen.
Kai Ole Hartwig: Ja, also, weil es gibt ja...
Daniel Langemann: Ja, ja, genau, keine falschen Fehlermeldungen, die dich dann, also, ne, dass du dann taub wirst da drauf, ja.
Kai Ole Hartwig: ständig, wer weiß wie viele Sicherheitsmeldungen, Sicherheitslücken und Meldungen dazu und wenn du natürlich jetzt dann sagst, okay, ich schaue nur auf das, was bei uns auch tatsächlich läuft, dann weißt du zum einen, was läuft bei dir tatsächlich und zum anderen musst du dann halt auch nur darauf achten und das, was ringsherum passiert, kannst du dann halt außen vor lassen.
Daniel Langemann: Hm.
Daniel Langemann: Hm.
Daniel Langemann: Hier ein Legacy-System ist das ruhig.
Kai Ole Hartwig: Das ist nämlich, finde ich, beim KPIs und beim Alerting nämlich auch wichtig, dass man da die Dinge nimmt und findet und einstellt, die tatsächlich relevant sind.
Kai Ole Hartwig: Wenn du sagst, okay, 10, 500er in der Minute sind völlig okay für uns, weil wir wissen, dass der Service eigentlich nicht stabil ist, aber wir wollen daran arbeiten, aber 10 Stück sind okay, da ist nichts kaputt, das ist quasi unser normales Grundrauschen.
Daniel Langemann: Das ist die Realität.
Daniel Langemann: Ja.
Kai Ole Hartwig: Das fühlt sich so falsch an, aber das kann ja sein.
Kai Ole Hartwig: Genau, wir wissen ja alle, wie das manchmal so ist.
Kai Ole Hartwig: Und dann hast du aber auf einmal 60, dann macht es ja Sinn, dass du ab einer gewissen Schwelle, die über 10 liegt, trotzdem ein Alerting machst.
Kai Ole Hartwig: Und nicht halt sagst, ja, okay, 500er sind für uns normal.
Kai Ole Hartwig: Sondern dann musst du halt auch sagen, okay, für uns ist ein Grundraufen in der Höhe normal.
Kai Ole Hartwig: ähm, aber wenn es darüber rausgeht, ja, dann, dann brauche ich eine Information.
Daniel Langemann: Eine Veränderung um x Prozent.
Daniel Langemann: Wobei das schwer ist.
Daniel Langemann: Also gerade bei Exceptions und Ausnahmen, wenn das Crown-Jobs sind zum Beispiel, dann ist das ja vorhersehbar, welches Grundrauschen die erzeugen, wenn die alle x Minuten starten.
Daniel Langemann: Bei Nutzern ist das schwerer.
Kai Ole Hartwig: Ja, aber der läuft ja auch auf einem eigenen Pod, da kannst du ja das Erleitung schon wieder entsprechend zuschneiden.
Daniel Langemann: Ja.
Kai Ole Hartwig: Also, ich hoffe, es läuft auf einem scheduled Pod, ähm,
Daniel Langemann: Sie hängt von der Architektur ab, ja.
Daniel Langemann: Aber zum Beispiel, das lockt das trotzdem mit rein in das Dashboard mit allem drum und dran.
Kai Ole Hartwig: Ja, natürlich, aber dann musst du halt entsprechend filtern.
Kai Ole Hartwig: Das gehört ja auch zum Einrichten vom Monitoring, dass man sagt, man richtet es sinnbehaftet ein und sinnvoll ein und sagt jetzt nicht, naja, gut, ich schmeiße jetzt hier alles rein und über alle Services möchte ich nur, naja, wenn man halt gerade, wenn man so problematische Dinge hat, muss man natürlich sagen, okay, ich brauche
Daniel Langemann: Ja.
Kai Ole Hartwig: Jetzt sind wir in der wunderbaren Kubernetes-Welt und können halt sagen, okay, wir haben da sehr unterschiedliche Ebenen, auf die wir draufschauen können.
Kai Ole Hartwig: Meistens muss man ja sagen, okay, der Service ist eigentlich das, wo wir draufschauen wollen.
Daniel Langemann: Ja.
Kai Ole Hartwig: Weil es ist ja auch kritisch, wenn ich jetzt fünf Pods da habe und einer schmeißt aber die ganze Zeit Fehler, okay, dann ist irgendwie die Entscheidung, dieser Pod muss weg und ein neuer muss starten.
Kai Ole Hartwig: aber dann macht es ja trotzdem Sinn, mein Alerting, mein Monitoring auf Service-Ebene zu haben und dann zu erkennen, ah, wir haben einen Pod, der ist irgendwie auf einer schlechten Note gelandet und hat da Probleme, keine Ahnung.
Daniel Langemann: Ja, genau das sind ja Sachen, die du dann aggregieren kannst und sogar adressieren kannst und sagen kannst, guck mal, weiß ich nicht, 500er, die nach einem Deployment oder 500er, die durch die Decke gehen, das ist einfach ein Ding, da muss das Alerting den Entwicklern Bescheid sagen.
Kai Ole Hartwig: Ja.
Daniel Langemann: Ist das aber so Fehlermeldungen, die aus der Infrastruktur kommen?
Daniel Langemann: Also weiß ich nicht.
Daniel Langemann: Andere Sachen davor, andere Loks, die anschlagen, wo Sachen.
Daniel Langemann: Da kannst du sagen, guck mal, das ist ja eher was so für Ops oder für diejenigen, die für den Betrieb zuständig sind.
Daniel Langemann: Hast du dann Metriken, die so eher in Richtung Umsatz, Kunden oder, ne, also vielleicht hast du auch irgendwo was drin, was Reklamationen oder solche Sachen betrifft, ne, also zum Beispiel Bewertungen und, und, und, und da verändern sich Sachen, da sind wieder ganz andere, ne, andere Zielgruppe, die da benachrichtigt werden muss.
Kai Ole Hartwig: Ja, und ich bin auch immer ein großer Freund von Kaskaden, also das ist hoch eskaliert automatisch.
Daniel Langemann: Was ich aber...
Daniel Langemann: Immer den Chef in CC, okay.
Daniel Langemann: Okay.
Daniel Langemann: Okay.
Kai Ole Hartwig: Naja, nicht immer den Chef in Sitzig, aber ab einer bestimmten Dauer oder Häufigkeit oder also Schwere des Problems bin ich der Meinung, dass automatisch das durchaus bis Zielevel hoch eskaliert werden muss und kann und soll.
Daniel Langemann: Habe ich bis jetzt noch nicht gehabt, weil für mich war das so, es gibt denen, die Verantwortlichen, die kriegen diese Info und was sie damit machen.
Daniel Langemann: Wenn die die verschweigen, dann hat das hoffentlich einen Grund und die sind fachlich Experten genug, dass da zum Beispiel das nicht gemeldet werden muss.
Daniel Langemann: Wenn du dann natürlich das hast, dass sie, also wenn Leute solche Sachen ignorieren oder nicht ernst nehmen, dann hast du aber ein grundlegendes Problem.
Kai Ole Hartwig: Ich gehe ja immer davon aus, die Leute sind dann schon im Stress, in der Chaosphase der Katastrophe.
Daniel Langemann: Das ist ganz was für die Hochenlage.
Daniel Langemann: Aber, hm.
Kai Ole Hartwig: So, jetzt kommt ja wieder mein Blaulichtmilieu bei mir durch, wo ich sage, die Chaosphase können wir nicht vermeiden, da haben wir auch Kommunikationschaos, wir haben
Kai Ole Hartwig: den Personal- und vielleicht Ressourcenmangel.
Kai Ole Hartwig: Also es gibt einen Mangel und deswegen funktioniert auch Kommunikation nicht.
Kai Ole Hartwig: Und jetzt bricht der Umsatz gerade auf null ein.
Kai Ole Hartwig: Länger als eine halbe Stunde, schon eine Stunde.
Kai Ole Hartwig: Also es gibt echte Probleme.
Kai Ole Hartwig: Genau.
Daniel Langemann: Reales Beispiel.
Daniel Langemann: Also war ja so.
Daniel Langemann: Und was ich jetzt nicht gesagt habe und natürlich unausgesprochen angenommen habe, ist, es gibt unterschiedliche Rollen.
Daniel Langemann: Natürlich kriegt das Team die Info oder im Team verteilt sich die Info.
Daniel Langemann: Und das hat immer dazu geführt, dass ich...
Daniel Langemann: Wir hatten halt so die Abstimmung, wenn sowas passiert, ist Slack zu und aus.
Daniel Langemann: Oder zumindest gemutet und die drei Entwickler, die da im Team sind, sitzen zusammen und lösen das Problem.
Daniel Langemann: Der PO hatte auch die Info und der war der Einzige, der zu den Entwicklern durchgekommen ist und der hat sich um die Kommunikation gekümmert.
Daniel Langemann: Weil natürlich alle Leute sagen, oh, guck mal, unser Shop ist offline, ich helfe den Entwicklern mal, indem ich denen auch nochmal eine Info schicke, wie die anderen 600 Mitarbeiter.
Daniel Langemann: Und jeder will dir helfen.
Daniel Langemann: Also natürlich muss das geklärt sein.
Daniel Langemann: Also müssen diese Rollen klar sein, dass du sagen kannst, guck mal, wenn die Entwickler das mitkriegen oder jemand sagt den Entwicklern Bescheid, dann gehen die in ihre kleine Höhle und konzentrieren sich darauf, den Fehler zu lösen, so schnell wie möglich.
Daniel Langemann: Holen sich Leute dazu, die sie brauchen, um das zu lösen.
Daniel Langemann: Und der Einzige, der dann, also im Team, der die Kommunikation übernimmt, kann Scrum Master sein, kann Product Owner sein, kann Teamleiter sein oder Lead Dev von mir aus, eine Person, dass alle da aufschlagen.
Kai Ole Hartwig: Genau, und die Annahme, die ich mit drin habe, ist, diese Person ist auch ausgelastet und achtet nicht auf die Zeit in dem Stress.
Daniel Langemann: Mhm.
Kai Ole Hartwig: So, und irgendwann wird ja die Situation so, dass sie so kritisch ist, dass es halt
Kai Ole Hartwig: C-Level betrifft und das C-Level informiert sein muss und handlungsfähig werden muss und deswegen wirklich eine Kaskade, natürlich mit entsprechender Zeit und so weiter, also ordentlich ausgearbeitet, nicht einfach, oh, das ist jetzt fünf Minuten offline, jetzt geht die E-Mail an den Chef raus, sondern vernünftige Eskalationsstufen drin sind, aber halt automatisiert, damit diese Information automatisiert weitergetragen wird und nicht verloren geht.
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ja, also ich sage jetzt mal, erst mal es tritt was auf, Junior Dev wird informiert.
Kai Ole Hartwig: So, der bekommt das Ganze in Zeitraum X, sagen wir mal 15 Minuten, nicht gelöst.
Kai Ole Hartwig: Dann geht quasi das weiter und Senior Dev wird informiert.
Kai Ole Hartwig: Der schaut drauf und bekommt es auch in Zeitraum X nicht gelöst.
Daniel Langemann: Kündigung raus, nächster informieren.
Kai Ole Hartwig: Dann
Daniel Langemann: Mhm.
Kai Ole Hartwig: So, und dann geht es halt an PO und so weiter, weißt du?
Kai Ole Hartwig: So diese Kaskade in der Annahme.
Kai Ole Hartwig: Erst immer, okay, das ist vielleicht etwas, was leicht zu lösen ist und dann geht man halt höher, holt mehr Leute dazu, mehr Erfahrung dazu, mehr Verantwortlichkeit und verteilt damit auch die Verantwortlichkeit und nimmt sicher auch selber ein Stück den Druck raus.
Kai Ole Hartwig: Wenn quasi der PO, der Chef, der CTO, CEO, der
Kai Ole Hartwig: informiert werden darüber, dann wissen die aber ja auch schon, okay, das läuft jetzt ja schon eine Zeit, die sind da ja schon dran,
Daniel Langemann: Zumindest, dass sie dann kommunizieren können oder weitere Sachen veranlassen können, ja.
Daniel Langemann: Hm.
Kai Ole Hartwig: einfach weitere Sachen veranlassen können und auch selber informiert sind und handlungsfähig sind.
Kai Ole Hartwig: Das ist immer so mein Gedanke in diesen ganzen Dingen.
Kai Ole Hartwig: Das, was nämlich in Krisen nie gut funktioniert, in dieser Chaosphase der Katastrophe, ist nämlich die Kommunikation.
Kai Ole Hartwig: Die Kommunikation bricht immer als erstes zusammen.
Kai Ole Hartwig: Wir wissen aus genug
Daniel Langemann: Aber ohne, dass ich Ahnung davon habe, werfe ich jetzt das Fachwort Triage rein.
Daniel Langemann: Was haben wir noch gar nicht in der Uhrzeit?
Kai Ole Hartwig: Ja.
Daniel Langemann: Also nicht jeder Alarm ist ja gleich schlimm.
Daniel Langemann: Also wenn das Import-Tool kaputt ist und, weiß ich nicht, die neuen Produktdaten nicht reinkommen, ist es nicht jeder, zum Glück.
Kai Ole Hartwig: Ja, nicht jeder stirbt in der Katastrophe, genau.
Daniel Langemann: Ja.
Kai Ole Hartwig: Aber das Leben ist schon ein vorübergehender Zustand.
Kai Ole Hartwig: So.
Daniel Langemann: Oh mein Gott, jetzt werden wir esoterisch, ja?
Daniel Langemann: Ja, ja, ja.
Daniel Langemann: Und sowas lässt du vom Stapel ohne Kaffee.
Kai Ole Hartwig: Das ist nicht esoterisch, das ist harte Realität, Daniel.
Kai Ole Hartwig: Also.
Kai Ole Hartwig: unsere Zeit auf dieser Murmel, auf der wir hier rumfliegen, ist begrenzt.
Kai Ole Hartwig: Zumindest mit dem bewussten Bewusstsein, soweit wir das beurteilen können.
Kai Ole Hartwig: Ja, ich musste ja auf Rum umsteigen.
Kai Ole Hartwig: Nein, aber... Ja, genau.
Daniel Langemann: Du trinkst nicht Kaffee mit Schuss, sondern Schuss ohne Kaffee, ne?
Daniel Langemann: Boah, ja.
Daniel Langemann: Also es wird Zeit.
Daniel Langemann: Also
Kai Ole Hartwig: Wir krock jetzt, Tee mit Rum.
Kai Ole Hartwig: Gorkmus, wie war das?
Kai Ole Hartwig: Tee, Zucker kann Wasser oder ich weiß es nicht mehr.
Kai Ole Hartwig: Also egal, Gorkrezept kann ich jetzt nicht auswendig spontan.
Kai Ole Hartwig: Aber natürlich, ja, Triage von Fehlern und so gehört natürlich auch dazu.
Kai Ole Hartwig: So, da habe ich jetzt aber keine gute Metrik.
Kai Ole Hartwig: Also ich sage immer, in dem Blaulichtmilieu, wo ich unterwegs bin,
Daniel Langemann: Ja genau, und darauf wollte ich hinaus, das kann der Mensch einfach besser.
Daniel Langemann: Dieses Beurteilen und sagen, guck mal, da gehen gerade Sachen, haben wir deployed, wir haben nichts deployed und auf einmal passieren Sachen, dann ist das ja was anderes, als wir haben gerade deployed und überall gehen alle roten Lämpchen an oder so und die Mutterkontrollleuchte leuchtet und alles geht.
Daniel Langemann: Da würden auch die Entwickler ja direkt sagen, komm, wir setzen uns alle zusammen, alle, die daran beteiligt waren, Brainstorming halbe Stunde oder und fixen das.
Kai Ole Hartwig: Ich sage jetzt mal, Abläufe und Algorithmen dazu sind eigentlich ursächlicher Bestandteil des BCM, des Business Continue.
Daniel Langemann: Du wolltest keine Fachwörter heute benutzen.
Kai Ole Hartwig: Hast du nicht gesehen?
Daniel Langemann: Lass das.
Daniel Langemann: Ich passe das BCM.
Daniel Langemann: Okay.
Kai Ole Hartwig: Business Continue Management, also die Planung, wie es sein kann, den Betrieb wieder aufzunehmen.
Kai Ole Hartwig: Also gehen wir mal davon aus,
Kai Ole Hartwig: Wir treffen jetzt völlig in ein neues Thema.
Kai Ole Hartwig: Egal.
Kai Ole Hartwig: Kurz zusammenfassend.
Kai Ole Hartwig: Wir gehen mal davon aus, das Rechenzentrum ist abgefackelt, wo alle deine Daten drin liegen.
Kai Ole Hartwig: Du hast aber, weil du schlau warst und das im BCM geplant hast, ein Offsite-Backup.
Daniel Langemann: Daniel muss auch den Roller und das Backup holen.
Kai Ole Hartwig: Dann steht in deinem BCM auch drin, wie läuft das denn jetzt ab, dass es jetzt wieder losgeht.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Wie läuft das?
Kai Ole Hartwig: Ja, genau, so, also diese Abläufpläne, was passiert wann, dass man das mal geplant hat und vor allem auch durchgespielt hat, das ist jetzt im Kritis-Bereich im Übrigen wesentlich relevanter, aus meiner Sicht, als so jetzt im Geschäftsbetrieb, aber natürlich, auch im normalen Geschäftsbetrieb muss so etwas geplant sein und muss vorhanden sein.
Kai Ole Hartwig: Ich glaube, ich bin mir jetzt nicht zu 100% sicher, aber ich meine, es ist
Kai Ole Hartwig: im Rahmen der ISO 27001 auch Pflichtbestandteil, das WCM.
Daniel Langemann: Okay, also Fachwort noch nicht gehört, aber ja.
Kai Ole Hartwig: IT-Sicherheit, in den IT-Sicherheitsmanagementsystemen sollte auch immer drin sein, geht es denn jetzt weiter.
Daniel Langemann: Vollkommen bei dir.
Kai Ole Hartwig: Ja, aber
Daniel Langemann: Wer ist alles zu informieren?
Daniel Langemann: Also welche Abteilung, welche Abteilung betrifft das?
Daniel Langemann: Ist ja auch immer so ein Thema, was relevant ist.
Daniel Langemann: Also zum Beispiel Customer Care kannst du, oder Kundensupport kannst du direkt anrufen und sagen, hier, wir wissen, Problem, arbeiten dran.
Kai Ole Hartwig: Ja, was machst du, wenn das Büro abgefackelt ist?
Daniel Langemann: Und
Daniel Langemann: Feierabend.
Kai Ole Hartwig: Ja?
Kai Ole Hartwig: Passt.
Kai Ole Hartwig: Sollten wir das auch machen mit dieser Folge.
Daniel Langemann: Ja.
Daniel Langemann: Müssen wir bei der nächsten weitermachen.
Kai Ole Hartwig: Was für ein Ende.
Kai Ole Hartwig: Gut, das war eine wunderbare Folge.
Kai Ole Hartwig: Secrets not included.
Kai Ole Hartwig: Wir überlegen dann mal, wie unser BCM-Konzept für den Podcast aussieht oder so und freuen uns auf nächste Woche.
Daniel Langemann: Ja.
Kai Ole Hartwig: Macht's gut.
Kai Ole Hartwig: Ciao, ciao.
