# Overcoming Friday Deployment Fears in Modern Engineering Teams

**Podcast:** Engineering Kiosk
**Published:** 2026-05-12

## Transcript

Willkommen zu einer neuen Episode vom Engineering Kiosk Podcast.
Es ist Freitag, 16.47 Uhr.
Der Pull-Request ist grün.
Drückst du nun auf Deploy oder schiebst du das Thema lieber ganz elegant in die Zukunft, also auf den Montag?
Genau um diesen Klassiker geht es heute, um Friday-Deployments, um Angst vor Produktionsfehlern, um kaputte Prozesse und um die Frage, ob das eigentliche Problem wirklich die Technik ist?
Oder doch eher wir Menschen?
Um das zu diskutieren, haben wir uns Verstärkung geholt.
Zu Gast ist Sucivan.
Vielen vielleicht auch bekannt aus dem Tillpot, als ehemaliger Solutions-Architekt bei GitLab und Grafana, als Buchautor rund um Git und DevOps und inzwischen mit seiner wunderbar provokanten Firma Friday Deployments GmbH unterwegs.
Mit ihm sprechen wir darüber, warum Freitag-Deployments in vielen Teams fast schon als tabu gelten, welche technischen Sicherheitsnetze wirklich helfen, von CI und CD, Staging und Monitoring bis Feature-Flags, Blue-Green und Canary-Deployments.
Aber wir schauen auch auf die unbequeme Seite, auf Kultur, auf Verantwortung, On-Call, Blameless Post Mortems, Freigabeprozesse und die Angst, am Wochenende aus dem Grillabd gepaget zu werden.
Die wichtigste Frage ist also nicht nur, ob du freitags deployen solltest, sondern ob dein Team es überhaupt könnte.
Genau da steigen wir heute ein.
Viel Spaß mit dieser Ecke.
Wolfgang, ich bin mir jetzt nicht sicher, ob ich dir jetzt eine Quizfrage oder eine Fangfrage stelle.
Hör gut zu.
Freitag, 16.47 Uhr.
Der Pull-Request ist grün.
Drückst du auf Deploy oder lässt du es wirklich bis Montag liegen?
Falsche Antworten only.
Hallo, ich bin selbstständig.
Also ich bin selbst und ständig.
Das heißt, Wochenende gibt es bei mir sowieso nicht.
Das heißt, ich deploye 24 Stunden, muss es dann aber immer selbst fixen und ich kann es nicht mal abschieben auf dich.
Weil wenn ich was deploye, dann muss ich es leider selber fixen und nicht mein großes Team, das ich zur Verfügung habe.
Das kennst du nicht, Andi, als Manager, aber bei mir wird noch Hand angelegt.
Ja, ich habe ja meine Leute dafür, würde ich jetzt rechnerweise sagen.
Aber Wolfgang, ich kenne ja auch deine Ausrede.
Du bist ja Berater und kein outgesorster Mitarbeiter.
Also mit Programmieren hast du es ja eh nicht mehr so.
Von daher kannst du ja Freitag um 16.47 Uhr auch nicht mehr deployen.
Aber du warst ja auch mal Engineering Manager und hast ja Leute gehabt, die die Arbeit gemacht haben.
Und da hattest du sehr wahrscheinlich auch schon mal Druck von oben bekommen, dass um Freitag 16.47 Uhr das Feature noch raus muss.
Bist du dann im Team eher auf technische Hürden gestoßen oder auf, oh nee, wir deployen jetzt nicht, ich bin morgen on call?
Also eher so auf, kann man das ein Kulturproblem nennen?
Ja, ich glaube schon.
Also ich habe eigentlich beides erlebt.
Es hat ein Team gegeben, da haben wir ein, ich würde es mal Greenfield-Projekt nennen, gestartet.
Und da waren diese ganzen Checks und Sicherheitsnetze alle verfügbar und da hat das Team von sich aus eigentlich deployed, wie es Lust gehabt hat.
Und das war nie ein Problem.
Hingegen, wenn ich so diese, ich nenne es mal Legacy-Codebase betrachte, da war es ein sehr großes Problem.
Ein technisches oder ein kulturelles?
Beides.
Also da war die technische Grundlage schon ein Problem und dadurch war es natürlich kulturell erst recht ein Problem, weil niemand das am Wochenende fixen wollte.
Okay, aber wir wissen ja alle, Legacy verdient das Geld, deswegen hat das C-Level sehr wahrscheinlich entschieden, es wird trotzdem deployed.
Ist mir völlig egal, ob es ein technisches oder ein kulturelles Problem ist.
Und das zeigt ja gerade diesen Konflikt hier, warum...
Freitags-Deployment irgendwie so ein komischer Mythos sind.
Und das ist genau das Thema dieser Episode.
Dazu machen der Wolfgang und ich jetzt keine Philosophie-Stunde, sondern wir haben jemanden angefragt, der damit, ich würde mal fast sagen, sein Geld verdient und vor kurzem sogar einen Talk gehalten hat zu dem Thema Freitags-Nachmittags-Zeit für ein Deployment.
Und ich begrüße Suczyvian.
Hallo.
Hi.
Deine Stimme kennt man vielleicht schon, denn du bist ebenfalls Podcast-Profi.
Und zwar machst du seit mehr als sechs Jahren inzwischen, seit 2020.
Seit sechs Jahren, Andi.
Stell dir das mal vor, wir haben es erst vier Jahre geschafft.
Sechs Jahre.
Und jetzt sei du mal wieder höflich und lass mich lieber ausreden.
Wir sind hier nicht bei kleinen Kindern.
Ja, aber das solltest du nach vier Jahren wissen, dass das auch vorbei ist.
Dieser Zug ist abgefahren.
Du machst mit dem Dirk den schönen Podcast Tillpot, der eigentlich nicht für Today I Learned steht.
Wofür steht Till in diesem Kontext?
Naja, also ursprünglich dachten wir an Today I Learned und dann war ich bei einem anderen Podcast mal zu Gast, nämlich bei einem Programmierbar-Podcast.
Da meinten die so, das steht doch für Things I Learned, oder?
Und ich dachte dann so, das macht eigentlich viel mehr Sinn.
Weil ja, wir reden über Dinge, die wir zuletzt gelernt haben und dadurch ist der Name entstanden.
Das ist auf jeden Fall eine Podcast-Empfehlung für alle, die den Podcast noch nicht kennen.
Grüße gehen raus, auch an den Dirk.
Aber, wer bist du wirklich?
Endlich mal haben wir einen Gast aus dem Pott.
Das freut mich sehr.
Wolfgang, ein bisschen Erdkunde.
Duisburg liegt im Ruhrgebiet, ist natürlich die schönste Stadt im Ruhrgebiet.
Direkt danach kommt jetzt für diesen Podcast Kastro Brauchsel.
Ich habe schon Schwierigkeiten, das auszusprechen.
Also so G-Venny ist leichter auszusprechen als was?
Kastro Brauchsel.
Ich kenne Kastro Transporte.
Hat das was damit zu tun?
Nicht ganz, nicht ganz, war fast.
Aber aus Kastrop-Rauxel hattest du berufliche Stationen, wie zum Beispiel als Solution-Architekt bei GitLab oder auch als Solution-Architekt bei Grafana.
Aber inzwischen arbeitest du bei beiden Firmen nicht mehr, denn du bist nämlich selbstständig und trollst jetzt so ein bisschen mit deinem neuen Firmennamen, wo ich sage, der geilste Firmenname, der mir in letzter Zeit untergekommen ist, und zwar hast du die Friday Deployments GmbH gegründet.
Ich weiß nicht, ob das jetzt irgendwie ein jahrelanger Plan war, um in diesen Podcast eingeladen zu werden.
Aber du warst teilweise auch schon, auch nicht nur teilweise, schon mehrfach als Buchautor unterwegs.
Wenn ich das richtig gezählt habe, von fünf Büchern, Versionsverwaltung mit Git.
Dann hast du ein Buch über den Schnelleinstieg in Git geschrieben und ein ganz berühmtes Buch über DevOps, wie IT-Projekte mit einem modernen Toolset und der richtigen Kultur gelingen.
Und?
Wenn du mal nicht vor dem Computer sitzt, dann läufst du auch Ultramarathons.
Und da hast du mir ein Funfact erzählt, den konnte ich leider nicht googeln.
Danke, dass du mir den erzählt hast.
Du bist mal Letzter bei einem Ultramarathon geworden.
Ist das richtig?
Das ist richtig.
Was heißt Letzter bei einem Ultramarathon?
Also wovon reden wir da?
Also Ultramarathon ist ja erstmal alles, was über einem Marathon ist, also über 42,2 Kilometer.
In der Regel meistens so 50 Kilometer plus.
Und in dem Fall auch ein Trail-Marathon, das heißt, man ist dann halt eher in Wäldern, Bergen unterwegs.
Und ich laufe quasi jedes Jahr in der Zugspitze den Zugspitz-Ultra-Trail mit.
Und vor zwei Jahren oder drei Jahren, also vor drei Jahren, als ich das erste Mal da mitgelaufen bin auf...
ich glaube, das waren 68, 69 Kilometer, bin ich nach 18 Stunden als Letzter ins Ziel gekommen.
Von denen, die es geschafft haben.
Es sind auch viele ausgestiegen.
Ich wollte gerade sagen, das Finischen an sich ist ja schon eine Leistung, definitiv.
Genau, weil ich habe ein paar Mal halt auch nicht geschafft.
Das ist dann halt auch in Ordnung.
Aber Letzter muss man auch erstmal schaffen.
Übrigens, wir hatten gestern einen Call mit den Jungs von Index Out of Bounce und der Christian von Index Out of Bounce sucht einen Buddy für seinen Ultramarathon von, keine Ahnung, 80 Kilometer oder so.
Vielleicht willst du ja mit ihm laufen, das wäre eigentlich ideal.
Oder wenn es sonst jetzt jemand gerade zuhört, Index Out of Bounce sucht noch Buddies zum Laufen.
Wolfgang, krieg mal die Fakten zurecht.
Der Christian sucht nicht jemanden für einen Ultramarathon, der sucht jemanden für einen Mammutmarsch.
Das ist ja dasselbe.
Das ist nicht dasselbe.
Also da merkst du einfach, der Sportmobil Wolfgang kriegt man wieder die ganzen Sachen nicht zusammen.
Ja, wer das eine kann, kann das andere auch.
Das ist gar nicht so weit entfernt, das geht schon.
Wer auf dem Berg rauflaufen kann...
Ein Ultramarathon, der bekommt auch noch flachbar 10 Kilometer mehr rauf oder so.
Ja, das ist dann einfach.
Flach ist einfacher auch, wenn es länger ist.
Aber kommen wir mal zum Extrem-Deployment zurück, also zum Fridays-Deployment.
Du kommst ja aus der ganzen GitLab-Welt, Grafana-Welt, da war alles wahrscheinlich schön und grün, vor allem die ganzen Pipelines waren grün und alles war gar kein Problem am Freitag zu deployen.
Jetzt bist du...
im ganzen Consulting-Wesen drin und hast plötzlich mit dem deutschen guten alten Mittelstand zu tun.
Wie würdest du die aktuelle, es ist so schön, jetzt kann ich endlich mal im Podcast so eine politische Frage stellen, wie schätzt du denn so die Lage in Deutschland ein, wenn es um Freitags-Deployments geht, wenn man auf den Mittelstand blickt?
Hast du gerade geglaubt, irgendwas ist kaputt?
Ja, siehst du, so geht es mir auch oft.
Und dann brauche ich unbedingt einen Kaffee.
Oder wie der Andi sagen würde, einen Kaffee.
Und für diese Koffeinenergie die ihr uns durch diese Kaffeespenden bereitstellt und die es uns eigentlich erst ermöglichen, diese Episoden zu produzieren, möchten wir uns einmal bedanken.
Und zwar bei den letzten Spendern.
Daniel, Jakob, Peter, Alfred, Florian, Michel, Dimo, David, Lukas, Adrian, Nico, Matthias, Wolfgang, by the way, schöner Name, Elias, Björn, Franco, Dominik, Paul und Fabian.
Und egal, ob ihr uns einen Kaffee sponsert oder vielleicht sogar ein Kaffee-Abo wie der Fabian oder einen ganzen Monatsbedarf an Kaffee wie der David, wir schätzen jeden einzelnen Kaffee und freuen uns wirklich über dieses ganze Koffein-Feedback.
Vielen Dank von Andi und von mir und jetzt geht es auch schon wieder zurück zur Episode.
Also, vielleicht sollten wir noch mal ein bisschen kurz darüber unterhalten, was ich dann bei GitLab genau gemacht habe als Solutions Architect.
Also, es war eine Pre-Sales-Rolle.
Also, es ging effektiv darum, dass ich den Leuten erkläre, was kann GitLab in den Enterprise-Varianten, welche Features sind da drin, in Premium, Ultimate, Security, Compliance und hast du nicht gesehen.
Und da habe ich halt vor allem alles aus dem deutschsprachigen Raum, Kunden plus 2000 Mitarbeitende, mit denen gesprochen.
Und da bekommt man halt einen sehr, sehr guten Überblick darüber, wie der technische Zustand der Software Delivery Lifecycle in den ganzen verschiedenen Firmen halt sind, also Mittelstand bis Konzern.
Und das ist immer super spannend, wenn man dann die Außendarstellung von den verschiedenen Firmen sieht, was sie so posten, was sie sagen öffentlich.
Und wenn man dann mit den Firmen spricht und dann mal tatsächlich mal sieht, wie sie arbeiten.
Es ist ein himmelweiter Unterschied.
Und was würdest du sagen?
Ist es gut?
Ist es schlecht?
Luft nach oben gibt es immer.
Sehst du einen Unterschied zwischen Konzern und Mittelstand?
Ich persönlich habe die Erfahrung gemacht, dass mancher Mittelstand durchaus unterschätzt wird, auch wenn es um die Fähigkeiten geht, also um die technischen Fähigkeiten.
Wie würdest du da auf Deutschland blicken natürlich?
Ja, also ich würde eher sagen, dass der Mittelstand ist eher besser, schneller, effizienter unterwegs als die Großkonzerne.
Und mit Großkonzern meine ich dann halt mit mehreren tausenden Mitarbeitenden.
als der Mittelstand halt auch eben.
Hat natürlich auch ein bisschen strukturelle Vor- und Nachteile beides jeweils, sodass man dann halt auch sieht, okay, große Versuche dann manchmal auch das Rad neu zu erfinden.
Mittelstand kann dann doch ein bisschen agiler sein, weil die dann nicht so viele Abhängigkeiten zu irgendwelchen anderen Tools, wo sie was anschließen müssen, halt sein müssen.
Wenn du jetzt eine Prozentzahl sagen müsstest, von dem, was du gesehen hast, wie viel Prozent der Firmen deployen am Freitag?
Eigentlich muss ich die Frage stellen, wäre die Pleut überhaupt regelmäßig?
Okay, wir müssen weiter unten anfangen.
Genau, ja, deswegen, das ist so ein bisschen, also aus meinen alten Rollen habe ich halt meistens auch immer nur mit den Teams geredet, die schon relativ modern unterwegs waren.
Aber wenn man die dann abgefrühstückt hat, dann spricht man oder sieht man dann halt die Teams, die halt nicht so sind.
nicht so modern sind, wo schon der neueste heiße Scheiß quasi mit drin ist, was man so von Konferenzen sieht.
Weil wenn man mal auf Konferenzen geht, dann sieht man immer so, ah ja, der macht hier mit Feature-Flex und echtes CICD mit hunderten Deployments pro Tag und hast du nicht gesehen.
Und dann merkt man eigentlich so, naja, es ist ein grüne Visa-Projekt, es ist ein kleines Projekt innerhalb von einer größeren Firma vielleicht.
Und wenn man sich dann aber die eigentlichen Cash-Cows ansieht, da sieht es wieder ganz anders aus.
Ist das nicht auch irgendwie Survivorship-Bias?
Im Endeffekt heuert man ja dich an oder Berater, wie kann ich freitags deployen, wenn ich freitags nicht deploye?
Deswegen war ja eigentlich die Frage von Wolfgang ja eigentlich mehr oder weniger schon eine Fangfrage.
Ja, vor allem ist das halt eh schwierig, weil es kommt halt sehr stark auf die verschiedenen Teams an.
Ja, und auch in einem Konzern.
Im Konzern hat ja nicht nur zwei Teams oder eine Applikation, sondern eine vierstellige Anzahl an Applikationen ja oft.
Eben, vor allem auch diese Zahlen, die man so von Netflix, Amazon und Co.
hört.
Wir machen 5000 Deployments oder sowas pro Tag.
Ja, okay, aber was ist das jetzt, wenn du jetzt jeden Microservice mitzählst?
Ja, aber ich meine, große Zahlen beeindrucken ja immer.
Lass uns mal ganz kurz in diesen Mythos Freitagsdeployment einsteigen.
Wir haben das jetzt so eigentlich schon angesprochen, als wäre das Gang und Gäbe und jeder wüsste, was denn eigentlich ein Problem ist.
Aber warum ist freitags ein Problem beim Deployment?
Vielleicht soll ich auch noch ein bisschen erzählen, warum ich die Firma überhaupt so genannt habe.
Also da sind mehrere Sachen, die so ein bisschen zusammenspielen.
A, ich habe überhaupt einen Firmennamen gesucht und dann war natürlich ein lustiges, war natürlich auch schön.
Aber es sollte auch irgendwo eine Message mit drin sein.
Das Schöne ist, wenn man die Firma Friday Deployments nimmt, die sagt jeder sofort, was er darüber denkt.
Was auch immer gute Gesprächseinstiege sind, weil dann kann man das immer so schön challengen.
Weil die meisten, mit denen ich rede oder die mir ihre Meinung sagen, sagen wir so, die sagen dann so, oh Gott, das würde ich doch nie tun, weil ich will doch Wochenende haben.
Und das sind meistens auch die Leute, die Bereitschaft haben am Wochenende oder halt die typischen Admins sind.
Aber ich frage mich gerade, wie viele Applikationen fehlen 24 Stunden nach dem Deployment und nicht sofort oder beziehungsweise in sehr naher Zukunft?
Also was heißt das denn, wenn ich Freitag morgens um 8 oder um 9 deploye?
Dann habe ich ja eigentlich noch theoretisch den ganzen Arbeitstag zu fixen.
Richtig.
Und jetzt kommt die Ausrede.
Oder vielleicht auch dein Trollhack.
Ich nenne die Firma so und jeder lacht mir, was er denkt.
Finde ich genial.
Die gehen ja alle davon aus, wie viele Wochenende haben samstags.
Das bedeutet, okay, du hast einen Delay.
Klar, vielleicht hast du irgendwie einen Badge-Job oder so was oder irgendwelche Zeitintervalle.
Das verstehe ich ja alles.
Aber ich rede jetzt mal einfach von einer Web-Applikation oder ähnlich.
Ich rede jetzt nicht von irgendeiner iOS-App, wo du den Rollout ja eh nicht kontrollieren kannst.
Mhm.
Zumindest wenn du keine Feature-Activation drin hast.
Da gibt es ja auch Hacks.
Aber wie oft ist das denn wirklich ein Problem, dass du versetzte Outages hast?
Ja, vor allem ist auch die Frage, die nächste Frage, macht das einen Unterschied, ob es ein Montag oder ein Freitag ist oder ein Dienstag?
Wenn es eh mitten in der Nacht passiert.
Ja, Moment mal, aber wenn du jetzt 24 Stunden versetzt hast, dann ist ja auch die Frage, darfst du überhaupt noch Donnerstagmittag deployen?
Dann ist ja Donnerstag vorm Mittagessen ja eigentlich schon Ende, oder?
Ja, frage gerne die 5Y-Fragen, wo man fünfmal fragt, warum.
Oder wir simulieren das mal.
Sag mal, Andy, deployst du am Freitag?
Nein.
Warum?
Ich habe Angst, dass es Samstag kaputt geht.
Und was machst du, wenn du dann am Donnerstag deployst?
Dann fixe ich es am Freitag.
Ja, aber warum hast du Angst, dass was kaputt geht?
Ja, da könnte ja immer nur ein Commit sein, den ich übersehen habe in einem Bug.
Ja, und warum testest du das nicht ordentlich vorher?
Ja, ja, das geht halt immer so weiter.
Also ich meine, theoretisch kann man ja auch vielleicht sogar sagen, okay, warum shipt man neue Features überhaupt ohne Feature-Fleck und dann einfach ohne Deployment aktivierbar oder nicht aktivierbar zu machen?
Aber ja, ich frage mich gerade, ist das Ganze überhaupt ein Technikproblem?
Ja und nein.
Was heißt ja und nein?
Wann ist es ein Technikproblem?
Fangen wir mal so an.
Das eine Ding ist, was man häufig halt auf diesen Konferenzen, sage ich jetzt mal so klassisch hört, so naja, so richtet man das ein.
Wir haben hier Kubernetes und hast du nicht gesehen.
Worauf ich aber gerade auch noch hinaus will ist, naja, es kommt ja auch ein bisschen darauf an, wie oft du überhaupt deployst.
Wenn du alle drei Monate deployst, dann macht es vielleicht sogar mehr Sinn, Freitag zu deployen, auch wenn viele sagen nein, weil du dann das Wochenende hast, was zu fixen.
Je nachdem natürlich, welche Kunden da drauf sind.
Aber grundsätzlich ist es eigentlich kein großes technisches Problem, weil du das kannst vieles ja lösen und mit Technik erschlagen.
Kommen wir gleich ja auch wahrscheinlich noch zu, oder?
Ich sage nur mal so Feature-Flags, Blue-Green-Deployments, Canoe-Deployments, ordentliches Monitoring, ordentliche Staging-Umgebungen, ordentliche Tests vorher auch laufen zu lassen.
Da gibt es ja diverse Sicherheitsnetze, die man machen kann.
Aber nur weil es technisch richtig funktioniert, heißt es ja immer noch nicht, dass du beziehungsweise die Leute in dem Team sich auch trauen, das entsprechend auch durchzuführen.
Ich bringe mal ein klassisches Auto-Beispiel.
Wir liefen noch Autos.
Ich bin, ich hatte bis vor drei Monaten, hatte ich kein eigenes Auto gehabt.
Ich bin, wenn, an den 20 Jahre alten Auto auf meinen Vater gefahren.
Also so ein dummes Auto.
Und dann hatte ich dieses neue Auto und Da gibt es dann ja die tollen neuen Features.
Also für mich waren sie dann neu, mit Spurhalteassistenz, mit Abstandhalter, das automatisch bremst, wenn du zu nah kommst und nicht selbst bremst und Tempomat und so ein Kram.
Und so ein bisschen so ähnlich ist das auch mit Freitagsdeployments, weil da muss ich tatsächlich auch drüber nachdenken, als ich dann im Auto saß und ich so und so, als eigentlich müsste jetzt das Auto gleich bremsen und sollte nicht auf das Vorderauto auffahren.
Aber ich hatte ja im Kopf, ich weiß, dass es technisch funktioniert.
Ich habe im Kopf aber noch nicht dieses Vertrauen gehabt, dass es tatsächlich funktioniert, weil ich noch nicht diese Erfahrung hatte, ob es tatsächlich funktioniert.
Ja, aber was heißt das jetzt?
Heißt das, dass du einfach Hoffnung zur Strategie machst und hoffentlich funktioniert dann das automatische Bremsen in deinem Auto und wenn nicht, dann fährst du halt drauf?
Also ich meine, Hoffnung ist in der Regel keine Strategie und einfach YOLO irgendwelche Sachen zu machen, in der Hoffnung, dass es dann funktioniert, Ist halt auch eigentlich nicht so smart, oder?
Genau.
Und da habe ich natürlich dann auch geguckt, wie kann ich das testen, ohne dass es brenzlig wird.
Ich will es ja nicht auf der Autobahn mit 150 machen, sage ich jetzt mal, und gucken, ob der Abstand noch richtig eingehalten wird, sondern eher, wenn du in der Stadt fährst mit 30 und gucken so, okay, bleibt er jetzt auch wirklich stehen an der Ampel.
Schön in der Spielstraße, richtig schön drängeln.
Genau.
Und dadurch bekommst du ja schon Gefühl.
Und dann arbeitest du dich ja so langsam, dass du merkst, okay, wie ist das Bremsverhalten?
Ist das jetzt schneller, später und so weiter?
Und genau das Gleiche hast du dann ja auch mit Freitags oder Deployments überhaupt.
Ich meine, eigentlich ist es ja egal, an welchen Tag es sich handelt.
Die meisten trauen sich überhaupt nicht zu deployen, egal welcher Tag es ist.
Aber bevor wir überhaupt das testen können, in die Spielstraße fahren können, ich bin übrigens kein großer Fan von...
von diesen automatischen Autodingen.
Ich habe selber gerade mal in so einem modernen Auto gekämpft, weil das immer gebremst hat bei einer Straße, die ich sehr gut kenne, bergab am Berg.
Und da war noch Platz, aber dieses Auto wollte einfach nicht um die Kurve fahren, weil dieser Abstandsassistent gedacht hat, es ist keine Chance, da runterzukommen.
Aber egal, nochmal ein anderes Thema.
Aber wenn man das mal jetzt so genau betrachtet, diese Features von...
einem modernen Auto.
Also was brauche ich denn für das Freitags-Deployment auf der technischen Seite?
Diese Sicherheitsnetze oder die Sicherheitsnetze oder die Features, was benötige ich da auf der technischen Seite, dass ich mir überhaupt mal drüber trauen kann und dass ich technisch bemächtigt bin, überhaupt Freitags-Deployments machen zu können?
Ja, ich meine, das Erste ist halt überhaupt, eine ordentliche CICD-Pipeline auch zu haben.
Sowohl die Pipeline selbst als auch Monitoring dahinter natürlich für den operativen Betrieb.
Und da würde ich jetzt erstmal angehen und gucken, okay, was kann ich jetzt machen, damit das Ganze überhaupt vorangeht, damit ich da ein besseres Gefühl für bekomme, wie zum Beispiel halt eine Staging-Umgebung.
Also kommt ja immer darauf an, von wo man gerade startet.
Weil wenn man gerade alle halbe Jahr deployt, dann ist erstmal mal gut, eine stabile Staging-Umgebung zu haben, wo man ihn auch testen kann und Gefühl dafür bekommen kann.
Selbst das trauen sich ja viele auch schon nicht.
Wenn du jetzt sagst, gute CICD-Pipeline, was ist denn für dich gut?
Also du hast es so hingeworfen, aber ich bin mir nicht sicher, ob jeder CICD-Pipeline, ob das so klar ist und was heißt Deployment überhaupt?
Und ich habe ja auch nicht in jeder Branche vielleicht so einfaches Deployment.
Hast du da irgendwelche Metriken oder was ist für dich State of the Art, sagen wir es mal so?
Ich würde es auch gar nicht zu sehr auf die Technik beschränken, sondern vielmehr auf Prozesse und auch auf die People eben drauf gucken.
weil die beste Technik bringt halt nichts, wenn du die Prozesse und den Mindset halt auch nicht drin hast.
Also klar, ein ordentliches ICD-Pipeline wäre dann zum Beispiel, naja, das Projekt wird auf allen Ebenen ordentlich getestet, also Unit-Tests, Integration-Tests und so weiter.
Dann wird es vielleicht noch auf Staging-Umgebungen deployed getestet, möglichst nah an Realität, dann vielleicht noch direkt auf Production-Ebene und da kann man ja auch nochmal unterscheiden.
Machen wir ein Delivery oder machen wir ein Deployment?
Weil wofür steht CICD?
Das steht ja entweder für Deployment oder für Delivery, was ja auch nochmal ein gewisser Unterschied ist.
Kannst du den Unterschied mal erklären?
Für alle, die das nicht wissen, der Andi hat es mir ja schon hundertmal erklärt und ich verwechsel es meistens immer noch, aber vielleicht hast du eine bessere Eselsbrücke jetzt für mich.
Also ich verwechsel das manchmal dann auch, aber meine Eselsbrücke ist die Waschmaschine, weil du kannst ja eine Waschmaschine geliefert bekommen, also eine Delivery.
Das heißt aber noch nicht, dass du da Load draufpackst, indem du da Wäsche reinpackst.
Wenn es deployed ist, dann ist sie auch angeschlossen und dann landet da auch eine gewisse Last drauf, also deine Wäsche.
Und dann kannst du auch so schöne Sachen machen wie Canoe-Deployments, dass du dann erstmal anfängst und sagst, ich packe jetzt erstmal nur 20% der Wäsche in die neue Waschmaschine und gucke, ob das auch alles sauber ist, bevor ich die alte wieder runternehme.
Das ist mal eine sehr schöne Eselverkehr.
Vielen Dank.
Ich habe jahrelang Andi zugehört und Andi hat es mir immer probiert zu erklären.
Jetzt?
Habe ich mal eine gute Esselsbrücke.
Wenn das Amazon-Paket angekommen ist, heißt es noch nicht, dass es in Verwendung ist.
Der Andi kennt das selber, der hat immer 20 Amazon-Pakete rumliegen oder irgendwelche IoT-Devices, die seit fünf Jahren nicht im Einsatz sind.
Das ist eine gute Esselsbrücke.
Ich meine, ich habe da ja gerade auch schon Blue-Green-Canary-Deployments mit reingerufen in die Waschmaschine oder in das Waschmaschinen-Setup.
Aber vom Prinzip her ist das ja genau das.
Du kannst Delivery dafür machen, dass es schon irgendwo läuft, aber noch keinen Traffic dahin schicken.
Und das kannst du halt technisch alles umsetzen.
Aber es heißt immer noch nicht, dass du es dann tatsächlich auch an einem Freitag ausrollst, in Betrieb nimmst.
Und was hat das für einen Vorteil, wenn du jetzt das irgendwo schon rumliegen hast, aber kein Traffic draufkommst?
Also man weiß zumindest, dass der technische Teil vom Deployment, also dass das Softwarepaket auf dem Zielsystem draufkommt, als auch startet, dass das zumindest funktioniert.
Da scheidet es bei vielen ja schon.
Weil ich hatte das bei...
Länger her, ich glaube, das war 2018, 19 rum, da war ich Angestellter, Consultant und da war ich bei so einer Firma, die haben unter anderem einen Online-Job betrieben und da hatte ich mich auch um so CICD-Krams gekümmert, deswegen kenne ich diesen Kontext und das war halt ein sehr großer, monolithischer Jenkins-Server.
Und da war zum Beispiel das Problem, dass sie da keine Feature-Flex genutzt haben und dieser Jenkins ist historisch gewachsen.
Ist erstmal jetzt auch egal, was die Technik ist, aber da gab es dann halt diesen Shop, der hatte dann Fernsehwerbung geschaltet für mittwochs 7 Uhr abends.
Und genau dann sollten die neuen Angebote live gehen.
Und was ich jetzt vor allem heute sagen würde, ist, du machst das Deployment irgendwann über den Tag, mittwochs über den Tag und machst dann irgendwann nur noch den Feature-Flag zum Klickse dann an, damit es dann halt aktiviert wird und alles ist gut.
Oder vielleicht sogar automatisiert, dass der Feature-Flag dann halt um 7 Uhr abends aktiv geht und dann sind die Angebote halt online und du kannst das schon für einzelne User, für dich selbst, also die internen User schon mal testen, bevor 7 Uhr abends ist.
Was war dort das Problem?
Das haben sie halt nicht gemacht.
Da musste der Jenkins zwangsläufig um 7 Uhr laufen.
Da durftest du den Tag über schon keine Updates oder sonst irgendwelche Plug-in-Updates machen.
Und dann hat was nicht funktioniert und dann läuft aber schon die Kampagne über Social Media, über Fernsehen und hast du nicht gesehen.
Und dann sind aber die Angebote nicht online.
Und das ist dann natürlich finanziell nicht so geil, um es freundlich auszudrücken.
Und da fragt man sich dann doch schon so, naja, woran hat es gelegen?
Am Ende fragt man sich immer, woran es gelegen hat.
Und viele Sachen lassen sich halt technisch dann auch schon ordentlich umsetzen, machen viele dann aber auch nicht.
Jetzt packst du natürlich schon eine ganze Menge technische Sachen aus.
Feature-Flex, Blue-Green-Deployments, Delivery versus Deployment, also das Paket da liegen haben und Co.
Du sprichst da gerade so von, als wäre das normal.
Bei großen Applikationen ist das vielleicht normal.
Jetzt hatten wir die Episode auch damit begonnen, wie sieht es denn eigentlich mit Deployments generell beim deutschen Mittelstand aus?
Also, wenn ich mal so auf Meetups unterwegs bin und dann über Observability spreche, Feature-Flags und Co., dann bekomme ich oft Gespräche zu hören, so, ja, ich wünschte, ich hätte Zeit, das alles zu implementieren.
Das wäre total toll.
Ist die Industrie, ist die deutsche Industrie überhaupt so weit?
Oder springen wir gerade irgendwelchen amerikanischen Hype und irgendwelchen Büchern hinterher und irgendwelchen Netflix-Talks?
Ja, ich würde sagen, für den Durchschnitt hängt man da deutlich hinterher.
Also dadurch, dass ich ja bei GitLab gesehen habe, wie vor allem die guten DevOps-Teams quasi arbeiten, bei den Deutschen oder aus dem Dachraum, Deutschland ist auch Schweiz.
Gleichzeitig aber auch den Kontakt hatten zu den Kolleginnen und Kollegen, die in den USA an der Westküste, also Silicon Valley, Seattle und hast du nicht gesehen, arbeiten.
Das ist eine ganz andere Liga technisch.
Da redet man halt auch auf der technischen Ebene auf ganz anderem Niveau, als das im Dachraum oder auch Europa generell der Fall ist.
Und man merkt halt schon, dass Mindset ist, in Silicon Valley, aber auch Seattle, die Ecke oder US-Westküste, halt schon was ganz anderes von oben auch gesehen, ja, als in Europa.
Mit allen Vor- und Nachteilen.
Also ich will jetzt nicht sagen, dass es eine total gut ist und das schlecht ist, aber so, man merkt halt schon viele, der deutsche Mittelstand ist ja häufig dann ja auch irgendwie Maschinen da und, oder halt Industrie, klassische Industrie und jetzt nicht unbedingt so die typischen IT-Buden.
Und die verstehen aber halt noch nicht, dass es eine IT-Bude ist.
Und das merkt man dann halt schon in Softwarequalität und wie das Ganze auch ausgerollt wird an die Kunden.
Ich mache immer gerne einen Unterschied, wie deine Firma IT betrachtet.
Als Kostenstelle oder Innovationstreiber.
Du hast ja gerade mehr oder weniger das beschrieben als Kostenstelle.
Aber du hast schon den Maschinenbau angesprochen.
Macht es eigentlich einen Unterschied, wenn wir von der Technik und bei, ich sage mal, Friday Deployments eigentlich über Banksoftware, einem internen Tool, einer Mobile App, einer Web App oder einem Embedded System reden?
Ist das eigentlich alles das Gleiche?
Naja, es kommt natürlich darauf an, welchen Blickwinkel wir jetzt drauf gucken.
Wenn ich, damit kommen wir wieder zurück zu Leuten, die mir ihre Meinung sagen zu Freitagsdeployments.
Es gibt halt auch welche, die sagen, ich darf nur Freitagsnachmittags deployen.
Und dann ist es, oh, endlich mal ein vernünftiger.
Aber dann, wenn man da ein bisschen weiter nachfragt, dann hört man auch sehr schnell, warum.
Im Bankenumfeld ist es teilweise so, naja, am Wochenende laufen ja keine Bankgeschäfte im klassischen Sinne ab.
Das heißt, wenn da mal irgendwelche Systeme down sind, ist das nicht so schlimm.
Also klar, es ist jetzt für die Mitarbeitenden doof, die das Ganze verwalten müssen, weil sie halt Wochenend arbeiten müssen.
Aber dafür kriegen sie ja auch Ausgleichstage oder Überstunden oder sowas, behaupte ich jetzt mal.
Aber es betrifft jetzt nicht so dann den typischen Kern von den Endnutzern, weil wenn du am Wochenende, ob du jetzt am Wochenende mal eine Stunde guckst, tendenziell halt machst du halt eher weniger deine Bankgeschäfte.
Andere Sache, ich habe ja viel mit den Leuten zu tun, die GitLab betreiben.
Und da ist es dann auch so, naja, wenn das Ding halt offline ist, und das ist ja wiederum ...
nochmal was anderes, weil es ist nicht die eigene Software.
Man muss ja auch nochmal unterscheiden, reden wir jetzt von unserer eigenen Software, wo wir, die selbst in-house entwickelt wird, wo wir volle Kontrolle theoretisch haben, wie es getestet wird, wo es getestet wird und wann wir es live schalten.
Oder es ist eine Fremdsoftware, wie ein GitLab, was wir dann halt eben ausrollen müssen in der eigenen Infrastruktur, wo man eventuell nicht die Edge-Cases kennt.
Und da ist es dann häufig auch so, naja, wir machen das lieber abends.
Oder Freitagabends zum Beispiel meint halt einer, weil da stört das halt nicht die tausend Entwickler und Entwicklerinnen, die wir in der Firma haben, sondern halt maximal die fünf Leute, die da gerade das Update fahren, wenn es halt ein bisschen länger dauern sollte.
Wenn man es tagsüber macht, dann kann es halt sein, weil es eine fremde Software ist, dass es dann doch mal eine halbe Stunde offline ist und dann können halt eine halbe Stunde lang tausend Leute nicht arbeiten.
In der Hoffnung, dass diese tausend Leute alle in derselben Zeitzone sind und nicht weltweit arbeiten, weil dann ist ja wieder dieses andere Problem.
Aber wir sind ja jetzt schon wieder bei den Prozessen, so nach dem Motto, ich darf ja nur Freitagabends deployen wegen einer Bank oder ähnliches.
Welche Prozesse sind dir denn schon mal untergekommen, die Freitags-Deployments vielleicht sehr schwierig machen oder die es gerade erst erlauben, dass du nur Freitags deployen darfst?
Ja, ich würde gerne noch einen Schritt zurückgehen.
Weil wir hatten die Begriffe zwar schon genannt, aber ich rede halt gerne von People over Processes over Tools.
Und das kommt ja aus dem ganzen DevOps-Movement halt auch.
Und das ist auch ein großes Thema bei mir in meinem DevOps-Buch.
Da ist es halt schon so, die meisten haben tendenziell eher die Technik unter Kontrolle, aber nicht unbedingt die Prozesse.
Und die People ist dann das nächste Problem.
Bevor wir jetzt halt auf die Prozesse gucken, sollten wir natürlich gucken, was haben wir als Technik?
Und das hatten wir ja gerade jetzt schon gut diskutiert.
Aber das ist halt so ein bisschen so, naja, du kaufst dir ein...
Schnelles Auto, ein Formel-1-Auto.
Und dann merkst du aber, und das war effektiv mein Gefühl, als ich bei GitLab in diesem Sales-Kosmos effektiv dann halt auch war, GitLab positioniert sich selbst als DevOps-Plattform.
Mit uns kannst du schneller, sicherer Software entwickeln und deployen.
Aber es hilft halt nicht, wenn du dein Formel-1-Auto hast, aber keine Rettstrecke hast, wo wir bei den Prozessen sind.
Weil wenn die Straße halt voll mit Schlaglöchern sind, das ist ein Problem.
Und das sieht man halt häufig bei Prozessen.
Und das geht aber auch sehr stark in diese People-Schiene auch mit rein.
Mein klassisches Beispiel sind irgendwelche Prozesse, die sagen, irgendein Vorgesetzter muss einen Change abnicken.
Das ist ein Prozess, hat aber auch Einflüsse auf die People.
Weil was ich zum Beispiel mal gehört habe von einer Freundin, die halt Entwicklerin ist, sie meinte dann so, naja, A, muss das irgendwie abnicken.
Dann nickt das zwar jemand ab, der aber an der Implementierung so gar nichts gemacht hat.
Und auch überhaupt nicht einschätzen kann, ist das jetzt gut oder ist das schlecht.
Und gleichzeitig muss man aber als Entwickler oder als Entwicklerin dann auch entsprechend dann diese Changes dann verantworten.
Da kommt halt die People und die Prozessthema zustande, weil wenn jetzt erstmal für einen Change, der ausgerollt werden muss, drei Leute von weiter oben das approven müssen, bis zum Vorstand hoch, dann ist das für einen Entwickler auch irgendwie so, die Verantwortung liegt weiter oben.
Und warum macht man überhaupt so ein Approval?
Woher kommt?
Wie du richtig sagst, die Leute haben ja meistens wenig Ahnung, was eigentlich in dem Change drinnen ist, außer jetzt auf High Level.
Aber sonst können die, die haben ja keine Ahnung über Architektur, über den aktuellen Zustand und sagen wahrscheinlich sowieso immer ja, außer wenn sie gerade wissen, vielleicht wir haben gerade eine super wichtige Kampagne und sagen, okay, jetzt mach kein Update, weil ich will nichts riskieren oder so.
Aber im Grundsätzlichen wird es ja wahrscheinlich immer durchgewunken.
Also woher kommt diese Angst überhaupt vom Management?
Ich würde sagen, das ist so ein bisschen kulturell auch.
Ich würde sagen, die Deutschen oder Europäer sind eher, naja, wir gucken uns das erstmal ein bisschen an und machen ein bisschen langsamer und nicht dieses Disruptive aus den USA jetzt quasi so, ach komm, wir machen jetzt einfach mal.
Und gleichzeitig merkt man ja doch schon in Deutschland, in Europa ja schon eine gewisse Hierarchie.
Weiter oben ist die Stimme von weiter oben wichtiger als die von weiter unten.
Auch wenn es faktisch...
fachlich egal ist.
Naja, also ich mag es gerne, diese Prozesse zu hinterfragen.
Hierarchie hin oder her.
Du stellst eine Fachkraft ein.
Er oder sie programmiert.
Du stellst diese Fachkraft entweder ein, weil du keine Zeit dafür hast und deswegen Hilfe brauchst.
Vielleicht kannst du ja selbst programmieren.
Wer weiß das schon?
Oder du stellst die Fachkraft ein, weil du es gerade nicht kannst.
Du holst dir also neue Skills ins Haus.
Und dann approvst du immer noch etwas, was du nicht verstehst.
Also das macht ja keinen Sinn, denn du bist ja in der Hierarchie drüber, weil du ja schon automatisch mehr Verantwortung trägst oder durch deine Position trägst du ja mehr Verantwortung.
Ja.
Hä?
Ja, ich bin ganz bei dir.
Aber jetzt lass uns mal da von dem Negativen und dem Blaming wegkommen.
Wie ändere ich denn das Ganze?
Weil das war in der Vergangenheit so und es ist ja auch immer so dieses schöne Argument, das ist historisch schon gewachsen.
Ja, mag sein, aber wie ändern wir das Ganze jetzt?
Also wie bringst du ein Management jetzt dazu, dann auch zu sagen, okay, jemand anderer darf entscheiden?
Also wie bekomme ich diesen Entscheidungsprozess dann weg?
Ja, das ist schwierig.
Grundsätzlich ist das schwierig.
Auf Prozessebene kann man das ein bisschen schotten, weil man das rein auf den Prozess betrachtet.
Aber häufig hängt da halt die Technik und die People, die Menschen halt auch mit dazu.
Du hattest ja Blaming, das Wort Blaming schon verwendet.
Das erste ist dann halt auch eben, dass dann so eine Blameless Post Mortem zum Beispiel überwacht.
Dass wenn was kaputt geht, und das ist ja jetzt mal egal, an welchem Tag oder wann auch immer was kaputt geht, sowohl als normaler, ich weiß nicht, Im Englischen sagt man ja immer Individual Contributor.
Ich weiß gar nicht, wie man das auf Deutsch sagt oder bei deutschen Firmen sagt.
Das ist eine gute Frage.
Wir sagen auch Individual Contributor.
Das ist einfach Mitarbeiter.
Keine Ahnung.
Ja, also Personen ohne Führungsverantwortung, die halt Dinge tun.
Wenn die Fehler machen, was passiert dann?
Sowohl für einen selbst, als auch für die Managementstruktur weiter oben.
Also Andi, warte, du bist ja Engineering Manager, ne?
Genau.
Wenn einer deiner Leute einen Fehler macht, Einer, mehrere, ist erstmal egal.
Was heißt das für dich?
Weil du musst ja auch weiter nach oben gerade stehen eventuell.
Ja, ja, also die, jetzt kann ich dir die beste Antwort geben.
Der wird natürlich gefeuert, ja, so wie es gehört.
Das wollte ich nicht wissen.
Nein, es ist, es ist, ich sehe das, oder ich habe mal was Schönes gehört und das finde ich auch wirklich, wirklich immer noch schön und ich glaube, das treibt auch diese ganze Antwort in die richtige Richtung.
Das ist jetzt der wertvollste Mitarbeiter.
Weil diese Person wird diesen Fehler nie wieder machen.
Nicht, weil ich dann mit dem Stock komme, um draufzuschlagen, sondern weil man ungern in der Situation ist.
Denn wenn da ein Ausfall ist, dann hat man Adrenalin im Blut oder im Körper und dann sind alle aufgeregt und allem drum und dran.
Und im Endeffekt interessiert es ja gar nicht, wer es war.
Denn so ist das bei uns zumindest.
Wenn du als Mensch in der Lage bist, diesen Fehler zu machen.
dann fehlt da irgendwas.
Dann ist entweder der Prozess kaputt oder da fehlt ein Sicherheitsnetz oder auch im dümmsten Falle ist einfach nur eine Anleitung falsch geschrieben.
Ja?
Ja.
Das ist so nicht der beste Weg, das zu fixen, die Anleitung zu beheben, weil man kann ja immer vertippen oder Ähnliches, aber das ist wenigstens ein Schritt in die richtige Richtung.
Und ich habe halt, wie gesagt, irgendwann mal, ich glaube, die steht sogar auch irgendwo in einem Buch.
In der Phoenix-Story, wie heißt das denn?
Unicorn-Phoenix-Story?
The Phoenix Project.
Phoenix Project.
Wie heißt das da drin?
Naja, wie du sagst, das ist auf jeden Fall der wertvollste Mitarbeiter, weil der wird diesen Fehler nie wieder machen.
Genau.
Und das ist auch ein guter Punkt zu eurer Folge über Seniorität, die ihr vor einer Weile veröffentlicht habt.
Aber das ist auch die Frage, wie lernt man dazu?
Und man lernt ja in der Regel ja dazu, wenn man Fehler macht.
Und Fehler machen muss ja nicht unbedingt auf Pod sein.
Das muss nicht gleich sein, die Pod-Datenbank ist gelöscht.
Das reicht ja schon, wenn Fehler auf Testumgebungen oder beziehungsweise Staging-Umgebungen halt passieren und man dafür dann auch ein besseres Gefühl für die Plattform bekommt.
Ich war früher halt auch, das ist ja so 2017 rum, war ich halt auch in einem klassischen Ops-Team gewesen.
Da gab es dann halt auch Bereitschaftswochen, wo man die ganze Woche dann halt Bereitschaft gemacht hat.
Ich war, glaube ich, bei zwei Wochenenden, wo ich dann halt auch Bereitschaft hatte.
Da war ich auch auf irgendeinem Hochzeiten unterwegs.
Der Laptop war dann in der Tasche im Auto oder sonst was.
Und ich hatte aber keine Angst, dass was kaputt geht, weil ich ein gutes Gefühl für die Plattform hatte.
Ich wusste, zu 99,9 Prozent der Fälle passiert nichts.
Weil da kommen wir wieder auf die Technik hinzu.
Du kannst ja auch schon vieles so bauen.
dass es Self-Healing ist.
Also Kubernetes zum Beispiel hat ja auch ganz viele Sachen, die dann halt auch eben helfen, dass es halt irgendwie eine Art Self-Healing-Mechanismus mit drin ist.
Und das eine ist, dass du das Technik halt kannst.
Das andere ist, dass die Prozesse auch richtig umgesetzt ist, dass es dann auch richtig funktioniert bei jedem Deployment zum Beispiel.
Und das andere ist, dass du selbst ein Gefühl dafür hast, das funktioniert auch tatsächlich.
Und das musst du dann halt auch lernen.
Mein Lieblingsbeispiel ist nämlich...
Die Booking.com-Story, der Christian Kündorp erzählt das immer gerne oder hat das mal vor Ewigkeiten mal in einem Talk erwähnt.
Da sagt er dann, ein neuer Mitarbeiter hat angefangen und irgendwie am zweiten oder dritten Tag trifft er den CTO in der Kantine.
Dann fragt halt der CTO so, ah, du bist ja neu hier, hast du schon einen Pott kaputt gemacht?
naja, wie antwortest du dann?
Ich glaube, so der typisch deutsche oder Europäer würde sagen, und das hat er wohl auch gesagt, was?
Nein, ich habe doch nicht Pott kaputt gemacht.
So, weil immer dieser Eindruck entsteht, man muss nach oben hin zeigen, man macht keine Fehler, man darf keine Fehler machen und hast du nicht gesehen.
Und darauf war halt die Antwort von dem CTO entsprechend so, warum hast du nicht Pott kaputt gemacht?
Du lernst nur dafür, wenn du Pott kaputt gemacht hast.
Hast du bisher noch nichts gemacht bei uns, sonst hättest du dir Pott kaputt machen müssen.
Genau, und kaputt machen ist ja auch nochmal ein bisschen unterschiedlich.
Was ist jetzt genau kaputt?
Wenn jetzt die Poddatenbank für die Hauptapplikation weg ist, ist es wahrscheinlich sehr schlecht.
Das sollte wahrscheinlich nicht passieren.
Aber da sind wir wieder das, was Andi gerade gesagt hat.
Da sollte es schon diverse Sicherheitsmechanismen geben, dass es das gar nicht gibt, durchführbar ist.
Gleichzeitig gibt es aber auch viele kleinere Fehler, wo etwas passieren kann, wo man halt schon wieder was dazu lernt.
Und wenn man das halt nicht traut, und dazu gehört dann auch regelmäßig zu deployen seine Changes, dass man dann halt eben ein Gefühl dafür bekommt, okay, dieses Deployment ist sicher.
Man muss ja nicht jedes Deployment an einem Freitag ausrollen.
Man sollte aber in der Lage sein, jeden Freitag oder überhaupt egal welchen Tag ausrollen zu können.
Ich glaube, dein letzter Satz, der ist auch einer dieser Keysätze, denn die Beispiele, die du gerade genannt hast, die können natürlich auch ins andere Extrem umschlagen.
Nehmen wir mal das Beispiel Self-Healing.
Du sagst jetzt gerade Kubernetes ist Self-Healing.
Ein Crash-Loop ist ja auch Self-Healing irgendwie.
Also ich meine, die Applikation crasht, Kubernetes startet das neu, die Applikation crasht, rescheduled die auf eine andere Note, bla bla bla.
Das ist ja auch Self-Healing in irgendeiner Art und Weise.
Die andere Thematik ist, du sagtest gerade Post-Mortems und herauszufinden, okay, was lief denn hier gerade verkehrt oder warum war dieser Mensch, dieser Mitarbeiter überhaupt in der Lage, diesen Fehler zu machen?
Hast du jetzt eine relativ instabile Infrastruktur oder hast ziemlich viele Inzidenz, bedeutet das im Umkehrschluss aber auch, du machst ziemlich viele Inzident-Reports und Post-Mortems.
Und da muss man natürlich auch ganz stark aufpassen, dass das nicht zur Qual wird oder zur Burden.
Weil natürlich sagst du, klar, wenn du hier und da mal ein Inzident hast, dass sich alle da hinsetzen, wirklich 5, 6, 8, 10 Mal warum fragen, um wirklich zu verstehen, was lief denn hier gerade verkehrt, ist eine schöne Erfahrung.
Gar keine Frage.
Wenn du die einmal pro Quartal hast, freut sich auch jeder drauf, weil jeder lernt was.
Hast du die sechsmal pro Woche, dann ist das Instant Report schreiben vielleicht einfach nur richtig harte Arbeit und fühlt sich nicht an wie Lernen, sondern wie Reporting.
Wie Strafe.
Wie Strafe.
Und das ist natürlich dann auch wieder so schwierig.
Ja, weil du sagtest ja auch gerade, du warst mal auf Rufbereitschaft auf irgendeiner Hochzeit, weil das System so stabil war.
Ich glaube, jeder, der schon mal irgendwie in diesem Bereich gearbeitet hat, der kann sich nur einen Hauch vorstellen, was das bedeutet, wie viel Vorarbeit da reingesteckt wurde.
Ja, genau.
Und diese Vorarbeit ist nicht wenig Aufwand.
Aber im Endeffekt ist das ja nicht nur für die eigenen Mitarbeiter relevant, sondern halt auch für die Kunden oder wer auch immer die Endnutzer sind.
Was sagst du denn den Leuten?
Weil die Leute kommen ja immer zu dir und die Leute geben dir ja dann eine Meinung.
Die sagen, ja, nee, ich arbeite bei einer Versicherung.
Ich darf gar nicht deployen hier und da, weil wegen reguliertem Umfeld ABC.
Ja.
Oder Zertifizierung oder PCI DSS, SOX, BaFin und weil es da nicht nur alles gibt.
Ja, dann habe ich häufig dann doch noch ein Beispiel, wo es geht.
Also das ist so ein bisschen wie Datenschutz.
Alle sagen, ah, das geht nicht wegen Datenschutz.
Wenn man mal wirklich hinterfragt, dann geht das meistens dann doch.
Nur, dass das als Vorschub genommen wird.
Viele Sachen aus den Compliance-relevanten Sachen, die lassen sich ja schon automatisieren.
Das meiste ist ja tatsächlich mehr so eine Reporting-Thematik.
Und einige Sachen sind dann ja auch mehr so, naja, da sind wir wieder bei den kaputten Prozessen.
So, ich habe eine Excel-Tabelle, wo ich irgendwelche Sachen abhaken muss.
Und viele Sachen lassen sich halt automatisieren.
Und einige Sachen sind ja sowas wie, es wurde jedes Mal ein Code-Review gemacht.
Kannst du es abhaken oder nicht?
Errollen sich bei mir auch immer die Fingernägel, weil meine Erfahrung ist eigentlich, dass sehr, sehr viele Leute einfach super schlecht in Code Reviews sind.
Ja, anderes Thema, aber ja.
Ja, und dann frage ich mich wieder, okay, warum muss da ein Code Review gemacht werden, wenn der Code Review eigentlich nur ein visueller Syntax-Check ist, was dann eigentlich bereits der Compiler macht oder eine Linter oder ähnliches und nicht die relevanten Fragen stellt, ist dieser Code an der richtigen Stelle, macht dieser Code eigentlich Sinn?
Eine Kontrollfrage ist, Wolfgang, und die geht jetzt an dich.
Und wirklich, antworte die bitte ehrlich.
Wenn du Code-Reviews machst, wie oft hast du dir das verlinkte Jira-Ticket vor dem Code-Review durchgelesen?
Ja, sehr, sehr, sehr, sehr selten, ja.
Woher willst du dann wissen, dass der geänderte Code überhaupt das Problem löst, was wir lösen wollten?
Ja, in guten PR steht das ja nochmal drinnen.
Heutzutage sowieso von der KI zusammengefasst.
Aber ja.
Fair point.
Du fängst schon an zu lachen und dann frage ich mich natürlich wieder, kommen wir zu der Abnäck-Thematik gerade, was soll das denn?
Über ordentliche Code-Reviews kann man eine eigene Folge dazu machen, glaube ich.
Aber wenn man jetzt nochmal auf diese Compliance-Thematik guckt, deswegen hatte ich hier die Frage auch gestellt, wurde eins gemacht, bei Compliance-Sachen ist ja mehr halt durchgeführt, nicht unbedingt, ob es sinnvoll ist.
Wenn wir auf diese sinnvolle Ebene gehen, was würdest du denn jemandem sagen bei einer Bank, warum Friday-Deployments oder die Möglichkeit, diese durchzuführen, sinnvoll wären.
Weil wenn du jetzt sagst, ja, wir sind eine Bank, es muss alles ultra geprüft werden und das ist alles langsam und so einen schnellen Prozess, der macht ja gar keinen Sinn bei uns in der Bank.
Also unabhängig, gar keine Ausrede von der Compliance-Seite, sondern einfach macht es für eine Bank überhaupt Sinn.
Ja, also ich habe da zwei Beispiele.
Also zu Banken gehören für mich jetzt halt auch Versicherungen und sowas zu.
Klar.
Ein früherer Arbeitskollege fand das witzig, dass ich halt die Firma so genannt habe.
Und ich hatte halt so Sticker gemacht mit dem, das ist Feind, Meme, Doc und Folledeployments drunter.
Und das muss ich in der Firma verteilen.
Wir deployen nämlich nur alle halbe Jahr.
Und da wird dann halt nämlich diese Compliance-Sachen dann auch alles zum Schluss dann halt gemacht.
Beziehungsweise als ich dann gefragt habe, wie macht ihr denn das?
Und dann so, naja, wir werden da eh durchfallen, weil wir das gar nicht richtig umgesetzt haben.
Also sie wissen, dass da noch viel zu tun ist.
Und das fängt schon damit an, auf technischer Ebene, dass sie noch auf Subversion und sowas setzen.
Oder dann auch so denken, das noch im Jahr 2000, ja, letztes Jahr war das 2025.
Und gleichzeitig kenne ich aber auch eine andere Bank, eine große Schweizer Bank.
Da merkt man auch wieder diesen Kulturunterschied.
Da gab es dann einen CTO irgendwas, der sagte, naja, wir wollen hier den ganzen Entwicklungsprozess komplett verschlanken.
Und da war der Fokus vor allem, die Mitarbeiterzufriedenheit und die Effizienz zu steigern.
Weil es ist letztendlich auch erstmal egal, ob du freitags deployst oder nicht.
Du willst aber, dass die Entwickler effizient arbeiten können.
Da musst du ja auch das Gefühl dafür haben, kannst du jetzt ständig was deployen.
Und da gibt es dann ja auch diverse Regularien wie, naja, es muss bei jeder Testumgebung, wenn dann nochmal separat was hochgezogen werden muss, muss das auch nachgehalten werden, dokumentiert werden, wer was wo wie gemacht hat.
Das lässt sich technisch schon automatisieren.
Und je größer du natürlich bist, desto mehr lohnt sich das natürlich, weil sich das ja auch in gewisser Skaleneffekt reinkommt.
Aber da gab es dann einen, der sagte so, naja, wenn ich jetzt einen neuen Mitarbeiter habe, der soll am Tag 1 Changes theoretisch machen können.
Und da haben wir jetzt die Kultur drin, da haben die Prozesse drin und da haben wir trotzdem Compliance in diesen Prozessen drin, weil viele Sachen dann halt in der IDE zum Beispiel, ist dann halt ein Knopf drin irgendwo, der dann sagt so, okay, ich möchte jetzt eine Testumgebung für diesen Change, den ich jetzt mache, haben.
wo das dann auch alles automatisch dokumentiert wird.
Da muss man vielleicht noch ein paar Sachen angeben.
Und viele andere Sachen werden dann halt enforced.
So Sachen wie, dass ein Code-Review technisch umgesetzt wird, das lässt sich dann halt ja auch enforcen.
Und ob man das dann richtig umsetzt, ist natürlich nochmal...
bisschen was anderes, aber viele Sachen lassen sich halt schon automatisieren und machen.
Ich glaube auch, dass diese Automatisierung und das Enforcen ja eigentlich, wenn du es automatisierst, viel leichter vonstatten geht, sonst hast du irgendwelche manuellen Prozesse und du loggst dich auf irgendwelchen Servern bei SSH ein und schiebst da irgendwie eine Datei rauf und hoffst, dass das irgendwie funktioniert oder dann weiter verbreitet wird.
Und es gibt ja da diesen berühmten Fall von Night Capital, der in der VPC-Szene immer gerne genannt wird.
wo dann irgendwie so ein halb-deployter Job, ich glaube, die haben, wenn ich mich richtig erinnere, die haben, glaube ich, vergessen, auf manchen Nodes das zu deployen oder es hat dann irgendwie nicht funktioniert und keiner hat es mitbekommen.
Die haben einen Feature-Flag wiederverwendet und auf einem Node war das aber noch irgendwie aktiv.
Irgendwie sowas war das.
Aber ja, dann sind da 100 Millionen Flagen gegangen.
Genau, es war so halb-manuell und ja, innerhalb von 45 Minuten sind 440 Millionen US-Dollar verloren gegangen, weil da irgendwelche...
krummen Orders, High Frequency Trading Orders um die Ohren irgendwie geflogen sind.
Also wenn man das automatisiert gehabt hätte und sinnvolle Metriken gehabt hätte, hätte sich das natürlich verhindern lassen.
Also nur weil man was manuell macht und jeder, der manuelle Prozesse macht und wenn man sie das fünfte oder das zehnte Mal macht, dann macht man sie halt gern falsch.
Also der Andi hat mich heute gerade gerügt, weil er gestern einen Zahlendreher drin hatte bei einer Episoden-ID und unsere ganze Pipeline um die Ohren geflogen ist.
Ja, menschliche Fehler passieren halt mal.
Ja, sei bitte ehrlich.
Wie habe ich diesen Satz oder diese Nachricht abgeschlossen, als ich dich gerügt habe?
Wie können wir es verhindern?
Das ist es nämlich.
Und ja, ich habe gesagt, du hast das gemacht.
Das ist richtig.
Aber ich finde beim Blameless, und da kommen wir jetzt mal zu diesem Punkt, heißt es nicht, ich blame den, sondern ...
Es ist ja teilweise auch zum Reporting und zur Dokumentation, wer hat wann welche Operation durchgeführt.
Also nur weil da ein Name steht, heißt das ja nicht unbedingt, ich blame jemanden.
Natürlich solltest du versuchen, den Namen nicht zu nennen, aber ab und zu macht es ja Sinn, falls irgendwie Leute außerhalb des normalen Realms involviert waren, dann fragt man sich, warum war die Person überhaupt involviert?
Das hat ja auch wieder einen Rückschluss auf Prozesse.
Jetzt bei Wolfgang und ich, zugegeben, wir sind ein Zwei-Mann-Team.
Also wenn ich es nicht war, war es halt der Wolfgang.
Das ist dann ein bisschen was anderes.
Lass uns mal ganz kurz auch zu den, vielleicht auch nicht ganz kurz, vielleicht auch ein bisschen länger, zu dem Bereich People kommen.
Prozesse haben wir jetzt ein bisschen gesprochen und wir haben jetzt gerade so ein bisschen über ein reguliertes Umfeld gesprochen.
Und das, was ich schon erlebt habe, ist, dass zum Beispiel die Operations-Abteilung sagt, nein, wir können freitags nicht deployen, wegen Ausrede, also Datenschutz.
Compliance, völlig egal was.
Um irgendein großes Buzzword zu droppen, wo dann Engineers keine Ahnung von haben, weil sie sich mit Datenschutz, Sox Compliance oder ähnliches nicht.
Einfach nur aus dem Grund, weil das eine strikte Trennung war, wer auf Rufbereitschaft war und diese Angst, dass Samstag oder am Wochenende was kaputt geht.
Und das ist ja, also ich meine, du hast ein Buch über DevOps geschrieben.
Also ich meine, DevOps.
kommen sich da in die Quere.
Je entfernter Dev und Ops voneinander sind, desto eher würde ich nicht empfehlen, überhaupt zu deployen, unabhängig vom, erst recht nicht am Freitag.
Also das ist schon ein DevOps-Thema, also wo in einem Team Dev und Ops zusammen sind und Security und Business und Finance vielleicht auch noch, weil die ja auch irgendwie alle dazugehören.
Und nur wenn das wirklich dazugehört, dann hat man auch so eine Shared Ownership.
Darüber.
Deswegen habe ich jetzt auch zum Beispiel Finance gerade auch noch mit dieser Aufsinnung mit reingenommen, weil ein Incident kann ja zum Beispiel auch sein, dass wegen irgendeiner technischen Implementierung dann von den fünf Kubernetes-Nodes, die du dann im Cluster hast, plötzlich 50.000 sind und dann ist die Rechnung plötzlich für drei Tage für das Wochenende dann 50.000 Euro statt 5.000 Euro oder 500 Euro.
Dann meckert plötzlich Finance, von denen du noch nie was gehört hast.
Wenn die aber nah im Boot sind und technisch nicht alles im Detail verstehen, aber schon so wissen, warum wird das jetzt gerade mehr oder vielleicht auch mal weniger, wie es mit Last zusammenhängt, dann hast du da auch ein bisschen mehr Verständnis.
Deswegen ist es schon wichtig, da die verschiedenen Rollen zusammenzubringen, möglichst nah beieinander und nicht ein, naja, Dev macht es halt auch obs.
Das passt dann halt häufig dann doch nicht so ganz.
Mit wie vielen Firmen arbeitest du zusammen, wo die Entwickler auf Rufbereitschaft sind?
Weil wenn du sagst Shared Ownership, ich meine, ich habe gerne die Shared Ownership, von Montag bis Weitag, 8 bis 16 Uhr.
Also, ja, das ist ein guter Punkt, weil viele sagen mir dann bei dem DevOps-Thema so, ja, dann muss aber doch Dev auch Bereitschaft machen.
Und dann meine ich, ja, stimmt.
Und dann gucken sie immer komisch.
Weil eigentlich haben sie nicht erwartet, dass ich ja sage.
Aber ja, so ist es dann halt.
Ich meine, so genau kann ich das nicht sagen, wer das wie wo macht.
Ich kann aber halt viel erzählen, wie es GitLab selbst macht als Firma.
Da wird zum Beispiel auch nicht freitags deployed.
Weil da sieht man das dann, dass es dann irgendwann, ja doch, Freitagmorgens, europäische Zeit, hört es auf, weil freitags in Neuseeland geht ja noch, weil dann ist ja noch bis zur Westküste USA ist dann ja noch ein bisschen 18 Stunden Zeit oder sowas.
Aber dann warten halt gemerchten Sachen bis zum nächsten Montag dann auch entsprechend.
Aber auch da.
Devs machen Rufbereitschaft.
Und da kommt es natürlich noch ein bisschen drauf an, okay, habe ich jetzt SAIs, habe ich jetzt klassische DevOps Teams, habe ich noch SAIs oder muss ich da nochmal ein bisschen was anderes strukturell machen?
Kann man nicht so einfach pauschal sagen, aber es ist ja auch nochmal ein Unterschied, wann sie reingerufen werden, weil sie müssen ja nicht der erste oder die erste sein, die sofort angerufen werden, sondern man hat ja häufig dann ja auch verschiedene Stufen, also Second Level Bereitschaft quasi.
Und das ist dann meistens ja noch eher entspannter.
Ich glaube, die schrecklichste Ausrede, die ich mal gehört habe, ist, ich kann nicht auf Rufbereitschaft, weil ich habe Familie.
Und meine Antwort war, ja, die Leute, die in der Operations-Abteilung arbeiten, haben auch Familie.
Und dann war auch Ruhe.
Aber ich meine, das ist ja teilweise auch so ein bisschen angstgetrieben.
Was ist, wenn das Handy schält?
Und dann bin ich ja erst mal alleine.
Dann bin ich vielleicht...
für den Stack verantwortlich und nicht nur meine kleine Java-Applikation, sondern weil die Datenbank jetzt down ist oder der Redis oder der Memcache oder ähnliches.
Und das ist ja auch mehr oder weniger dasselbe Thema wie ich deploy Freitag nicht, weil ich habe Angst, was kaputt zu machen und dann Überstunden zu machen oder ich komme nicht richtig zum Grillen oder ähnliches, was man so freitags halt macht.
Wie geht man mit Angst im Team um?
Ich meine, das ist ja prinzipiell genau die Frage, wie teste ich mein Auto, wenn ich dicht auf der Spielstraße auffahre, ob das jetzt wirklich bremst, was du vorhin gesagt hast.
Wie testet man ein Team daran?
Also erstmal würde ich mal die Frage stellen, wenn ich einen Fehler mache, was passiert dann?
Und das ist, glaube ich, die wichtigste Frage, die man sich zu Beginn stellen kann.
Vor allem, wenn du es nicht in der Hand hast, was die anderen machen.
Und dann kommt es...
Aber du meinst jetzt auf der Ebene...
Bezüglich blameless culture, bekomme ich irgendwie Anschiss, wenn ich einen Fehler mache?
Nicht nur.
Auf welcher Ebene?
Auf allen Ebenen.
Weil das eine ist so, ich muss mich rechtfertigen.
Aber es kann ja auch sein, wie was wir vorhin hatten mit, oh Gott, wenn ich jetzt einen Fehler mache, dann muss ich sechs Seiten Reporting schreiben.
Das hatte Andi ja als Negativbeispiel genommen.
Man kann es aber auch als Positivbeispiel nehmen, weil du dann nochmal stärker darauf achtest, kein Schipfel oder zu treiben.
sondern das ordentlich testest, damit du eben nicht noch ein langes Reporting schreiben musst.
Kann man beide Seiten drin sehen.
Aber ja, grundsätzlich ist es aber Fehlerkultur.
Was passiert, traue ich mich Fehler zu machen?
Was passiert dann?
Was passiert für mich selbst erstmal?
Weil ich meine, ich bin effektiv solo-selbstständig.
Wenn ich in Sachen, die ich selbst Hoster betreibe, dann gucke ich natürlich auch, wie schlimm ist es jetzt, wenn was nicht funktioniert.
Dadurch, dass es das meiste nur mich selbst betrifft, ist das relativ egal.
Wenn ich jetzt aber was für einen Kunden...
dann will ich das teilweise auch gar nicht, weil ich gar nicht alleine das komplett managen kann, wenn ich halt auch mal offline sein will und so weiter.
Und da hängt es halt auch wieder darauf an, okay, was ist das?
Da kommen natürlich die verschiedenen Faktoren, die wir vorhin auch schon teilweise hatten.
Wer sind die Endnutzer?
Wann sind die Endnutzer aktiv und so weiter?
Aber halt auch so Sachen wie, habe ich ein Errorbudget?
Was passiert denn an der Nacht?
Kann ich vielleicht auch ein paar, vielleicht werde ich manchmal auch, das gibt es ja auch voll oft.
dass irgendwas in der Nacht benachrichtigt, was überhaupt nicht relevant ist.
Das hat er auch schon so oft, wo mir Leute gesagt haben, naja, wenn ich nachts aufgeweckt, dann sehe ich, das SSL-Zertifikat läuft in sieben Tagen aus.
Warum kriege ich da nachts eine Benachrichtigung?
Wer stößt denn überhaupt so einen Wandel an?
Denn jetzt mal entweder du bist in einer Luxussituation und die ganze Firma ist blameless unterwegs.
Die ganze Firma sagt, Move fast, break things.
Facebook hat ja auch nicht mehr das Motto.
Die haben es ja auch geändert.
Aus unerklärlichen Gründen.
Aber wenn die ganze Firma da ist, dann bist du natürlich in einer Luxussituation.
Aber es kann natürlich sein, dass das C-Level jetzt noch auf der Blameful-Kultur, wie nennt sich die Kultur?
Blameful.
Traditionelle Kultur.
Oh, das ist fies.
Aber wahr.
Nennen wir sie Blameful.
Kultur unterwegs ist, aber dann dein Abteilungsleiter und dein Teamleiter sich den ganzen Blame abholen und nach unten blameless betreiben.
Das ist ja schon eine tolle Sache eigentlich von deiner Abteilung.
Aber jetzt ist es natürlich auch so, dass das auch zu Streit im Team selbst führen kann.
Stell dir mal vor, wir drei arbeiten zusammen.
Schlimmer Vorstellung.
Ist richtig.
Und der Wolfgang macht halt AI-Slop.
Force Merge auf dem Master.
Ja, weil Protective Branches haben wir auch nicht.
Die behindern uns ja nur.
Der Wolfgang ist aber am Wochenende auf einem Rockfestival oder auf einer Hütten-Tour in den Bergen.
Und ich bin on-call.
Und der macht das zum vierten Mal in Folge.
Shippt einfach irgendeinen Eislob, den er nicht gereviewt hat.
Weil es geht ja um Produktivität, es geht ja nicht um Verstehen.
Das kann ja richtig Knatsch erzeugen.
Was sagst du solchen Teams oder Teamleitern, die vielleicht so ein Team haben, die sich nicht mehr grün miteinander sind?
Was mit Holz machen?
Nee, da gibt es keine einfache Antwort.
Also da kann ich jetzt so auch spontan auch nichts so richtig zu sagen, weil da muss man sich schon ein bisschen gucken, so okay, warum, also müsste ich jetzt wieder die 5Y-Fragen stellen, so warum macht er da das?
Also ein paar Sachen würde ich jetzt eh sagen, so okay, Frostpush of Master oder Frostmerge of Master sollte man eh nicht können alleine.
Per Default, damit löst du schon einige Probleme.
Aber halt, es kann natürlich dann trotzdem sein, dass der Wolfgang dann sagt so, ich werde hier nur ausgebremst, weil ich ständig ein Review machen muss.
Aber dann kann man ja schon dann sagen, okay, da musst du aber auch die Schmerzen selbst spüren.
Wie von wegen, okay, du darfst was selbst mörchen, aber dann hast du das Wochenende dann Bereitschaft oder sowas.
Die meisten gucken ja dann doch eher, sind doch eher egoistisch und gucken auf sich.
ihm rette ich meinen Arsch und sowas.
Und dadurch ist jetzt ein Mechanismus, man müsste jetzt noch genauer gucken und überlegen, was man dann halt auch macht, um das Ganze zusammenzuführen.
Und weil theoretisch kannst du das Gleiche ja mit ihm auch machen, wenn es jetzt egal ist für den Kunden.
Dann mache ich jetzt auch einen Change, wo ich weiß, das wird dem Wolfgang auf die Nase fallen.
Ich kenne ein Beispiel von einem Kollegen, wo ich in einem Team auch saß als Externer, den hat ich dann Jahre später wieder getroffen, vor ein paar Jahren.
Und der meinte, der hat die Firma und das Team, wo er war, hat er gekündigt, ohne einen Folgejob zu haben.
Da fragte ich ja, was war denn los?
Und dadurch, dass ich in diesem Team halt war, als Externer, ohne dass ich Bereitschaft machen musste, die anderen aber schon, war es dann halt auch so, die wurden halt jede Nacht, also nicht jede Nacht, aber regelmäßig nachts aufgeweckt, weil ein Fallsystem vollgelaufen ist.
Und da bist du dann als reines Ops-Team, stehst du dann da und kannst nicht viel machen, was irgendeine Anwendung ist, von der du keine Ahnung hast.
Da würde ich an seiner Stelle, hätte ich auch schon längst gekündigt.
Also ich konnte das voll nachvollziehen.
Und da bist du dann aber teilweise an dem Punkt, wo du dann halt strukturell schon was verändern musst, wo du als einzelner Individual Contributor effektiv halt nicht zu einer Verbesserung führen kannst.
Also ein paar Sachen kannst du schon machen, weil du kannst ja schon zu den Teams hingehen, gucken, was ist das für eine Anwendung, mit denen reden, in der von Ops natürlich getrennt sind.
Viele Sachen lösen sich halt doch durch Reden.
Und da war es zum Beispiel auch so, da gab es dann immer irgendwelche Projektmanager, die sind dann, wenn sie was schneller unterwegs haben wollten, sind die mit so Tafel Schokolade ins Büro geladen.
Und dann so, ich hier, Katze, dich doch.
Aber so als Dankeschön und sonst was und mit den Leuten halt reden hilft.
Ja, aber vielleicht ist das jetzt auch wirklich, das klingt jetzt so ein bisschen komisch, aber ich habe vor kurzem einen Actionfilm gesehen.
Da ist dann irgendwie so ein Elite-Soldatenteam irgendwo in Bolivien und ja, bla bla bla, wurden dann abgesetzt und kommen sich irgendwann in die Haare und dann kloppen sich zwei Leute.
Und ein Dritter aus dem Team sagt, so Werner, du sagst jetzt dem Henry mal Entschuldigung.
Entschuldigung, Henry.
Und so, Henry, du sagst dem Werner jetzt auch mal Entschuldigung.
So nach dem Motto, so muss es ja auch gehen.
Also irgendwie, ich habe so das Gefühl, die Situation, die ich gerade beschreibe, ach so, bevor ich die weiter beschreibe.
Wolfgang, was sagst du eigentlich zu deiner Verteidigung?
Warum muss ich mich verteidigen?
Also das ist die Zukunft, Andi.
Du hast es nur noch nicht verstanden, dass AI alles macht und das durchgewunken wird.
Dass wir da jetzt flotter am Weg sind und nicht nur da auf alten Reviews herumhängen.
Ich finde das toll, dass man bei PagerDuty und Obstgenie dann sehr wahrscheinlich die Rufbereitschaft auch überschreiben kann, ohne dass der andere das irgendwie acknowledging muss, von daher.
Nee, aber ich glaube, du sprichst da gerade einen guten Punkt an und den sprechen Wolfgang und ich natürlich auch dauerhaft irgendwie im...
Moment, du kannst jetzt ein neues Thema anfangen.
Du wolltest noch deine Kindergartentaktik fertig besprechen, dass man sich gegenseitig entschuldigt.
Ja, sag ich doch gerade, sag ich doch gerade, da komme ich da gerade zu.
Lass mich doch mal ausreden.
Ach so, okay, okay, natürlich, natürlich.
Also ich glaube, da kommt es dann wirklich darauf an, dass sich das Team jetzt, sag mal, in der Retrospektive oder sowas einfach mal klar wird, okay, wir arbeiten hier zusammen und wir müssen jetzt hier an einem Strang ziehen und wenn einer halt irgendwie ins Haus geht, dann funktioniert die ganze Sache, weil die ganze Sache vielleicht hier auch kein Einzelsport, sondern Teamsport ist.
Und vielleicht fehlt dann aber auch mal eine direkte Ansage vom Management, was dann sehr wahrscheinlich nicht förderungsfähig für die Frage ist, was passiert, wenn du einen Fehler machst, aber wenn einer halt irgendwie immer gegen den Strom schwimmt, dann ist es natürlich auch schwierig.
Und da frage ich mich natürlich, okay, ist Freitagsdeployment überhaupt eine technische Sache oder geht es halt wirklich nur um den Zusammenhalt eines Teams?
Und wie stark steht man da zusammen?
Ich möchte aber auch nochmal grundsätzlich, weil du alles aufs Team lenkst, schon auch noch sagen, dass es gerade bei diesen Sachen, und da kommt jetzt wieder mein Feuerwehrhut ins Spiel, Wenn du schnell Entscheidungen treffen musst, und das musst du ja meistens, wenn es on call und so weiter ist, damit es stressfreier abläuft, gibt es einfach gewisse Regeln und du kannst Guardrails einstellen.
Du kannst verhindern, dass jemand irgendwie einen Force-Push macht.
Du kannst Standard Operation Procedures definieren, dass sich die Leute leichter tun, dass die Angst wegkommt.
Dann funktioniert es auch zwischenmenschlich öfters besser.
Vor allem, wenn man dann auch, wenn man mal zusammenkracht und dann sagt, okay, dann machen wir da irgendwelche Guardrails, dann machen wir da irgendwelche Action Points und ändern das aber auf struktureller Ebene oder auf Automatisierungsebene und kommen dann auch weiter.
Also ich glaube, das Problem ist einfach, wenn, wie ihr das schon als Beispiel gesagt habt, wenn einer immer Scheiße baut, aber du musst dich dann halt auch darum kümmern, dass das besser wird und vielleicht irgendwie in die Schranken weisen, weil oft ist es ja auch so, dass die Leute gar nicht absichtlich machen.
Ich habe noch ein paar Beispiele, die ich gerade wieder super passend finde.
Ich bin ja teilweise auch in Teams als Externer, jetzt gerade auch in einem Team, da gibt es halt eine Person, die ist ein bisschen, sagen wir mal, anstrengender.
Und auch sehr nach, naja, ich möchte was verändern, also er möchte nichts verändern, es sollte möglichst alles gleich bleiben, wie es ist.
Und das haben wir schon immer so gemacht.
Was dann halt wieder schwierig ist, wenn man dann auch wieder keinen Vorgesetzten hat, der da ein bisschen eingreift.
Weil wenn dann so Sachen kommen, so Aussagen kommen wie, oh, bei Reboots wäre ich vorsichtig.
dann weißt du schon, mit dem brauchst du nicht über Freitags-Deployments diskutieren, sondern über alle Deployments, egal welchen Tag.
Das weiß ich einfach nur, wo ich meine Ransomware verstecke.
Oder halt auch irgendwie so Sachen, die hatte ich dann auch zum Beispiel so gemacht, so naja, okay, wenn Abhängigkeiten nicht händisch aktualisiert werden und die ständig hinterherhängen, kannst du hingehen und das mit Renovate automatisieren, bist du wieder bei Technik und Prozesse.
Wenn aber eine Person dann wieder Angst hat, dass dadurch, meinte dann halt so, naja, das ist ja schon ziemlich fahrlässig, wenn einfach Merch-Requests aufgemacht werden von einem Bot.
Und dann meinte so, naja, was ist daran fahrlässig?
Es wird ja nicht gemercht.
Und sträubt sich halt mit Händen und Füßen dagegen, wo ich dann manchmal halt auch nicht weiß, warum ist das Problem?
Und dann muss halt schon irgendwann ...
Vorgesetzte eingreifen und sagen, das macht hier schon Sinn, weil was ich häufig sehe in den verschiedenen Teams, Firmen, wo ich war, dass eine Person, die ständig blockiert und so, ja, aber sagt für alles Mögliche, das zieht dann schon die Produktivität, die Zufriedenheit von diesem Team halt herunter.
Manchmal wird das gar nicht so sichtbar, weil Leute haben dann keine Lust zu diskutieren, wenn man weiß, dass wenn ich jetzt was anbringe, was uns voranbringen würde.
dass ich dann in einer endlosen Diskussion mit einem, ich nenne ihn jetzt einfach mal Andi, bis er nur Andi wäre, der ständig mit mir alles tot diskutieren will.
Deswegen macht er ja einen Podcast.
So, das muss man aber halt auch als Teamlead dann vielleicht auch sehen oder auch Strukturen schaffen, damit man das sehen kann.
Weil wenn du in einer Retro bist und hatten wir das Beispiel vorhin ja auch, du traust dich aber nicht zu sagen, dass jemand ständig nur am Blockieren ist, weil es wieder zu unnötigen Diskussionen für du darauf keine Lust hast, dann ist das vielleicht ein bisschen schlecht.
Dann solltest du halt auch in One-and-Ones oder einen anderen Feedback-Kanal noch aufmachen, womit du solche Themen dann halt auch besprechen kannst und anbringen kannst, weil es halt keinen Sinn macht, das in der Gruppe zu machen.
Menschen ist echt ein kompliziertes Thema und da gibt es echt nicht die einzig wahre Lösung.
Deswegen ist das echt nicht so einfach.
Einige Sachen müssen durchgedrückt werden, aber ich sage immer so ein bisschen, Von unten her gesehen, von der Hierarchie her, muss man nach oben hin die Hand geben, aber die andere Seite muss halt auch die Hand zurückstrecken, damit das was wird.
Weil wenn wir jetzt gerade, also ich meine, wir haben kaum über AI gesprochen hier und das müssen wir jetzt auch mal ändern.
Wir hören hier gerade irgendwie alle möglichen Leute, egal ob in den USA oder auch in Deutschland oder in Europa, sagen, oh ja, wir sind jetzt mit AI so viel mehr produktiver.
Ich frage den Leuten ständig, aber wie oft deployt ihr das Ganze überhaupt?
Oder wie testet ihr das Ganze?
AI-Slop hatten wir vorhin ja so ein bisschen.
Und das ist auch bei Management gar nicht so auf dem Schirm.
Und ich frage mich dann häufig, du hast Angst, Freitag zu deployen.
Gleichzeitig habt ihr aber so viel AI-Slop, der da irgendwie rumfliegt.
Da wundert mich nicht, dass ihr auch nicht Freitag deployt, aber dann habt ihr auch da keinen wesentlichen Mehrwert durch AI.
Sehr vereinfacht gesagt.
Ja, ich glaube auch, dass das Problem ja dann, wenn wir jetzt über Renovate Bot sprechen und das schon ein Problem ist, dann brauchen wir ja gar nicht über AI sprechen, weil das ist ja nochmal ein Schritt weiter.
Aber meine Herangehensweise ist ja auch immer, ein bisschen in den Untergrund zu schauen, weil meist hat es ja irgendwelche Gründe, warum Leute jetzt ein Problem haben, dass dann Bot ein Merge Request aufmacht.
Hast du da Ideen?
Warum das so ist?
Haben die Angst vor, dass sie ihren Job verlieren, weil da jetzt ein Bot irgendwas macht oder die Kontrolle zu verlieren?
Oder hast du da irgendwie Ideen, warum Leute ein Problem damit haben, wenn ein Bot einen Merge-Request aufmacht?
Also da, wo ich es gemerkt habe, wo es zu solchen Diskussionen kam, wo Angst vor Automatisierung effektiv gab.
hatte ich mehr das Gefühl, dass die Leute Angst hatten, deren Jobs zu verlieren oder halt nicht mehr relevant zu sein.
Ich habe für mich immer, ich habe bei ein paar Firmen gearbeitet.
Bei mir war immer der Punkt, ich möchte nicht unersetzbar sein, weil das gehört für mich jetzt auch in diese Kultur dazu, weil ich möchte auch, wenn andere Bereitschaft haben und trotzdem was nicht funktioniert, dann möchte ich nicht der sein, der angerufen will.
Auch wenn ich die Firma vielleicht längst verlassen habe.
Ich finde es immer noch spannend zu hören, was sie so machen und sonst was, auch wenn ich da schon lange raus bin.
Aber ich will damit auch abschließen können.
Wenn ich aber mich so manifestiert habe in einem Firma, in einem Projekt, in einer Infrastruktur, dass es nicht mehr ohne mich geht, dann habe ich so eine starke Abhängigkeit in beide Richtungen, dass ich dann halt auch Angst habe, dass ohne mich nichts läuft.
Und das ist dann wieder ein schlechter Indikator für, wie gut funktioniert denn das an einem Freitag, Samstag, Sonntag, wenn ich im Urlaub bin.
Das habe ich übrigens auch erlebt bei OnCore.
Die Teams, die davor ziemlich Probleme hatten, irgendwas aufzuschreiben.
Das waren teilweise auch so Persönlichkeiten.
Ich habe das Wissen und die Leute kommen dann zu mir und fragen mich.
Nach On-Call war das meistens seltenes Problem.
Dann haben plötzlich alle freiwillig angefangen, alles niederzuschreiben und dass jeder alles weiß, weil wenn man mal in der Situation ist und auf die Schnauze fällt, dann ist man froh, wenn es irgendwo steht oder wenn auch jemand anderer das machen kann oder man nicht ständig aus dem Urlaub rausgebätscht wird.
Also vielleicht ist das gar nicht so schlecht, auch wenn man einfach mal On-Call einführt.
Dann verstehen Leute auch, wo die Probleme liegen.
Man muss halt doch hin und wieder einfach selber gegen die Wand laufen, damit man versteht, um was es geht.
Ja, absolut.
Ich bring mal die andere Seite rein.
Und ich advokate jetzt nicht dafür, dass du dich unersetzbar machen sollst.
Ich will nur sagen, menschlich, psychologisch ist es ein tolles Gefühl, gebraucht zu werden.
Und es ist unglaublich schwierig, daraus zu kommen und dich ersetzbar zu machen.
Denn es ist halt nicht intuitiv.
Eigentlich, wenn du darüber nachdenkst, wenn du dich ersetzbar machst, dann dokumentierst du viel, dann machst du hochqualitative Arbeit, dann schreibst du Runbooks und all das, was halt Leute enabelt, diese Probleme selbst zu lösen.
Das bewegt dich ja eigentlich dazu, der beste Mitarbeiter zu sein, weil du ja ersetzbar bist.
Ja.
Also das ist ja eigentlich gegenläufig von dem, was man eigentlich so denken würde.
Aber psychologisch gesehen ist es echt toll, wenn du immer vom Management gefragt wirst und alles in der Antwort hast, in die großen Meetings mit eingeladen wirst, in die Entscheidungen mittriffst, weil du weißt ja alles.
Vielleicht bist du ein BuzzFactor.
Vielleicht bist du der Knowledge-Geeholder.
Es ist alles schwierig.
Aber ich will nur sagen, psychologisch fühlt sich das toll an, dass das weitreichende Probleme hat.
Und dass du dann vielleicht auch die Firma als Geisel nehmen kannst, wenn die dir nicht 300.000 Euro im Monat zahlen oder im Jahr.
Das steht auf einem anderen Blatt.
Aber ich will nur sagen, Psychologisch, wenn man in die Situation ist, da rauszukommen, ist so vielleicht ein Drogensüchtigen sagen, dass er drogensüchtig ist.
Ich bin ganz bei dir.
Also es ist wie so vieles bei diesem People-Thema.
Es gibt keine einfache Lösung.
Es gibt sehr viele Faktoren, über die man schauen kann, sollte, muss.
Und das ist halt auch so ein Punkt, den man betrachten muss.
Weil ich denke dann halt wieder, naja.
Wenn ich so gut bin, dass ich das so dokumentiere, so verwalte, dass das auch ohne mich läuft, dann finde ich auch in einem anderen Job, in einer anderen Firma, kann das Gleiche machen und in den Jobinterviews auch davon erzählen.
Weil wenn du dich abhängig, wenn du die Infrastruktur oder deine Anwendungen so baust, dass die davon abhängig ist, dann kannst du das bei einem Jobinterview nicht so gut erzählen wie andere.
Ich sage den Leuten immer, meistens halt eher so juniorige Leute, wenn sie sich irgendwo bewerben, also die mich dann halt fragen, so ja, hast du Bewerbungstipps oder so, schau, wie du das Leben von dem Teamleiter vereinfachen kannst, das Arbeitsleben vereinfachen kannst.
Wenn du das nicht hinbekommst, dann wirst du den Job halt auch nicht kriegen.
Und das zieht sich dann halt auch, wie du tatsächlich auch arbeitest, dann halt auch Job für Job weiter durch.
Würde ich dir zustimmen, ohne halt jetzt irgendwem in den Arschwein zu kriechen.
Also ich meine, das gibt es natürlich dann auch, aber nun gut.
Aber ich finde, eine schöne Sache, die diese Podcast-Episode mal wieder zeigt, ist, die Technik ist zwar kompliziert, aber ein gelöstes Problem.
Anscheinend sind die Menschen mal wieder das reale Problem, weil die Menschen schaffen dann auch Prozesse und allem drum und dran und sich gegenseitig vertrauen.
Das ist ja auch mehr oder weniger das Credo dieses Podcasts.
Aber kommen wir mal zum Ende.
Wenn die Hörerschaft nach dieser Episode nur eine Sache mitnimmt, was ist das?
Man muss nicht freitags deployen.
Man sollte es können bzw.
dahinarbeiten, dass man theoretisch immer deployen könnte.
Und welchen konkreten Arbeitsauftrag würdest du unserer Hörerschaft mitgeben, wenn die morgen oder, falls ihr diese Episode am Wochenende hört, am Montag ins Büro geht?
Was sollte man überprüfen?
Was sollte man direkt?
als ersten Handlungsstrang machen?
Ich würde erst mal überlegen für mich selbst, die Frage hatten wir vorhin ja auch, wenn ich einen Fehler mache, was passiert dann?
Und kann ich das verbessern?
Also die Antwort, die da drauf kommt, kann ich das verbessern?
Wenn die Antwort auf die Frage ist, ich würde Ärger bekommen von meinen Teamkollegen, dann kann man schon mal wieder fragen, warum kriege ich Ärger und kann das verbessern?
Wenn es von dem Chef oder vom Teamleiter oder von weiter oben kommt, ist es wieder ein bisschen schwieriger.
Aber auch da kann man nochmal gucken, wie kann ich das verbessern?
Kann ich strukturell vielleicht was verbessern, damit das gar nicht erst auftritt, wo ich mal mit anderen Teams arbeiten muss?
Also sehr viel Warum-Fragen, aber halt auch, was kann ich im Konkreten tun?
Das klingt für mich ganz stark nach, man tippt mal seinen Bestie am Montag im Büro an und lasst mal Kaffee trinken gehen und dann versackt man da in der Kaffeeküche.
Aber Jetzt nochmal, jetzt bin ich Montag im Büro, ich komme nicht weiter und denke mir so, aber ich will das Thema angehen.
Man kann auch Geld bei dir dafür ausgeben, ist das richtig?
Korrekt, das ist einer meiner Punkte, die ich angehe bei vielen, genau.
Wie kontaktiert man dich, was bietest du an?
Nutze diese Zeit doch bitte, um etwas Werbung für die Firma zu machen, mit dem Troll-Namen oder mit dem besten Namen ever, Friday Diplomates.
Genau, also man findet mich oder meine Firmenseite unter 4id-deployments.com oder 4id-deployments.com.
Ich glaube, wir gehören beide Domains.
Und da gibt es auch Kontaktformular.
Man findet mich auf im 4Diverse, also auf Masteron findet man mich.
Und auf LinkedIn auch, wo ich vielleicht demnächst mal ein bisschen mehr posten.
werde und wer sich mit dem Thema genauer auseinandersetzen will, also vollumfänglicher, im Endeffekt geht es in meinem DevOps-Buch ja genau darum, jetzt nicht um Freitagsdeployment, zum Konkreten, aber letztendlich ist es ja auch nur ein Aufhänger, über die Kultur zu sprechen.
Ist dann wieder unabhängig davon, welchen Tag wir jetzt deployen oder ist das überhaupt eine Software, die man deployt.
Und falls ihr, also in dem Sinne, die ihr zuhören, eine Story habt aus einer Firma.
wo was gut funktioniert hat, wo was anders funktioniert hat, die wir vielleicht nicht betrachtet haben.
Ich werde demnächst an der zweiten Auflage meines DevOps-Buchs arbeiten und ich suche da noch Storys von deutschen Firmen, was alles rund um DevOps angeht.
Das kann sein, wie man Blameless Post Mortems eingeführt hat vielleicht, wie man Freitags Deployments eingeführt hat, weil man kennt halt diese ganzen Storys von so einer Netflix, von so einer Amazon, von so einer Google.
Man sieht jetzt aber irgendwie nicht so richtig, deutsche Firmen oder aus dem deutschsprachigen Raum, die auch eher modern nach den DevOps-Prinzipien halt arbeiten.
Und das würde ich gerne ein bisschen tiefer halt mit eingehen in meinem Buch.
Also, falls ihr eine Story zum Teilen habt, wie ihr jeden Freitag absichtlich deployt oder fast noch spannender, wie ihr da hingekommen seid und wie ihr ein komplettes Management-Turnaround hingelegt habt, meldet euch doch einfach mal.
Alle Kontaktdaten für Suchiwan findet ihr in den Shownotes.
Ich glaube, du bist bei uns auch im Discord, richtig?
Ja.
aber nicht sonderlich aktiv.
Aber vielleicht jetzt.
Das geht gar nicht.
Jetzt natürlich.
Alle jetzt zu Jeevan pingen auf Discord, bitte direkt.
Ich ändere jetzt meinen Namen zu.
Friday the comments.
Ja, eigentlich.
eigentlich wollte ich ja in meine Selbstständigkeit gehen und weniger arbeiten, damit ich sagen konnte, naja, ich mache hier Lifestyle-Teilzeit und ich deploye auch nicht freitags, sondern donnerstags, aber dann dachte ich, okay, dann müsste ich die Firma auch wieder umbenennen und dann müsste ich eigentlich Thursday-Deployments nennen.
Egal.
Ja, also ich meine, du musst halt auch das machen, was Friedrich Merz sagt, mehr arbeiten, deswegen ist das alles okay.
Also, Saturday Deployments.
Das ist es.
Genau.
Saturday Deployments.
Auch geil.
Oder Sunday Deployments.
Ich finde den Namen immer noch.
Ich feiere den total.
Und ich glaube, ich habe auch irgendwo diesen This is fine Friday Deployments Sticker hier rumfliegen.
Vielen lieben Dank, dass du dir die Zeit genommen hast, mit uns über dieses Thema zu sprechen.
Ich weiß nicht, ist es ein Streitthema?
Ist es kein Streitthema?
Es ist ein Leidensthema, würde ich sagen.
Aber kein Streitthema mehr.
Zumindest in der Community würde ich fast davon ausgehen.
Also jetzt die Frage, was machen wir als nächstes?
Ich meine, wir nehmen am Abend auf, wir haben jetzt kurz vor 21 Uhr, also ich deploy gleich nochmal die Engineering-Kurs-Webseite und Aber wir haben auch keine Rufbereitschaft für die Webseite.
Naja, gut, aber dann geht das einfach.
Und du hast auch keine Angst, dass was kaputt geht.
Wir sind immer verfügbar, bitte, Andi.
Ja, die Self-Healing auf Netlify oder so.
Von daher, das passt schon.
Wobei, während wir diesen Podcast aufgenommen haben, habe ich zumindest drei Messages von unserer Pipeline gesehen, dass irgendwie unsere Webseite dreimal deployed wurde, weil wir sind ja mittlerweile ein großes Team mit den Meetups und es gibt ja auch andere Leute, die die Pipeline nutzen.
Also Andi, wir sind nicht mehr zu zweit und sie scheint...
Hoffentlich hat sie funktioniert.
Ich habe es nicht überprüft.
Wir haben aber in letzter Zeit auch über Discord Bescheid bekommen, wenn irgendwas kaputt war.
Und von irgendeiner, vom Frankie, schöne Grüße, raus, haben wir, glaube ich, auch einen Pull-Bequest bekommen, der das dann auch gefixt, was ich dann mit AI kaputt gemacht habe.
Aber nun gut.
Das war es von uns.
Friday Deployments.
Wir wünschen euch ganz viele schöne und erholsame Friday Deployments.
Habt keine Angst.
Fangt einfach an zu shippen.
Und shippt auch einfach mal vielleicht irgendeinen Type in irgendeinem Dokument oder so oder in einem Kommentar als Friday-Deployment, als Übung.
Denn theoretisch sollte da nichts kaputt gehen, ist ja keine Code-Änderung.
Vielleicht ist das eigentlich mal ein ganz guter Tipp.
Nächsten Freitag einfach mal einen Kommentar ändern, durchmergen, Freitags-Deployen.
Einfach nur, um den Teamleiter oder Teamleiterin zu sagen, hey, schau mal, das geht.
Da geht nichts kaputt.
Das war's von uns.
Und falls ihr noch nicht genug habt, hört mal in den Tillpod rein, tillpod.net.
findet ihr natürlich überall da, wo es Podcasts gibt.
Und ansonsten würde ich sagen, vielen lieben Dank und tschüss.
Ciao.
Ciao.