Folge 57: DevOps bei T-Systems MMS 2/2

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Hier folgt die zweite Folge zu DevOps bei T-Systems MMS. Unsere Gäste sind weiterhin Michael Glathe und Holger Helas.

Die beiden berichten von ihrer täglichen Arbeit und helfen uns, DevOps Theorie und gelebte Praxis zu verbinden.

In Dieser Folge geht’s um’s Eingemachte: um die Menschen, mit denen man zusammenarbeitet.

Insbesondere um beliebte heiße Eisen wie die Rufbereitschaft und wie sie bei T-Systems MMS umgesetzt ist.
Außerdem sprechen wir viel über das Menschenbild und das Thema Vertrauen, die natürlich zentrale Punkte bei der Gestaltung der Zusammenarbeit sind.

Inhalt

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Dierk Söllner, Falko Werner und Luca Ingianni
Hallo und herzlich willkommen zu einer weiteren Folge des Podcasts DevOps – auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingiarni, Dirk Söllner und Falko Werner.
Wir sind jetzt in der Fortsetzungsfolge, immer noch mit unseren Gästen Holger Helers und Michael Glate von der T-Systems MMS aus Dresden.
Die hatten so viele Themen mitgebracht und wir haben so nett geplaudert und so gut uns unterhalten,
dass wir über die Zeit gegangen sind und dann, dass wir es schon so ein bisschen erwartet haben, eine zweite Folge jetzt aufnehmen.
Also hier Folge 57, wo wir ein bisschen mehr versuchen wollen, auf das Thema DevOps in der Praxis einzugehen.
Und dann fange ich mal an mit der…
… der Liste, von der ich ja auch in der letzten Folge schon gesprochen habe.
Ihr habt uns ja eine lange Liste mit Punkten gesprochen, geschickt, über die ihr sprechen könntet.
Und ein bisschen habt ihr schon über den nächsten Punkt gesprochen in der letzten Folge.
Einarbeitung. Wie organisiere ich den Ramp-up? Also wie kriegt man Leute in ein DevOps-Team?
Vielleicht ist es ganz gut, wenn ich aus meiner Rolle Scrum Master beginne und Michael, du dann über deine eigene Einarbeitung erzählst, oder?
Na klar.
Also wir haben…
Vor anderthalb Jahren sind wir gestartet als komplett neues Team, was neben ein anderes Team gestellt wurde.
Und wir haben ein sehr gutes anderes, ein sehr kommunikatives anderes Team gefunden.
Und da war die Einarbeitung so, dass sie am Blog stattfand und die erste Woche wirklich dafür da war, uns aufzuladen, was es bedeutet,
Schweizer Transportunternehmen, was erreicht werden soll, was wir in unserem Bereich machen und sozusagen von der Flughöhe weit oben immer tiefer herabgegangen sind,
um dann wirklich in unserem Bereich anzukommen.
Aber ich als Scrum Master habe…
Ich habe jetzt noch weitere Teammitglieder, die ich reinbringen muss.
Und da stelle ich halt fest, dass das wirklich so wie eine Art Trainingslager ist, die ersten zwei, drei Monate, die unbedingt einen motivierten Mitarbeiter haben.
Und dann diesen Kopf aufmachen, das Wissen da reinstecken, wieder zumachen und hoffen, dass es bleibt.
Das ist echt schwierig.
Die Themen sind so aneinandergereiht, dass man einfach auch vergisst und Dinge mehrfach hören muss.
Und wie man das halt strukturiert, das ist gar nicht so einfach.
Und der Mitarbeiter durchläuft da auch so.
Also ein paar Phasen, wenn ich so die letzten drei von uns angucke, die haben immer Euphorie, weil die Umgebung positiv ist.
Die erlangen erste Inselerkenntnisse, die werden dann auch frustriert, weil es nie weitergeht oder die treten irgendwo drauf und das rutscht weg.
Die spüren dann auch so die Wärme des Teams, dass sie aufgefangen werden, dass jeder bereit ist, die Fragen zu beantworten.
Und irgendwann kommt es dann zu dieser wunderbaren Erleuchtung, wo diese Synapsen geschlossen werden, dieses Aha-Erlebnis kommt und ich bin ja doch nicht doof und das brauche aber.
Und das sind meines Erachtens…
Ein halbes Jahr vergangen.
Und so ist auch der Zeitraum, in dem wir planen.
Wir führen die ran, sorgen für Arbeitsfähigkeit, geben die Rechte, erklären den agilen Prozess.
Und dann geht es in ein Thema, meistens bei uns als Tandem, also zu zweit neben einem Erfahrenen, weil es bringt einfach nichts.
Es braucht diese helfende Hand am Anfang, alles alleine rauszufinden, macht einfach frustrierend.
Da braucht man jemanden, der sagt, guck mal, das ist der Zustand, mach das so, lese das so.
Und dann kommt es auf den Mitarbeiter drauf an, was er mitbringt.
Und wie merkt er sich Dinge, schreibt er sich schöne Cheats, die wachsen ins Unerlässliche.
Und er braucht aber die Motivation, wenn sonst ist dieses Trainingslager nie auszuhalten.
So, Michael, jetzt erzähl mal, hast du das so wahrgenommen im ersten halben Jahr?
Also erst mal vom Anfang angefangen ist ja ganz lustig, dass als das Team von Holger angekommen ist, das war ja das Team von Holger plus ich.
Ich hatte die Einarbeitung da mit euch zusammen.
Ich weiß gar nicht, ob ich noch Mitspracherecht beim Teamnamen hatte.
Aber ich glaube nicht.
Jedenfalls, als ich dann angekommen bin in diesem komplexen Umfeld, war es auch erst mal ein sehr, sehr fast schon überfordernde Menge an Informationen, die neu auf einem eingeprasselt sind.
Und ich bin auch der Meinung, dass dieses Einarbeiten im weitesten Sinne gar nicht so schnell aufhört.
Weil die Themen jetzt gerade, wenn ich jetzt über einem Jahr in dem Projekt mit dabei bin, neue Themen werden immer.
Auf Einkommen.
Dinge, von denen man nur am Rande vielleicht mal den Begriff gehört hat, aber jetzt noch nicht groß was mit zu tun hatte.
Also muss diese Bereitschaft auch über das Einarbeiten hinaus bleiben, sich mit neuen Dingen zu beschäftigen und da offen zu sein und da halt vielleicht auch sich die Fähigkeit anzutrainieren, schneller zu lernen.
Also mit der Zeit.
An sich, ich kann auch darüber sprechen, wir hatten jetzt auch zwei neue Kollegen, also drei eigentlich.
Wir einarbeiten mussten, was wir auch versucht haben, als Team abzufangen.
Und dementsprechend sind uns ganz viele Know-how-Träger weggebrochen.
Gerade in bestimmten komplexen Bereichen, wo wir dann gesagt haben, hier, bevor du weg bist, stell uns mal eine Agenda zusammen.
Was ist in deinem Kopf alles drin?
Und dann haben wir nochmal extra Know-how-Sessions gemacht.
Also quasi eine Stunde oder auch ein bisschen kürzer, wo wir das Ganze als Video aufgenommen haben.
Und das dann.
Für perspektivisch neue Kollegen oder Dritte abgelegt haben, wo man sich das immer wieder, ich möchte mal sagen, antun kann.
Natürlich ist das Initial so viel, das kann keiner nach einmal hören, begreifen oder erleben.
Aber letztendlich ist es dafür wichtig, dass, wenn dann der neue Kollege mal in dem Bereich zu tun hat, kann er sich das ja dann mal ein bisschen detaillierter anschauen.
Ich muss da lachen.
Ich habe heute mit dem Kollegen nochmal vorab geredet und gefragt.
Und er hat halt so einen schönen Satz gesagt.
Ja, das Video, das reicht ja nicht.
Es gibt einfach so Pummelthemen, wo man rausfinden muss.
Und wenn man da zwei Stunden sucht und so und niemanden hat, der ihm hilft, dann ist man einfach aufgeschmissen.
Dann kann er den Tag wegschmeißen.
Aber ich habe Respekt vor jedem, der den Schritt, den du auch gegangen bist, sozusagen getätigt hat.
Und dieses Trainingslager, Knochenmühle, so viel Wissen wie möglich reinschaufeln.
Und vor allen Dingen, meine Sachen, es ist viel wichtiger, das Wissen zu behalten.
Und du weißt noch, als wir angefangen haben, haben wir jeden Tag die Schleife gemacht.
Wir haben das irgendwie fortgeführt.
Es gibt ja alle möglichen Toolings dafür, Miro und wir arbeiten mit Microsoft Teams.
Da bleibt jeder Chatraum persistent mit allem da.
Und das ist da gut unterstützt.
Aber es braucht halt das.
Ganz kurz.
Ich wollte definitiv jetzt nicht damit sagen, dass so ein Video reicht.
Um Gottes Willen.
Also allein dieses Theoretische, das ist dann erstmal vielleicht der Einstieg.
Aber dann hat es mir auch erst geholfen oder hat ein nachhaltiges Wissen aufgebaut.
Wenn so dieses, der Begriff Make Your Hands Dirty, also quasi wirklich mal den Code angefasst,
eine Kleinigkeit gemacht, an einer Kleinigkeit frustriert und die dann irgendwann gelöst.
Und das dann immer Stück für Stück.
Findet das richtige Level der Frustration, was noch ausgehalten werden kann pro Tag.
In Hosen sozusagen, ja.
Ja, wie läuft das denn eigentlich bei euch?
Wenn ich jetzt anfange bei euch nagelneu als irgendwie Entwickler, sagen wir mal,
ab wann darf ich mir denn da die Finger dreckig machen?
Das ist, also wie gesagt, bei dem großen Big Bang, Team neben Team gestellt,
gab es diesen richtig klassischen Einarbeitungsplan.
Da wurde geguckt, welches Wissen benötigt wird.
Da wurden Termine dafür gemacht.
Da war die erste Woche nur Vorstellung, was die SBB ist, was ein Transportunternehmen ist,
wie wichtig in Schweizer die Versorgung ist, das auf Bargeldwert legen.
Was unsere Aufgabe ist, dass die Kasse stimmt.
Das wurde wirklich eingebrannt.
Das war auch notwendig, um diesen Anwendungsfall zu verstehen.
Und dann ging es weiter.
Und dann ging es weiter.
Und dann ging es weiter.
Und dann ging es weiter.
Und dann ging es zum Team.
Dann wurden die Tools erklärt.
Und dann wurden in den einzelnen Bereichen Applikationen von Architekten wie Vorträge gemacht.
Und dann war man eigentlich platt nach den drei Wochen.
Und dann durfte man aber recht schnell ins Team kommen.
Und da, wie wir es jetzt inzwischen machen, machen wir es eigentlich so,
wir haben so einen Plan, dass nach einem halben Jahr ungefähr er wissen muss,
wo er hingreifen muss und auch vielleicht sogar die Rufbereitschaft schon durchgeführt hat.
Und nach einem Jahr muss er produktiv sein.
Und das ist so der Zyklus.
Und das wird…
Und das wird bei uns aktuell so erreicht, dass wir wirklich ganz viel über Tandems arbeiten.
Dass die Kollegen mit einem Erfahrenen zusammen Dinge lösen, aber nie zugucken und lösen lassen,
sondern sich selber eigentlich so ab dritte, vierte, fünfte Woche,
nee, eigentlich schon ab den ersten Tagen auch die Hände schmutzig machen.
Genau.
Weil anders lernen sie es ja nicht.
Genau.
Und es ist im Sinne, man ist ja dann auch nicht allein oder wird nicht allein gelassen, um Gottes Willen.
Also, wenn man jetzt sagt,
man kommt an, hat hier ein kleines Problem, ja, und man traut sich das zu, da mal ranzugehen,
dann ist es ja auch immer, bevor das Ganze produktiv geht, wird ja noch so viele,
geht das ja noch über so viele Stages bis hin zu, es muss ja noch auch jemand über den Commit,
also den Pull Request gucken und den dann genehmigen.
Also, sage ich jetzt mal, ein neuer Kollege am zweiten Tag schreibt ja schon mal was,
sind wir mal optimistisch.
So, und dann muss es aber auch immer einen Kollegen geben, der sagt,
okay, ja, das ist gut so, das ist richtig so, das genehmige ich jetzt mal.
Ja, also, das ist nicht so, dass ein neuer jetzt dann kommen kann, sich überschätzt, da was macht
und dann alleine auf einmal unsere ganzen Schienen im Larm legt.
So, das kann eigentlich in der Regel nicht passieren.
Es kann sich, wie gesagt, auch rausstellen, dass die Verantwortung oder die Aufgabenbreite einfach zu breit ist,
dass der Mensch, der da anfängt, das auch nicht schafft.
Das kann durchaus sein.
Wir reden ja über DevOps und die Erweiterung der Wissensfelder und mehr Verantwortung.
Das kann auch zu viel sein.
Aber was wir zum Beispiel auch gut rausbekommen haben, ist, um jetzt neue Kollegen an,
sagen wir mal, Sachen, Sachte an den Code heranzuführen, sind solche Dinge,
die keiner tut, wenn man in diesen Stories und Featuren Kreislauf drin hängt,
nämlich einfach mal Codesmells aufzuräumen, Optimierungen am Code zu machen.
Da gibt es ja jetzt hier neuerdings bei uns auch so ein Analyse-Tool,
was uns da sagt, ja hier vom Code,
da müsste man mal aufräumen, da sollte man mal was machen.
Und dann ist es auch die Eigenverantwortung des neuen Kollegen,
dass er jetzt nicht einfach nur die Pendancies da rauslöscht,
sondern dass er sich dann halt auch vielleicht in dem Modul,
in dem er unterwegs ist, sich das Ganze mal ein bisschen anguckt.
Ja, was macht denn das überhaupt? Wofür ist das da?
Und dann, dass sich vielleicht mal durch den Kopf gehen lässt im Zuge dessen.
Aber man hat dann schon ein paar Aufräumarbeiten, die man dann ja durchaus mitgeben kann.
Ja.
Michael, ich musste gerade lachen. Wir haben ja wirklich zusammen angefangen.
Weißt du noch, wie wir zusammen unsere Entwicklungsumgebung aufgesetzt haben mit sieben Kollegen?
Ja, ja, ja.
Wir haben das als Mob gemacht.
Also alle zusammen in einer Session, alle eine halbe Stunde hat der Driver-Seed gewechselt.
Einer war im Dokumentations-Seed und dann haben wir bei der SBB die Dokumentation,
wie die Entwicklungsumgebung eingerichtet wird,
was ja in einem Confluence ein ganz normales Dokument drunter ist,
macht dies nach, dies nach dem.
Hat der Doku-Seed sitzen, sind dann halt verfeinert mit Bildern,
wie es wirklich funktioniert und, aber wir haben es halt durchgezogen.
Und das war auch eine gute Art des Lernens, weil du warst immer dabei.
Am Ende hatte jeder die gleiche Entwicklungsumgebung.
Jeder wusste ungefähr, was für Entwicklungspräferenzen, Stile sind.
Und das hat zum Beispiel als Maßnahme sehr gut geholfen am Anfang.
Mob-Programming.
War durchaus sehr intensiv, aber zielführend.
Ja, wenn ich das so höre, Holger, du hast es eben sehr schön gesagt.
Ja.
Und erweiterte Verantwortung oder eine relativ hohe Verantwortung.
Und zwar sozusagen nicht nur in die Tiefe, sondern auch in die Breite.
Also wir reden ja bei DevOps von End-to-End.
Und das habt ihr vorhin in der ersten Folge von dieser Doppelstaffel jetzt hier
ja auch schon mal angesprochen.
Ihr habt ja wirklich eine End-to-End-Verantwortung.
Ja, die ist da.
Also vom, wie gesagt, Refinement bis zur Skizze, wie der Code aussehen soll,
bis zum Commit, bis zum Monitoren, bis zum Loggen, bis zum Backloggen,
bis zum Backfixen, wird die Strecke von dem Entwickler begleitet.
Es gibt maximalen Übergang zu anderen Entwicklern,
wenn halt ein neues Planning ansteht und ein anderer da weiterarbeitet.
Aber die gibt es.
Und das Wissen ist unglaublich breit.
Und das ist auch sowas, wo ich immer mit mir kämpfe.
Kann ein Mensch das alles auffassen?
Ist das zielführend, wenn er auch wirklich den Anspruch an sich hat,
alles zu wissen?
Geht das vielleicht gar nicht?
Und da habe ich noch keine richtige Antwort dafür.
Ja, ich denke, es ist auch personenabhängig.
Denn ich hätte jetzt wiederum gesagt, die Frage ist ja auch, will jemand das?
Also da habt ihr sicherlich auch, oder habt ihr vielleicht auch andere Erfahrungen,
aber die Entwickler, die ich kenne, das ist schon ein paar Jährchen her,
wo ich intensiver mit denen zusammengearbeitet habe,
die hatten letzten Endes, sage ich mal ganz platt, keinen Bock zum Testen.
Und Produktion schon mal gar nicht.
Die haben tolle Dinge gebaut, die haben wunderschöne Applikationen gebaut
und dann hat es auch aufgehört.
Und das ist ja die Frage.
Was da so eure Erfahrungen sind, ob das, was ihr erwartet,
nämlich den Wunsch, mehr Verantwortung zu übernehmen,
mehr Aufgabenfelder zu übernehmen, wie das sozusagen ankommt
bei euch und bei euren Entwicklern sozusagen.
Da können wir ja wieder Bande spielen, Michael.
Wir nehmen mal das Thema Rufbereitschaft, oder?
Weil das ist ja so ein Wissensthema, was ganz weit in der DevOps-Welt ist
und wo viele Entwickler sich weigern, das zu tun.
Und bei uns gehört es dazu.
Wir denken auch, dass das nachhaltig ist.
Dass das ein Erfolgsfaktor ist.
Weil wenn ich wirklich mal nachts rausgerufen werde
und feststelle, dass der Code, den ich da geschrieben habe, nicht funktioniert,
dann spüre ich die Verantwortung im wahrsten Sinne des Wirkes,
dass ich vielleicht mal kurz orientierungslos bin
oder danach auch nicht mehr schlafen kann.
Das will man nicht.
Deswegen sind die Rufbereitschaften auch getaktet,
dass sie nicht zu nah hintereinander sind.
Aber wie führt man einen Entwickler ran, dass er Rufbereitschaft macht?
Wie war es bei dir, Michael?
Da möchte ich vielleicht noch mal ganz kurz daran ansetzen,
an der grundlegenden Frage von Dirk,
ob man darauf Lust hat.
Also ich kann da nicht für jeden Entwickler sprechen wahrscheinlich,
aber ich persönlich, ich habe Bock darauf,
jetzt nicht einfach nur ein Feature oder eine Story zu schreiben
und die dann abzugeben und mich dann nicht mehr dafür zu interessieren,
ja, was passiert denn mit der überhaupt?
Was für ein Traffic läuft darüber? Wie funktioniert das?
Geht das überhaupt in der Praxis so eine Art?
Das würde ich schon, da habe ich schon Bock drauf,
das weiter zu verfolgen.
Und dementsprechend jetzt mal ganz weggeschoben
mit der Verantwortung ist es einfach so dieses,
ich möchte damit auch was damit zu tun haben,
von dem, was ich geschaffen habe letztendlich.
Das ist dein Code, den hast du gemacht.
Und dann mit der Rufbereitschaft, das ist dann,
okay, da spürt man dann die Verantwortung.
Das ist richtig, auf jeden Fall.
Nur kann ich dir auch da ganz ehrlich sagen,
hatte ich auch Bock drauf, nicht um darauf zu warten,
dass beim Kunden irgendwas kaputt geht, um Gottes Willen.
Nein, aber es ist gar nicht so schlimm,
Rufbereitschaft zu haben, denn wenn wirklich was kaputt geht,
wenn wirklich da, ich will jetzt nicht ein Wort benutzen,
was jetzt hier vielleicht, wenn wirklich was kaputt geht,
ist man nicht alleine, auf jeden Fall.
Dann sind auch noch andere involviert.
Wie wurden wir da rangeführt?
Es ging ganz einfach los, erstmal natürlich mit den Monitoring-Systemen,
sich vertraut zu machen und zu gucken,
was haben wir überhaupt für Anwendungen,
was läuft da für Traffic drüber,
was kann ich daraus an Informationen gewinnen?
Dann ist das nächste, Schulungen organisiert
und dann kommen wir dann auch wieder zu den Rufbereitschaften.
Das ist ein ganz wichtiger Punkt,
weil wir haben ja in der SBB eben zu sagen,
hier, du hast jetzt mal simuliert einen ganzen Tag Rufbereitschaft.
Wir machen auf den Integrationsumgebungen irgendwas kaputt
und du sollst das dann einfach mal lösen
und eben diesen ganzen Kreislauf mitmachen
mit eben der Kommunikation untereinander.
Und dann gibt’s wiederum auch ein Partner-Team,
ähnlich bei Holger, das nennen wir Cluster.
Wir haben auch ein Cluster-Partner-Team,
was sehr, sehr erfahren ist schon.
Das ist jetzt auch ein Thema,
das wir auch im zweiten Jahr,
in der ersten Session wiederum,
also wo sie uns diesen Timo War Room,
also einen Kriegsraum gezeigt haben,
in dem wir dann im Zweifel auch einfach Informationen finden,
wo auch ganz viel stand,
ja hier, so und so ist manches zu lesen.
Das ist schon mal ganz oft vorgekommen.
Und damit konnte man vielleicht auch schon 90 Prozent
der zu erwartenden kleinen Fehler,
wo man dann alleine bleibt, mit lösen.
Ja, und wenn dann die anderen zehn Prozent,
dann kann man sicher sein,
dass man nicht alleine wach ist in der Nacht.
Die Idee dahinter ist ja,
dass die SBB so eine Art Zero-Impact-Strategie fährt,
dass man Fehler frühzeitig bekommen will
und dass man da so eine Staffelung hat aus Fehlern,
wo man sofort aktiv werden muss und wo gemailt wird.
Und deswegen gibt’s die Rufbereitschaft jedes Team.
Bei uns sind insgesamt elf Teams.
Fast jedes Team stellt immer einen,
der von 17 bis 7 Uhr in Rufbereitschaft ist.
Der kriegt ein Telefon, auf den kommen Sprachnachrichten.
Und wenn man dann so eine Rufbereitschaft hat,
wenn dann seine Applikation dran ist,
dann muss er da eine Problembehebung,
Erstentstörung machen.
Aber es ist das Netz wieder angesprochen worden.
Es ist immer noch so ein Häuptling da,
der drüber sitzt und mit aufpasst.
Und wir haben die Schulung angesprochen,
wo wirklich fast produktionsnah was runtergerissen wird.
Und danach kommen meistens alle
und wollen noch mal ein bisschen Monitoring auffrischen,
wie sie was lesen können.
Und dann, wenn es in die erste Rufbereitschaft gibt,
ist meistens auch noch ein anderer, erfahrener,
Genau.
Mitarbeiter mit im Call, den man anrufen kann.
Und dann sind wir wieder dabei.
Also das war die Strecke halbes Jahr.
Da soll er seine Rufbereitschaft gemacht haben.
Da soll er das Gefühl gehabt haben,
die Verantwortung mitnehmen.
Und in der Zeitraum soll es auch stattfinden.
Und bisher haben sich dem allen gestellt.
Mir persönlich wäre das schwergefallen.
Also ich so Feierabend, Nacht,
ich stelle mir das heilig vor,
aber ich entwickle niemals Software.
Von daher wirklich Respekt für alle, die das machen.
Und letztendlich, weil du am Anfang auch mal gesagt hattest,
wenn dann den Code, den man geschrieben hat, da kaputt geht,
im Zweifel, bevor etwas produktiv ist,
was ich anfangs oder in der letzten Folge gesagt hatte,
es durchläuft so viele Stages,
bevor wirklich etwas produktiv ist,
da wird so oft auffallen und noch Bugs kommen,
bis da wirklich man selber nur für diese eine Codezeile verantwortlich war,
die dann etwas kaputt gemacht hat.
Da muss schon sehr viel passieren.
Und dann ist man auch lange nicht mehr alleine schuld.
Und dann gibt es immer auch die goldene Regel bei der Rufbereitschaft,
niemals in den Code gehen und um Gottes Willen nicht auf
Produktion in der Nacht noch irgendeinen Bugfix zu machen.
Das kann ja noch Schlimmeres hervorrufen,
sondern dann wird einfach das Ganze zurückgefahren auf eine Version,
die man funktioniert hat letztendlich oder von der man hofft,
dass sie funktioniert.
Und dann gibt es am nächsten Tag einfach ein sogenanntes Postmortem,
wo dann das besprochen wird, was da passiert ist,
wo das dann halt auch mit Kollegen ganz entspannt analysiert wird,
geguckt wird, wie problematisch ist das?
Und dann wird das auch gemeinsam gelöst.
Wobei ich da jetzt auch dazu sagen muss,
es klingt so, ihr sagt, Rufbereitschaft ist gar nicht so schlimm.
Ich glaube, das liegt ganz wesentlich daran, dass ihr sehr,
sehr viel Energie und sehr viel Hirnschmalz da reingesteckt habt,
dass es auch tatsächlich nicht schlimm ist.
Ja, wenn ihr mal anruft, die Hütte brennt, dann ist das was anderes.
Ja, und schau, ihr habt ein hinreichend stabiles Grundsystem.
Ihr habt Mechanismen, ihr habt Rückfall-Ebenen, ihr habt…
Ja.
… Anweisungen und so weiter.
Wenn man all das nicht hat, allein wenn ich, wenn alle besten Willens sind,
aber leider habe ich sehr viele technische Schulden oder sowas,
und jede zweite Nacht kracht, ja, dann fände ich es auch ätzend.
Aber mei, wenn es dann halt einmal im Monat ein bisschen knirscht, meine Güte,
dann kann ich das Telefon mal mitnehmen, wird ja eh nicht bringen.
Genau. Ich muss noch was dazu sagen.
Wir sind ja für ein Projekt, für einen Auftraggeber 100 Prozent verantwortlich.
Wir fahren jetzt nie das Thema, dass man drei Projekte gleichzeitig hat
und Rufbereitschaft für mehrere Kunden nachzahlt.
Das führt auch zu Zufriedenheit.
Auch so ein Ding, genau.
Genau. Also, ich glaube, ihr stellt da so ein bisschen euer Licht unter den Scheffel,
weil ich glaube, nach dem, was ich so gehört habe, habe ich mir gedacht,
meine Güte, die haben sich aber schon echt Mühe gegeben,
dass man das auch tatsächlich jedem zumuten kann, Rufbereitschaft anzunehmen.
Ich sage es halt immer so, wenn diese Welt, in der wir arbeiten und Lösungen suchen,
so komplex ist, dann muss die Organisation dafür mindestens,
genauso sein. Und wenn ihr jetzt hört, was es alles für Rollenschulungen gibt,
dann ist die Ausbaustufe sehr hoch. Und das ist ja jetzt nicht nur unser Verdienst,
sondern das ist eine gewachsene Organisationsform mit vor allen Dingen viel,
wahrscheinlich auch Rückenwind, diese Veränderung, dass jeder, die mitmacht,
auch vom Management oder vom Mitarbeiter. Und das ist ja das Feld, in das wir reingekommen sind.
Was wir einbringen, ist, dass wir schnell lernen, dass wir Fragen stellen,
dass wir neugierig sind und dass wir überall mitmachen. Und indem wir das machen
und auch wahrgenommen werden und auf Augenhöhe das ist, ist es halt diese motivierende Umgebung,
die dafür sorgt, dass aus jedem das Beste rauskommt und dass Michael in einem halben Jahr
sich einarbeitet, seine Rufbereitschaft gemacht hat und das halt eingeht.
Genau. Und ich denke aber, und ich bin eigentlich auch felsenfest davon überzeugt,
dass so etwas auch nur in so einem agilen Umfeld entstehen kann.
Also, dass man dann eben, wenn wir dieses Inspect and Adapt nochmal aufgreifen,
was wir in der letzten Folge hatten,
dann eben mal Missstände, das ist jetzt ein großes Wort, aber wenn man dann eben so Dinge,
die nicht funktioniert haben, anspricht und dann ernsthaft darüber nachdenkt,
ja, wie kann man es dann besser machen, dann ist ja klar, dann entstehen auch solche Umgebungen,
wo man sich dann eben nochmal so einen War Room anlegt, wo man dann nochmal so eine Schulung
vom CPR-Team gestellt bekommt für neue Entwickler, alles drumherum.
Ich kann mir nicht vorstellen, dass da einer saß und gesagt hat, ja, hier, damit das gut funktioniert,
brauchen wir von Tag eins dies, das, jenes.
Sondern es wird viel mal vor die Wand gefahren sein.
Aber man hat in dem Umfeld oder Projekt von der SBB halt eben daraus gelernt
und hat dadurch entsprechende Veränderungen vorgenommen, die es dann eben für neue Kollegen einfacherer macht,
so etwas leichter anzunehmen und als gar nicht so schlimm zu empfinden.
Ja, richtig.
Ich möchte gerne auch nochmal auf etwas anderes eingehen,
weil ich finde, ein ganz wesentlicher Aspekt davon, Fehler zu beheben, ist überhaupt erstmal wahrzunehmen,
dass ein Problem besteht.
Mit anderen Worten, eine ausreichende Infrastruktur zu haben in Richtung Monitoring und Logging und sowas.
Dazu hattet ihr ja auch eine Notiz in eurer Themenliste.
Das ist so ein bisschen dieser Zero Impact.
Also das ist alles vorgegeben und gefunden, aber ich finde ihn stark,
weil bei 250.000 Finanztransaktionen am Tag ist ja die Frage, wo stellt man sein Messinstrument ein,
ab wann man benachrichtigt werden will und wie sensibel ist es auch über die Zeit.
Und wir haben…
Wir haben da wirklich Kollegen, die da fast alles auf null Fehler runterbringen wollen,
wo ich schon immer sage, das ist ja so viel Aufwand, der ist ja gar nicht wirtschaftlich.
Aber den Ansatz haben sie halt.
Die wollen nicht, dass der Kollege, nee, der Kollege, der Kunde am Bahnsteig steht und sein Ticket nie buchen kann
oder sein SAV, sein Service Apprevent, sein Rückgeld, wenn er die Reise nie angetreten hat, halt auch pünktlich bekommt.
Und das steckt in denen drin.
Da gibt’s…
Ich bin da immer erstaunt, egal auf welcher Ebene, wie tief man vergraben ist.
Ist es da sozusagen, glänzt hervor, diesen Kunden in den Fokus zu stellen?
Ja, auf jeden Fall.
Auch wenn man mal den Umgang dann halt auch mit entsprechenden…
Also die Folge aus diesen Fehlern sind ja dann auch, gerade auf Produktion sind ja auch Bugs,
beziehungsweise Blocker-Bugs bei uns genannt.
Und wenn man jetzt in der Bugs-Bock-Rolle ist beispielsweise und so einen Blocker-Bug gerade aus der Produktion aufschlägt,
ja, dann hat man auch, dann hat man alles stehen und fallen zu lassen und sich erstmal um den zu kümmern.
Genau.
Und das hoffentlich in möglichst kurzer Zeit.
Du hast die Bugs-Bock-Rolle angesprochen.
Also wir sind DevOps-Entwickler, alle müssen und dürfen alles können.
Aber wir sind noch nie so weit in der Evolution, dass jeder alle Bugs quer fällt, löst, weil da die Abstimmung einfach groß ist.
Sondern es gibt eine Rolle, die schützt das Team und die löst nur Bugs.
Und es gibt eine Rolle, das ist der DevOps, der macht nur Produktionssachen, entstören und aktualisieren.
Und die zwei Rollen schützen das Team.
Und in den Rollen lernt man aber sehr viel.
Und das ist aber auch ein Knochenjob, weil man da wirklich in den Sprint drei Wochen drin sitzt und täglich nur Bugs nach Prio löst.
Da lernt man unglaublich viel, auch weil wir vorhin gesagt haben, wie bringt man neue Mitarbeiter ins Rollen.
Es ist die Pflicht bei uns, dass die beide Rollen mit einem Erfahrenen machen, weil man da einfach so viel lernt,
weil man so viele neue Problemfälle sieht und die end-to-end durchgespielt kriegt,
bis sie dann wirklich auf Produktion mit einem Bug-Fix wieder gelöst sind.
Da muss man wirklich dafür sorgen.
Ich würde sagen, dass das Wissen auch alles hängen bleibt.
Das ist ja das Schwierige.
Ich will nochmal auf einen anderen Punkt eingehen.
Wir hatten ja vorhin den Punkt Entwickler und Hofbereitschaft.
Da haben wir ja herausgearbeitet, wie ihr das seht.
Und Michael hat ja auch gesagt, dass für ihn das okay ist.
Es wird Entwickler geben, die das nicht so okay finden.
Das ist auch nochmal eine persönliche Entscheidung.
Es gibt noch einen anderen Punkt, den ich in den DevOps-Trainings regelmäßig höre
und wo ich immer nur wieder sage, das geht.
Aber vielleicht habt ihr nochmal so eine wirklich gute Antwort und eine gute Erklärung.
Nämlich die Frage, wie kann es sein, dass ich die Entwickler in meine Produktionsumgebung lasse?
Naja, jetzt mal aus der Praxis gesprochen.
Wie oft war ich jetzt auf der Produktionsumgebung wirklich aktiv?
Das kann ich an einer Hand abzählen, jetzt über das Jahr hinweg gesehen.
Und das ist die Vorbereitung auf meine Hofbereitschaft gewesen.
Also im Sinne mal zu testen, komme ich im Zweifel auf die Produktionsumgebung
und kann da etwas nachstellen, wenn etwas schief läuft.
Ansonsten, als Entwickler arbeitest du ja auf Testsystemen,
also auf Snatchot-Umgebung bei uns, die dann irgendwann zur Integration wird.
Da laufen dann noch Abnahmetests, Finanztests drumherum,
bis dann irgendwann diese Freigabe gegeben wird.
Ja, es darf Produktion.
Und dann aktiviert man das ja auch nur in Anführungsstrichen.
Also das glaube ich dir, Michael.
Jetzt kommt das Aber.
Es soll Sicherheitsauditoren geben, die überprüfen, ob du dahin darfst,
weil du da eigentlich nicht hinkommen dürftest.
Bin ich da vollkommen aus der Welt oder wie seht ihr das?
Also das eine ist natürlich klar, DevOps.
Ihr sagt ganz klar, das macht Sinn.
Und das können wir auch alle nachvollziehen.
Aber es gibt eben Menschen, die gucken auf andere Dinge.
Die gucken auf Governance und Security und so weiter.
Und wie gesagt, da kriege ich regelmäßig die Fragen.
Es kann ja nicht sein, dass wir die Entwickler auf die Produktionsumgebung lassen.
Die können ja Kundendaten angucken und so weiter.
Ja, okay, ich verstehe.
Aber Sicherheitsvorfälle waren ja Log4J und Sonstiges im letzten Jahr alle betroffen.
Und die haben auch eine Sicherheitsabteilung, die Leitfäden rausgibt, wie man handeln soll.
Aber was ist denn jetzt wirklich das Risikobehaftetere, wenn jeder Zugriff hat und sich dem Zugriff bewusst ist
und solche Dinge an die Leute auch gestreut werden, dass sie bitte auch auf Informationssicherheitssachen aufpassen müssen,
ist das doch eigentlich was Besseres, wenn es nur der eine oder andere ist.
Also ich versuche die Frage gerade zu greifen und darauf zu antworten, aber mir fällt es schwer.
Okay.
Weil das ist ja dieses Denken, sollte jeder, könnte jeder, warum nicht?
Ja.
Also was ist die Antwort?
Wie stellt ihr sicher, dass Michael sich nicht, Michael, du verzeihst mir das,
sich nicht die Kreditkartenzahlen holt oder die Handynummern oder, oder, oder.
Also all das, was wir ja verhindern wollen.
Ja.
Über geschulte Mitarbeiter.
Ja, was heißt geschulte Mitarbeiter?
Ich glaube, der Dirk möchte auch darauf hinaus, dass, keine Ahnung, wenn ich mal irgendwie einen Frust auf unseren Kunden habe,
und dann da mutwillig böse Aktionen mache, weil ich die Möglichkeit habe, auf diese Umgebung zu gehen.
Aber dann ist für mich die Frage, okay, wenn man seinem Mitarbeiter oder seinem Entwickler von vornherein schon misstraut,
dann warum sollte man ihm vertrauen, dass er pünktlich bestimmte Feature liefert?
Ich denke auch, das geht in die Richtung positives Menschenbild, von dem wir reden und von dem wir ausgehen.
Die Chance besteht, aber die wird halt nie in den Fokus gerückt.
Ich kann mich noch erinnern, vor zehn Jahren, als ich angefangen habe, zwölf Jahren,
da habe ich bei Auslieferungen, bin ich mal drei Etagen hochgegangen von den Entwicklern zu denen, die es in Produktionen dann betreut haben
und habe mich da, damals hieß es noch, Qualitätsmanager hingesetzt und gesagt, die unten haben das gesagt, die oben haben das gesagt
und dann passierte das ein paar Mal und ich habe dann ganz paar Höhenmeter gemacht.
Das ist ja das alte System und da war vielleicht auch sicher, dass nur der darauf kann oder der Teilnehmerkreis,
aber deswegen war es ja nicht produktiv, das hat ja alles viel länger gedauert.
Wir haben ja Dinge designt, die ersten Jahre später dann irgendwie mit CD verschickt und aufgespielt wurden.
Das ist ja heute, Nehmer, heute wird alle drei Wochen geliefert und da hat halt jeder Zugriff.
Und man muss auch dazu sagen, finde ich, wenn jemand tatsächlich böswillig irgendwo ran will an das System,
dann schafft das eh, also gerade von den Internen, an irgendeinem Punkt, da stimme ich euch zu, Holger und Michael,
muss man halt auch seinen Kollegen irgendwie vertrauen, das hilft ja alles nichts.
Ich muss ja auch, also ganz stumpf gesagt, ich muss auch dem Busfahrer vertrauen,
dass er neben der Bushaltestelle anhält und mich nicht einfach unterfliegt.
Genau.
Das gehört einfach mit dazu, ich kann es auch nicht unterbinden.
Na gut, da kommen wir auf den Punkt Menschenbild.
Also ich stimme euch ja zu, aber habe jetzt vielleicht so ein, zwei Argumente mehr nochmal bekommen.
Es geht einfach auch um das Menschenbild und um die praktischen Anforderungen.
Das heißt also, ich kann diese Sicherheitsstufen, die so jemand dann gerne hätte,
die kann ich heute zeitlich gar nicht mehr umsetzen.
Also dann bin ich irgendwann raus aus der Nummer, weil ich eben nicht schnell genug liefere.
Okay, Haken.
Ich muss jetzt aber auch.
Ich muss vielleicht das nochmal relativieren an der ganzen Geschichte und damit zugeben,
man weiß es, ich weiß es auch nicht ganz genau, vielleicht auch aus dem Grund,
weil ich noch nie ein böswilliges Vorhaben hatte.
Sehr gut.
Letztendlich haben wir auch ein Team, das ist das CPR-Team,
die sich eben um diese ganze Robustheit des Gesamtsystems und der Infrastruktur kümmern.
Und die haben auch irgendwo bei den Deployments und bei den, wenn bevor etwas produktiv geht,
die Aufsicht oder sage ich jetzt,
mal die Hoheit und überwachen das so ein bisschen, dass alles korrekt verläuft.
Und dadurch wird auch ein Stück weit sichergestellt, dass jetzt nicht einfach mal irgendein Entwickler,
weil er nicht richtig zugehört hat,
eine noch nicht freigegebene Version auf Produktion bringt.
Weil das muss erstmal alles, wir haben da immer hier unser Daily,
das kommt dann vom Release Train Engineer, glaube ich, genau,
kommt das runtergeschickt, wo dann eine Freigabe für eine Version passiert.
Und dann erst kann das auf Produktion kommen.
Diese ganzen Argumente zeigen dann auch so ein bisschen darauf,
wie robust ist eigentlich eure Infrastruktur.
Wie riskant wäre es denn, jemanden in die Produktion zu lassen,
jetzt einfach nur im Sinne der Stabilität.
Wenn ihr, ich sage jetzt mal, ausreichend gute Rollback-Mechanismen habt,
dann soll er halt Kleinholz machen, dann rollen wir es halt wieder zurück.
Und das ist also auf der technischen Ebene dann,
auf der technischen Ebene das, und auf der menschlichen Ebene irgendwie,
muss man natürlich auch Leuten vertrauen.
Ich meine, es gibt ja auch Techniken, es gibt gewisse Organisationen,
die gesagt haben, wisst ihr was, wir lassen einfach niemanden auf die Produktionsumgebung.
Sondern das läuft alles nur automatisiert.
Du kannst ein neues, keine Ahnung, Ansible-Skript einspeisen,
und das wird dann halt ausgeführt, und dann gibt es einen Papertrail und so.
Aber gar niemand kommt auf die direkte Produktionsumgebung drauf.
Das wäre auch ein Weg, den man gehen kann, auch wenn er natürlich gewisse Grenzen hat.
Wir haben ja den Punkt gehabt oben, der heißt Können, Dürfen, Wollen.
Das ist ja so das Dreieck, wo ich denke, dass der DevOps-Mitarbeiter
in alle drei Bereiche vollen Zugriff haben muss, damit er intrinsisch motiviert ist.
Und da ist das positive Menschenbild dahinter.
Man kann nicht davon alles so bauen, dass nur Einzelne durchkommen,
und dass alles sicher ist. Das wollen wir auch nie.
Also so wird es auch nicht wahrgenommen, von daher.
Nee, aber diese ganze Diskussion oder das Gespräch gerade
macht mich fast schon ein bisschen neugierig darauf,
ob ich das überhaupt könnte, jetzt, heute, auf Produktion der Version hochzudeployen,
die ich nicht dahin deployen soll.
Ich kann mir nicht vorstellen, dass man dann doch so viel Macht hätte.
Du, es, du, es, du, es.
Du brauchst den Mithilfer, der hat ja den Pull-Request, oder irgendwie.
Checks and Balance gibt es ja. Einen zweiten brauchst du schon, würde ich sagen.
Ja, genau, eben. Es muss ja dann auch nochmal eine Bestätigung kommen, letztendlich.
Und es bleibt ja unter uns, also wenn ich da was probiere, dann…
Ja, ja.
Michael, mach mal. Wir schneiden das raus, aber mach mal.
Das würde ich gerne mal erleben.
Dann stehst du wahrscheinlich morgen dann in der Schweiz in den Zeitungen.
Das habe ich mir so erzählen lassen, dass das Ziel ist, was ihr nicht habt,
nämlich nicht in die Schweizer Zeitungen zu kommen.
Ja, das war eine Anekdote, die haben wir sogar zusammen mitbekommen am Anfang,
weil wir halt in Finance landen und da viel Druck drauf ist,
dass die schwarze Null steht, dass, wenn man einen Fehler macht,
hatte einer gesagt, aber sofort das auch zurückgenommen,
dann stehst du in der Zeitung. Und das war so, wo ich gedacht habe, das ist Kramer.
Oh, das ist ungünstig.
Das baut so eine gewisse Art von Druck auf, den wir nicht haben wollen.
Da ist mir lieber, wir machen einen Fehler, aber einmal und lernen dann draus
und nicht ein zweites Mal. Und das Credo ist auch das, was jetzt aktuell gültig ist.
Das war einfach nur so ein Hallo wach, da, wo ihr dran rumarbeitet.
Das kann auch mal schiefgehen und in der Zeitung landen, so Bild-Zeitung oder so was.
Ja, okay.
Ich glaube, damit wollte uns vor allem signalisieren,
dass da auch die Presse in der Schweiz durchaus sehr feinfühlig ist,
wenn da etwas passiert mit der Schweizer Bundesbahn,
dass da auch sehr fix mal ein Artikel draußen ist.
Die haben auch Haltepunkte bei deutlich weniger Mitarbeitern.
Die haben auch eine andere Pünktlichkeit.
Die zahlen auch das Doppelte von wir für ihre Mobilität
und erwarten dann natürlich auch etwas dafür.
Und das ist ja so wichtig, warum wir im Finance das Geld einnehmen müssen,
weil es ist ja durch Schweizer bezahlt, der öffentliche Transport.
Und wir sorgen dafür, dass die, ich weiß es nicht,
35, 36, 40 Prozent wieder zurückkommen durch Ticketeinnahmen.
Das ist ja…
Ich würde ganz gerne noch mal auf etwas anderes eingehen.
Nämlich, wir haben ja jetzt eine Menge Mutmaßungen angestellt
über die böswilligen Angreifer von innen.
Aber viel harmloser, was passiert denn jetzt,
wenn einer etwas verkehrt macht, trotz aller besten Absichten?
Mit anderen Worten, wie steht es denn eigentlich um Fehlerkultur?
Wie wird das denn bei euch gelebt und gehandhabt und philosophiert?
Letztendlich, wenn Fehler geschehen,
dann sind die meistens nicht alleine passiert.
Weil es gibt, sobald man etwas merchen möchte
oder auf Develop bringen möchte, muss es immer jemanden geben,
der auch diesen Pull-Request freigegeben hat,
also eine Review gemacht hat.
Also sind schon mal auf jeden Fall zwei im Boot.
Aber letztendlich, was ich mitbekommen habe,
wenn mal wirklich große Fehler in der Endkonsequenz passieren,
dieses Fingerpointing,
habe ich bisher noch nicht wahrgenommen in dem Umfeld.
Und ich habe da sogar auch mal einen Spruch gehört,
wenn man sich über unangenehme Themen oder auch Fehler unterhält,
dann war da immer so dieser geflügelte Satz,
hart am Thema, weich an der Person.
Harte an der Sache, weich zur Person.
Richtig, genau.
Und das ist mir im Kopf hängen geblieben,
weil es eigentlich genau das zusammenfasst,
wie meiner Meinung nach eine Fehlerkultur sein sollte.
Dass man, klar,
kommuniziert, was ist schlecht gelaufen,
wie können wir es besser machen,
aber jetzt nicht sagt, Mitarbeiter A, B, C,
was hast du da für einen Mist gebaut?
Genau.
Also ich glaube, dahinter steckt,
keiner will ja der Idiot sein und macht bewusst was falsch.
Davon gehen wir aus, gehört zum positiven Menschenbild.
Und ich kann das auch nur so bestätigen,
ich habe zwei Fälle erlebt, wo schwere Fehler passiert sind
und wo ich im Meeting dann mit drin war
und wo ich sehen kann man es ja nicht mehr,
wir sind ja virtuell unterwegs,
man kann das Video in die Stimme anhören,
wo ich schon gemerkt habe,
da knirscht es auf der gegenüberliegenden Seite,
es wäre schon echt gut gewesen,
wenn der Fehler nie passiert wäre,
aber die Person hat sich so zusammengenommen und gesagt,
es kann passieren, es gibt die Postmortem,
wir lernen draus und du machst den Fehler nicht nochmal.
So in der Art wie einmal ist keinmal,
zweimal ist einmal zu viel und das schätze ich aber.
Bei allem Wohlfühloase,
wie das jetzt auch manchmal so ein bisschen im Podcast rübergekommen ist,
natürlich, wenn da Fehler sind,
wir sind immer noch da,
in einem Umfeld, wo es sehr sensibel sein kann,
wenn große Fehler passieren,
dann kann die Stimmung auch schon mal kippen.
Ich bin aber der Meinung,
dann zeigt sich erstmal die Professionalität auch des Kunden daran,
wie man dann eben mit diesem Fehler oder mit der Person,
die den Fehler gemacht hat, umgeht.
Und da muss ich sagen,
habe ich das bisher auch immer als sehr produktiv wahrgenommen.
Sehr schön.
Ich habe in eurer Liste einen Satz gefunden, eine Aussage gefunden,
wo ich gedacht hätte, die kommt niemals von einem ITler,
die kommt aus der Personalentwicklung,
die kommt von diesen Chaka-Chaka-Menschen,
nämlich Feedback ist das Frühstück der Champion.
Könnt ihr das mal erläutern?
Erstmal finde ich Chaka-Chaka-Menschen einen sehr, sehr schönen Ausdruck.
Ich habe ja die Rolle als Scrum Master
und ich bin ja nicht in der Personalführung
und ich muss mir überlegen, wie ich Menschen dazu bewege,
Veränderungen wahrzunehmen,
und auch anzugehen.
Und mein Hauptmittel dazu ist, ihnen Feedback zu geben.
Also ich muss genau beobachten
und ich muss dann diese Beobachtung dem Kollegen mitteilen,
sagen, was mir dabei im Kopf vorgeht,
wie ich mich dabei fühle und wo ich mir Dinge besser vorstelle.
Und das machen wir sehr oft.
Das machen wir einzeln.
Ich als Scrum Master bin natürlich ein großer Feedbackgeber,
auch in Terminen wie dem Daily, wo man einfach sagt,
ja, das war gut, dass du Danke gesagt hast,
dass du eine Hilfestellung gekriegt hast,
dass die Idee dazu gekommen ist.
Aber wir machen es auch in so einmal im Sprint als Team,
wo man sich virtuell in einem Tool trifft und Kreise bilden kann
und sich da Feedback gibt.
Und ich muss auch dazu sagen,
dass das auch ein zentrales Thema unter allen Scrum Master waren.
Die wurden alle geschult darin,
wie man ordentlich Feedback gibt für ein Team.
Und das findet statt und ist für mich
einer der wichtigsten Mittel herauszufinden,
wo man steht, wo man schon gut ist,
wo man noch besser werden kann.
Und wenn man das von einem Kollegen hört
und das auch noch gut rüberkommt,
dann motiviert das einfach unglaublich.
Genau, also das kann ich unterstreichen.
Also Feedback zu bekommen und zu geben ist meiner Meinung nach
auch extrem wichtig für die auch persönliche Weiterentwicklung
so in dem Projektumfeld, sowohl als Entwickler
als auch so in diesen Soft Skills.
Wie gebe ich mich, wie wirke ich auf andere?
Aber also mein persönlich großes Anliegen
als Arber, als Entwickler oder als IT-Lehrer ist…
Die Lüge kommt nach dem Arber.
Genau, als IT-Lehrer ist es,
man kann, es ist auch zu viel des Guten manchmal.
Also ständig immer ein Feedback zu geben.
Ich sehe es auch im Cluster.
Wahrscheinlich unser Scrum Master wurde genauso geschult wie du.
Und er versucht jetzt auch im Cluster
eine Feedback-Kultur zu etablieren,
was auch durchaus wichtig ist, immer daran erinnert zu werden.
Man hat die Möglichkeit, sowohl Feedback zu bekommen,
als auch selber zu geben.
Aber solche festen Runden zu bestimmten Zeitpunkten
finde ich teilweise kontraproduktiv,
weil dann sagt man, wenn es zu oft ist, auch immer dasselbe
oder weiß nicht, dann findet man auch irgendwann keine Worte mehr dafür.
Und dann sitzt man sich gegenüber und sagt so,
jo, ich mag heute dein Hemd.
Gestern sah es schlechter aus oder keine Ahnung,
so auf die Spitze getrieben.
Man muss das auch üben.
Also ich bin ja ein großer Vogelfreund.
Ich fütter seit zwei, drei Jahren
und beobachte alle unterschiedlichen in meinem Garten
und ich bin da sehr zufrieden.
Ich mag beobachten.
Aber wenn man Feedback geben will, muss man davor auch beobachten.
Bei mir ist immer ein Zettel bereit.
Da schreibe ich das dann auf und ich kann das teilen mit dir.
Wenn man natürlich verordnet in den Termin kommt
und dann einfach willkürlich jemandem Feedback geben,
dann kann das auch nie inhaltsgenug sein
oder das gegenteilige Ergebnis erzielen.
Das stimmt.
Feedback geben muss man können
und auch Feedback nehmen muss man sozusagen können.
Das muss ja auch von der Kultur her so sein,
dass wir das auch annehmen können,
muss und nicht muss,
sondern dass man es annehmen kann
und dass das nicht so aufgesetzt wirkt.
Genau, auf jeden Fall.
Also ich habe heute schon zwei Kollegen Feedback gegeben
und das war einmal jemand,
der heute früh eine Präsentation gehalten hat,
die gut vorbereitet war, auf den Punkt.
Ist auch ein neuer Mitarbeiter, der sich das zugetraut hat.
Das fand ich sehr gut.
Und einmal war es ein Feedback zu einem Thema in einem Daily,
wo das Eingeständnis ist,
und das war, dass er gestern nie so gut erreichbar war
und nie so viel geschafft hat
und er sich getraut hat, das zu sagen
und im Prinzip auch weggenannt hat,
wie er da heute besser wird in dieser Rolle.
Gut, aber das muss man jetzt vielleicht dann auch
ein bisschen differenzieren,
was Holger gerade auch mit angesprochen hat.
Feedback zu Dingen oder zu Events,
die man gerade ausgeführt hat,
also sei es eine Präsentation oder mal etwas zu moderieren,
ne?
Ein Abgleich.
Dieses Feedback zu geben,
finde ich in der Regelmäßigkeit direkt danach
auf jeden Fall sehr, sehr wichtig,
dass man das auch vielleicht jedes Mal,
jedes zweite Mal bekommt,
muss man natürlich auch teilweise einfordern,
bin ich der Meinung.
Andersrum aber diese allgemeinen Feedbacks,
wo man sagt, okay, ich habe jetzt hier eine Feedback-Runde,
diese sollte man nicht zu oft machen,
denn man muss auch demjenigen die Zeit geben,
der das Feedback bekommen hat,
sich dementsprechend weiterzuentwickeln.
Wenn ich jetzt überlege,
ich habe jetzt hier vielleicht im Monat
eine Feedback-Runde mit jedem Kollegen,
wir haben jetzt sieben Kollegen im Team,
das sind sechs Feedback-Runden pro Monat,
dann habe ich in der Woche mehr als eine.
So, dann finde ich das schon sehr häufig.
Ja.
Sehr schön.
Ja, Mensch, also,
wahrscheinlich könnten wir noch eine dritte Folge aufnehmen
mit den Themen, die wir haben.
Spielend.
Mit dem, was ihr so zu berichten habt.
Ich spucke alle, jetzt müssen wir aufhören.
Jetzt müssen wir aufhören, ne?
Ja.
Also, nee, wir müssen nichts, aber wir dürfen.
Also, Spaß beiseite mit der Wortwahl.
Gibt es irgendetwas, was ihr noch zum Abschluss sagen wollen würdet,
was ihr noch nicht gesagt habt?
Denn dann würden wir so ein bisschen in den Abgesang einsteigen.
Ja, ich bedanke mich für die Gelegenheit, hier teilzunehmen
und habe eigentlich jetzt gar nicht so groß im Kopf,
wenn noch Fragen sind, können wir die beantworten,
aber ich finde, das ist eine runde Sache
und es hat mir Spaß gemacht.
Also, da kann ich mit Leichtigkeit einsteigen.
Es hat mir auch super viel Spaß gemacht,
hier auch ein bisschen mal drüber schwafeln zu können,
was wir hier Tag für Tag treiben.
Ja, genau.
Sehr schön, das freut mich.
Und schwafeln, das klingt so ein bisschen wie,
na ja, wir reden mal so ein bisschen.
Ich fand, da war sehr viel Inhalt dabei
und sehr viel, weiß ich, Zusammenhang.
Also, es hat für mich ein sehr, sehr rundes Bild gegeben,
ein sehr, sehr tolles Bild.
Und ich weiß eins, dass diese beiden Folgen
werde ich in meinen Trainings immer empfehlen.
Vielleicht können wir die sozusagen
als Voraussetzung mal einbauen.
Das heißt, jeder, der ein Training bei uns besuchen will,
der muss diese beiden Folgen erstmal hören,
damit er weiß, auf was er sich einlässt,
wenn er Def Ops macht.
Das Schwafeln können wir gerne rausschneiden.
Sehr schön. Dann sage ich vielen Dank, Luca.
Ich würde sagen, dir überlasse ich jetzt mal gerne das Schlusswort.
Ja, da gibt es ja fast nichts mehr hinzuzufügen.
Ich möchte mich auch nur nochmal bei euch bedanken dafür,
dass ihr euch die Zeit genommen habt heute
und dass ihr uns so sehr habt teilhaben lassen
an der Art und Weise, wie ihr arbeitet.
Ich fand das unglaublich spannend.
Insofern vielen Dank dafür.
Ja, wir bedanken uns.
Genau. In diesem Sinne wünsche ich euch einen ganz tollen Tag
und vielen, vielen Dank für diese zwei tollen Podcast-Folgen.
Bis zum nächsten Mal.

Folge 56: DevOps bei T-Systems MMS 1/2

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Heute haben wir Michael Glathe und Holger Helas von T-Systems MMS zu Gast.

Die beiden berichten von ihrer täglichen Arbeit und helfen uns, DevOps Theorie und gelebte Praxis zu verbinden.

In der Tat war dieses Gespräch so angenehm und spannend, daß es uns nicht gelang uns kurz zu fassen, so daß wir es in zwei Folgen aufgespalten haben.

Heute hört Ihr einen etwas allgemeineren Teil, die kommende Folge wird demgegenüber etwas praxisorientierter sein.

In dieser Folge des Podcasts „DevOps – auf die Ohren und ins Hirn“ tauschen sich die Gastgeber Dirk Söllner, Falko Werner und Luca Ingiarni mit ihren Gästen Holger Helas und Michael Glathe von T-Systems MMS aus Dresden über verschiedene Aspekte von DevOps aus. Die Diskussion umfasst praktische Erfahrungen und Herausforderungen im Bereich DevOps, insbesondere im Kontext der Arbeit bei T-Systems MMS. Die Teilnehmer erörtern verschiedene Themen, von der Bedeutung des Übens und des Lernens im Arbeitsalltag bis hin zu spezifischen Projekterfahrungen und den Herausforderungen im Umgang mit DevOps in einem großen, komplexen Projektumfeld.

Inhalt

  • Definition und praktische Bedeutung von DevOps
  • DevOps im Kontext von T-Systems MMS
  • Üben und Lernen im Arbeitsalltag von DevOps-Profis
  • Spezifische Herausforderungen und Lösungsansätze in großen DevOps-Projekten
  • Erfahrungen und Erkenntnisse aus der Arbeit von Holger Helas und Michael Glate
  • Diskussion über die kulturellen, organisatorischen und technischen Aspekte von DevOps

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Dierk Söllner, Falko Werner und Luca Ingianni
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts
DevOps – auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingiarni, Dirk Söllner und Falko Werner.
Wir sind Trainer für DevOps und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns drei kulturelle, organisatorische und technische Aspekte.
Diese diskutieren wir mit Experten aus der Praxis oder in einer gemeinsamen Folge zwischen uns dreien.
Heute haben wir wieder mal Gäste aus der Praxis, nämlich sogar zwei.
Holger Helas und Michael Glate von der T-Systems MMS aus Dresden.
Ich habe die beiden in einem Training kennengelernt, wo sie mich unterstützt haben
für die T-Systems MMS und habe gefragt, ob sie einfach bei uns hier mal ein bisschen was von dem berichten wollen,
was sie auch in der Praxis, was sie in dem Training berichtet haben.
Wir haben ein ganz tolles DevOps-Projekt, wobei ob es ein Projekt ist, das klären wir gleich noch,
aber wir haben ein ganz tolles Thema, wir haben einen ganz tollen Kunden
und insofern freuen wir uns auf ein oder zwei Folgen,
denn die Themen, die sie uns gegeben haben zur Vorbereitung, die sind so lang und so interessant,
dass wir gesagt haben, da können wir eventuell sogar zwei Folgen draus machen.
Also insofern freuen wir uns auf Holger und Michael und ich würde sagen,
Holger, stell dich mal doch vielleicht mal ganz kurz vor.
Ja, herzlich willkommen. Holger, mein Name, 40 Jahre alt, frisch aus der Quarantäne mit drei Kindern,
von daher weiß ich noch gar nicht so richtig, heute die ersten Arbeitstage hinter mir
und in meiner Rolle als Scrum Master für drei Teams mit so 20 Mann tätig.
Und wir waren beim Dirk.
Ich bin der Schulung und das hat uns, da haben wir schon einen guten Austausch gehabt
und das führen wir heute weiter.
Genau, dann würde ich mich mal kurz vorstellen.
Ich bin der Michael, 28 Jahre jung und bin in dem Projekt, was Dirk kurz angeteasert hat,
als Entwickler tätig und werde aus der Sicht meiner Rolle berichten können,
was da in der Praxis so vor sich geht.
Super.
Endlich ja mal ein DevOps-Engineer hier an Bord, hoffe ich doch mal,
weil sonst haben wir immer nur schlaue Leute, so wie Luca und Falco und mich,
aber hier haben wir jemanden, der von der Front berichten kann.
Sehr schön. Interessant fand ich auch, Holger, du hast dein Alter genannt.
Michael hat sein Alter als jung bezeichnet, aber ich kann dich beruhigen,
mindestens ich bin auch noch ein bisschen älter.
Also insofern kriegen wir das hin. Heute haben wir eine gesunde Mischung.
Sehr schön.
Die erste Frage, die wir in dem Podcast immer haben,
ist das Thema, wie definiert ihr oder wie definierst du DevOps?
Wie würdest du DevOps beschreiben?
Und ich würde sagen, dann lass uns mal bei Michael anfangen.
Michael, was ist für dich DevOps?
Genau, also die Frage ist auf jeden Fall schon mal richtig.
Was ist für mich DevOps?
Ich denke, da gehen die Meinungen oder die Ansichten auch sehr stark auseinander.
Für mich speziell als Entwickler bedeutet dieses DevOps eher,
sage ich mal, das Aufgabenumfeld oder die Zuständigkeit.
Also wofür oder was wird von mir erwartet?
In einem Projektumfeld als Entwickler, in dem Fall eben nicht nur die reine Entwicklung,
sondern halt auch eben bestimmte Aktivitäten im Betrieb, auf der Produktion.
Also quasi nicht mehr nur dieses klassische Entwickler-Dasein,
sondern zusätzliche Aufgaben, die durch das DevOps mit dazukommen.
Aber ich denke, da kann man, wenn man jetzt Holger fragt,
dann auch noch mal eine andere Sicht.
Dann übernehme ich gleich.
Also ich würde die Frage beantworten,
dass ich es nicht weiß.
Das wurde schon in so viele Richtungen hin diskutiert.
Für mich macht es aus, dass ich mit einer größeren Vielzahl an Menschen zu tun habe.
Es gibt einfach Testerinnen, Entwickler, Kollegen,
die sich tief unten in Atmosphären auskennen, die ich noch nie gesehen habe.
Und das macht mir Spaß, das ist das eine.
Und das andere ist, dass die Kollegen das selber in der Hand haben,
von der Idee bis zur Umsetzung.
Und für mich sind die dadurch motivierter und ich arbeite einfach gern mit
motivierten Personen, weil da kommt Spaß rüber,
da kommen gute Ergebnisse raus und deswegen DevOps.
Super. Okay, dann haben wir das ja schon geklärt.
Und ich finde es immer wieder interessant,
wie viele unterschiedliche Beschreibungen wir dafür bekommen.
Und ich glaube, wenn jemand eine DevOps-Schulung jetzt konzipieren würde,
dann könnte er wahrscheinlich den Podcast immer so die ersten fünf Minuten anhören.
Dann hätte er schon 20, 30 Folien voll mit Themen,
die man da behandeln müsste.
Das ist so, so vielfältig.
Also vielen Dank auch für eure beiden Beschreibungen oder Definitionen.
Sehr schön. Gut, wir haben es gesagt, dass wir von euch eine Liste bekommen haben
von Themen, über die ihr sprechen könntet oder auch wolltet.
Denn ihr seid ja nicht nur in dem Podcast hier unterwegs als DevOps-Experten,
sondern auch bei euch bei der T-Systems MMS.
Und da sprecht ihr auch über Themen.
Und insofern haben wir gesagt, Mensch, das sind so viele gute Themen.
Wir haben sie ein bisschen
für uns sortiert, aber ich finde es einfach gut,
was ihr da so geliefert oder bereitgestellt habt.
Und ich würde einfach mal so mit dem ersten Punkt anfangen,
den wir so ein bisschen bei Organisation und Werte einsortiert haben.
Und da habt ihr geschrieben Üben, üben, üben oder geht uns die spielerische Art verloren?
Ohne Spieltrieb keine menschliche Entwicklung, nur noch triste Perfektion.
Und das finde ich so interessant, weil das eben was Übergreifendes ist.
Holger, du hast es eben gesagt, du arbeitest gern mit Menschen zusammen,
wo es Spaß macht.
Das ist ja letzten Endes was, denke ich, nicht nur beim Lernen motiviert,
auch beim Arbeiten motiviert.
Also insofern siehst du gegebenenfalls die Gefahr,
dass die spielerische Art verloren geht durch das ganze Thema DevOps?
Ja, der Fokus liegt bei mir bei dem Ausdruck auf dem Üben.
Ich habe so das Gefühl, wenn man es zum Beispiel mit dem Fußball vergleicht,
die tun 95 Prozent trainieren und fünf Prozent haben sie Spiel.
Und in der Softwareentwicklung ist es andersrum.
Und das Üben, das macht aber Spaß und da entstehen andere Dinge.
Und wir versuchen immer, die Formate zu finden, wo man halt auch ins Üben reinkommt,
wo Ideen gechallenged werden.
Und deswegen war mir das so wichtig.
Also wie kommt man hin, dass man offen ist, dass man lernt, dass man neue Dinge tut?
Und ich musste bloß gerade meinen Rechner entsperren.
Das kommt jetzt in den Podcast mit drauf.
Aber es passt, deswegen bin ich jetzt ein bisschen aus der Idee raus.
Und wir versuchen halt Erfahrungen damit zusammen.
Zum Beispiel haben wir gerade einen Disaster Recovery Test.
Wir haben eine Zahlmittelkette mit verschiedenen Dienstleistern
und da gab es mehrere Problemfälle.
Und wir tun immer wieder neue Probleme feststellen und nie üben,
sondern immer nur direkt knallhart Einsatz machen und entstören.
Und wir versuchen, die jetzt zusammenzukriegen
und halt so produktionsnah wie möglich wirklich mal ein Inzident da platzen zu lassen
und dann zu schauen,
wie die einzelnen Menschen und die Menschen müssen ja noch zusammenarbeiten,
miteinander handeln und wollen dann rauskriegen,
was gut lief und was nicht gut lief.
Und von den Formaten gibt es ein paar.
Wir haben noch ein anderes Format, wo auch viel geübt wird.
Alle, die bei uns eine Rufbereitschaft machen,
müssen so eine Rufbereitschaftsschulung.
Und da kriegt man dann einen Anruf und hat einen Echtfall.
Und auch da wird geübt.
Und ich habe das Gefühl, dass die Menschen daran Spaß haben,
dass die da eine Rückmeldung kriegen, wo sie gut sind, wo Themen noch flach liegen,
wo sie sich weiterentwickeln können.
Und dann kommt halt diese spielerische Art rein.
Und die ist auch ein bisschen das Salz in der Suppe.
Ja, ich würde mal kurz auch was zu sagen.
Ich finde es gut, dass das Holger so anspricht im Sinne von,
dass der Entwickler auch manchmal einfach immer nur am Reagieren ist,
also quasi löscht, wo es brennt und selber dann gar nicht in diese Möglichkeit gerät,
dann neue Dinge auszuprobieren oder halt eben sich auf den Ernstfall vorzubereiten.
Klar hat man jetzt in dem Projekt
hier bei der, wo wir beide mit involviert sind, was Holger angesprochen hat,
einige Formate wie diese Schulung von dem Picket-Dienst, also der Rufbereitschaft.
Allerdings kann ich das nicht so ganz unterstreichen,
denn wir haben ja auch in dem Sprint-Zyklus immer noch als Entwickler am Ende so eine Phase,
die sehr viel Spaß macht, die so zwei bis drei Wochen lang ist,
wo wir eben Neues ausprobieren können, wo wir Innovationen mit vorantreiben können.
Wir nennen das IP-Sprint, wo wir dann Ideen oder Probleme mal aufschreiben,
besprechen im Team und dann vielleicht mal challengen und daran ein bisschen was arbeiten.
Aber vielleicht muss man dazu sagen, ich bin auch in einem anderen Team jetzt als der Holger.
Klar, wenn man jetzt in Zahlung da ganz, ganz viele Brände hat
und die dann am Ende nur noch am Löschen ist, das macht keinen Spaß.
Das sehe ich ein, genau.
Mhm.
Vielleicht sollte man wissen, was über euch ist.
Ich wollte ja über euer Projekt oder über euer Programm erzählen,
weil ich habe ja gesagt, ein interessantes Programm oder Projekt, wie gesagt,
das müssen wir noch mal klären, ob das für euch ein Projekt ist, wie ihr das seht.
Vielleicht könnt ihr da mal ein bisschen was zu berichten,
weil das sicherlich auch sehr interessant ist für die Hörer,
dass wir eben nicht über ein Produkt sprechen, was irgendwo so eine App ist oder so,
sondern das ist ja ziemlich sichtbar, das, was ihr da baut und betreibt.
Wir sind bei der SBB in der Schweiz tätig,
Mobilitätsdienstleiter.
Da sind recht viele Unternehmungen unter dem roten Dach vereint
und wir speziell sind da in Zahlung drin.
Es gibt ganz viele Transaktionen, ob sie nur über das Mobile naht hier in der Schweiz
oder am Schalter gemacht werden.
Es gibt unglaublich viele Zahlmittel und in der Kette hängen auch ganz viele andere Dienstleister mit drin.
Man ist nie allein.
Also DevOps umfasst jetzt ja nicht bloß das, was wir direkt beim Dienstleister tun,
sondern oft sind auch externe Partner mit dabei.
Und, äh,
da sind halt viele Transaktionen am Tag tätig, über 200.000.
Und die müssen halt durchprozessiert werden und immer am Laufen gehalten werden.
Und der DevOps-Anteil ist dann da halt dafür zu sorgen,
dass auf der einen Seite die Produktion immer läuft.
Das ist auch die erste Priorität.
Auf der anderen Seite, dass die Wünsche der Kunden und der Vertreter im Unternehmen der SBB,
die das übersetzen in Form von Epic Features User Stories,
dann auch stabil eine Weiterentwicklung erfährt.
Und auf den zwei Beinen muss man immer hin und her springen.
Man darf aber keins von den beiden irgendwie mal eine längere Zeit eingeknickt lassen,
weil dann wird’s schwierig.
Deswegen ist das so anspruchsvoll, nenn ich’s mal.
Aber okay.
Okay.
Genau.
Das heißt, wenn ein Schaffner in einer Schweizer Bahn ein Ticket kontrolliert,
dann läuft das sozusagen über euer Produkt oder über eure Produkte?
Das muss man ein bisschen differenzieren.
Also letztendlich arbeiten wir an,
wenn man das als Produkt bezeichnen möchte,
an mehreren.
Also es gibt sowohl den Webshop,
also was jeder Kunde in der Schweiz oder wir hier von Deutschland aus einfach auf unserem Handy aufrufen können.
Dann gibt es aber wiederum das Kassensystem, also dieses CASA.
Man muss sich das vorstellen, jetzt in Deutschland,
man geht in ein Infozentrum und dann sitzt da ein Angestellter vor einem Rechner
und möchte dir ein Ticket ausdrucken oder dir eine Erstattung machen, was auch immer.
Und dann arbeitet er mit einer Seite, Produkt nenn ich’s jetzt mal,
das heißt bei uns CASA.
Dafür sind wir quasi auch noch zuständig letztendlich.
Und das sind so zwei Dinge, für die wir uns offensichtlich kümmern,
die man selber sehen kann.
Der Holger mit seinem Team ist da, wie er gerade beschrieben hat, in den Finanzen tätig.
Für mich in meinem Team als Entwickler geht es dann eher darum, was passiert nach der Fahrt.
Also in der Schweiz heißt es Service à prévent,
wenn ich das hoffentlich richtig ausgesprochen habe.
Ein französischer Begriff, war ich nie gut.
Jedenfalls heißt es, was passiert, wenn man die Reise getätigt hat oder sie eben nicht antreten konnte.
Also man hat einen Erstattungswunsch, man möchte etwas teilerstatten lassen.
Und da muss man sagen, sind die Schweizer schon sehr sehr kulant, was da zu erstatten geht.
Das ist schon ganz schön Wahnsinn.
Und da muss man natürlich auch gucken, mit den ganzen Providern und Drittsystemen zusammenzuarbeiten.
Gerade im internationalen Personenverkehr
hat man ja da auch grenzübergreifende Themen, wo man dann eben gucken muss,
ja okay, wie kriegt man das Geld wieder anteilig, was passiert da drumherum.
Und dann setzt natürlich Holgers Team wieder an.
Wenn wir sagen, ja okay, wir erstatten euers, dann…
Ja, wir haben dann wieder Probleme, wenn in einem Land der Mehrwertsteuersatz gehoben oder gesunken wurde.
Das war ja letztes Jahr gang und gäbe während der Pandemie.
Und dann spielen wir wieder zusammen in größeren Unternehmen.
Aber das ist dann nicht mehr mein Problem.
Ich habe jetzt gerade auch noch mal kurz eine Nachfrage, wo wir vorhin diese Überschrift üben, üben, üben hatten.
Ich habe mal gehört, dass DevOps irgendwie um Automation ginge. Sollte ich denn dann überhaupt noch üben müssen?
Automation in welchem Bereich? Also Testautomatisierung würde mir da jetzt als erstes einfallen.
Naja, also meine Antwort darauf wäre, dieses Mobilitätsunternehmen mit seinen 300 verschiedenen Unternehmungen,
die da sind und der Vielzahl an Tickets, dass da alles automatisiert ist.
Das ist eine Ausbaustufe, die können wir uns vorstellen.
Aber ob die irgendwann erreicht wird, das ist schwierig.
Nach wie vor sind Menschen notwendig, um halt Brüche in Unternehmen oder in Tools oder in Fehlermeldeprozessen zu machen.
Und das muss nach wie vor noch geübt werden.
Es ist ja nie dieser ominöse Button, der in vielen Köpfen hängt, auf den man draufdrückt und dann wird da paketiert und ausgeliefert.
Und es ist sofort live. Also es gibt wirklich mehr als genug Sachen, die man übt.
Und mein Gefühl ist halt, wenn man die Möglichkeit gibt, zu üben, dass die Mitarbeiterinnen sicherer werden,
Vertrauen haben und damit auch besser handeln in ihrer täglichen Arbeit. Und deswegen mein Plädoyer fürs Üben.
Genau. Aber mich würde der Punkt mit dem Automatisieren gerade noch mal interessieren, Luca, an was du da gedacht hast.
Ja, ich meine, ich gebe es zu. Die Frage war natürlich auch ein bisschen hinterhältig gestellt.
Aber ich war so erinnert an einen anderen Podcast, den wir hier gemacht haben, wo wir einen Site Reliability Engineer von Google zu Gast hatten.
Und der hat auch etwas gesagt, was ich eben so bemerkenswert fand. Er hat gesagt, die befinden sich immer in diesem Spannungsfeld.
Eigentlich wollen sie alles wegautomatisieren, was sie irgend können.
Macht ja auch Sinn, wenn du irgendwie fußballfeldweise Server betreiben musst.
Aber andererseits ist es ihnen ganz wichtig, dass jeder SRE sich …
sicher fühlt, selbstbewusst fühlt, auch manuell sogar auf Produktionsumgebungen rumzufuschen, weil früher oder später wird er es eh tun müssen.
Ja, das ist aber auch der Klassiker. Also wenn ein Neuer in das Projekt reinkommt und wir ihm am Anfang erzählen, du hast ab morgen Zugriff auf Prod und auch die Rechte
und du dürftest, wenn du wolltest, da was ändern und das würde direkt am Schalter oder im Mobile sein, dann hätte er einfach zu viel Angst.
Oder irgendwelche andere Sinne schlagen fehlen und er macht es einfach.
Aber ich sage halt, über das Üben kommt man ran. Also was ist die andere Methode zu lernen in so einem Projekt?
Und das ist ja riesig, dieses Umfeld. Das ist ja zugucken, aufschreiben, notieren, ausprobieren, aber irgendwann muss man ja auf Produktion kommen.
Genau. Und wenn da dann eben das Üben fehlt, dann ist es auch wichtig, in einem gesicherten Umfeld zu sein mit dem Team, wo man meistens dann auch erfahrene Mitglieder dabei hat,
wo, sage ich auch, Dokumentationen vielleicht schon existieren von Fehlern, die mal aufgetreten sind und die schon mal da waren.
Und das macht ja keinen Sinn, einen neuen Mitarbeiter in ein Haifischbecken zu werfen, dass er seine Erfahrungen erstmal selber sammeln muss,
sondern dass er dann immer Dokumentationen nochmal beiseite hat oder weiß, wo er es findet zumindest, um dann auf Dinge reagieren zu können, die er zum ersten Mal sieht.
Aber das Problem hatte man schon mal. Das hat mal jemand zu mir gesagt, ja, dann google doch einfach, ich wette mit dir, dass irgendjemand auf der Welt das Problem schon mal vor dir hatte.
So.
Und so läuft es mit einer guten Dokumentation eben von Fehlern, gerade wenn man sagt, man ist in der Rufbereitschaft und da passiert etwas, dann muss man immer diese Fallstricke oder dieses Sicherheitsnetz haben, gerade als neuer Entwickler.
Also das war ein tolles Stichwort, Entwickler in der Rufbereitschaft, das werden wir sicherlich nachher nochmal aufgreifen, aber jetzt habe ich noch eine andere Frage, wenn ich mich in die Lage eines Controllers versetze oder in das Business,
also bei der SBB wird es ja sicherlich auch Business geben, wird es Controller geben, die aufs Geld gucken und wenn ich jetzt mir so vorstelle, üben, üben, üben, ja, spielerische Art, wir wollen was durchprobieren, das kostet doch und das bringt für mich keinen Wert, oder?
Naja, der Controller, das ist ja so, der ist eher auf der automatisierten Seite, weil er viele Transaktionen oder viele Prüfungen machen muss zu einem regelmäßigen Zeitraum, der tut jedes Release, was gebaut wird, daraufhin prüfen,
dass am Ende die schwarze Null steht und bei 250.000 Transaktionen täglich über so eine drei Wochen Sprintzeit, wenn da Neues reinkommt, ist da einiges drin, der ist wahrscheinlich für Automation auch sehr willkommen und will gar nicht so links und rechts so viel Überraschung haben, aber wir haben den einen Aspekt angesprochen, der neue Mitarbeiter braucht es für die Sicherheit und für mich braucht es auch der bestehende Mitarbeiter, das ist das Salz in der Suppe, weil so eine Übung, wie wir es jetzt machen mit fünf Dienstleistern, wo man auf so ein Niveau kommt, dass man sich erbaut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut
hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich vertraut hat, dass man sich
Ich hätte jetzt sogar gedacht, dass du auch noch ein bisschen darauf abhebst,
dass der Vorteil bei diesem Üben ja auch derjenige ist,
dass man dann im Fall der Fälle besser ist.
Also dass es sich schlussendlich auch für einen Controller rechnet,
wenn man einfach sozusagen mal über die gesamte Zeit sich das anschaut.
Also nicht nur, naja, jetzt sitzen sie zwei Tage und üben irgendwas und bauen nichts.
Ich kriege keine Funktionalität, aber es lohnt sich eben für das Gesamtthema.
Ja, nicht für die Schule, für das Leben lernt man noch.
Naja, letztendlich ist, glaube ich, die Übung oder das Üben, worüber wir hier sprechen,
eher dieses, wie gehe ich an Probleme ran, an neuen Problemen?
Und wie finde ich schnell eine Lösung dazu, wenn ich das Problem vorher noch nicht gesehen habe?
Weil ich meine, wir sprechen jetzt als Entwickler da sein.
Zum Beispiel, ich habe das über meine Ausbildung, über mein Studium zum gewissen Teil gelernt,
dieses Handwerkszeug, wenn man das mal so runter bricht.
Wir sprechen hier jetzt nicht von Skifahren.
Ich spiele Geige und muss da jetzt durch Wiederholungen üben,
sondern eher, man hat das Handwerkszeug und durch Erfahrung im Projekt
und mit Arbeit mit dem Code und den Systemen und den Monitoring-Systemen
eignet man sich ja ein bestimmtes Verständnis von diesem System an.
Und wenn man dieses als Entwickler hat, klar, dann wird es immer wieder irgendwelche Probleme geben,
die man vorher noch nie hatte.
Aber, okay, da sind wir wieder bei dem Üben.
Dann muss man üben, wie gehe ich an dieses Problem?
Dann muss man eben ran mit dem Handwerkszeug, was ich habe.
Verständnis plus eben die Basics, die man als Entwickler gelernt haben muss.
Und demnach ist es dann einfach auch Erfahrung, die man sammelt.
Und dadurch kann man halt dieses fehlende Üben vielleicht durch die Erfahrung der Kollegen im Team,
die schon länger dabei sind, ein Stück auffangen.
Das dehnt sich jetzt, das geht aus Üben schon raus in Richtung Lernen
und vor allen Dingen auch, wie so ein Neuer reinkommt.
Ich finde das auch gut.
Wir hatten in unserer Demo zum Beispiel mal den Part,
dass dir immer ein Bug gezeigt wurde und erklärt wurde mit Fokus,
wie habe ich überhaupt rausgefunden, wo der Fehler ist.
Und ein Erfahrener wird da aus irgendwelchen Logs was rauslesen,
was du nie siehst oder in Dinge reingucken, Schubladen aufziehen, die du nie gesehen hast.
Und dann, ja, soll das halt aus dem einen Kopf in den anderen.
Und hoffentlich steht er dann vor der Situation mal und muss da die gute Lösung finden.
Aber weil wir ja den Rückschuss nochmal zur Automatisierung finden würden,
wir haben ja gerade beschrieben, das Problem ist immer ein Neues
und das ist halt schwer zu automatisieren.
Deswegen hat der Mensch seine Berechtigung.
Wenn ich immer nur Transaktionen nach Schema X mache,
dann kann ich da den Button hinsetzen und das schwarze Loch automatisiert alles
und dann wird es ausgeliefert.
Aber so weit sind wir noch nicht.
Ich habe auch mit dem Begriff der Automatisierung immer noch ein kleines Problem.
Klar kann man Tests automatisieren, bestimmte Testszenarien per Selenium,
was auch immer, die Oberfläche und Prozesse testen.
Von deinem Produkt oder von einem System.
Aber darüber hinaus, wenn ein neues Feature ansteht,
wenn neue Anforderungen kommen vom Business, vom PO oder was halt im Planning angesprochen wird,
dann ist es da schwierig, gerade in so einem komplexen Umfeld,
ohne jetzt dem Menschen auszukommen.
Auf jeden Fall.
Ja, das ist Balsam auf meine Seele.
Ich bin ja eigentlich ein altgedienter Software-Tester und ich sehe das ganz gleich wie du.
Ich meine, Testautomatisierung ist ganz toll und ich möchte sie auf gar keinen Fall missen.
Aber nichts geht über einen mit ausreichend Bosheit gesegneten Tester.
Der findet Sachen, die findet kein Automat jemals.
Zumal die Testautomatisierung, gerade was ich angesprochen habe mit Selenium,
jetzt nur Prozesse testen kann.
Der Code oder bestimmte Module müssen immer noch anders getestet werden mit Grenzkriterien,
wo auch meiner Meinung nach immer noch zu wenig Zeit reingesteckt wird jetzt als Entwickler.
Und da fasse ich mich auch um meine eigenen.
Also definitiv, dass man erst mal das Feature fertig kriegen möchte und sagt,
hier, ich habe das Ticket abgearbeitet.
Testen, ach so, ja, wird schon funktionieren.
So schlimm ist es nicht, jetzt mal so unter uns.
Aber es ist immer noch mal so eine Sache, die noch mal oben drauf kommt,
die man vielleicht jetzt auch nicht mitgeplant hat an Zeit.
Da muss man sich immer wieder daran erinnern,
oh, hier, wenn ich sage, okay, ich brauche so lange für ein Ticket,
aber plus, ich schreibe ordentliche Tests.
Das muss vielleicht noch in den Köpfen der Entwickler ein bisschen mehr ankommen.
Dass das sehr, sehr wichtig ist.
Aber da sind wir ja beim DevOps-Ansatz.
Also ich glaube, wenn was Neues entwickelt wird, dann gehört es dazu,
dass auf einer sehr produktionsnahen Umgebung der Screenshot angehangen wird,
ein Jira-Ticket, dass der Test erfolgreich durchgeführt wurde.
Und dann wird es abgenommen.
Und das muss halt auch der Entwickler machen, der es entwickelt hat.
Der muss auch den Test dafür neu schreiben.
Der muss auch sorgen, dass es getestet wird
und auf die richtige Produktionsstraße gebracht wird.
Und da sind wir ja dann wieder dabei.
Aber es sind noch Menschen, die da tätig sind.
Naja, tatsächlich geht täglich bei uns der erste Blick aufs Cleopatra-Board,
wo wir dann…
Du musst erklären, was es ist.
Ja, das Cleopatra-Board ist bei uns so ein Monitoring-Tool,
wo wir alle unsere Anwendungen sehen, welche Versionen laufen drauf,
wo wir dann uns auch bestimmte Test-Automatisierungen anzeigen,
die halt in Regressionen täglich zweimal auf den unterschiedlichen Umgebungen laufen.
Und da sehen wir, okay, was ist hingefallen?
Ja, die starten wir als Entwickler gar nicht.
Die laufen einfach irgendwann los.
Und täglich sitzt unser Scrum-Master zum Beispiel, der Hannes,
im Scrum-Master-Daily und da wird geguckt…
Mit mir?
Genau, mit dir.
Da ist viel Rotes.
Was ist denn da los?
Und dann wird dann eine Aussage getätigt werden müssen.
Okay, wir haben das auf dem Schirm, wir fixen das.
Oder Umsystem A reagiert nicht, wir kriegen die Verträge nicht und so weiter.
Das sind die meisten Antworten dann letztendlich,
weil wir immer sehr abhängig sind von dem,
was drumherum ist bei uns.
Aber so sieht Test-Automatisierung bei uns letztendlich dann aus, vom Prozess.
Da muss ich auch immer dran denken.
Ich gebe eine Vorlesung an der FH, Software-Qualitätssicherung.
Und wenn ich da…
Das sind alles so berufsbegleitende Studenten.
Die arbeiten also irgendwie alle als Software-Entwickler.
Wenn ich die frage, wer von euch testet denn eigentlich?
Dann herrscht immer so betretenes Schweigen.
Insofern finde ich es schön, dass ihr das anders macht.
Auch, ich meine, wenn man immer noch sich steigern kann oder sowas.
Aber ich befürchte, ihr seid da wesentlich weiter vorne,
als mir lieb ist, als Nutzer von Software.
Ja, aber das ist ja das Ganzhaltige, wo ich auch sage,
dass das die Menschen motiviert.
Wenn das Thema das erste Mal ausgesprochen wird vom Business
oder man es selbst einbringt,
wird es halt irgendwann in eine brauchbare Programmiergröße runtergebrochen,
wird refined.
Da kann man bei der Idee schon dabei sein,
kann vielleicht auch eine Architektur mit beeinflussen.
Selbst wenn man bloß Entwickler ist,
nicht mal eine Architektenrolle hat,
man kann sich dann zu dem Team mit hinzubringen.
Man kann es umsetzen, man kann es testen,
man kann es in die Welt bringen,
man kann die Bugs lösen.
Das ist halt von der Wiege bis zur Bar.
Genau.
Und ich meine, es ist ja auch im Grundeigensten Interesse des Kunden,
dass das System, gerade wenn es um Geld geht,
um Geldfluss, dass da das auch ordentlich getestet ist.
Ich meine, bestes Beispiel jetzt von meiner Sicht bei der Erstattung,
dass man dem Kunden nicht mehr Geld zurückzahlt,
als das Ticket gekostet hat.
Ich finde das ja kundenfreundlich.
Naja, also für uns ist der Kunde ja letztendlich die SBB.
Der Endkunde letztendlich am Schalter.
Genau.
Aber jetzt lass uns doch mal eins weiterspringen.
Wir haben uns hier aufgeschrieben,
Inspect and Adapt.
Die Chance, das Gehege zu flicken
und nicht immer nur Schafe einzeln im Sprint einzufangen.
Um was geht es denn da?
Das ist so ein klassischer Ausspruch,
den ich schon in vielen Scrum-Teams gehört habe.
Könnten wir doch mal jetzt das schließen oder das machen,
damit wir nicht immer diese Anzahl von Bugs haben?
Und da hat es der Michael schon angesprochen.
Und ich würde noch aus Sicht des Entwicklers das berichten lassen.
Ich sage nur so viel.
Bei uns im PI sind es drei Sprints,
drei Wochen und dann sind zwei Wochen lang
ein Zeitraum, der Inspect and Adapt heißt.
Und was es ist, kann Michael bestimmt erklären.
Genau.
In dieser Zeit,
in dieser Zeit,
ganz kurz, Stopp, Holger,
die Nachfrage.
Die Zeit, Inspect and Adapt,
für mich persönlich ist das ein Termin,
ein Meeting mit
Der IP-Sprint sozusagen.
Der IP-Sprint, genau.
Das ist ja Innovation, genau.
Improvement-Sprint quasi,
also das IP steht für Improvement.
Und das sind zwei Wochen,
an denen ein Entwickler mal Themen ausprobieren kann
und mal challengen kann,
zu der er im normalen Sprint nicht kommt.
Also quasi, wo das Business nicht reinredet,
wo kein PO sagt,
hier ist ein Backlog mit,
mit geschätzten Stories
und hier ist die Priorisierung, mach mal,
sondern das sucht sich der Entwickler selber
und quasi, auf was er Bock hat
und nimmt sich das dann in dieser Zeit vor.
Kann aber auch explizit dafür genutzt werden,
um sich weiterzubilden.
Also sagen, okay,
ich habe ja noch ein bisschen Schwächen in Angular
oder in anderen technischen Systemen
und sagt, okay, ich mache da nochmal eine Schulung
oder kümmere mich nochmal darum.
So, never mind.
Und hier ist ja Inspect and Adapt angesprochen
und das ist für mich ein Termin,
der ist ziemlich nützlich aus meiner Sicht.
Ich glaube, da gehen die Meinungen auch auseinander.
Aber wir sitzen da zusammen,
wo bestimmte Statistiken mit den Entwicklern geteilt werden.
Also quasi, wie lief denn der letzte Sprint?
Was ist so das Feedback vom Business quasi?
Wie haben die das gesehen?
Wie ist unsere Lieferzuverlässigkeit?
Also wie viele Stories konnten wir in der Zeit,
die wir uns vorgenommen haben, bearbeiten?
Dann ist immer noch ein ganz nützlicher Punkt,
wie stabil sind unsere Systeme gelaufen?
Also die Ausfallzeiten prozentual dargestellt.
Letztendlich und als so eine Dinge, wo man dann halt sieht,
okay, was lief alles gut?
Das ist natürlich auch immer schön zu sehen,
aber auch auf der anderen Seite, was lief schlecht?
Und dann wird auch immer Zeit dafür gegeben,
das zu diskutieren.
Also es ist quasi wie eine,
Holger, bitte korrigiere mich da,
wie eine Kronik,
wo man dann sagt, okay, das lief schlecht.
Wir gucken mal, wie wir das verändern können mit Next Steps
und diskutieren darüber.
Genau, also die Begriffe Inspect und Adapt
ist die Retrospektive nicht vom Team,
sondern in einem Safe-Umfeld einer ganzen Art.
Und das sind bei uns 80 Leute
und zu den Terminen kommen auch immer so 30, 40 Leute
und der dauert zwei Stunden.
Und da werden die Themen als Frage vorgeschlagen,
die man betrachten will.
Und dann gibt es einzelne Breakout-Sessionen dazu.
Da werden dann die Dinge besprochen.
Und die sind dann für den nächsten Planungszeitraum
als Verbesserungen hinzuzufügen.
Und dieser Improvement-Sprint wurde ja auch noch angesprochen.
Also immer, wir haben drei Wochensprints,
davon drei am Stück sind ein PI
und danach kommt ein Improvement-Sprint.
Und natürlich ist es so,
dass Leftovers aus den Sprints da zum Teil noch gefixt werden.
Aber die Entwickler organisieren sich das selbst.
Die machen selber das Planning.
Die pflegen selber das Backlog.
Die legen selber die Priorität fest.
Die sind frei darin zu sagen,
was sie verbessern wollen,
oder ob sie in Weiterbildungen investieren.
Und das ist immer der Abschluss von so einem PI sozusagen.
Und das ist auch der Wert.
Und dann sind wir wieder beim Üben,
wie immer am Anfang.
Genau, wollte ich gerade auch sagen.
Da sind wir wieder beim Üben, die Zeit da.
Ich finde diese Metapher so schön.
Die Chance, das Gehege zu flicken
und nicht immer nur die Schafe einzufangen.
Weil ich habe ja manchmal so meine Schubladen von ITlern.
Und ich glaube, dass viele ITler eben nach wie vor
noch gerne immer wieder Schafe einfangen.
Weil sie sich da beweisen können,
wenn man das Beispiel jetzt mal nimmt.
Und ich komme ja immer in meinen Trainings
mit dem Beispiel Axt schärfen,
um die Bäume besser frähen zu können.
Ist ja das Gleiche.
Also insofern, das habe ich jetzt hier gelernt.
Ich habe das irgendwann schon mal gehört,
aber ich finde es einfach ein schönes Bild,
einfach zu sagen so,
wie kann ich denn Agiles vorgehen?
Wie kann ich ins Backend-Adapt erklären?
Nämlich genau zu sagen,
ich kann immer Schafe wieder einfangen,
aber ich kann auch mal dran gehen,
das Gehege zu flicken.
Und dann vielleicht sogar dauerhafter zu flicken.
Also nicht nur flicken,
sondern vielleicht sozusagen dann den Zaun noch höher ziehen
oder die Maschen enger zu ziehen, wie auch immer.
Also das finde ich schon sehr, sehr interessant.
Für mich sind die zwei Punkte, die da wichtig sind.
A, dass diese Zeit gegeben wird
und dass die Teams wirklich selbst organisiert
das machen können.
Und wenn man es ordentlich durchführt,
dass auch der Glaube daran wächst,
dass es einen Sinn hat,
dass es das wirklich verbessert,
weil das ja dann direkt
auf die Motivation einzahlt.
Nichts motiviert weniger,
als wenn ich permanent Bugs hinterherlaufe,
die immer, wo die Quelle immer wieder offen ist,
aber ich nie den Weg dahin schließe,
sondern es immer wieder kommen lasse,
weil ich einfach die Zeit gar nicht habe,
daran zu gehen.
Genau.
Und als Entwickler hat man da auch vor allem das Gefühl,
dass man sich da auch mal selber bei Dingen,
die einen stören oder die schieflaufen,
dass man die ansprechen kann
und dann auch mitbekommt,
ja, da kann man,
da wird drüber nachgedacht.
Also,
ich weiß noch ganz am Anfang in der Zeit,
da wurde auch mal,
oder man wird als Entwickler immer mal wieder gefragt,
von wegen Marionette oder Puppenspieler.
Es gibt einem zumindest das Gefühl,
ein Stück weit Puppenspieler sein zu können,
dass man auch mal Dinge anspricht,
die nicht gut laufen
und man dann auch einen Raum hat,
wo man diese angehen kann
oder wo zumindest das Ganze gechallenged wird.
Und das bringt schon viel.
Ich kann das nochmal
als Scrum Master Perspektive bringen.
Wir leiten ja im Sprint die Meetings
und da kann man ja auch mal messen
oder beobachten,
wer welchen Redeanteil hat
und ich kann sagen,
in den IP-Sprints,
wo das Team selber plant,
kommen deutlich mehr Mitarbeiter zu Wort.
Es ist viel diverser.
Viele, die ich sonst nie höre,
weil die Moderation halt vorgegeben ist
oder weil man sich dann zum Teil
vielleicht auch bequem zurücksetzt
und auf seinen Einsatz wartet.
Das gibt es da nicht.
Da ist das Team unter sich.
Da wird gesprochen.
Sehr schön.
Übrigens für die Zuhörer,
die sich beruflich verändern wollen,
wahrscheinlich,
man findet auch eure Webseite,
da habt ihr bestimmt auch noch freie Stellen,
denn ich denke mal,
dass von dem, was ihr dort berichtet,
ich mich als Entwickler wohlfühlen würde.
Und wir haben immer das Thema
intrinsische Motivation.
Und das, was ich bei euch raushöre,
ist eben wirklich,
dass ihr das nicht nur,
ich sag mal,
im Sinne von,
ja, wir machen mal so ein Bildchen,
als ob wir das tun,
sondern für mich klingt das so,
als ob sich das durch eure ganze Einstellung,
durch eure ganze Organisation durchzieht,
dass ihr eben Wert auf die Entwickler legt,
auf deren Motivation,
auf deren Kreativität
und dass ihr darüber ja auch
die intrinsische Motivation herbeiführt.
Aber das müssen wir machen.
Wir stellen Teams mit Leuten,
die schnell produktiv werden müssen
und wir müssen die Umgebung so gestalten,
dass sie positiv ist
und dass aus jedem das Beste rauskommt,
weil nur dann,
also es gibt ja auch ein harter Fakt dahinter,
nur dann überleben wir das halbe Jahr,
das Jahr, das nächste Jahr
und bleiben Partner
und können auch an solchen guten Projekten teilnehmen.
Ja, zum einen Partner,
aber zum anderen,
ohne dass jeder von sich aus auch mitarbeitet
und dann sagt,
hier, ich bin gerade frei.
Hat denn jemand gerade was für mich,
weil ich gerade blockiert bin mit dem Ticket?
Ohne diese Einstellung würden wir als Team
am Ende des Tages auch nicht auf unsere Ziele kommen,
die im Planning gesetzt werden
und dann hat man das Meeting mit den Business Leuten
und muss sich vielleicht für etwas rechtfertigen,
was man nicht geschafft hat,
was immer nicht schön ist.
Ja.
Aber um das zu verhindern,
ist es ein,
ja,
ist es,
nur miteinander kann man das letztendlich schaffen
und deswegen,
ja,
ist das meiner Meinung nach
eine Anforderung an eine Person,
in so einem Umfeld zu arbeiten.
Man profitiert dann eben halt auch davon,
dass der Arbeitgeber
oder sage ich jetzt mal im Projekt,
man,
ja,
ein schönes Umfeld geliefert bekommt,
aber ich,
letztendlich,
was Holger gesagt hat,
runtergebrochen,
das ist ja auch so,
dass man dann auch produktiv sein muss,
ne.
Also,
wie gesagt,
mein,
mein Eingangssatz war,
dass ich gern mit motivierten Menschen arbeite
und
die Umgebung macht da viel aus
und das miteinander
und
ohne den würde man das auch nicht schaffen.
Wir,
wir sind darauf angewiesen,
dass der,
der mitarbeitet,
sich traut,
Fragen zu stellen,
Feedback gibt,
Rückmeldung gibt
und nur,
wenn er das macht
und interagiert
und dann sind wir auch wieder bei DevOps,
weil das gehört für mich genauso dazu,
dann,
dann kommt am Ende auch das Ergebnis raus,
weil ankommen tut man nur als Team,
äh,
ja.
In der Liste,
die ihr uns,
äh,
an Themen gegeben habt,
ist so ein Begriff,
den habe ich vorher nicht geklärt,
ich habe nicht nachgefragt
und ich bin mal gespannt,
was da jetzt als Erklärung kommt.
Da steht nämlich,
Hamsterrad.
Jeder kann so viel,
wie er kann
oder jeder gibt so viel,
wie er kann.
Ja,
wir hatten das vorher schon abgesprochen,
ne,
der,
der,
der Martin kannte das auch nicht,
sozusagen.
Jetzt werden wir mal gucken.
Martin?
Das war eingebaut.
War eingebaut.
Genau,
ähm,
na ja,
also,
wenn,
wenn du mich jetzt fragen würdest,
was ich tippe,
was du damit meinst,
gut,
na ja,
dann hieße das höchstens,
im Hamsterrad befinde ich mich,
wenn es immer wieder von vorne losgeht
und immer wieder dasselbe passiert.
Ja,
kennst du das nicht,
du bist in Sprints drin,
du bist vielleicht in einem Projekt,
das schon Sprint 52 hat
und alle zwei,
drei Wochen wird das Ding neu angeworfen
und du bist die User Story Factory
und musst
am Ende die Stories liefern,
am besten mit 100% Commitment,
12 von 12 geschafft,
dann,
und dann,
halben Tag frei,
Autos suchen,
weil die Demo so
aufreibend war,
dass du nicht mehr weißt,
wo du früh geparkt hast
und dann geht’s nächste Woche
wieder los.
Hamsterrad.
Genau,
aber da würde ich dir
insofern widersprechen,
ein Hamster sieht immer dasselbe
und,
ähm,
wir,
also ich habe nicht das Gefühl,
dass ich,
ähm,
auf Arbeit komme
und jeden Tag
mit denselben Themen,
klar,
wenn ich mal ein großes,
komplexes Thema habe,
dann beschäftigt man sich
auch eine Weile damit
und dann kommen vielleicht
nochmal ein paar Bugs
in der Richtung daher,
aber das ist schon
vielfältiger
von den Aufgaben her,
zudem haben wir im Team
auch noch selber
untereinander Rollen,
also mal ein Bugs-Bug
zu sein,
dann,
wir nennen das bei uns
DevOps-Bug,
ne,
das soll jetzt nicht diese,
ähm,
diesen Podcast untergraben,
aber so,
so nennen wir diese,
diese Rolle,
der,
der für die Deployments
verantwortlich ist
und sich das Testing anguckt,
das definiert jedes Team
für sich selbst,
aber dadurch,
dass die Rollen immer wechseln,
hat man auch da
nochmal Abwechslung,
dann,
wie willst du das sagen?
Ja,
ja,
also,
der,
die Überschrift hieß ja
Hamsterrad,
jeder gibt so viel,
wie er kann
und in meinen ersten Monaten,
wo ich bei der SBB gekommen bin,
mit einer super Einarbeitung,
motiviert,
bis in die Haarspitzen,
haben wir dann angefangen,
das Team
zusammenzubringen,
die agilen Prozesse
einzuschleifen
äh,
und das war,
war wirklich motivierend,
aber du kommst da dann
irgendwann an den Punkt,
wo du einfach auch
keine Kraft mehr hast,
wo deine Selbstkontrolle
durch ist
und da war dann der Satz,
äh,
P.I. Objectives ausgelegt,
dass sich niemand hinlegt
und aufgrund des Teams ausruht,
aber,
wenn man halt so schnell,
wenn man eine User Story Factory ist
oder wenn man P.I. Objectives
immer alle ein Vierteljahr
bringen muss,
da kann nicht jeder
jeden Sprint
120 Prozent machen,
denn einen Sprint
stricht halt der hervor,
den anderen der
und ich finde,
wenn man auf so ein Niveau kommt,
dass jeder so viel gibt,
wie er kann
und dieser Satz ist wirklich gefallen,
den fand ich halt so passend,
als äh,
wie nennt man’s denn,
als,
als kooperatives Team,
wo,
wo halt nie nur
die Professionalität
im Vordergrund steht
und was jeder macht
und tut,
äh,
sondern dass man auch mal
sagen kann,
hey,
heute ist schlecht,
äh,
nicht ganz so produktiv.
Ich,
ich versteh.
Da geht’s so ein bisschen
einfach dann in Richtung Team
und ähm,
nicht toll ein anderer macht’s,
sondern together
each one achieves more,
ne,
also,
dass man sich wirklich
dann mal,
ähm,
wie du schon sagst,
nicht ausruhen kann,
aber wenn’s,
wenn’s mal nicht so geht,
dann geht’s eben nicht
und dann sollte man’s
auch sagen können
und auch sagen dürfen,
ja,
ja,
ja,
aber ich muss da jetzt mal kurz,
äh,
ich muss da jetzt mal kurz
reingrätschen,
weil das klingt jetzt immer so ganz nett
und ganz prima und so,
aber,
äh,
also,
mein Chef hätte da was dagegen,
wenn,
wenn ich sage,
öh,
also,
hm,
die Woche ist irgendwie mir so,
hm,
ähm,
nee,
Leistung muss hier.
Ja,
das ist so eine Sache,
also,
ich denke mir,
wenn ich dich als Mitarbeiter hätte,
dann würd ich sagen,
die acht Stunden,
die du täglich machst,
40 Stunden in der Woche,
entstehen ja auch Gefühle
und die Gefühle können ja auch Frustration sein,
wegen schlechter Arbeitsmittel
oder weil du nicht vorankommst
und es,
es ist kein gefühlsvoller,
äh,
gefühlsfreier Raum,
du,
klar geht’s um Produktivität
und am Ende wird gemessen,
aber deswegen bist du ja ein Team
und deswegen kann der eine mal mehr bringen
und der andere mal weniger,
das heißt,
nie ausruhen,
sondern,
da muss das Team auch schon zusammen sein
und dafür einstehen
und sagen,
okay,
das,
äh,
dann nehmen wir was dafür.
Muss ich jetzt nochmal nachfragen,
weil angenommen,
du bist jetzt doppelt so schlau wie ich,
was ich jetzt einfach mal voraussetzen würde,
dann,
ähm,
dann wär das doch irgendwie ganz schön mies
für das ganze Team,
wenn ich dann irgendwie immer nur halb so viel leiste,
wie du beispielsweise,
also,
ist das,
entspricht das dann auch dem Teamgeist?
Du fragst ja mich als Scrum Master
und das ist genau meine Tätigkeit
und ich muss da mit einer Geschichte antworten,
ich hatte jetzt das erste Elterngespräch
und der Lehrer sagte,
äh,
über Lerngeschwindigkeiten
bei seinen 28 Schülern,
der eine ist schneller,
der andere ist langsamer
und er hat das super gemanagt,
der hat gesagt,
okay,
das ist jetzt so,
das müssen wir im Klassenrat besprechen
und das ist was,
was ich täglich hab,
es gibt einfach unterschiedliche Geschwindigkeiten,
Dinge aufzunehmen
oder Dinge abzuarbeiten
und die wird’s immer geben in dem Team
und da wird’s auch immer Streit geben,
die beiden Enden werden immer gegeneinander sein,
aber,
wir müssen ja zusammen ankommen am Ende,
äh,
nur die Superhirne hinschalten,
Rücken freizuräumen
und machen zu lassen,
dann bring ich doch über die Jahre
keine,
äh,
stabile Produktion
und neue Features,
weil der,
der Wandel ist das Endstil,
was,
was Stabiles bei uns,
wir hatten letztes Jahr acht Abgänge
und 13,
äh,
Zugänge,
äh,
ja,
wo willst du’s machen?
Und deswegen finde ich dieses,
jeder gibt so viel er kann
und zwar positiv,
ausgelegt,
wichtig.
Und das auch immer sagen kann,
heute ist nicht so.
Da würde ich vielleicht auch mal als Entwickler einhaken,
ähm,
mit diesem,
äh,
im Sinne von,
aus persönlichen Gefühlen heraus zu sagen,
ich nehme mich jetzt mal zurück,
ähm,
was tatsächlich im Team oder uns im Team
noch gar nicht so groß passiert.
Ähm,
klar spielt das immer mal unterbewusst noch eine Rolle,
dass da ein bisschen,
ein bisschen Produktivität hängen bleibt,
aber nicht,
dass jetzt es so in Anführungsstrichen akut ist,
dass ein anderes Teammitglied einspringen muss.
Man hat,
es klingt natürlich immer strikt,
man hat seine drei Wochen pro Sprint,
das drei Mal
und dann ist der Sprint vorbei.
Es ist auch eine gewisse Zeit dahinter.
Und wenn man etwas nicht schafft
oder mit in den nächsten Sprint,
nimmt,
dann gibt es da kein Fingerpointing,
wo gesagt wird,
hey,
hier,
ihr habt so viel da eingeplant,
warum hast du das nicht geschafft?
Dann ist es so,
dann braucht es seine Zeit
und dann geht es halt noch mal ein Stück weiter.
Aber dieses jeder gibt so viel er kann,
würde ich jetzt halt auch fast auf neue Kollegen mitbeziehen.
Also,
wenn man einen neuen Kollegen hat,
der kann eben noch nicht so viel
oder sagen wir mal,
wir haben zwei,
der eine lernt schneller als der andere,
dann ist das eben so,
ne?
Aber wir vom Team sind darauf angewiesen,
dass beide früher oder später produktiv sind,
um uns eben gemeinsam mit nach vorne zu bringen.
Und dann ist dieses Teamkonzept
oder das Klima im Team entscheidend.
Wie wird den beiden geholfen?
Und das ist ganz normal und menschlich,
dass sie unterschiedlich schnell lernen.
Und dann können sie noch das fünfte Mal kommen,
fragen und um Unterstützung bitten.
Und dann ist es so.
Und dann wird die Unterstützung auch gewährt und gegeben.
Also ich habe noch nie im Team erlebt,
dass auf die Frage
kann ich,
kann ich dich mal um eine Meinung bitten,
dass da jemand Nein sagt.
Das ist,
finde ich,
das geht auch nicht in dem Umfeld.
Das ist,
muss ich sagen,
ist auch beachtlich,
weil gerade Architekten oder Lead-Entwickler
so viel zu tun haben.
Genau.
Und sich trotzdem immer noch die Zeit nehmen.
Und wenn es am Abend 17 Uhr dann die zehn Minuten sind,
um das zu erklären,
dann ziehe ich einen Hut davor.
Und das,
Respekt,
ja.
Genau.
Also das finde ich ganz toll,
dass ihr das gesagt habt.
Und ich finde,
dass du auch insbesondere,
Michael,
fast ganz Wichtiges gesagt hast.
Wenn einer irgendwie nicht so richtig mit dem Team mitziehen kann,
dann muss sich an irgendeinem Punkt auch das Team fragen,
warum sie den zurückgelassen haben.
Genau.
Also das fand ich ganz spannend.
Und ich habe die Frage auch deswegen gestellt,
sozusagen stellvertretend für viele Leute in meinen Trainings,
die vielleicht noch nicht so erfahren sind in agiler Arbeit
und die dann eben die ganz ehrliche Sorge haben.
Wenn ich jetzt mal den unvermeidlichen schlechten Tag habe,
trotz all meiner ehrlichen Bemühungen,
machen die mich dann kopfkürzer,
weil ich kann mich ja auch gar nicht mehr verstecken.
Also und darum finde ich,
dass ganz wichtig,
dass man,
genauso wie ihr es jetzt gesagt habt,
da auch erstens die Sorge nehmt,
sagt,
das passt schon.
Und zweitens,
dass man auch ganz klar den Spieß umdreht und sagt,
es ist auch in der Verantwortung des Teams,
dass das Team als Ganzes vorwärtskommt.
Ich würde es nochmal umdrehen.
Also die Verantwortung,
die seelische sozusagen und produktiv und gesund zu sein,
die hat natürlich jeder selber
und auf die muss er auch aufpassen.
Er muss auch gucken,
dass er nicht zu viel arbeitet,
hat und kann auch nicht immer mehr annehmen
und sich vom Management auch noch beklatschen lassen.
Nimm noch mehr dazu,
sozusagen.
Es gibt ja so verschiedene Ebenen davon,
wo das hingehen kann.
Man muss halt aufpassen.
Und das ist vielleicht ein großer Sprung.
Ich glaube,
dieser Strom an Arbeit,
was er das Hamsterrad auch festmacht,
der muss auch wirklich gut geplant werden.
Und der ist bei uns gut geplant.
Das muss abarbeitbar sein.
Das ist dieses berüchtigte Commitment,
das halt im 58. Sprint so fast gar nicht mehr hörbar ist.
Schaffen wir das jetzt so hier alles?
Fragt das Grammar.
Das Team so,
und am Ende macht man so.
Aber das ist halt wichtig.
Also das muss auch dazu passen,
was drin abgearbeitet werden kann in den Teams.
Und da immer in diesem Rahmen sage ich halt,
jeder gibt so viel er kann.
Das Ziel ist immer gesetzt am Ende.
Alle User-Stories schaffen,
die PI-Objects schaffen,
Dinge ausliefern,
die Kundenwert haben.
Das hört ja nicht auf.
Es dreht sich weiter.
Genau.
Klar.
Da kann ich vielleicht auch ein bisschen
aus dem Projekt mal reden.
Wir waren da auch an einem Thema dran,
was wir erst eingeplant haben
und dann halt auch maßlos unterschätzt haben.
Tatsächlich,
weil wir in einer bestimmten Sache
nicht einfach nur weiter so wollten,
sondern halt auch da die Chance gesehen haben,
eine Verbesserung für uns als Team reinzubekommen.
Und diese Geschichte zieht sich jetzt schon
auch eine ganze Weile und einige Sprints
und wird auch immer wieder mitgenommen,
wo wir dann halt auch uns rechtfertigen müssen.
Warum dauert es so lange?
Was sind denn die Gründe?
Aber letztendlich haben wir daraus jetzt
den Mehrwert zu generieren,
dass wir dann auch
die
jetzt auch zusammenstellen können.
Okay, welche Fehler haben wir gemacht?
Und wenn dieses Problem nochmal in der ganzen Factory,
in der Timo Factory vorkommt,
hier, so ist das Vorgehen.
Die Fehler haben wir gemacht.
Macht die nicht.
Fangt lieber gleich den richtigen Weg an.
Und dadurch haben wir dann auch nochmal vielleicht
aus dieser Zeit, die wir länger gebraucht haben,
wo wir erst mal vor eine Wand gelaufen sind,
natürlich jetzt auch zu zeigen,
hier ist die Wand,
geht mal lieber drum herum.
Ja.
Und das bringt dann auch schon mal viel,
weil man dann in einem,
sage ich mal,
konstruktiven Umfeld ist,
wie mit einem,
ich will es nicht Versagen nennen,
aber wie es mit einem Fehler
oder mit einem Fail einfach umzugehen.
Ja, für mich gehört das zu der Umgebung dazu,
die motivierend ist.
Wettbewerb ist gut,
das muss auch da sein,
aber ich würde gerne da arbeiten,
wo nett sein die Regel ist.
Und ich will auch, dass alle nett sein
und trotzdem ihre Professionalität,
Ehrgeiz und Erfolg weiter behalten.
Das ist schon richtig.
Aber irgendwo ist die Grenze.
Genau, irgendwo ist die Grenze.
Das stimmt natürlich.
Wenn es für den Kunden kritisch wird,
gerade in Sachen Hilfsbereitschaft drumherum,
dann muss man natürlich auch liefern.
Und dann ist auch mal schnell diese Wohlfühlmentalität
und Bereich vorbei,
wenn man da eben auch nicht liefert.
Ja.
Aber insofern finde ich es gut,
dass ihr den Begriff Hamsterrad nochmal erklärt habt.
Denn ich habe manchmal so diesen,
den flapsigen Spruch,
auch ein Hamsterrad kann wie eine Karriereleiter aussehen.
Das wäre natürlich nicht das, was ihr wollt.
Also deswegen ist es sehr schön gehört zu haben,
jeder gibt so viel, wie er kann.
Und das finde ich, zeigt auch,
wie ich eben vorhin schon auch gesagt habe,
dass das nicht nur einzelne Aspekte sind,
wo ihr sozusagen euch so eine agile Fassade aufbaut,
sondern wo das sich eben komplett durchzieht.
Und wo man, ich finde,
auch so nach und nach jetzt mitbekommt,
wenn das alles gemacht wird,
dann greift das quasi eins ins andere hinein.
Das heißt also,
das sind alles Aspekte,
die überall in Summe Vorteile bringen,
die natürlich auch Konsequenzen mit sich bringen.
Aber in Summe habt ihr einfach engagierte, motivierte Leute.
Und das zahlt sich eben aus.
Es zahlt sich auch aus durch Dinge,
die man vielleicht nicht messen kann.
Aber es zahlt sich eben auch aus durch,
dass ihr die Mitarbeiter an Bord behaltet
und dann doch gut performt.
Weil, das hast du ja auch gesagt, Holger,
bei allen agilen und menschlichen Sichten,
ihr müsst liefern.
Ihr müsst was abliefern.
Also nur zu sagen,
unserem Team geht es gut
und wir schaffen aber heute nichts,
das wird er nur zweimal sagen können wahrscheinlich.
Ja.
Ich gucke ein bisschen auf die Uhr.
Und wir haben ein Luxusproblem.
Nämlich das Luxusproblem,
dass wir von unseren geplanten Punkten
na ja, noch nicht mal die Hälfte abgearbeitet haben.
Was ich aber absolut super finde,
weil wir nach meiner Meinung,
nach meiner Einschätzung,
ein ganz tolles Gespräch haben.
Also ich frage jetzt mal in unserer kleinen Teamrunde.
Ist es für euch okay,
wenn wir jetzt diese erste Aufnahme stoppen,
die erste Folge sozusagen hiermit beenden
und dann quasi mit der zweiten dann irgendwie weitermachen
und wo wir dann so ein bisschen auf die Punkte
der Forbes in der Praxis eingehen?
Na klar.
Machen wir so.
Jawohl.
Gut.
Dann sage ich erstmal für diese Folge herzlichen Dank
und bis gleich zur nächsten Folge.
Auf Wiedersehen.

Folge 55: DevOps in 2022

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Neues Jahr, selber Podcast: Falko, Dierk und Luca schauen auf 2021 zurück und denken darüber nach, was DevOps im Jahre 2022 wohl bedeuten mag.
Ist DevOps noch aktuell? Hat es sich in den vergangenen Jahren gewandelt (und wenn ja, wie)? Was erwartet Organisationen im Jahr 2022 im Bezug auf DevOps?

In dieser Podcast-Episode wird intensiv über die Integration und den aktuellen Stand von DevOps in Unternehmen diskutiert. Die Teilnehmer erörtern, inwiefern DevOps in der Unternehmenspraxis angekommen ist und welche Herausforderungen und Missverständnisse bestehen. Sie sprechen über verschiedene Herangehensweisen und Perspektiven, wie DevOps implementiert werden kann und welche Rolle kulturelle, organisatorische und technische Aspekte dabei spielen. Besondere Aufmerksamkeit gilt auch der Frage, wie Unternehmen DevOps effektiv umsetzen und welche Rolle individuelle Unternehmensbedingungen dabei spielen.

Inhalt

  • Begrüßung und Einführung ins Thema
  • Thesen zur Verbreitung von DevOps in Unternehmen
  • Diskussion über DevOps-Implementierungen in verschiedenen Unternehmen
  • Herausforderungen bei der Einführung von DevOps
  • Rolle von ITIL 4 und SAFe im Kontext von DevOps
  • Bedeutung der Unternehmenskultur und -organisation für DevOps
  • Abrechnungsmodelle und wirtschaftliche Aspekte von DevOps
  • Perspektiven für DevOps im Jahr 2022
  • Schlusswort und Ausblick

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps Auf die Ohren und ins Hirn.
Ein Podcast rund um DevOps.
Von Dirk Söllner, Falko Werner und Luca Ingiarni.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps Auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingiarni, Dirk Söllner und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Und wir sind heute im neuen Jahr. Also alles Gute von uns für euch, für euch Hörer, für das neue Jahr 2022.
Und zu Beginn des neuen Jahres wollen wir eine Standortbestimmung wagen.
Was haben wir im vergangenen Jahr bei unseren Kunden und in der Szene wahrgenommen?
Und wie sehen wir DevOps im Jahr 2022?
Und wir hatten uns in der Vorbereitung auf dem Podcast überlegt, okay, jeder formuliert so zwei, drei Thesen, über die wir diskutieren.
Und wir haben schnell festgestellt, dass wir eigentlich zwei ganz coole Thesen haben, die eigentlich These und Antithese sind.
Das heißt, wir haben uns eigentlich geeinigt darauf, dass wir gesagt haben, wir haben eine These, die heißt, DevOps ist in den Unternehmen angekommen.
Und die zweite These ist, DevOps ist doch nicht in den Unternehmen angekommen.
Und über diese beiden Thesen oder Antithesen.
Wenn wir sprechen und vielleicht schafft man nachher ja auch noch eine Synthese, eine Zusammenführung.
Da schauen wir mal.
Aber das wollte es vielleicht zu meiner Seite aus gewesen sein.
Ich übergebe mal an Luca oder Falco.
Wer von euch will denn mal starten?
Ja, dann mache ich das doch.
Okay, dann machst du Falco.
Bingo!
Der Klassiker.
Zwei Sekunden warten reicht nicht.
Man muss fünf Sekunden warten.
Egal, schneiden.
Ja.
Ja, hallo.
Auch von mir ein gesundes neues Jahr.
Meine Corona-Infektion ist durch.
Insofern hoffe ich, dass es dabei bleibt und dass ihr das alle nicht durchmachen müsst.
Ich freue mich auch, mit Luca und Dirk mal wieder im Podcast zusammenzusitzen und finde die beiden Thesen, die Dirk gerade erwähnt hat, zum Stand von DevOps und ob oder ob es nicht in Unternehmen angekommen ist.
Ein spannendes Thema, so zum Beginn des Jahres.
Also vielen Dank für die Idee und ich übergebe.
An Luca.
Tja, was soll ich noch sagen?
Außer von mir natürlich auch ein gesundes Neues.
Ich bin schon sehr gespannt, was jetzt rauskommt bei diesen zwei Thesen.
Wir können ja mal anfangen mit der, ich sage jetzt mal mit der freundlicheren, dass wir sagen, DevOps ist in den Unternehmen angekommen.
Dirk, ist das so?
Naja, vielleicht kriege ich nur meine Filterblase mit bei Unternehmen, die uns beauftragen für DevOps-Trainings.
Das ist natürlich klar.
Wenn jemand sich nicht für DevOps interessiert, wird da auch kein Training gebucht.
Aber natürlich habe ich auch Kontakt zu anderen Unternehmen, zu anderen Ansprechpartnern.
Also ich glaube, dass DevOps schon in den Unternehmen angekommen ist.
Und angekommen heißt eben, dass aus meiner Sicht die Unternehmen, also die, die es betrifft natürlich, sich der Problematik bewusst sind und dass sie die Herausforderung erkennen und angehen.
Einfach mal so zwei, drei Beispiele, dass eben nicht nur wir für Trainings gebucht werden, sondern dass auch Gespräche stattfinden.
Wie könnte man denn DevOps unterstützen?
Also im Prinzip Projektanfragen, Beratungsanfragen.
Das ist so der eine Punkt.
Und der andere Punkt ist, dass ich sehe, in den Unternehmen, es werden Lösungsansätze ausprobiert und umgesetzt.
Das heißt also, es gibt die Unternehmen, die sagen, hey, wir machen jetzt DevOps.
Wir werden sicherlich noch klären, ob das DevOps ist, was die machen, wenn sie sagen, wir machen DevOps.
Aber zumindestens ist der Begriff angekommen.
Und wenn ich dann meinen lieben Bernd.
Grüßen darf an der Stelle, der auch sagt, DevOps ist angekommen.
Wir werden Bernd heute noch das eine oder andere Mal vielleicht erwähnen als Ideengeber,
der eben auch aus meiner Sicht als gestandener IT-Service-Management-Experte und Vertreter sagt,
DevOps ist jetzt da, wo vielleicht ITIL vor zehn oder 15 Jahren war.
Also wirklich als ein Begriff, als eine Philosophie, die in den Unternehmen wahrgenommen wird
und wo die Unternehmen sich dran setzen, das irgendwie anzugehen.
Ja, da sind wir natürlich tatsächlich ein bisschen in der Filterblase.
Die Unternehmen, die uns ansprechen, sind die Unternehmen, die sich mit DevOps beschäftigen.
Aber ich glaube, man erkennt es auch daran, dass diese Beschäftigung halt irgendwie ernsthafter wird,
fokussierter wird, dass das nicht nur als irgendwie so ein Randthema betrachtet wird,
dass man irgendwie mal so eine Handvoll Techies überlässt oder sowas,
sondern dass man das wirklich als Herausforderung für die Organisation als Ganzes begreift.
Was, glaube ich, ein ganz, ganz wichtiger Entwicklungsschritt ist.
Und das ist vielleicht so in der Rückschau die Entwicklung, die natürlich nicht erst 2021 angefangen hat,
aber die jetzt in vollem Gang ist, dass man weggeht von DevOps als Dev und Ops
und dass man stattdessen den Bogen noch viel weiter schlägt und noch viel weitere Teile der Organisation
und nicht nur der IT-Organisation mit einbezieht.
Insofern, da gebe ich dir recht, Dirk.
Falco, wie siehst du das?
Ja, ich sehe das.
Ich sehe, dass DevOps im engeren Sinne an vielen Stellen ein Thema ist.
Ob jetzt Teams so aufgesetzt werden, dass sie sowohl für bestimmte Funktionalitäten,
Umfänge in ihrem Bereich die Verantwortung für neue Funktionen, neue Erweiterungen und Entwicklungen übernehmen,
als auch an den Stellen, wo Service Support oder Betrieb Deployment einen Blick haben,
das ist aber aus meiner Sicht viel auf Team-Ebene platziert.
Dass es im Unternehmen angekommen ist, dass man DevOps in dem Blickfeld von Anforderungen vom Kunden,
vom Endkunden, vom Nutzer bis zur Realisierung dieser Anforderungen für diesen Endkunden
wirklich als durchgängiger Prozess, vielleicht auch mit…
… allen Aspekten, die zu DevOps gehören, so kam es im Hintergrund, kulturell, Lean, agile Entwicklung,
Measurement, kontinuierliches Verbessern, Experimentieren, sehe ich relativ selten.
Aber wir sind ja aktuell immer noch bei dem Punkt, DevOps ist ein Unternehmen angekommen,
also der Begriff, würde ich sagen, ja, Verständnis dafür an vielen Stellen auch.
Die Notwendigkeit für Automatisierung sehe ich an der Stelle ebenso bei vielen Unternehmen,
in der Wahrnehmung, in dem Punkt, wo ich sagen würde, es ist angekommen.
Ja, für mich ist auch ein Aspekt, das, was ich vorhin sagte, dass Lösungsansätze ausprobiert oder umgesetzt werden.
Das heißt, ich erlebe schon, dass Unternehmen DevOps-Teams gründen oder etablieren.
Vielleicht noch nicht ganz durchgängig, da gebe ich dir recht, Falco,
aber zumindestens werden DevOps-Teams gebildet oder DevOps-Projekte gebildet.
Klar, jetzt könnte man sagen, höre, Projekte, DevOps, widerspricht sich ja.
Können wir auch noch klären.
Aber einfach der Begriff und organisatorische Veränderungen, die werden entsprechend umgesetzt.
Und das macht man ja nicht zum Spaß.
Also ich denke, kein Bereichsverantwortlicher, kein Geschäftsführer oder kein Projektverantwortlicher,
kein Produktmanager wird mal ebenso aus Spaß sagen, hey, lass uns mal ein bisschen DevOps machen
oder lass uns mal DevOps machen.
Also das denke ich schon, dass eben die Unternehmen erkannt haben, sie müssen etwas verändern.
Wir sind an die Grenzen dessen gestoßen.
Was?
Was eine IT-Organisation leisten kann im Vergleich zu dessen, was sie auch wirklich leisten muss oder müsste.
Und du hast es eben gesagt oder ein bisschen angesprochen, Falco,
die Wert- und Kundenperspektive, die ist noch nicht ganz da, aber sie kommt schon ein bisschen näher.
Und es gibt eben auch ganz tolle Beispiele, wie das entsprechend umgesetzt ist.
Und da haben wir ja im nächsten Podcast, in der nächsten Folge ein tolles Beispiel,
wie DevOps wirklich umgesetzt werden kann oder könnte.
Also das ist eben für mich wirklich ein Zeichen, es ist angekommen, weil die Unternehmen etwas tun,
weil sie etwas verändern.
Und wir werden sicherlich auch gleich noch darüber sprechen, was sie vielleicht auch falsch machen
oder wo wir von Dingen berichten können, wo sie ihre Erfahrungen machen.
Das heißt, es anders zu machen, aber sie stellen sich dieser Verantwortung und stellen sich auch der Herausforderung,
Dinge wirklich mal anders zu machen und auch anders zu gestalten.
Ja, ich finde, zum Ersten hat Falco natürlich recht, wenn er sagt,
ganz häufig ist das auf der Team-Ebene schon viel mehr angekommen als auf größeren Organisationsebenen.
Aber andererseits spürt man eben auch Bewegung in diesem Thema,
zum Beispiel durch Bücher wie Team Topologies, das ja auch nicht 2021 rauskam,
aber zumindest meiner Wahrnehmung nach 2021 irgendwie sehr viel mehr Aufmerksamkeit,
erfahren hat, dass viele Organisationen jetzt merken, dass es eben keine Teamaufgabe
und es ist auch kein Projekt, so wie Dirk gesagt hat, sondern da geht es um viel, viel mehr,
dass sie sozusagen an die Grenzen der Sichtweise stoßen, dass DevOps eine technische Herangehensweise ist
und dass das jetzt zunehmend ausstrahlt auf weitere Bereiche der Organisation.
Und das beobachte ich auch in Gesprächen, auch in Trainings, dass die Leute dann sagen,
ach Donnerwette, jetzt wird mir alles möglich.
Okay, klar, was ich irgendwie schon wahrgenommen und erfahren habe in meiner Organisation,
jetzt verstehe ich langsam die Mechanismen, die da dahinter stehen.
Ja, stimmt. Das ist das, was ich auch feststelle.
Wir haben ja einige größere Kunden auch bei unseren Trainings sitzen.
Und das, was du sagst, die sagen, ah, alles klar, das verstehe ich jetzt, warum wir das so und so machen.
Interessant ist natürlich auch, fällt mir jetzt so auf,
dass wir natürlich häufig auch ältere Teilnehmer haben und dann sagen die,
boah, haben wir alles früher schon mal gehabt.
Also da kommt dann so dieser Effekt, na ja klar, vor 20 Jahren haben wir das gemacht oder vor 15 Jahren
und dann wurde es irgendwie getrennt, aber es macht irgendwie Sinn, das wieder zusammenzuführen.
Das heißt auch, das ist für mich ein Argument, dass DevOps in den Unternehmen angekommen ist,
weil sich nämlich eben Dinge sozusagen wieder etablieren, die vor Jahren mal etabliert waren,
aus verschiedenen Gründen.
Und ich sag mal, nicht mehr fortgeführt wurden, aber eben jetzt wieder aufleben oder wo man das wieder aufleben lässt
und da versucht doch wieder die Erfahrung von damals, die positiven Erfahrungen wieder entsprechend umzusetzen.
Aber was Luca sagte, ah, jetzt verstehe ich, was wir da machen oder warum wir das machen.
Und die Zustimmung kommt, es macht eigentlich Sinn.
Also es macht Sinn für die Teilnehmer.
Ja, das ist ja auch so. Es macht ja auch schlicht und ergreifend Sinn.
Ich meine, viele der Aspekte von DevOps.
Das sind ja auch eigentlich schon keineswegs mehr neu.
Man denke an Lean, das ja eigentlich vom Toyota-Produktionssystem kommt
und das wurde in den 30er Jahren in seinen Anfängen erdacht.
30er Jahren des 20. Jahrhunderts wohlgemerkt.
Insofern, das ist nicht mehr so wahnsinnig neu.
Dasselbe ist mit der agilen Vorgehensweise.
Ich meine, der Begriff agil ist immerhin auch schon 20 Jahre alt
und die dahinterstehenden Gedankengänge, naja, ich sag immer,
das Rad ist bestimmt nicht im Wasserfallprozess erfunden worden.
Tja, wer weiß. Warst du dabei?
Nee, aber ich habe gute Quellen.
Okay, gut. Dann bring die bitte mal. Die möchte ich sehen.
Genau. Nee, aber im Ernst, das sind einfach Herangehensweisen,
die sich, glaube ich, anbieten und die sich schon oft angeboten haben.
Und die Leute fühlen sich jetzt vielleicht wieder ermutigt,
Dinge zu tun, von denen sie das Gefühl haben, ja, das fühlt sich richtig an.
Ja, und ich meine, wir sind ja auch alle, die das Gefühl haben,
wir sind ja auch alle in so einem Buzzword-Bingo-Business unterwegs.
Also, das ist für mich auch ein Argument.
Das kann man jetzt gut oder schlecht finden.
Aber wenn ich so an so zwei, drei Kontakte von mir denke,
mit denen ich auch immer wieder im Austausch bin,
das sind alle drei in diesem Fall, also ich habe jetzt drei Menschen vor Augen,
die sind wirklich eingefleischte Service-Management-Profis.
Also, die sind wirklich stark auf ITIL beispielsweise ausgerichtet.
Und selbst die haben im letzten Jahr gesagt,
mehr oder weniger,
eindeutig, hey, wir machen bei uns jetzt DevOps.
Auch da wieder die Frage, was ist DevOps?
Das ist ja ein Punkt, wahrscheinlich, da können wir stundenlang diskutieren.
Deswegen fragen wir das ja auch alle unsere Gäste immer.
Aber auch da sage ich mal so, diese eingefleischten Service-Management-Profis,
also auch Experten, die auf Prozesse Wert legen,
die auf, vielleicht auf einen Wasserfall vielleicht eher Wert legen,
die auf Silos vielleicht aufgebaut sind, um ihre Prozesse drüber zu legen.
Selbst die reden davon,
dass sie jetzt DevOps machen und finde ich dann eben auch schon sehr interessant.
Und wie gesagt, wir sind ja immer noch bei dem Part,
DevOps ist in den Unternehmen angekommen.
Hängt das vielleicht auch damit zusammen,
wenn Service-Management-Spezialisten, erfahrene Kollegen über DevOps reden,
dass ITIL als verbreitetes Framework im Service-Management die Version 4
herausgebracht hat und da viele Themen, die auch mit Agile-Management,
die auch mit Agile-Management, die auch mit Agile-Management, die auch mit Agile-Management,
die auch mit Agilität zu tun haben, auch in dem Bereich Service-Management
einen höheren, ja, Wahrnehmungsgrad erhalten?
Das könnte natürlich sein, wenn ich jetzt so ein bisschen schubladenartig denke,
also die drei Kollegen mögen mir das verzeihen, dann könnten die ja eigentlich
auch sagen, hey, wir machen jetzt ITIL 4. Das wäre ja auch eine Argumentation,
wenn man auf dieser Begrifflichkeit bleibt. Aber und ITIL 4 hat ja auch ganz klar gesagt,
Lean-Praktiken übernehmen wir, wir übernehmen DevOps, also ITIL 4 hat sich quasi
so ein bisschen auch als übergreifendes Framework positioniert. Ich weiß gar nicht,
ob uns jetzt sozusagen so eine Framework-Diskussion weiterbringt. Aber was ich dabei rausnehme,
ist, dass zumindestens der Begriff von DevOps und das, was dahintersteckt,
dass das eben wahrgenommen wird und dass sich das auch bei Menschen in den Gesprächen widerspiegelt
widerspiegelt, die eben davon früher nichts wissen wollten. Also bei all diesen dreien Menschen
weiß ich, wie sie noch vor drei, vier Jahren wirklich so von wegen Agilität, bleibt mir weg damit,
so wie sie da entsprechend argumentiert haben.
Ja, wobei ich unterstellen würde, dass bestimmt eine Menge pragmatische Praktiker,
auch wenn die vielleicht noch in ITIL-Versionen geschult wurden, die das Wort DevOps zumindest nicht
ausgeführt haben, dass die sehr wohl natürlich Praktiken verwendet haben, die man jetzt vielleicht
DevOps nennt, aber die natürlich vor 10 oder 20 Jahren auch schon eine gute Idee waren.
Das erinnert mich so ein bisschen an meinen eigenen Werdegang, weil ich mache auch schon länger
DevOps, als ich das Wort DevOps kenne. Sondern ich habe halt Sachen gemacht, die für mich sinnvoll waren.
Und irgendwann habe ich gemerkt, es gibt noch mehr Leute, die das machen und die nennen das DevOps.
Also nenne ich es halt auch DevOps. Und ich glaube, so geht das ganz häufig. Wenn die Leute sich trauen,
das zu tun, was sinnvoll ist.
Dann landen sie ganz häufig bei Sachen, über die man halt auch in DevOps redet.
Ja, ich habe gerade nochmal darüber nachgedacht, bei unseren SAFe-Trainings, bei den Einführungstrainings von SAFe.
Da ist meine Wahrnehmung, dass dann auch Betriebsleute sitzen. Also SAFe kommt ja auch eher aus der agilen Seite,
als agiles Skalierungsframework. Und wenn dann die Betriebsleute da drin sitzen, dann kommt auch immer die Frage,
ja, wo sind wir denn da? Oder wo finden wir uns wieder? Also auch das ist, wie ich finde,
dann schon ein Punkt, wo man daraus ableiten kann, dass der Betrieb oder das Ops, wenn man jetzt wirklich das Ops nimmt,
dass das angekommen ist in dem Unternehmen im Sinne von, auch da, die Leute müssen wir auch einbeziehen.
Also die Lösung einer zukünftigen Organisation kann nicht darin liegen, Dev und Ops zu trennen.
Also ich muss, wenn ich, auch wenn ich agil skaliere, wenn ich ein Unternehmen nach SAFe ausrichten möchte, muss ich mir Gedanken machen,
wo platziere ich meine Betriebe?
Wo sind meine Betriebsleute? Wo finden die sich wieder?
Ja, das kann natürlich auch sein, dass ein Unternehmen sagt, wir machen DevOps, das ist bei uns angekommen.
Wir haben ein Programm, in dem verschiedene Teams zusammenarbeiten, bei dem letztendlich eine Gesamtverantwortung ist,
sowohl für die Weiterentwicklung, als auch für Test, als auch für den Betrieb, Support, Deployments und ähnliches.
Dass man sich aber dann trotzdem,
teamweise siloartig organisiert und sagt, wir machen zwar DevOps im Programm, aber wir haben ein Test-Team.
Wir haben ein Entwicklungsteam, wir haben ein Architektur-Team und wir haben ein Betriebsteam.
Wir haben vielleicht auch noch ein Support-Team, die dann die Support-Fälle aufnehmen und dann an die entsprechenden Entwickler oder Tester oder Architekten auch weiterreichen.
Also so ein Kommunikations- oder Service-Desk-Team.
Ist das dann etwas, was ihr als DevOps ist im Unternehmen angekommen, bewerten würdet?
Oder ist das was, wo ihr sagt, nee, eigentlich ist das noch nicht DevOps?
Also, wenn ich mal meine persönliche Sicht darauf ausbreiten darf.
Ich finde, wenn das im Einzelfall sinnvoll umgesetzt ist, ja, dann ist das auf jeden Fall DevOps.
Ich meine, die wesentlichen Aspekte von DevOps zeichnen sich doch dadurch aus, dass ich diesen Kundenfokus habe.
Dass ich den Produktfokus habe.
Und wenn ich den am besten abbilden kann, zum Beispiel in einem zentralen Service-Desk, dann ist das doch voll okay.
Was wäre denn die Alternative?
Angenommen, ich weiß auch nicht, das ist ein großes Produkt und das wird von 20 Teams gebaut und der arme Nutzer, der ein Problem hat, müsste jetzt wissen, welches von den 20 Teams er anrufen soll, damit dieses Team seine Ende-zu-Ende-Verantwortung wahrnehmen kann.
Das ist doch in niemandes Sinne.
Insofern, solange eine vernünftige Kommunikation möglich ist.
Auch klar ist, dass die Entwicklungsteams nicht die Verantwortung dann irgendwann mal abgeben an ein Support-Team oder sowas.
Dann ist das doch voll okay zu sagen, wir delegieren hier gewisse Kommunikationsaufgaben, zum Beispiel im Sinne des Kunden, im Sinne der Teams.
Aber wir behalten unsere Flexibilität, wir behalten unsere Feedback-Schleifen.
Wir gehen auf die drei Wege von Gene Kim, mit Systemdenken und Rückkopplungsschleifen und kontinuierlichem Lernen.
Dann ist das doch voll okay.
Aus meiner Sicht ist das ein wunderbarer DevOps-Ansatz.
Ja und jetzt kommen wir so ein bisschen in diese zweite These, in die Anti-These, würde ich ja Falkos Frage dazu mal nutzen.
Ich würde Luca erstmal zustimmen, dass ich das auch als DevOps sehen würde, weil ich ja der Meinung bin, DevOps heißt, es gibt keinen eindeutigen DevOps-Zielzustand.
Das würde ja heißen, ich führe DevOps ein und der, der mich kennt aus meinen Trainings, der weiß, dass ich nicht der Freund davon bin, etwas einzuführen.
Das heißt nämlich immer, ich habe einen Zielzustand, einen Endzustand erreicht und da bin ich ja wie gesagt kein Freund von.
Das heißt, ich denke schon, dass es sinnvoll ist, wenn man sich dieser Probleme bewusst ist, die wir haben und die zu DevOps führen und da muss man ein bisschen ausprobieren.
Natürlich kann man Dinge umsetzen, die sozusagen erprobt sind, sonst bräuchte man ja auch Trainer nicht, sonst müsste man über das Thema gar nicht sprechen.
Aber wie gesagt, es gibt nicht die Ideallösung, es gibt vielleicht Zwischenschritte und insofern glaube ich, um auf deine Frage einzugehen Falko,
wir sind schon, das ist schon angekommen, wenn man so etwas tut, aber es ist eben noch nicht quasi am Ende angekommen.
Es ist noch nicht fertig, weil ich eben auch glaube, dass es eben einen fertigen Zustand vielleicht jetzt aktuell noch gar nicht gibt.
Also wenn das für euch okay ist, dann würde ich sagen, dann lasst uns jetzt mal in die Antithese wechseln, nämlich den Punkt, DevOps ist noch nicht angekommen.
Denn das, was ich in den Unternehmen, in den Trainings erlebe und ich denke, das geht euch genauso, ist, da kommt die Frage immer.
Habt ihr mal ein Beispiel dafür oder hast du mal ein Beispiel dafür? Wie machen das denn andere?
Und da kann ich natürlich versuchen, aus Projekten zu erzählen, aber es gibt aus meiner Sicht oder ich habe kein wirklich Beispiel, wo ich sagen würde, das ist jetzt, weiß ich nicht, 90% DevOps oder 100% DevOps.
Es sind überall Erlebnisse aus einem kleineren Umfeld, auch aus einem größeren Umfeld und wie gesagt, wir haben ja nächste Woche, wollte ich gerade sagen, nächsten Monat haben wir ja wieder ein Beispiel,
wo Dinge umgesetzt werden, die aber eben auf bestimmte Rahmenbedingungen abzielen, die bestimmte Voraussetzungen erfüllen und deswegen glaube ich eben, dass es so ein, es fehlt noch ein richtiges, cooles DevOps, was man sozusagen nutzen kann.
Und dann ist die Frage, geht das überhaupt? Also gibt es das überhaupt? Denn DevOps ist ja kein Framework und es ist, insofern gibt es auch keine gefertige Blaupause, das heißt, die Unternehmen und die Verantwortlichen und auch die Teilnehmer in den Trainings,
die suchen aus meiner Sicht händeringend fertige Komplettprodukte, also so können wir das nehmen und so machen wir das, so wie das ja Safe anbietet im anderen Kontext, aber da habe ich eben ein fertiges Konstrukt und auch da erleben wir oder erlebe ich, dass die Unternehmen sagen, ja, wir nutzen Safe, aber wir machen nicht alles von Safe.
Also, lange Rede, kurzer Sinn, ich glaube, dass das, was ich an DevOps gut finde, dass es kein fertiges Framework ist, das ist die Herausforderung für die Unternehmen.
Dass es eben nichts Fertiges gibt, sie müssen eigene Erfahrungen sammeln und das ist natürlich in wirtschaftlich schwierigen Zeiten eine Herausforderung, wenn ich nicht sofort ein tolles Ziel aufzeigen kann.
Da stimme ich dir auch völlig zu, Dirk. Man merkt das ja dann auch häufig, dass DevOps halt doch ein bisschen zu sehr auf die leichte Schulter genommen wird und zwar lustigerweise, obwohl sie es jetzt immerhin schon viel ernsthafter angehen und nicht nur als reine Technologie und Automationsspiel, wie sie sehen.
Ich meine, ungeachtet dessen, dass es ja jetzt in vielen Organisationen auch die Stellenbeschreibung eines DevOps-Ingenieurs gibt, wo ich mich immer frage, was das sein soll, gemessen an der Perspektive von DevOps, die Dirk und Falko und ich beispielsweise vertreten.
Ja, genau.
Du hast DevOps-Ingenieurin gesprochen, also ich kriege auch Anfragen, da sucht ein Unternehmen ein DevOps.
Genau.
Dann frage ich immer.
Wir können auch zwei oder drei DevOps kaufen.
Genau.
Richtig.
Wenn wir einen halben oder ein Dreiviertel DevOps wollen oder 100 Gramm oder so, ich habe mir sogar den Spaß auch mal gemacht, die Antwort zu senden, aber ich habe dann keine Antwort auf meine Antwort bekommen.
Wer weiß, warum.
Ja, also Jonathan Hall von Tiny DevOps, das ist übrigens auch ein sehr hörenswerter Podcast, muss ich sagen, der hat einen ziemlich coolen Kunstgriff.
Wenn er eine Stellenbeschreibung für einen DevOps-Ingenieur liest, dann ersetzt er überall das Wort DevOps mit Zusammenarbeit und dann schaut er, ob die Stellenbeschreibung dann immer noch Sinn macht.
Und wenn ja?
Dann war es eine gute Perspektive auf DevOps.
Wir haben ja noch ein paar Punkte nachher.
Genau.
Aber um mal meinen Gedankengang zu Ende zu kriegen, die ich vor circa einer Minute mal irgendwie angefangen hatte.
Obwohl das Bewusstsein mittlerweile schon gewachsen ist, dass DevOps halt nicht nur eine rein technische Sache ist, glaube ich, unterschätzen immer noch sehr viele Unternehmen das.
Weil wenn man das wirklich ernsthaft…
Wenn man das wirklich ernsthaft betreibt, wenn man diese Agilisierung, diese DevOps-Lichung tatsächlich bis zum Ende führt, dann strahlt das notwendigerweise auf nahezu alle Bereiche des Unternehmens aus.
Wenn ich diesen Kundenfokus wirklich durchhalten will, dann macht das ja nicht irgendwie an den Grenzen der IT-Organisation halt, sondern dann nimmt das höchstens seinen Anfang.
Wenn ich agil Produkte plane, dann muss das zwingend irgendwie einen Einfluss darauf haben, wie ich budgetiere und so weiter und so weiter.
Wie ich mit meinen Zulieferern zusammenarbeite.
Welche Art von Verträgen ich überhaupt abzuschließen in der Lage bin.
Und was man da für einen riesen Fass aufmacht, ich glaube, das ist bei vielen Unternehmen, das ist denen noch nicht so richtig bewusst.
Und das ist dann häufig, glaube ich, auch der Punkt, wo es dann anfängt wehzutun.
Dass dann diese Spannungen entstehen, dass sie sagen, also die IT-Organisation, die ist jetzt ja irgendwie total agilisiert und verdevopselt und alle anderen machen weiter wie bisher und irgendwie klemmt das.
Oder sehe ich das zu negativ oder habt ihr auch diese Beobachtung gemacht?
Doch, ich sehe schon, dass das so…
In der Form immer wieder auftaucht, dass man letztendlich häufig mit der IT anfängt.
Und an den Stellen, wo ich vorhin gesagt habe, so Team-Ebene, man versucht letztendlich Cross-Funktionale oder Feature-Teams aufzusetzen, die den Blick haben, der von Anfang der Entwicklung, von vielleicht auch einer beschriebenen Anforderung, User-Story, Feature, Epic, was auch immer, hin zu einem für den Endkunden nutzbaren Ergebnis.
Ergebnis.
Einem funktional freigegebenen, releasten und funktionierenden Feature geht.
Dass man aber den Punkt auch weiter früher ansetzen muss, dass man überlegen muss, welches Feature welche Priorität haben soll, wie man letztendlich auch verschiedene Umsetzungswege vielleicht priorisiert, dass man vielleicht Dinge kleiner schneidet, dass man experimentiert, dass man im engen Kontakt mit dem Kunden auch Feedback sammelt.
Das ist was, wo halt…
Bei diesem noch nicht angekommenen Aspekt von DevOps noch eine ganze Menge an freien Schritten sind, die in Unternehmen zu gehen sind, wo letztendlich noch Luft für Entwicklung bleibt.
Und das ist letztendlich der Weg, den diese Unternehmen, die angefangen haben, den Weg in Richtung DevOps zu gehen, halt auch gehen müssen.
Das heißt, da kommen ja dann auch diese Aspekte wieder raus.
Diese Erweiterung.
Diese Erweiterung des Akronymes oder des zusammengesetzten DevOps-Worts in Richtung Business bis DevOps oder Einbeziehung von Security, DevSecOps oder ähnliche Bereiche, die letztendlich genau darauf dann immer wieder fokussieren, dass es allein die Entwicklung und der Betrieb halt nicht sein können.
Was halt auch häufig bei DevOps nicht erwähnt wird, dass dazwischen ja irgendwo auch eine Art von Testing stattfindet.
Also eigentlich ist das klassische DevOps ja eigentlich…
Ein DevTestOps, ohne dass es halt irgendjemand erwähnt.
Das heißt, man muss den Wertstrom an sich in den Fokus setzen, in den Blick von dem Kundenwunsch oder dem Kundenbedürfnis im besten Fall noch bis hin zu der Erfüllung genau dessen.
Und dabei kann man natürlich viele Dinge optimieren, zum Beispiel durch Automatisierung, durch Vereinfachung von Prozessen, dass man nach Wertschöpfung analysiert, dass man in die Richtung geht.
Um wirklich auch die Teamorganisation und die Kommunikationsprozesse, die es geben muss, um diesen Entwicklungsprozess abzubilden, entsprechend auch in der Aufbauorganisation wiederzuspiegeln.
Und da hapert es halt bei vielen Unternehmen.
Und da gibt es natürlich dann die Punkte, wo man in die Aktivität gehen muss.
Ja, finde ich interessant.
Also das Thema Wertstrom spricht ja auch genau das an, was eben…
Und das ist halt auch wirklich ein Grund, warum das eben noch nicht angekommen ist, weil sich die Unternehmen eben organisatorisch noch nicht darauf ausrichten können oder wollen.
Das können wir vielleicht nachher nochmal ein bisschen besprechen, weil mir ist noch ein anderer Punkt gerade eingefallen, als du angefangen hast, die Begriffe sozusagen zu sezieren und zusammenzusetzen.
Dev und Ops.
Und in der Anfangsphase deiner Ausführungen habe ich auch gedacht, Mensch, stimmt.
Es ist auch die Frage, woher kommt eine DevOps-Initiative?
Und da erlebe ich natürlich…
Und da erlebe ich zwei unterschiedliche Richtungen.
Also ich habe Kunden, die kommen aus der Dev-Ebene.
Das heißt, die Entwickler sagen, wir möchten jetzt die Ops-Leute mit dazunehmen.
Also wir möchten DevOps machen, aber getrieben aus der Entwicklung.
Und ich sehe Unternehmen, die treiben quasi DevOps oder da kommen DevOps-Initiativen zustande aus dem Ops-Bereich.
Das heißt, der Betrieb sagt, wir möchten agiler werden.
Auch da immer die Frage ist, was bedeutet das für sie?
Und das sehen sie unter DevOps.
Denn einen interessanten Punkt…
Und der wird meines Erachtens gar nicht so vielen Leuten bekannt.
Der Begriff DevOps und die Initiative zu DevOps kommt eigentlich aus dem Ops-Bereich.
Also es ist nicht so, dass die Dev-Leute irgendwann mal gesagt haben vor 10, 15 Jahren, lass uns mal ein bisschen Ops dazunehmen, sondern der Begriff DevOps, auch die DevOps Days, sind ja eigentlich entstanden durch Menschen, die aus der Ops-Welt gekommen sind und die Ops-Welt anders gestalten wollten, indem sie gesagt haben, lass uns doch mal ein bisschen Agilität mit dazunehmen.
Also insofern, auch da wieder mal kurz gesagt, es ist deswegen noch nicht angekommen, weil es immer aus meiner Sicht eine Richtung gibt.
Also ein Bereich von Dev oder Ops versucht, den anderen Bereich zu integrieren, versucht da zusammenzukommen.
Und das hat dann manchmal auch vielleicht noch ein kleines Geschmäckle, wenn die anderen damit kommen und man das deswegen, auch wenn es vielleicht gut wäre, halt so ein bisschen skeptisch betrachtet.
Ja, das ist…
Da habt ihr echt ganz viele wahre Sachen.
Und aus meiner Sicht, das ist das Tolle, aber auch das Bedrohliche irgendwie an DevOps, dadurch, dass es so viele verschiedene Aspekte zugleich berührt, die technische Automatisierungsebene über die Prozess- und Organisationsebene bis hin zur Kultur, hat das eine unglaubliche Wirkmacht.
Wir reden hier nicht bloß von 10% Verbesserung oder sowas, sondern wir reden im Zweifelsfall wirklich von Vervielfachungen, wenn ich mir den State-of-Devops-Report anschaue.
Aber das zeigt halt auch, wie tiefgreifend die Umwälzungen sind und wie bedrohlich sich das anfühlen mag, wenn man da unterwegs ist.
Ja, und dieses Bedrohliche, ich habe ja eben schon gesagt, es wäre ja schön, wenn wir ein fertiges Modell hätten, also so von wegen DevOps out of the box.
Wir drei können das nicht bieten, ich glaube, das wäre etwas zu viel verlangt, dann würden wir diesen Podcast nicht mehr machen wahrscheinlich, wenn wir da eine passende Antwort für hätten.
Aber auch, wenn ich mal so rumschaue beim Kunden und bei den Marktkunden.
Marktbegleiter, wie man es so schön nennt, dass ich da auch bei vielen Beratungs- und Systemintegrationsunternehmen auch da eigentlich sehr wenig sehe.
Das heißt, selbst die großen Beratungshäuser, selbst große Systemintegratoren, die da dafür prädestiniert sind, über DevOps vielleicht mehr zu machen, selbst die sind eigentlich nur in zwei Ecken unterwegs.
Entweder bieten sie Beratung an zu agilen Methoden, das heißt, sie helfen bei Einführung von Scrum oder Kanban, unterstützen die Unternehmen, unterstützen die Teams,
aber eben eher auf der Team-Ebene und nicht auf einer Unternehmensebene.
Oder sie kommen eben mit Tools daher, das heißt, sie zeigen auf, wie man eine tolle CI-CD-Pipeline gestalten kann und sagen dann, alles klar, wenn du das Tool hier eingeführt hast und die Teams agil sind, dann machst du DevOps.
Also auch da wieder kurz gesagt, glaube ich oder bemerke ich, dass eben am Markt auch große Beratungsfirmen, große Systemintegrationsunternehmen es nicht schaffen,
ein ganzes Konstrukt anzubieten.
Oder nur mit einzelnen Elementen kommen und dadurch auch die Unternehmen natürlich nicht animieren, da wirklich konsequent weiterzugehen.
Ja, aber das erscheint mir auch irgendwie logisch, weil letzten Endes, wenn man es zu Ende denkt, dann geht es halt ganz wesentlich um Kommunikation zwischen Leuten, die da stattfinden muss.
Und die Kommunikation muss sich danach richten, was für Bedürfnisse diese Leute haben.
Und das wiederum hängt natürlich ganz stark davon ab, was die für Produkte bauen, welche Beschaffenheit die Produkte haben, welche Struktur die Produkte haben.
Und somit natürlich auch, welche Wünsche die Kunden an diese Produkte richten.
Das heißt, es kann irgendwie, glaube ich, kein Schema F geben.
Das ist, ich glaube, das ist eine gute Nachricht, weil am Ende des Tages geht es dann da wieder um Menschen.
Und das ist etwas übrigens, was nicht nur ich mir irgendwie ausgedacht habe, sondern ich unterhalte mich sehr viel mit Technologie-Managern, CTOs, solchen Leuten.
Und interessanterweise haben die alle einen entsprechenden…
Werdegang, sage ich mal, von ihrer Philosophie im Laufe der Zeit gemacht, dass sie gesagt haben, naja, ich dachte immer, bei Technologie geht es um Technologie, bis ich irgendwann darauf gekommen bin, bei Technologie geht es ja um Leute.
Und die Art und Weisen, wie Leute zusammenarbeiten, ist wahrscheinlich so verschieden wie die Leute selber, ne?
Vielleicht als kleine Ergänzung noch, auch weil wir ja gerade dabei sind oder ich dabei auch gerade war, wo sehe ich auch Lücken?
Wo haben wir keine Antworten?
Also wir sehe ich jetzt mal die Berater, die Beraterzunft.
Die Trainerzunft.
Wir haben ja auch, wir reden darüber, was DevOps eine neue Art der Zusammenarbeit ist oder eine andere Art.
Und ich sage mal, so richtig gute Zusammenarbeitsmodelle in der Praxis können wir ja eigentlich auch gar nicht bieten.
Also wir können natürlich sagen, ja, wenn man Teams zusammenstellt, dass wir nicht die Menschen bereitstellen, sondern dass wir das Wissen transferieren müssen.
Alles okay, also da gibt es schon ein paar Antworten.
Aber ich habe auch an vielen Stellen in den Trainings…
In den Trainingsfragen, die ich einfach nicht wirklich konkret beantworten kann, vielleicht liegt es ja an mir, aber da darf sich gerne jemand melden, der dazu Antworten hat.
Aber zum Beispiel können wir, oder sehe ich hier in der Praxis, dass es eben schwierig ist, dass Auftraggeber DevOps gar nicht beauftragen können.
Also die Konstrukte in der Auftragsverteilung oder in der Auftragsvergabe, in der Auftragskontrolle, in der Durchführungskontrolle, das sind alles Dinge, die noch nicht so weit verbreitet sind.
Das heißt, Auftraggeber können meiner Meinung nach heute DevOps nur sehr, sehr schwer bei Leistungserbringern beauftragen.
Da kommt immer die Frage, wie wird das abgerechnet mit Stundenbasis und so weiter.
Also wahnsinnig viele praktische Herausforderungen.
Wenn ich eben gesagt habe, wie Stundenbasis abrechnen, also wie wird denn DevOps abgerechnet?
Und da sehe ich auf der anderen Seite ja auch den Punkt, wir haben ja auch Kunden, die aus der Softwareentwicklung kommen.
Also klassische Systementwicklung.
Also Entwicklungshäuser, die eben auch vermehrt, ich sag mal, dahin gebracht werden von ihren Kunden, das im Sinne von DevOps zu machen.
Also dass die Verantwortung für ein System nicht darin liegt, eine Diskette oder CD zu erstellen und die zum Download bereitzustellen,
sondern die Systemhäuser werden gezwungen, werden dahin gebracht, wirklich ein System as a Service bereitzustellen.
Auch die müssen ja über DevOps reden. Auch da ist es schwierig, Abrechnungsmodelle zu finden auf der Anbieterseite.
Wie kriege ich das hin, dauerhaft Teams zusammenzusetzen?
Wie kriege ich es hin, dauerhaft Teams zusammenzusetzen, die jetzt einfach gar nicht da sind?
Also es ist keine Seltenheit, dass da Mitarbeiter sind in den DevOps-Trainings, die sind in vier, fünf Projekten.
Wie soll ich denn einem Unternehmen oder wie soll ein Unternehmen es schaffen, diese Projektstruktur mit Experten, die immer in irgendwelchen Projekten arbeiten, in so eine dauerhafte Teamstruktur zu bekommen?
Also es gibt Ideen dazu, aber ich sehe noch keine wirklich heilsbringende Lösung, die in der Praxis auch funktioniert und die man einfach und erfolgreich implementieren oder umsetzen kann.
Ja, das ist eben die große Schwierigkeit, nicht wahr?
Dass es letzten Endes um Kommunikation zwischen den verschiedenen Mitarbeitern geht, innerhalb des Teams, zwischen Teams und so fort.
Und die muss sich ja auch wandeln können.
Also selbst wenn ich mir jetzt eine Teamstruktur…
Überlege und die sei jetzt perfekt, weil ich so unglaublich schlau bin, dann ist die in zwei Jahren vielleicht nicht mehr so ganz stimmig, sondern da bräuchte ich was anderes.
Also auch in diesem Sinne, DevOps ist eigentlich kein Endzustand, sondern DevOps ist ein Prozess des Hinarbeitens auf eine Struktur, die sich im Jetzt als hilfreich und günstig herausstellt, aber in der Zukunft ganz bestimmt nicht mehr ist.
Weil die Welt bleibt halt nicht stehen und Unternehmen bleiben auch nicht stehen.
Das ist übrigens ein anderer Punkt.
Wo ich gerade darauf komme, das ist ein ganz beliebter Fehler, finde ich, bei DevOps-Einführungen, dass man nur in Vorwärtsrichtung denkt.
Dass man denkt, ich baue jetzt…
Ich meine, selbst der Begriff Wertstrom drückt das ja schon aus.
Ich hätte viel lieber eine Wertschleife.
Ich würde viel lieber nicht nur in Vorwärtsrichtung, in Stromabrichtung denken, sondern auch dann die entsprechenden Rückkupplungen haben.
Und das ist etwas, was man, wie ich finde, ganz gezielt und ganz bewusst…
…von Anfang an einbinden muss.
Das wäre übrigens eine der Antworten, die man sozusagen allgemeingültig geben kann, Dirk, dass man sagt, wie mache ich denn ein DevOps?
Zum Beispiel, indem ich Rückkopplungsschleifen baue.
Und was das dann konkret heißt, hängt halt vom Einzelfall ab.
Da muss ich dann wieder in meinen Berater-Kommt-drauf-an ausweichen.
Ja, klar. Aber dann komme ich als Kunde und sage, diese Rückkopplung, die bezahle ich dir nicht.
Ich bezahle nur, dass da was rauskommt, was ich anfassen kann.
Ja, aber die Rückkopplung macht das, was rauskommt.
Ja, und dass das stabil rauskommt.
Und dass das, was rauskommt, auch wirklich anfassbar ist.
Und nicht nur die klassischen, zum Beispiel PowerPoints, die man dann sich schön angucken, aber nicht wirklich anfassen kann.
Also kein Produkt, keine Funktionalität, kein lebendiges, sich weiterentwickelndes System, das kontinuierlich neuen Wert für die Anwender schöpft.
Es ist mir auch ganz wichtig zu betonen, dass wir jetzt nicht über irgendwas reden, was sich irgendwie in den letzten zehn Jahren entwickelt hat.
Zum Beispiel Lockheed Skunkworks, die Forschungsabteilung des Flugzeugherstellers Lockheed.
Der Chef von denen hat gesagt, um Himmels Willen darf meine ganze Organisation nicht mehr als 150 Leute umfassen.
Einschließlich Putzfrau und Sekretärin.
Weil ich brauche es, dass wenn der Konstrukteur, der eine Turbine konstruiert, seinen Bleistift schmeißt, dann muss er den Dreher am Hirn treffen, der sie abdreht.
Wenn ich das nicht mehr habe, kann ich nicht mehr die Arbeit machen, die ich mache.
Und die haben Unglaubliches geleistet.
Vollkommen richtig.
Und jetzt spiele ich auch bei der Spielchen weiter, was wir von eben hatten.
Weil das, was du gerade sagst, Luca, da war der Chef, der stand dahinter.
Das Business, die Geldgeber standen dahinter.
Und ich sage jetzt mal so ein bisschen provozierend, ich will diese Rückkopplungsschleife nicht bezahlen.
Also ich bezahle euch für das, was ihr mir liefert als Kunde.
Dafür kriegt ihr eh schon viel zu viel Geld.
Und ich möchte, dass ihr, wenn ihr euch verbessert, das ist nicht mein Ding, das ist euer Ding.
Und das will ich auch nicht bezahlen.
So, jetzt wisst ihr es.
Du?
Du willst nicht, dass wir besser werden, Kunde.
Das können wir machen.
Dann kriegst du halt denselben Mist wie immer.
Kein Problem.
Ja.
Ey, ich will, dass ihr besser werdet.
Aber ich will das Ergebnis bezahlen.
Also ich will dafür bezahlen, dass ihr mir bessere Ergebnisse liefert.
Aber dieses ganze Verbessern und Zusammenarbeit und Rückkopplung und so weiter,
das könnt ihr mal schön ohne mich machen.
Kalkuliert mir einfach mal was Neues.
Ja, ist ja okay.
Dann kommt dann halt ein Pay-Per-Use-System bei raus.
Und du kannst dann kontinuieren.
Natürlich für den Wert, den du mit der Lösung, die entwickelt wird, schöpfst.
Einen gewissen Anteil kontinuierlich abgeben.
So ähnlich ist es ja an vielen Stellen geworden, dass man eben, keine Ahnung,
nicht mehr die CD oder die Kassette oder die Schallplatte als physisches Produkt kauft,
wo man eigentlich dann dauerhaft etwas von hat,
sondern dass man häufig auf den Service übergeht.
Zum Beispiel irgendein Streaming oder…
Oder anderen Anbieter, den man regelmäßig, dann halt in kleineren Paketen,
nicht in einem Schwung, großes Produkt, die CD oder die CD-Sammlung dann halt kauft und bezahlen lässt,
sondern halt die Nutzung.
Und das ist ja für mich auch völlig okay, weil im besten Fall hat man ein Produkt,
das mehrere Kunden, vielleicht sogar viele oder ein großer Markt nutzt,
wo dann jeder, der für diese Nutzung, an dieser Nutzung profitiert,
dann auch seinen Anteil kontinuierlich leistet.
So hat Spotify oder auch ein Adobe oder viele andere einen guten Weg gefunden,
um diese kontinuierliche Entwicklung und Weiterentwicklung, Verbesserung auch zu finanzieren.
So kommen wir dann halt auch in die Richtung Abrechnungsmodelle, Software as a Service,
die ganzen Cloud-Anbieter, die dann in Richtung Infrastructure oder andere Dinge as a Service,
dann auch ihre Abrechnungsmodelle gefunden haben.
Und an der Stelle gibt es dann DevOps.
Und an den Unternehmen, die das nicht denken, die so weit halt nicht sind,
die halt sagen, okay, ich möchte halt die Schallplatte haben,
dann müssen sie halt gucken, dass sie die Schallplatte bekommen.
Aber die verändert sich auch über die Zeit nicht.
Die wird dann halt nicht besser.
Das ist dann halt die Schallplatte mit der Musik von der Band, die dort halt draufgepresst wurde.
Naja, ich sehe es schon.
Wahrscheinlich müssen wir uns nochmal…
Wir müssen uns nochmal zusammensetzen und unsere Unterlagen ein bisschen aktualisieren,
dass ich auch was zu Abrechnungsmodellen sagen kann, ne, Falco?
Finde ich auch gern.
Okay, gut.
Gut, ein Punkt finde ich noch wichtig, den ich mir noch hier so vermerkt habe,
nämlich der Punkt, wie praxisrelevant das ist, was DevOps quasi beschreibt.
Und auch da, wenn ich mir schaue, die Idee von DevOps ist aus meiner Sicht,
dass wir quasi ein Produkt, ein Produktteam haben,
wir haben eine Produktorganisation, wir haben vielleicht wirklich erstmal ein kleines Team,
ein kleines Produkt, wir haben ein Startup.
Das beginnt klein und das wird dann organisch wachsen.
Also wir fangen ja nicht an, bei DevOps zu weiter Grundidee erstmal,
gleich so in einem Riesenkonstrukt von 100, 200 oder 400 Leuten zu arbeiten.
Das heißt also, der Grundgedanke von DevOps, auch so wie wir das erklären
und dann den Leuten näher bringen, passt eigentlich nicht zur Realität,
weil dort wir ja gerade durch die vielen Abhängigkeiten, die wir heute schon besprochen haben,
wir häufig darüber reden, dass wir größere Bereiche haben,
dass wir größere Produkte haben, die vielleicht im schlimmsten Fall auch total viele technische Abhängigkeiten haben,
die wir nicht einfach so trennen können.
Auch das haben wir schon oftmals behandelt, jetzt sagen wir mal zwischen Architektur und Organisation.
Also der Grundgedanke von DevOps passt vielleicht nicht immer sehr gut für die Unternehmen,
weil die in großen Kategorien denken müssen oder nur denken können.
Ja, also vielleicht hast du da auch etwas sehr Schönes gesagt,
gerade Dirk, insofern, als wir jetzt irgendwie auch ein sehr bedrohliches Bild,
ich komme nicht weg davon, DevOps kann sich auch sehr bedrohlich anhören,
dass wir ein sehr bedrohliches Bild gezeichnet haben, oh, es ist so schwer und es ist so viel
und man muss so viel und man muss und man darf und man, ne.
Aber andererseits ist es ja auch total okay, erstmal kleine Brötchen zu backen
und sich seine Erfahrungen zu sammeln und sich seine Rückkopplungsschleifen zu bauen, nicht wahr?
Und dann halt Schritt für Schritt, ihr wisst ja, wie ist man ein Elefanten, Gabel für Gabel,
sich so langsam aber sicher in seinen DevOps reinzuarbeiten.
Ich glaube, das ist auch das Wichtige, dass man da ein bisschen fair mit sich selber ist
und sagt, das ist ein weiter Weg und ich muss mich jetzt nicht irgendwie fertig machen
und mich grämen, dass ich nicht auf der Stelle die ganze Strecke schaffe,
nicht auf der Stelle einen Marathon-Weltrekord schaffe,
sondern ich kann ja erstmal mit einem 10-Kilometer-Lauf anfangen oder sogar nur mit einem 5-Kilometer-Lauf
oder überhaupt erstmal aus der Tür rausgehen und der Rest ergibt sich dann unterwegs.
Mhm.
Und dann, wenn du ein Jahr später mal schaust, wie weit du gekommen bist,
dann wirst du nämlich ziemlich erstaunt sein.
Dann sind wir nämlich bei der kontinuierlichen Verbesserung,
bei den Rückkopplungsschleifen, beim kontinuierlichen Lernen.
Und dann kommen wir halt von dem, was vielleicht bei Unternehmen schon angekommen ist.
Ich nehme mal so ein bisschen Gene Kim, die drei Wege gerade im Kopf.
An vielen Stellen ist der Gedanke des ersten Wegs, eine kontinuierliche Entwicklungspipeline
von Anfang bis Ende vielleicht schon angekommen, dass dann halt der nächste Schritt,
die Feedbackschleifen, das kontinuierliche Lernen.
Und das Ganze halt ins Unternehmen hereinzutragen, auch in Bereiche,
die eben größer als 150 Personen sein können, dass man an einer Ecke etwas lernt,
wovon man an der anderen Ecke profitieren kann, wäre natürlich dann der Punkt,
wo ich sage, okay, da ist halt noch Potenzial in vielen Unternehmen.
Genau. Wir haben uns ja auch in unseren Notizen aufgeschrieben als Frage,
was müssen Unternehmen noch tun? Wie geht es 2022 weiter? Wann ist DevOps fertig?
Und ich glaube, Falco hat gerade auf all diese Fragen die Antwort gegeben, oder?
Ich bin auch erfreut gewesen, dass wir das doch nicht ganz so düster sehen müssen.
Und es kommt doch ein ganz toller Spruch, auch der längste Weg beginnt mit dem ersten Schritt.
Der kommt nicht von mir, aber ich weiß die Quelle jetzt gerade nicht.
Das war bestimmt Konfuzius oder so.
Wahrscheinlich, klingt so.
Genau.
Genau.
Nee, aber ich glaube, Falco, du hast da wirklich die Antwort gegeben.
Genau.
Falco, du hast da wirklich den Nagel auf den Kopf getroffen.
Den ersten Weg, eine kontinuierliche Pipeline, das ist notwendig, aber es ist noch nicht hinreichend.
Sondern das Zweite ist dann, Rückkopplungsschreifen zu bauen.
Das Dritte ist, sich eine Kultur des kontinuierlichen Lernens zu verordnen.
Und dazu gehört natürlich auch vielleicht zuerst mal, dass man lernt, wie man eigentlich lernt.
Und dann ergibt es sich von selber.
Das ist vielleicht der Unterschied zwischen Unternehmen,
die erfolgreich mit DevOps arbeiten und solchen, die es nicht tun,
dass sie nicht nur den ersten, sondern dass sie alle drei Wege irgendwie zu ihrem Recht kommen lassen.
Naja, also insofern klingt ja schon fast wie so eine Art Schlusswort.
Ich bin zumindest beruhigt, dass wir nicht alle so schwarz gemalt haben,
dass wir auf ein paar Dinge hingewiesen haben und dass wir vielleicht wirklich eine Botschaft ebenso gemeinsam hier erarbeitet haben.
Die einfach heißt, anfangen, natürlich konzentriert und fokussiert anfangen
und auch nicht einfach sowas, irgendwas machen, sondern auch bewusst anfangen.
Aber das Wichtige ist einfach anzufangen und den ersten Schritt zu tun.
Oder zumindest den nächsten Schritt für alle die, die schon unterwegs sind.
Das heißt, sich zu überlegen, wo stehen wir gerade, sich vielleicht Hilfe zu suchen an den Stellen,
an denen man von alleine im Unternehmen nicht weiterkommt,
wo dann die Beratungsunternehmen oder auch die Toolhersteller vielleicht hilfreiche Ansprechpartner sind.
Und ansonsten reflektieren, selbst zu schauen, an welchen Stellen hakt es dann am ehesten?
Und dann für die Probleme Lösungen zu finden.
In kleinen Schritten voranzugehen und sich dem Ziel, dem Weg der kontinuierlichen Verbesserung zu öffnen
und auf dem weiterzugehen.
Regelmäßig zu reflektieren, regelmäßig zum Beispiel eine Wertstromanalyse zu machen,
zu schauen, welche Prozessschritte denn wirklich der Wertschöpfung einen Beitrag leisten,
an welchen Stellen es regelmäßig Nacharbeiten gibt,
wo man halt vielleicht mit Automatisierung oder mit anderen Hilfsmitteln Verbesserungen erreichen kann.
Und dann?
Eben nicht davon auszugehen, dass DevOps oder das Produkt oder das alles auf einmal fertig sein kann,
sondern dass das halt ein Weg ist, der nicht unbedingt an einem Ziel endet,
sondern der vielleicht auch das Ziel ist.
Genau, DevOps ist kein Ziel, DevOps ist ein Prozess.
Ja, und wie du auch sagtest, aus Fehlern auch lernen.
Da muss man bereit sein, Fehler zu machen.
Und sie am besten dann wirklich auch nur einmal zu machen,
um daraus eben Veränderungen abzuleiten.
Also ich glaube, Falco, das war ein schönes fachliches Schlusswort aus meiner Sicht.
Also ich glaube, wir können jetzt hier die Aufnahme beenden,
können allen weiterhin ein frohes neues Jahr wünschen.
Und ich habe schon zwei, drei Mal angedeutet,
wir haben im Februar vielleicht wirklich dann auch einen richtig tollen Praxisbericht,
der uns auch vielleicht zeigt, dass in dem Unternehmen, das wir im Februar haben,
dass da DevOps wirklich so schon sehr gut angekommen ist.
Bin mal gespannt, was wir dann mit den Kollegen dort besprechen werden.
Also ich danke euch beiden für das schöne Gespräch
und wir müssen noch einen Termin machen,
um die Schulungsunterlagen mit den Abrechnungsmodellen zu ergänzen.
Wunderbar, machen wir das.
Vielen Dank, hat mich auch gefreut.
Genau, das war ein toller Einklang, glaube ich, für das Jahr 2022.
Ich bin gespannt, was uns noch erwartet.
Ciao.
Tschüss.

Folge 54: SAFe und DevOps

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Zu Gast haben wir heute George Romanenko, einen Experten für SAFe. Mit ihm überlegen wir, inwieweit DevOps und SAFe das selbe sind oder nicht, ob das Eine das Andere benötigt, und ähnliche Fragen um die Beziehung zwischen den beiden.

In dieser Podcast-Episode diskutieren die Gastgeber mit dem Agile Coach und SAFe-Experten George Ramanenko über die Integration von DevOps in das Scaled Agile Framework (SAFe) und dessen Rolle in großen Unternehmen. George betont, dass DevOps mehr als nur ein technisches Tool ist und vielmehr einen Kulturwandel darstellt, der auf Zusammenarbeit und kontinuierlicher Verbesserung basiert. Die Diskussion umfasst die Unterschiede und Gemeinsamkeiten zwischen SAFe und anderen agilen Frameworks, die Bedeutung von DevOps innerhalb von SAFe, und die Herausforderungen bei der Implementierung in großen, traditionell organisierten Unternehmen. Es wird auch auf die Wichtigkeit von Kundenorientierung und die kontinuierliche Lieferung von Mehrwert hingewiesen.

Inhalt

  • Einführung und Vorstellung von George Ramanenko
  • Definition und Bedeutung von DevOps
  • Integration von DevOps in das Scaled Agile Framework (SAFe)
  • Unterschiede und Gemeinsamkeiten zwischen SAFe und anderen agilen Frameworks
  • Die Rolle von DevOps innerhalb von SAFe
  • Herausforderungen bei der Implementierung von SAFe und DevOps in großen Unternehmen
  • Bedeutung von Kundenorientierung und kontinuierlicher Wertlieferung
  • Diskussion über verschiedene Skalierungsframeworks und Modelle
  • CALMS vs. CALM im Kontext von SAFe und DevOps
  • Abschlussdiskussion und Empfehlungen für die Implementierung von SAFe und DevOps

Shownotes:

George’s LinkedIn: https://www.linkedin.com/in/george-romanenko-mba-1799402b/

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps. Auf die Ohren und ins Hirn.
Ein Podcast rund um DevOps.
Von Luca Ingiagni und Dirk Söllner.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingiagni, Dirk Söllner und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Heute wollen wir sprechen über das Thema DevOps in skalierter Umgebung.
Dazu haben wir als Gast heute George Ramanenko bei uns.
George ist Agile Coach, Safe Program Consultant, Safe Trainer mit langjähriger internationaler Erfahrung
in skaliertem Umfeld und führt selbst als Release Train Engineer einen agilen Release Train.
Hallo George, willkommen bei uns.
Hallo Luca.
Erstmal vielen Dank für die Einladung und ich freue mich sehr, heute dabei sein zu dürfen.
Ja, ganz toll, dass das geklappt hat.
Wir haben ja immer so eine kleine Startfrage für alle unsere Gäste im Podcast,
nämlich nachdem sich niemand zu einigen können scheint, was die Definition von DevOps ist,
fragen wir einfach jeden Einzelnen nach seiner Definition von DevOps.
Insofern George, was ist für dich DevOps?
Für mich ist DevOps ein Kulturwandel.
Manche sagen, es geht nur um Tools zur Verbesserung.
Es geht um Software Delivery, Software Maintenance oder Performance, aber für mich bedeutet es eigentlich viel, viel mehr.
Es entsteht aus der veränderten Denkweise einer Kultur, der gemeinsamen Verantwortung,
dass Entwicklung und Betrieb zusammenarbeiten, um unseren Kunden kontinuierlich Business Values liefern zu können.
Wunderbar, dankeschön.
Und heute wollen wir, wie ja schon angekündigt, über Safe sprechen und vor allen Dingen Safe,
ich sage jetzt mal in seinem Zusammenhang,
mit DevOps, aber bevor wir da mitten reinspringen, ist es vielleicht angebracht, wenn wir noch mal kurz erklären,
was ist denn Safe eigentlich gleich nochmal?
Ja, ich versuche es sehr kurz, weil normalerweise dauert ein Safe-Training irgendwie drei Tage.
Ich glaube, so viel Zeit haben Sie nicht.
Das CAD-Ager-Framework oder kurz Safe ist eine frei verfügbare Wissendatenbank
mit bewährten, integrierten Prinzipien und Praktiken für Lean-Ager und,
was uns heute besonders interessant ist, DevOps, die Unternehmen nutzen können,
um ihren Kunden in kürzester, nachhaltiger Vorlaufzeit einen fortwärtigen Mehrwert zu bieten.
Safe wurde 2011, also noch gar nicht so alt, von Dean Levenwell geschaffen.
Es hat erkannt, dass Scrum, eine weitere äußerst populäre Struktur aus dem Bereich des agiles Denkens,
mit Anstrengungen verbunden war.
Also die Anstrengungen kommen meistens bei den Kunden, aber die Anstrengungen kommen meistens bei den Kunden.
Also die Anstrengungen kommen meistens bei den Kunden, aber die Anstrengungen kommen meistens bei den Kunden.
In großen Entwicklungsunternehmen mit mehr als ein paar hundert, zweihundert,
ich sage ehrlich auch mit hundert Mitarbeitern, zum Tragen.
Scrum ist gemacht für kleine agile Teams.
Und wir reden halt im Scrum von Teams bis elf Teilnehmer.
Und in großen Unternehmen wäre es nicht möglich, ein cross-funktionales Produkt in so ein kleines Team zu liefern.
In großen Unternehmen gäbe es schon bald Dutzende solcher Scrum Teams.
Diese Teams brauchen eine begreifende Struktur, dass sich sonst niemand merken kann, wie gerade woran arbeitet.
SAFe bietet eine solche Struktur.
Übrigens, das ist gleichzeitig auch das, was viele an SAFe kritisieren.
Es wäre nicht sehr agile, Teams in eine große Struktur anzuwenden.
Aber in der Praxis stellen wir jedoch fest, dass diese Struktur, dass es genau was notwendig ist, um Chaos zu vermeiden.
Aber in der Praxis stellen wir jedoch fest, dass diese Struktur, dass es genau was notwendig ist, um Chaos zu vermeiden.
Ähm, SAFe fordert auch die Abstimmung.
Ähm, SAFe fordert auch die Abstimmung.
Zusammenarbeit und Ausführung über zahlreiche agile Teams hinweg.
Das hören wir immer so, ähnliche Begriffe schon auch mit dem DevOps.
Im Mittelpunkt stehen dabei drei Themenbereiche.
Agile Softwareentwicklung, Lean Product Entwicklung und Systemdenkweise.
Wenn Unternehmen wachsen, liefert SAFe einen strukturierten Ansatz zur Skalierung von Agile.
Es gibt vier SAFe Konfigurationen.
för verschiedene Skalierungsebenen.
Essential SAFe.
Da sagen wir halt, das passt sehr gut für das Unternehmen.
Oder für das Team bis zu 120, 130 Mitarbeiter.
Large Solution, wo können halt schon mehrere Agile Students arbeiten.
Portfolio SAFe und FaoSAFe.
Ich könnte natürlich noch lange von SAFe erzählen, wie gesagt, aber ich fürchte,
dann haben wir zu wenig Zeit für die andere Frage.
habe simplesmente zu wenig Zeit für die andere Frage.
Vielleicht noch einen Satz.
Vielleicht noch einen Satz.
Ähm, banner av Fort Guers.
SAFE ist tatsächlich der beliebteste Einsatz zum Skalierung Agile Marketing.
Der beliebteste oder der beste?
Der beste ist natürlich auch die Geschmackssache, aber wenn wir prüfen tatsächlich auf dem Markt,
wie viele verwenden zum Beispiel LESS oder SAFE, dann sehen wir, das ist der beliebteste.
Also ich bin ein großer Fan von SAFE.
Und sonst bin ich ja auch die SAFE-Coach und ich glaube, das ist der beste Einsatz zum Skalieren.
Aber wie gesagt, das ist meine persönliche Meinung, aber die Fakten bestätigen einfach diese Äußerung.
Hast du schon Erfahrungen mit anderen Skalierungsframeworks im realen Leben gemacht?
Ja, ich habe auch LESS versucht. Wir haben auch Spotify Modell, sagen wir so, versucht.
Aber auch Spotify selbst sagt ja,
das Spotify Modell funktioniert nur bei Spotify.
Und wir haben es versucht.
Ich glaube, mit SAFE haben wir viel bessere Ergebnisse geschafft.
Nichtsdestotrotz muss man auch sagen, auf Team-Ebene,
alle diese Modelle bieten mehr oder weniger die gleichen Methoden.
Wenn wir aber darüber hinausgehen,
dann wäre SAFE für mich, in meinen Augen, die beste.
By the way, nur SAFE so offen spricht von DevOps.
DevOps ist quasi Bestandteil.
Ja, SAFE.
SAFE spricht von DevOps, sagst du.
Die Frage ist natürlich, wie siehst du das Zusammenspiel zwischen DevOps und SAFE?
Was sind die Zusammenhänge? Was sind die Unterschiede?
Ja, es gibt natürlich auch die Unterschiede, aber lass uns erstmal mit Zusammenhang reden.
DevOps ist Teil der Agile Product Delivery Kompetenz in SAFE.
Die Unternehmen, die Scale Agile Framework implementieren, implementieren DevOps,
um organisatorische Silos aufzubrechen, um ein Continuous Delivery Pipeline zu entwickeln.
Eine leistungsstarke Innovationsmaschine,
die marktführende Lösungen mit der Geschwindigkeit bereitstellen kann.
Was jedes Prinzip von SAFE, es gibt ja 10,
aber von Prinzip Nummer 1, wirtschaftliche Sichtweise,
bis zum Prinzip Nummer 10, Value System Organization, gilt für DevOps.
Weil auch in DevOps reden von Kundenorientierung, von Zusammenarbeit, von Risikotoleranz.
Bei DevOps-Kulturen belohnen Risikobereitschaft,
kontinuierliches Lernen und unermüdliche Verbesserung,
von Wissen Austausch, also alles das,
um diese Kunden innerhalb von SAFE und DevOps zu finden.
Es gibt aber auch kleine Unterschiede.
Und zwar, in DevOps, wir reden von CALMS Framework.
Und bei CALMS meinen wir Culture, Automation, Lean, Measurement und Sharing.
SAFE teilt diese Überzeugungen, aber mit kleinen Modifikationen.
Laut SAFE,
Sharing, also Teilen, ist ein natürlicher Bestand der Kultur.
Wenn wir reden um offene Kultur,
dann Sharing, ob es unsere Erfolge oder Responsibilities,
Verantwortung sind, das ist tatsächlich Teil der Kultur.
Dafür präsentiert aber SAFE ein neues Element, Recovery, Widerstehen.
Also Unternehmen sollen in der Lage sein, sofort einen Rollback durchzuführen,
wenn es notwendig ist.
Also in SAFE reden wir von CALM Culture,
Automation, Lean, Measurement, also bis jetzt ist es das Gleiche,
aber dann um Recovery.
CALMS und CALM, die beiden Modelle, die ich gerade erwähnt habe,
von DevOps und SAFE DevOps, beide decken die gleiche Idee ab.
Meiner Meinung nach könnte der Unterschied zwischen CALMS und CALM
eine Frage der Fokus sein.
Vielleicht lag der anfangliche Fokus von CALMS darauf,
die Bedeutung von Knowledge Transfer,
beziehungsweise Wissenaustausch zu betonen.
Während CALM die Notwendigkeit betont,
eine fehlgeschlagene Änderung rückgängig zu machen.
So oder so und in dem Stich sind CALMS und CALM vielleicht nicht ganz gleich,
aber sie sind definitiv gleichwertig.
Und vielleicht noch eine Kleinigkeit,
in SAFE bedeutet DevOps eigentlich DevSecOps.
Wir schützen unsere Kunden, Mitarbeiter und unser Unternehmen.
Ja, das ist immer das Übliche.
Eigentlich müsste man DevOps dann Dev, Test, Sec, Spec,
was weiß ich noch, alles Ops nennen.
Und genauso ist es auch mit CALMS versus CALM.
Ich könnte mir auch noch eine ganze Menge andere Buchstaben überlegen,
die ich da ganz gerne mit reinhaben möchte,
aber auf irgendwas muss man sich halt beschränken.
Ja, auch in SAFE sagen wir DevOps.
Meinen wir natürlich auch Security.
Aber ich glaube, heute Tage, wenn man von DevOps auch allgemein spricht,
wird Security natürlich auch dabei sein.
Genau, dass es auch dabei ist, denke ich, sind wir alle der Meinung.
Ich finde aus den ein oder anderen SAFE Schulungen heraus,
die Sicht auf DevOps, dass sie halt den gesamten Wertstrom abbilden,
von der Anforderungserhebung bis hin in den Betrieb.
Und da gehört natürlich nicht nur Security
neben Entwicklung und Operations dazu,
sondern halt der gesamte,
der gesamte Prozessfluss.
Insofern, ja, stimme ich da mit dir überein,
dass Security auf jeden Fall dazu gehört.
Ja, definitiv.
Also überhaupt in SAFE, wir reden von Value Streams.
Ja, quasi von allen, die beteiligt sind im Prozess,
um diese Value zu liefern.
Und DevOps ist natürlich ein großer Bestandteil.
Und das ist halt alle diese Beteiligten,
also ob es Betrieb,
ob es Development,
ob es Security.
Aber wie gesagt,
ich glaube heutzutage auch ohne SAFE,
diejenigen, die halt DevOps erwähnen,
meinen auch schon die drei.
Ist einfach, DevOps ist schon ein Begriff,
die quasi schon Security dabei hält.
Ja, das ist immer das Schwierige daran.
Ich denke, man impliziert mittlerweile sehr viel,
gerade wenn man DevOps sagt.
Deswegen zum Beispiel haben wir auch gefragt,
was ist deine Definition von DevOps?
Weil jeder meint irgendwie was Eigenes.
Es ist immer lustig,
mal auf die Wikipedia-Seite zu schauen über DevOps,
wo sie ganz offiziell zugeben,
es tut uns leid,
wir haben keine allgemeingültige Definition.
Hier sind ein paar,
sucht euch die raus, die euch am besten gefällt.
Wenn ich in einem Wort den DevOps beschreiben sollte,
da würde ich überhaupt nur Philosophie sagen.
Weil das ist Philosophie von Zusammenarbeit.
Und da können wir sagen,
ob es Betrieb und Development
oder Philosophie von Zusammenarbeit,
von Development Security und Betrieb,
Hauptsache, dass wir zusammenarbeiten,
um diese Value an unsere Kunden zu liefern.
Und am Ende des Tages, wie gesagt,
hier ist wieder diese Schnittstelle zwischen Safe und DevOps.
Ja, eben, weil Safe ist ja auch ein,
ich sage jetzt mal ein Vehikel,
um Zusammenarbeit zu fördern.
Genau.
Inwiefern passt für dich die Perspektive,
die Safe auf DevOps hat,
und deine Perspektive zu DevOps zusammen?
Hast du da eigene Meinung?
Eigene Sichten?
Oder sind da Parallelitäten zu erkennen?
Also ich stimme rein, absolut.
Wie gesagt, wir haben gerade auch die Kunden erwähnt.
Das ist eigentlich die gleiche Philosophie.
Nur das Safe ist,
fängt ja etwas nach vorne.
Also DevOps macht die Dinge einfacher
und kostengünstiger.
Besonders, wenn sie skalieren.
Wenn die Aufgaben automatisiert werden
und es viel schneller Feedback an Entwickler
und Betriebs-Team gibt,
was schnell wachsende Unternehmen brauchen.
Je schneller die Feedback-Schleife,
desto schneller lernt das Unternehmen
und desto schneller wird es keine Konkurrenten.
Und das wollen wir am Ende des Tages.
Wir wollen uns auf den Markt positionieren.
DevOps macht Continuous Delivery möglich.
Unternehmen, die ihren Kunden und Stakeholdern
einen wirklich kontinuierlichen Mehrwert bieten möchten,
müssen die Denkweise
und die technischen Praktiken von DevOps beherrschen.
Diese Ära ständiger digitaler
Description und Innovation
sind diese Fähigkeiten auf dem Tisch.
Und das ist nicht einfach,
Continuous Delivery zu erreichen,
im besonders großen Maßstab.
Der Develop-Einsatz von Safe-Hits-Unternehmen
diese Komplexität zu bewältigen.
Continuous Delivery Pipelines sind das Ergebnis
der effektiven Anwendung von DevOps
auf Value-Streams.
Heute stehen Unternehmen sowieso
immer in ständigem Druck,
neue Features schneller als je zuvor zu releasen,
um in ihren Markten
relevant zu bleiben.
Diese Features haben keinen Wert,
also die haben ja keinen Wert,
bis sie veröffentlicht sind,
aber hier, deswegen sage ich ja auch,
dieser Recovery-Element von Safe, von DevOps,
ist mir wichtig.
Sobald die Unternehmen unter diesem Druck stehen,
die können auch was releasen,
was vielleicht noch nicht so optimal
oder nicht so wie gewünscht funktioniert.
Und dieser Recovery ist ein extrem wichtiger Teil
von DevOps,
um diese Rollback
so schnell wie möglich zu machen.
Okay.
Safe spricht viel von Continuous Delivery Pipeline.
Was hältst du von Continuous Deployment?
Das ist letztendlich,
was ist der Unterschied für dich
zwischen Continuous Delivery
und Continuous Deployment
und inwiefern
ist es hilfreich
in diese Richtung zu denken?
Safe
spricht gerade auch darüber.
Also wir sagen, es ist extrem wichtig
diese Fähigkeiten zu haben
von Release und Demand.
Continuous Delivery
und Continuous Deployment
ist noch nicht alles.
Wir sollen auch in der Lage sein,
von Demand auch releasen zu können.
Und Safe spricht immer
und explizit darüber.
Deswegen, das ist wie gesagt wieder
ein Punkt,
wo Safe
und DevOps
sich trifft.
Weil wie gesagt, Release und Demand
ist ein extrem wichtiger Teil von Safe.
Das heißt, Feature Flags
und Dark Deployments
sind für dich letztendlich
wichtig und Teil der ganzen
Arbeitsweise, aber
das Releasen
an die Endkunden sollte trotzdem noch
von einer Person
entschieden und freigegeben
werden. Ist das richtig?
Nein, das muss ja nicht von einer Person
entschieden werden. Es kann auch sein,
dass das Team
es praktischer findet,
auf Daily Basis
zu releasen, weil es einfach keine
Nutzung gibt, sondern sagen wir so,
einmal in drei Tagen.
Deswegen, wir sollen ja in der Lage
sein, zu releasen,
wann wir das entschieden haben.
Das muss aber nicht auf Tagesbasis
erfolgen, auch wenn wir in der Lage sind.
Das ist immer halt
auch die Frage von der Nutzung
auf Tagesbasis
zu releasen.
Wenn es keine Nutzung bringt oder vielleicht
unsere Kunden wünschen auch nicht ständig
die Veränderung, sondern
die wünschen halt, dass wir mal pro Woche
das releasen, dann sollen wir auch in die Lage
sein, das auch zu machen.
Also ich denke da
überhaupt selten darüber nach,
wann ein guter Zeitpunkt für ein Release
ist. Wenn man es
kontinuierlich macht und
jede Codeänderung zu einem Release
bis hin in die Produktivumgebung
reicht, dann bräuchte man sich überhaupt
keine großen Gedanken darüber machen.
Ist das
eine
Veränderung, mit der
du schon in Kontakt
gekommen bist?
Ja, das ist aber sehr unterschiedlich
vom System.
Wenn wir jetzt von einem Billingsystem
reden, das sind sehr schwierige
und massive Systeme, die am Ende des Tages
unsere Endkunden nicht sehen.
Ich würde sagen, es ist nicht unbedingt
auch sinnvoll auf Tagesbasis
zu deployen und releasen.
Das könnte
halt wirklich zu Instabilität führen.
Wenn wir reden natürlich von
etwas, was unsere Kunden profitieren
wollen, von unseren Features, die wir an
Kunden liefern wollen, dann ist es natürlich
ein ganz anderes Thema und da wünschen wir
uns tatsächlich Continuous Delivery,
Continuous Deployment und Release
on Demand fast wirklich so schnell
wie möglich. Von mir aus mehrmals
pro Tag. Aber dass es wirklich unterscheidet
sich von den großen Konzernen,
großen Unternehmen, ist natürlich auch
diese Backend-Systeme
eine große Rolle spielen.
Und da, wie gesagt,
sehr oft, wir finden uns in der
Lage, dass wir können halt auch
auf Tage, auch täglich releasen,
ist aber nicht gewünscht.
Wer profitiert am meisten
von der Integration von DevOps
in SAFe? Die Teammitglieder?
Die Organisation?
Oder vielleicht sogar die Kunden?
Alle. Das ist
Win-Win-Situation.
SAFe und Agile Praktiken
und die Prozesse selbst sind schon
sehr mächtig. Und die Konstruktionierung,
eine Vision
oder ein Produkt bis hin zum
Product Road Mapping, Release Planning
und Product Backlog
und Entwicklung des Product Features.
Aber von dort aus sehen wir
normalerweise organisatorische
Anstrengungen.
Bei Development Organisationen
behält sich die Feature in Produktion
zu bringen. Das ist ja uns bekannt.
Aber die Operation,
Operational Teams haben
Mühe, Brände in Produktion zu löschen
und die Stabilität zu schaffen.
Während sie gleichzeitig versuchen
neue Features zu deployen, die schon in die
Organisation sind.
Also das ist das typische DevOps Problem.
Hier kommt genau dieses DevOps ins Spiel.
Und unterstreicht
den Punkt, dass
Entwicklung und Betrieb Hand in Hand gehen
und zusammenarbeiten müssen,
während sie auf ein Ziel
hinarbeiten. Nämlich
die Releasing Business Value zusammen.
Also wie gesagt, das ist Win-Win
Situation, wo die Teammitglieder
selbst, wo die Organisation
profitiert. Aber noch wichtiger,
wie du gerade auch gesagt hast,
davon profitieren unsere Kunden.
Die Kunden profitieren von den neuen Features
oder den Dienstleistungen.
Ist wieder natürlich abhängig von der Firma.
Inwieweit sind denn jetzt tatsächlich
Safe und DevOps verschiedene
Sachen, wenn ich dich reden höre?
Also
ist natürlich sehr unterschiedlich.
Weil, ich habe ja gerade
erwähnt ja,
Safe startet ja viel
früher. Und dieser
Prozess von Konzeptionierung
und überhaupt von Produktvision,
welche Produkte möchte ich
ja auf den Markt bringen?
Damit beschäftigt sich DevOps nicht.
Daher sage ich ja, DevOps
ist der wichtige Anteil,
der startet etwas
von besonderem, von gewissem Punkt.
Safe macht
das gesamte Prozess.
Die ersten Gedanken von Vision
sondern, wir reden sogar nicht von Produkt.
Im Rahmen von Safe, wir
besprechen überhaupt unsere Vision, ein Produkt.
Wir beschreiben
das Produkt, wir machen die
Konzepte und
von vorne
bis zu
unseren Kunden.
Wir reden von Value Stream.
Unsere Kunden wollen etwas
und wir versuchen diese Value zu liefern.
In DevOps, wir reden schon natürlich
von der Entwicklung
und Betrieb. Natürlich mit dem
Security. Aber das ist schon
die zweite Hälfte
der Kette. Wir müssen ja
anfangen sogar von der ersten
Visionierung. Und da
DevOps spielt noch
keine Rolle. Daher sage ich ja,
DevOps ist Bestandteil des
Safes, das ist klar.
Aber Safe ist natürlich das
macht die Coverage von der gesamten
Kette und DevOps ist
ab gewisser Stelle.
Okay, also
Safe, hast du auch gesagt, gehört zur
Product Delivery Kompetenz.
Eher auf Team und Release
Train Ebene und Safe
als Framework geht ja dann viel weiter.
Geht in das Portfolio
Management, geht in
die Large Solution
Entwicklung
und weit über die
Team Ebene hinaus. Genau, okay.
Es muss aber
nicht in Large Solution gehen. Es gibt auch
diese Essential Safe, bevor wir
von Large Solution reden.
Aber auch da, wir reden erstmal
von Visionen, von den
Konzepten, von
Konzeptionierungen.
Und wie gesagt,
bevor es überhaupt zu
Firmen kommt. Es gibt schon ein paar Sachen,
die gemacht werden sollen.
Und Continuous Integration.
Und deswegen sage ich ja,
DevOps ist ja,
das ist ein Teil
der Azure Product Delivery Kompetenz,
aber ist natürlich nur ein Teil von
einer Kompetenz. Es gibt ja viel mehr.
Okay, das heißt,
ist
DevOps dann doch wieder
ein rein technisches Thema geworden?
Weil, ich sage jetzt mal,
alles was in Richtung Produktmanagement geht
und so weiter, das gehört ja dann
aus dieser Perspektive nicht mehr zu
DevOps dazu. Nein,
definitiv nicht. Wie gesagt,
das wäre immer ein Fehler,
DevOps als nur ein
technischer Teil gesehen, weil das ist
Kulturwandel und das ist die
Cultural Change. Aber
wie gesagt, DevOps beschäftigt sich
sehr wenig mit der Vision des Produktes
oder Auswahl des Produktes.
DevOps startet etwas später
in dem Prozess.
Nämlich dann, wenn es um die Umsetzung der, der
Ideen geht, der Visionen geht,
die man etwas früher schon
dann erarbeitet hat, ne?
Ja, also, wie am Ende des Tages,
wir wollen unsere Kunden
fragen, was sie da wollen.
Wir wollen
den Bedarf auf dem Market nachforschen
und das passiert viel früher,
als DevOps ins Spiel kommt.
Wenn ich ja eine Frage mache
und meine Customer frage,
was eure wünschen,
ja, was wollen wir, sollen
wir unseren Service verbessern oder was
sind die neuen Features,
die ihr geil findet?
Da hat ja DevOps noch wenig
was zu bieten.
Okay, das bedeutet, dass
DevOps, ich sage jetzt mal,
separat von Safe auch
ein wichtiges Thema ist,
mit dem sich zum Beispiel das Management befassen muss.
Verstehe ich das richtig?
Definitiv. Also, DevOps
kann auch implementiert werden ohne Safe.
Ich sage nur für die
größeren Unternehmen, es macht natürlich Sinn,
Safe implementieren, weil damit implementieren wir
irgendwie auch den DevOps.
Aber es gibt ja auch
dutzende Unternehmen, hunderttausende Unternehmen,
die implementieren DevOps,
brauchen vielleicht den Safe auch nicht,
weil die sind auch nicht so groß.
Also, wenn wir reden von einem Startup mit 20
Leuten, würde ich ja nie empfehlen, auch Safe
implementieren, da kann man auch nur DevOps implementieren.
Mhm, und
neugehalber, also DevOps ohne
Safe geht, geht auch Safe ohne DevOps?
Nein, DevOps ist
Bestandteil des Safes, also
bei der Definition, weil das ist wieder,
das ist einfach kulturelle Change
und das wollen wir haben.
Wir wollen nicht mehr, dass die Leute in
eigenen Silos arbeiten,
in die Silos denken.
Ich glaube, keine Organisation wünscht sich,
dass Leute Operationals sind
und Development Teams
wieder separat arbeiten
und keine,
und nicht miteinander sprechen.
Das wollen wir auf keinen Fall. Und wie gesagt,
für mich, DevOps ist in erster Linie
dieser kulturelle Wandel und
Zusammenarbeit und nicht nur Pipeline zu bauen.
Das ist aber auch sehr wichtig.
Ich sage nicht, dass Pipeline ist
nicht nötig. Das wollen wir natürlich auch
haben. Aber in erster Linie diese
Zusammenarbeit und das ist auch,
was ist in Safe wichtig.
Was macht für dich die
Pipeline aus?
Das ist, das
macht ja viel. Also, das ist
auch eine Sache, womit man auch
sehr viel auch unser
Management bewerben kann.
Weil, wenn wir von Pipeline reden,
natürlich auch reden von
der Möglichkeit, die Arbeit schneller
machen, billiger, also
kostengünstiger. Man liefert
mit höherer Qualität,
bessere
Predictability und einfach
mit höherer Produktivität.
Also Safe DevOps bietet uns die Möglichkeit,
fast notwendig ist auch schnellere
Recovery, also Widerstellung zu machen.
Wie gesagt, was ist extrem
wichtig, um diesem ständigen Druck
neue Features in Produktion zu bringen.
Und das ist eigentlich
im Wesentlichen die wahre
Position von Business Engineering.
Und by the way,
wenn man DevOps für
den Management verkaufen möchte,
ist manchmal sehr schwierig
machen mit dieser kulturellen Change.
Aber mit dem
schnelleren und kostengünstigen
Lieferungskette, das funktioniert
besser.
Hast du da ein paar
Zahlen und Daten,
Fakten vielleicht im Hintergrund,
wie viel schneller man mit
DevOps werden kann, wie
billiger es wird? Kannst du das
irgendwie quantifizieren?
Ich kann nur sagen,
ich habe die Zahlen jetzt nicht ad hoc gebracht,
weil ich
das natürlich von Kunden zu Kunden
unterschiedlich ist. Ich kann nur
sagen, ohne
zum Beispiel diese Zusammenarbeit
und ohne diese Pipeline,
das wäre unmöglich,
die Bugfixing im Rahmen von
halbe Stunde
in Produktion fixen. Wenn du es alles
manuell machen musst, du hast ja keine
Chance. Wenn die Betriebleute
und die Werbung nicht zusammen reden
wollen, du hast ja auch keine Chance.
Und in den Unternehmen, wo ich ja auch
unterstütze, wir schaffen
es,
Minuten Bugfix
zu finden, das zu fixen,
mit Abstimmungen, die sofort erfolgen,
weil die Teams, ist sogar nicht die Teams,
das ist ein Team. Die reden
ein mit anderen und wenn einfach Klick auf
einen Knopf, das geht in die Produktion.
Du musst ja nicht mehr jetzt irgendwie ein Ticket
erstellen, die erstmal bei
Operation Team lernt, die haben
irgendwie ein paar Tage SLA
und dann, die bearbeiten
das ja oder nein und dann
kriegst du Meldung oder auch nicht.
Also das
gehört nicht zu unserer Zeit,
das gehört nicht zur Digitalisierung,
das gehört nicht zu den Unternehmen,
die attraktiv auf die Marken bleiben.
Genau und ich glaube, es ist wichtig
an der Stelle nochmal herauszustreichen,
dass wenn du meinst, das Problem ist innerhalb von
ein paar Minuten behoben, meinst du damit nicht,
man hat schnell schnell eine Push-Lösung hingewurschtelt,
die einem dann am nächsten Tag nochmal um
die Ohren fliegt, sondern wirklich eine
nachhaltige, irgendwie
handwerklich solide gemachte Lösung.
Genau, also und das ist eben auch einfach,
tatsächlich einfach, wenn du hast einfach eine
gut funktionierende auch
Pipeline, die auch testautomatisiert
durchläuft, die
das in Container packt,
die wie gesagt schon geprüft und
getestet worden und dann einfach
vielleicht erstmal in
Prod-Umgebung landet, da könnte man
bei Bedarf, wenn es gibt und wenn es so
kritische System ist, vielleicht sogar
überprüft werden und dann geht es
in Produktion. Das war früher aber
nicht der Fall. Also früher sollte
so ein Ticket erstellen,
die Leute sollten das Ticket bearbeiten
und da definitiv haben die gewisse
SRAs und vielleicht wenn das
schneller gehen sollte, müsste es eskalieren
oder wenn ihr ein paar Telefonate machen,
das existiert
ja nicht mehr. Die Leute arbeiten zusammen,
die wissen, dass das Problem besteht,
die arbeiten gemeinsam an der Lösung und
bei einem Klick, es geht einfach
um die richtige Umgebung.
Hast du Erfahrungen
mit Blameless Postmortems
als Fehler,
Lösung und Dokumentationsansatz?
Nein, ehrlich gesagt nicht.
Vielleicht kannst du dazu was sagen, das wäre auch
interessant für mich. Das ist ein Ansatz, der
letztendlich aus dem
Site Reliability Engineering
kommt,
dass Google als
seine Software Engineering
basierten Implementierung von
DevOps sieht und
ja
publiziert hat und zwar
geht es halt darum, ähnlich wie man das
bei cross-funktionalen DevOps Teams hat,
alle Beteiligten, die an einem
Ausfall, an einem Problem in
irgendeiner Form
einen Anteil hatten zusammenzubringen,
eine gemeinsame Timeline
der verschiedenen
zum Problem geführten
oder parallel zum Problem
auftretenden
Themen zu dokumentieren,
dann zu schauen,
welches von diesen Maßnahmen
hat dann zur Auslösung des Problems
geführt, was hat letztendlich dazu
beigetragen, welche
weiteren Effekte gab es und
wie kann man daraus am besten
lernen, wie kann man
sicherstellen, dass diese Ursachen
beseitigt werden, dass
solch ein Problem möglichst nicht wieder
auftritt. Das Ganze dann halt auch
so zu dokumentieren, dass man es
unternehmensweit recherchierbar hat.
Das heißt, falls an einer anderen Stelle ein ähnliches
Problem auftritt, dass man dann halt
auch wieder auf die
Fehlerursachen
aus anderen Bereichen, auf die Maßnahmen,
die in anderen Unternehmensbereichen dazu
eingeführt worden sind,
reagieren kann.
Also auch eine Art des
Lernens aus
im gesamten Unternehmen.
Okay, sehr cool.
Dann musst du, glaube ich, weiter den Podcast hören, George, weil
auf meiner Liste von Themen habe ich auch schon
das Thema Blameless Postmortems.
Da möchte ich gelegentlich mal eine Folge
dazu machen.
Haben Sie bereits jetzt Provo gemacht.
Genau, perfekt. Aber ich bin so ein bisschen
neugierig, weil
wir haben uns ja jetzt sehr, ich sage es mal,
allgemein und theoretisch unterhalten über
Safe. Aber ich frage
mich, wie führt
man denn Safe überhaupt in ein
Unternehmen ein? Und vielleicht als
Detailfrage, insbesondere im Hinblick auf
den Aufhänger Safe und
DevOps, sollte man, ich weiß auch nicht,
mit DevOps starten und sich dann weiterentwickeln
in Richtung Safe? Oder sollte man
beides parallel machen? Oder
wie fängt man es denn an?
Also, sobald man Safe
einführt, wird da schon
mit Safe diese
Kulturwandel kommen. Weil
bei Safe kannst du auch nicht anders arbeiten.
Alle arbeiten, und das ist eigentlich
alles, alle Mitglieder
ist ein großes Team.
Du hast ja natürlich Teams von Teams,
du hast ja auch dieses Scrum-Team bis elf
Team-Members,
aber am Ende des Tages, wir sind ja alle ein Team.
Und da sind sowieso schon alle Leute
dabei, die wir brauchen, um die
Values-Team zu schaffen,
um die Values-Kunden zu liefern.
Das heißt, da sind sowieso schon
auch die Developers
dabei, da sind sowieso schon auch
Betriebsleute dabei, da sind sowieso schon Security-Leute
dabei, und wir sind ja ein Team.
Wir sind schon gespielt in diese
konventionellen Teams, wo wir alle diese
Kompetenzen auch haben. Das heißt,
du musst ja nicht
anfangen mit dieser kulturellen Änderung,
was du in DevOps,
wenn du noch DevOps einführen möchtest,
damit musst du dich nicht mehr beschäftigen.
Du hast es schon.
Wie gesagt, deswegen sage ich ja immer,
wir implementieren uns schon gleichzeitig
mit Save auch DevOps.
Und sobald du diesen Kontakt
hast, und du hast diese
Wand schon
zerbrochen zwischen den beiden,
das ist schon natürlich viel einfacher.
Und dann reden wir natürlich nicht nur halt
um diese kulturelle Change, weil das haben wir
schon geschafft, dann haben wir natürlich auch
andere Komponenten. Also wir können
ja reden jetzt von Pipeline-Entwicklung,
was natürlich uns alle weiterbringt,
und nicht vergessen, wir reden jetzt nicht wieder
nicht von 11 Leute, es kann auch
sein 100 Leute, die entwickeln
natürlich auch ständig und viel, und das muss
ja auch relativ schnell getestet und deployed werden.
Und bei Bedarf auch released.
Daher müssen wir halt machen.
Und
deswegen sage ich ja, die wichtigste
und die schwierigste Anteil von
DevOps ist eigentlich
sofort mit der Einführung von Save.
Diese Zusammenarbeit. Und dann
kommen wir halt für den Bedarf,
die spezifischen Themen zu besprechen, aber
auch über das Pipeline oder wie auch immer.
Aber diese Basis hast du
damit schon geschafft.
Eine Sache, die mich auch interessiert, ist,
wenn ich mich umhöre in
agilen Kreisen, gibt es ganz viele,
die über Save schimpfen und sagen, oh,
Save ist ganz schrecklich und ist überhaupt nicht
agil und es ist total
furchtbar und es ist einfach nur Wasserfall,
gelb angemalt.
Was ist deine Antwort auf
diese Leute?
Ja, ich habe es
auch kurz schon erwähnt, dass es die
Vorteile, die Save bietet,
auch oft benutzt wird
bei den Kritikern. Ich sage,
es ist mega geil, sofort zu starten
wie so ein Unternehmen wie
Amazon oder Netflix oder
Spotify, die so klein
gestartet und gewachsen sind,
aber immer schon von vorne in diesem
agilen Umfeld.
Die wissen ja nichts anderes.
Diese Kultur, das war immer der Bestandteil
des Unternehmens. Es ist eine ganz andere
Nummer, so Agilität einzuführen
in große Konzerne. Die haben schon
jahrelang
Wasserfallmethoden verwendet
und haben schon diese
Silos überall.
Dann kann man natürlich sagen,
oh, wie wollen wir Google sein? Ja, cool.
Kannst du das?
Nein. Also bevor du laufen kannst,
musst du auch den ersten Schritt erst
machen. Und ich finde,
dass Save genau
dieses Framework, mit dem du
diese Schritte machen
kannst. Du kannst einfach nicht
sich von heute auf morgen
von einem großen
Konzern, der komplett auf Wasserfallmethoden
basiert, plötzlich
sagen, oh, ich mache jetzt wie
Netflix. Das wird einfach nicht funktionieren.
Du kannst ja, du hast ja diese
Zusammenarbeit nicht, du hast diese kulturellen
Change und Wandel noch nicht.
Das kannst du einfach nicht machen.
Also du kannst es versuchen,
du kannst davon träumen,
du kriegst das nicht hin.
Und Save ist genau das richtige Framework,
um diesen
Move zu schaffen.
Daher sage ich ja, es kann natürlich
viel noch kritisiert werden.
Es kann auch natürlich viel verbessert werden,
deswegen sage ich ja, obwohl Save
nur 2011 eingeführt, wir haben schon
die vierte Version von Save,
die wird auch dieses Jahr noch
eingeführt. Und das gibt ja immer
große Änderungen. Save
ist keine Bible.
Also das entwickelt sich,
das ändert sich, weil unsere Welt
ist auch ändert, permanent.
Und Save ist einfach,
die Sammlung von Bestpraktiken.
Und du kannst auch sagen, okay, diese Praktiken
passen für mich und diese nicht.
Das ist auch vollkommen in Ordnung.
Ja, aber wie gesagt,
kritisieren ist natürlich immer
einfacher. Und ich würde mir
auch wünschen, vielleicht so ein großes
Konzert sofort in einem Tag wie
Netflix oder wie Google machen.
Das geht nicht. Und wir brauchen
halt gewisse Framework, die bietet uns
diese Möglichkeit von Wasserfall
und Unternehmen, die halt in
Serials funktionieren erstmal,
umwandeln und agile Methoden
halt beizubringen. Und wie gesagt,
für mich, da gebe ich ja mehrere
unterschiedliche Frameworks und Modellen
benutzt habe, Save ist
nicht optimal. Genau,
also da stimme ich dir auch völlig zu,
weil mir geht es ähnlich wie dir,
die Leute, die so fürchterlich über
Save schimpfen, die machen sich
vielleicht ein bisschen einfach. Weil
man kann darüber streiten, ob Save
in allen Fällen das Richtige ist, oder
ob sie nicht manchmal auch ein bisschen, ich weiß nicht,
noch mutiger sein könnten in Richtung Agilität
oder sowas. Aber genau wie du sagst,
man würde bestimmt die Unternehmen, die
gedacht sind als, wie soll ich
sagen, als die Kunden von Save, als
die Anwender von Save, würde man schlicht und ergreifend
überfordern. Genauso wie du sagst.
Es ist nicht nur überfordern. Also
die Teams in Save arbeiten
genau laut Scrum-Modell.
Manche Teams arbeiten
mit Kanban-Modellen, manche arbeiten
mit Scrum-Modellen. Ist auch in Ordnung,
aber Scrum ist sowieso. Die
treffen eigene Entscheidungen und machen
halt, was die
sich hier halten, nach dem Wunsch von
Customers und unseren Kunden.
Das Problem ist, in so einem komplexen
Unternehmen mit
dutzendtausend Mitarbeitern,
du schaffst kein Produkt in ein oder
zwei oder sogar auch in drei Teams.
Und auch hier brauchst
du gewisse Koordination von Teams.
Beziehungsweise du brauchst Minimum
Alignment zwischen den Teams.
Und, weil die Teams entscheiden ja
selbst in Ordnung, aber wir brauchen halt
irgendwie zentrale Priorisierung.
Es bringt mir ja nicht, wenn ein Team arbeitet,
auf Feature A, brauchen aber
dafür vielleicht etwas von Team B
und Team B hat das überhaupt nicht priorisiert.
Daher, wir brauchen diese
gemeinsame Priorisierung. Und zum Beispiel
ich bin gerade, wie du
schon auch gesagt hast, ich bin Release Training
Engineer, ich hab acht Teams.
Dann brauchen wir gewisse Alignment zwischen die acht.
Sonst kriegen
wir am Ende des Tages nicht das
gute Produkt. Es reicht
mir nicht, dass vier Teams haben was
priorisiert, aber die anderen vier gar nicht
im Radar gehabt.
Daher, diese gemeinsame Priorisierung,
gemeinsame Vision des Produktes,
es muss ja transparent für alle Teams sein.
Und diese Transparenz und diese
Alignment, das ist genau, was SAFe uns
bringt. Ich könnte
bis jetzt nicht finden,
was SAFe weniger
agil macht. Also,
vielleicht liegt es daran, wie tief
die Leute in SAFe Freiburg
einsteigen. Da ist so ein
Besammeln von allen Methoden,
ich habe noch keinen Nachteil gesehen.
Was jetzt wichtig ist vielleicht,
noch dazu zu sagen, das, was
ich immer auch in meinen Trainings sage,
one size doesn’t fit all.
Du kannst ja nicht sagen,
okay, ich habe hier
SAFe eingeführt,
ich mache das gleiche jetzt in anderen Unternehmen.
Das funktioniert eben nicht.
Alle haben unterschiedliche Produkte,
alle haben ein bisschen unterschiedliche
kulturelle Änderungen von Unternehmen zu
Unternehmen. Und wie gesagt, aber hier
auch ein zusätzlicher Vorteil von SAFe,
wie gesagt, es ist nur die Sammlung von den Praktiken
und Methoden. Du kannst immer, wenn du
gut bist und du kennst die ja,
die passende finden von Unternehmen zu Unternehmen.
Und das funktioniert auch
sehr erfolgreich. Kann man dann überhaupt sagen,
dass es das eine SAFe gibt?
Weil es klingt jetzt ein bisschen so, als ob es ein
ich sage jetzt mal ein SAFe für, ich weiß auch nicht,
für Daimler gibt und ein SAFe für die Deutsche Bank
und ein SAFe für, ich weiß nicht,
Deutsche Telekom. Und es steht zwar überall
SAFe drauf, aber vielleicht ist jedes Mal was ganz anderes
drin. Das ist
eine sehr interessante Frage,
weil das ist natürlich,
kann man auch nicht so, wie auch die
anderen beantworten. Wieso? Es gibt
ja immer die Elemente, die sein müssen,
um das überhaupt SAFe zu nehmen.
Du musst zum Beispiel DevOps haben.
Du musst PI-Pläne
durchführen. PI-Pläne durchführen.
Du musst Innovation & Planning haben.
Du musst permanent Transparency & Adapt
haben. Du musst in klarer
Kadenz arbeiten. Du musst ja Transparenz
haben und so weiter und so fort. Es gibt gewisse
Sachen, die müssen sein.
Aber zum Beispiel, du musst ja nicht
sagen, dass
alle müssen Scrum nutzen. Ist auch in
den Teams ja kann man nutzen, wenn die
das für die richtig halten.
Und die sagen, es kann sein, dass SAFe
bei einer Firma sieht ganz
anders wie bei anderen. Aber gewisse
Elemente müssen das sein.
Und das beobachte ich ja auch sehr oft,
wenn ich komme und mir sagen die
Customer zum Beispiel, wir arbeiten
nach SAFe und ich komme und sage,
nein, das ist nicht SAFe.
Also du kannst es nehmen,
wie du möchtest, aber SAFe ist es
nicht. Die Tatsache, dass du
plötzlich da Daily machst,
und irgendwelche Events machst,
quasi BI Training ähnlich,
das macht es doch nicht SAFe.
Wenn du aber immer noch in
Silos arbeitest und
du hast ja alle Rollen von deinem
Department
mit Leuten von deinem Department besetzt
und du sprichst aber mit Kunden nicht und
du weißt doch gar nicht, was die Kunden wollen,
dann ist es nicht SAFe. Du kannst die Rollen
benennen, du kannst die Events haben,
aber es ist immer noch nicht SAFe,
ist nicht Agile, aber ich glaube,
dass es unabhängig von SAFe, das wäre genau
so im Scrum. Ich habe auch gesehen,
die Leute sagen, oh, ich habe Product Owner
und ich habe Scrum Master, aber die machen
genau, was die Vorgesetzten gesagt haben.
Das ist auch nicht der Scrum, auch wenn du
die Rollen hast und du die Events hast.
Also das ist wie gesagt, auch
hier, ich habe ja in einem Wort gesagt,
DevOps für mich ist eine Philosophie,
auch Agilität ist eine Philosophie und
unabhängig von welchem
Framework wir reden, ob es
SAFe, ob es Spotify Modell ist,
Scrum, da muss einfach
diese Change
erfolgen. Ohne
wird es nicht funktionieren. Deswegen
für deine Frage, ja, SAFe
kann unterschiedlich aussehen,
es gibt aber gewisse Elemente,
die müssen sein. Anderesrum,
wir können es auch SAFe nennen, aber das ist
nicht SAFe. Okay,
sehr interessant. Und das klingt
jetzt für mich auch danach,
dass eigentlich der vielleicht
klassische Fehler, den man machen kann bei einer SAFe
Einführung, dass man genau eben
nur die Rollen
sich aneignet, nur
die Events durchführt,
aber nicht den notwendigen
Mindset-Change mitmacht und sagt, wir
reden nicht nur anders miteinander,
wir nennen uns anders, sondern wir arbeiten
jetzt auch anders miteinander. Genau.
Also ich glaube, wie gesagt,
jetzt sage ich ja etwas, wir reden von SAFe,
aber das ist genauso
für jede Agile Framework oder Methode.
Die größte und die wichtigste
Änderung ist in unserem Mindset.
Du kannst Tools einführen,
du kannst Prozesse
einführen, wie gesagt, ob es
Daily, Retro oder
Inspector Adapt und BI Planning sind.
Du kannst es auch benennen, aber wenn du
wirklich nicht zusammenarbeitest,
wenn du immer noch in deine
eigenen Silos denkst,
an eigene Ziele und nicht um
gesamte Ziele des Unternehmens,
wenn du nicht um Value
denkst, was du an Kunden
liefern, sondern an deine spezifischen
Ziele von deiner Abteilung,
dann bringt das ja nichts.
Das ist egal, wie du das nennst
und es ist egal, welche Rolle du
also ich habe ja auch gesehen, dass die
IT-PLs haben einen Namen gekriegt,
ob Scrum Master oder RT
oder die
PLs haben plötzlich Product Management
gewesen oder Product Owners.
Das spielt ja keine Rolle, du kannst
ja auch Bananen-Apfel nennen, das schmeckt aber
nicht anders.
Also
nur um die Rollen
zu benennen und die
deine irgendwie Jurafix jetzt
BI Planning oder Daily
zu nennen, das ändert ja nicht.
Die gesamte Änderung und
wie gesagt, das gilt genauso für DevOps
wie für Scrum oder für Save,
startet im Mindset. Und
im Gesamt, wenn wir
zurück zum Save gehen, du brauchst
auch hier quasi immer erstmal
überlegen, dass du das tatsächlich
cross-functional bildest.
Wenn du jetzt nur ein Team von
Developern stellst und da auch BI und Scrum
Master nennst, aber die wirklich in
Silo arbeiten, dann wird das auch nicht safe.
Und du brauchst auch
die Leadership, die dich unterstützt
in diesem Wandel.
Und die unterstützt und
proaktiv auch
diesen Wandel treibt.
Dann kannst du Save auch erfolgreich
implementieren. Und wie gesagt, bei
Implementierung von Save, implementierst du auch
in DevOps.
Dann haben wir jetzt schon sehr viel über
Save gehört und über den Zusammenhang zwischen
Save und DevOps. Und ich glaube, es ist
langsam auch ein guter Zeitpunkt, um diesen
Podcast dann am Ende zuzuführen.
Aber vielleicht als letztes Geschenk,
an die Hörerinnen und Hörer.
Gibt es einen besonders
wichtigen Tipp, den du den Hörerinnen
und Hörern mitgeben könntest, wenn sie
vielleicht gerade versuchen, eine
Transformation in Richtung Save
vorzunehmen? Ja, ich versuche es.
Also, wir haben jetzt
sehr viel von Values
gesprochen. Und Value Delivery
beginnt mit einer Idee
oder einer Hypothese darüber, was
Kunden brauchen. Das müssen wir
immer als erstes betrachten.
Und Save spricht immer von
Customer Centricity. Diese Bedürfnisse
müssen dann kontinuierlich untersucht und
bewertet werden, um sicherzustellen,
dass ein Produkt dem Menschen, dem
Kunden entspricht. Sonst, wie gesagt,
haben wir auch nicht erreicht, wenn wir
nicht die richtigen Produkte aber einfach schnell
zur Macht mitgebracht haben.
In diesen Zeiten
müssen dann agile Teams diese Systeme und
Lösungen kontinuierlich erstellen
und integrieren und die kontinuierlich
in die Produktion bereitstellen.
Dort werden sie validiert und auf
die Business Entscheidung, ob die
Produkte released oder vielleicht nicht,
warten werden. Ein häufiger
Fehler besteht darin,
eine agile Transmission
ohne DevOps zu versuchen.
Oder umgekehrt. Deswegen auch hier
sage ich ja, Safe Framework
ist schon
bestimmt,
beeinhaltet schon DevOps. Deswegen, wenn wir
Safe schon einführen, dann werden wir DevOps
nicht vergessen. Agile ohne DevOps
schafft nur diese
Qualitätsarbeit, die nicht schnell
genug an den Kunden geliefert werden kann.
Und daher nicht zu den ultimativen
wirtschaftlichen Erlebnissen führt.
Umgekehrt, mit DevOps
ohne Agile bestenfalls
eine nicht ausgelastete
Pipeline. Im schlimmsten Fall
liefert agile Teams
die falschen Dinge schneller. Das heißt,
wenn wir nur DevOps haben, das kann
implementiert werden. Aber wenn wir überhaupt
nicht die Wünsche der Kunden betrachten,
dann liefern wir schnell, aber
falsch. Das hat uns auch
relativ wenig gebracht. Man braucht sowohl
Agile als auch DevOps,
um einen Mehrwert zu erzielen.
Und wie gesagt, wiederhole ich mich,
deswegen bin ich ja auch Fan
von Framework. Sonst würde
ich ja vielleicht Trainer von einer anderen
Framework sein. Eine der
schwierigsten Fragen, mit denen Unternehmen
bei DevOps Transformation konfrontiert sind,
ist die Entscheidung, womit
die überhaupt
anfangen sollen.
Und an dieser Stelle muss ich ja sagen,
der Safe DevOps Kurs beantwortet
genau diese Frage.
Dieser Erfahrungskurs ermöglicht es,
den Teilnehmern ihre
bestehende Lieferpipeline
abzubilden und
die Zeit und die
Qualitätsengpässe zu identifizieren.
Also wir arbeiten einfach zusammen,
wir austauschen, und das ist auch sehr hilfreich,
die Leute von unterschiedlichen
Unternehmen halt
diesen Austausch zu machen.
Wir verwenden
alle zusammen Safe DevOps
Health Radar, um ihren
Reifengrad in jeder der

  1. Unterdimensionen
    und Demand
    zu prüfen. Und wir dann
    identifizieren einfach die Endpässe
    und nehmen die
    Punkte mit, die wir auch dann
    in unserem Unternehmen verbessern sollen.
    Und wie gesagt, am Ende
    haben die Teams die drei wichtigsten
    Verbesserungspunkte identifiziert,
    die in ihrer Umgebung
    die besten Ergebnisse auch liefern
    würden. Und
    erfahrungsgemäß, und das ist
    immer witzig, dann am Ende zu sehen,
    dass die Leute die Endpässe
    an Orten finden, wo die überhaupt
    nicht erwartet haben. Also ich empfehle
    am Ende des Tages
    die Unternehmen, die diese Schritte wagen, die
    Safe oder DevOps zu implementieren,
    in einer Safe DevOps Schulung
    teilzunehmen, um
    sich ein besseres Verständnis zu schaffen.
    Auch von Zusammenarbeit,
    auch um silofreien Gedanken,
    aber natürlich auch von
    Pipeline zu verstehen. Anschließend
    erstellen sie auch in
    dieser Schulung
    einen zukünftigen Statuspipeline,
    in dem sie Fähigkeiten
    in den vier Dimensionen
    die Bereitstellungspakete identifizieren.
    Continuous Exploration, Continuous Integration,
    Continuous Bereitstellung
    und Resonance machen.
    Also wie gesagt,
    das wäre wirklich mein Tipp.
    Und bitte auch nicht vergessen,
    das startet einfach von Mindset Change.
    Gut, ich würde mal vorschlagen,
    dann haben wir
    eine ausgezeichnete Folge
    gerade aufgenommen, in den Kasten gebracht.
    Ich denke, wir sollten auch darauf hinweisen,
    George, dass du natürlich auch
    Unternehmen, Organisationen dabei hilfst,
    safe einzuführen. Haben wir
    vorher gesagt, als Coach, als Trainer.
    Und ich schlage vor, wir
    packen einen Link zu deiner
    Webseite in die Shownotes, sodass
    Leute, die sich dafür interessieren, mit dir
    in Kontakt zu kommen, da die Möglichkeit
    haben, dich zu finden.
    Sehr gerne.
    Wunderbar, dann
    bleibt mir nichts anderes übrig, als
    mich sehr herzlich zu bedanken, dass du dir heute die Zeit
    für uns genommen hast. Ich weiß, es ist gerade eine stressige Zeit für dich.
    Umso toller, dass es heute geklappt hat.
    Vielen Dank dafür und vielen Dank
    für diese spannende Folge.
    Danke euch. Es ist mir eine Freude
    und ich werde zugleich heute dabei sein dürfen.
    Alles klar. Bis zum nächsten Mal, George.
    Wunderbar.
    Ciao. Ciao.
    Ciao.

Folge 53: Terraform

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Folge unterhalten wir uns mit dem Automatisierungsexperten Helge Zimpel über Terraform.
Was ist es, wofür wird es verwendet, und wie fügt es sich in den weiteren Zoo von DevOps Werkzeugen ein?

In dieser Episode des Podcasts „DevOps – auf die Ohren und ins Hirn“ sprechen die Moderatoren Luca Ingianni und Dierk Söllner mit Helge Zimpel, einem erfahrenen DevOps-Automatisierungsexperten. Sie diskutieren detailliert über Terraform, ein Tool für Infrastructure as Code, seine Anwendung in verschiedenen IT-Umgebungen, dessen Vorteile wie Dokumentation und Reproduzierbarkeit, und wie es sich von anderen Tools wie Docker und Ansible unterscheidet. Helge betont auch die Bedeutung von Terraform in Bezug auf die DevOps-Kultur und agile Prozesse sowie die Herausforderungen und Vorteile der Implementierung in Unternehmen verschiedener Größen.

Inhalt

  • Einführung und Vorstellung von Helge Zimpel
  • Grundkonzept und Vorteile von Terraform
  • Unterschiede zwischen Terraform und anderen Tools wie Docker und Ansible
  • Anwendungsbereiche und Grenzen von Terraform
  • Bedeutung von Terraform im Kontext von DevOps und agilem Arbeiten
  • Praktische Tipps und Best Practices zur Implementierung von Terraform
  • Helge Zimpels berufliche Tätigkeit und Angebot auf seiner Webseite

Shownotes:

Das Thema der Folge: Terraform
Die angesprochene Testframework für Terraform: Terratest
Helges Webseite: kontainer.sh

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Luca Ingianni und Dirk Söllner
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps – auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni, Dierk Söllner und Falco Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Und heute kommen wir zu einem technischen Aspekt.
Zu Gast haben wir Helge Zimpel.
Und ich würde sagen, bevor ich jetzt lange dich vorstelle, Helge, übernimm du es doch selber.
Bitteschön.
Ja, ich bin der Helge. Ich bin Experte für DevOps-Automatisierung
und begleite meine Kunden auf dem Weg zu weniger Routinearbeit als Entwickler.
Und mit meiner langen Erfahrung als Entwickler unterstütze ich bei der Einführung agiler Vorgehensmodelle,
bei der Ausschöpfung von Automatisierungspotenzialen im Entwicklungsprozess
und bringe meine Erfahrung aus vielen größeren Softwareprojekten dort ein, aus der Praxis.
Super. Das ist ganz interessant, weil ich bin ja nicht so der Technik-Freak.
Ich kann zwar ein bisschen was zu Technik erklären, aber ich glaube,
in den meisten Fällen gibt es auch in meinen Trainings,
sehr viel mehr Leute, die da vielleicht an einigen Stellen tiefer drin sind.
Insofern werde ich wahrscheinlich heute auch noch ein bisschen was lernen.
Luca, das heißt, du übernimmst den Experten-Part auf der Frage-Seite
und ich übernehme den Part mit den dummen Fragen.
Ach je, aber ich wollte eigentlich auch gerne die dummen Fragen stellen.
Ja gut, okay.
Dann müssen wir das beide machen.
Gut, wir haben uns ja vorgenommen, heute zu sprechen über das Thema Terraform.
Was ist denn das eigentlich, Helge?
Also die Idee hinter Terraform ist Infrastructure as Code.
Das ist die Idee, Infrastruktur ja im Grunde auch zu programmieren,
in Form einer Programmiersprache seine Infrastruktur zu definieren.
Und das, was man sonst klassischerweise per Hand macht oder auf der Kommandozeile
bei der Einrichtung von Servern, bei der Installation von Backdingen
oder wenn man sich durch eine Oberfläche klickt, bei Amazon Cloud gibt es hier eine Web-Oberfläche,
wo ich mir auch die ganzen Dinge über eine Oberfläche einrichten kann,
Server aufsetzen kann und alle möglichen Dinge hinterlegen kann.
Und bei Terraform ist die Idee, das Ganze auch in Form von Code zu hinterlegen,
hat zum einen den schönen Seiteneffekt, dass auch alles gleich dokumentiert ist
und das Wissen nicht verloren geht und dass man es auch reproduzieren kann
und wiederverwenden kann.
Super, da haben wir ja gleich mal zwei Vorteile.
Reproduktion und Dokumentation.
Das sind ja zwei Punkte, die, wie ich finde, auch für einen normalen Administrator
eigentlich von Interesse sein sollten, weil IT-Experten und Dokumentation,
das sind ja so zwei Welten, die aufeinandertreffen.
Wenn ich mal ein paar so Klischees bemühe, gibt es noch ein paar Punkte,
die du erklären würdest zu Terraform, was noch so ein paar wichtige Highlights sind?
Also erstmal ist die Idee, dass Terraform deklarativ arbeitet.
Das heißt, ich beschreibe im Grunde einen Sollzustand meiner Infrastruktur.
Wie soll die Infrastruktur aussehen?
Das heißt jetzt nicht nur irgendwelche Server, sondern kann in einer Cloud-Umgebung auch bedeuten.
Datenbanken kann heißen Benutzerrechte und Rollen oder verschiedene weitere Services,
die innerhalb der Infrastruktur genutzt werden.
Man definiert halt, wie die einzelnen Komponenten funktionieren.
Und dann kann man in Terraform erstmal das Ganze durchspielen.
Das gibt so einen Befehl auf der Kommandozeile Terraform-Plan,
wo man erstmal ausprobieren kann, stimmt das Setup und was würde passieren,
wenn ich das jetzt ausführen würde auf der Infrastruktur.
Und dann kann man das Ganze erstmalig ausführen.
Okay, du hast eben zu Anfang deiner Antwort gesagt, deklarativ.
Gibt es noch irgendetwas, gibt es andere Ansätze, die quasi,
ein Gegenteil oder eine andere Abwandlung von deklarativ sind?
Ja, es gibt auch Ansätze, die im Grunde wie,
die entweder sogar auf klassischen Programmiersprachen beruhen.
Das heißt, das sind dann Bibliotheken für Sprachen wie Python oder Java.
Es gibt natürlich auch spezialisierte Tools,
um beispielsweise ein Kubernetes-Cluster aufzusetzen oder so etwas.
Und bei Terraform ist halt die Idee dann auch noch,
einen Soll- und Ist-Zustand immer wieder abzugleichen.
Das heißt, wenn ich dann Änderungen vornehme,
dann erkennt das Terraform, wie unterscheidet sich denn jetzt meine Infrastruktur,
die gerade läuft, mit dem, was ich, mit meinem Zielzustand,
und gleicht dann das gegeneinander ab und führt dann die notwendigen Änderungen aus
und rollt sie aus.
Ja, okay.
Ich fand es sehr interessant, weil du sagtest, man kann das durchspielen.
Und dann, ich dachte, der Befehl würde heißen Terraform Play.
Aber okay, Plan macht natürlich Sinn, auch wenn man es wirklich mal so durchspielen will,
Plan und Ist vergleichen würde.
Okay.
Gibt es noch ein paar Punkte, die du,
die du zu Terraform sagen würdest, die wir auch nutzen können,
um Infrastructure as Code Leuten wie mir zu erklären,
also die eigentlich wenig technisches Gefühl haben
und die das quasi einfach lernen können von Leuten wie dir?
Ja, also zunächst mal gibt es eine Programmiersprache,
in der man, oder eine Konfigurationssprache, besser gesagt,
in der man die Infrastruktur beschreibt.
Das, die nennt sich HCL, HashiCore Configuration Language.
Terraform speichert lokal den Zustand der Infrastruktur ab,
um hinterher diesen Abgleich zu machen zwischen dem,
wie soll denn mein neuer Soll-Zustand sein und wie ist der derzeitige Ist-Zustand?
Und was Terraform auch macht, ist die Abhängigkeiten aufzulösen.
Und das kennt man auch so aus dem Linux-Umfeld von Paketmanagern,
wo dann der Paketmanager weiß, das Paket B hängt von Paket A ab
und das muss ich, demzufolge muss ich B zuerst installieren.
Und so funktioniert das hier auch, wenn ich jetzt abhängige Ressourcen habe,
eine, ein Festplatten-Volume und ich möchte eine Maschine aufsetzen,
mit der dieses Volume verknüpft ist,
dann wird das in der richtigen Reihenfolge ausgerollt,
sodass es dann auch funktioniert.
Und darum kümmert sich Terraform automatisch, dass das klappt.
Oder meckert zum Beispiel auch, wenn man jetzt so genannte Zirkelbezüge hat,
also wenn A von B abhängt, B von C und dann wiederum der Kreis geschlossen wird hin zu A.
Okay, also ich kenne die Zirkelbezüge nur von Excel,
aber ich glaube, dass sie in der,
in der Terraform-Umgebung wahrscheinlich etwas kritischer sind als, als in Excel.
Gut, wobei, wenn ich einen Controller fragen würde,
der würde wahrscheinlich sagen, in Excel könnte das auch kritischer sein.
Ebenso, oder so gehst du baden, ne?
Ja, stimmt. Okay, also Zirkelbezüge werden aufgelöst.
Ähm, warte mal ein Stück zurück.
Für mich, du hast ja gesagt, ähm, ich definiere einen Sollzustand
und Terraform gleicht immer ab, ähm, quasi von einem Ist zum Sollzustand.
Jetzt hätte ich gesagt, äh, ich will den Sollzustand sofort haben.
Warum muss da noch was abgeglichen werden?
Also, man benutzt Terraform ja nicht nur initial,
um die Infrastruktur aufzusetzen beim ersten Mal,
sondern auch, um sie weiter zu pflegen.
Und wenn ich dann Änderungen vornehme,
dann werden entsprechend nur diese Änderungen ausgerollt
und die Komponenten der Infrastruktur abgeändert,
an denen ich Modifikationen vornehme.
In einer Cloud-Umgebung kann das zum Beispiel auch heißen,
eine Instanz mit mehr Speicher oder mit größerer Festplatte anderer CPU.
Was dann sogar im laufenden Betrieb, ja, innerhalb von wenigen Sekunden umsetzbar ist,
dass ich sage, ich möchte meine Festplatte beibehalten,
möchte jetzt aber auf eine Instanz mit mehr Speicher oder besserer CPU wechseln.
Ja, ähm, jetzt bin ich doch neugierig, weil das klingt ja dann so,
als ob Terraform immer noch dieses Modell zugrunde legt,
dass es eigentlich langlebige Ressourcen gibt.
Irgendwie langlebige Server, die jetzt, ich sag jetzt mal, monatelang laufen
und du änderst halt dann und wann mal ihre Konfigurationen, aus welchen Gründen auch immer.
Ist das nicht ein Modell, das sich so ein bisschen mittlerweile überholt hat,
wenn ich an unveränderliche Infrastruktur denke,
wenn ich an die Risiken von Konfigurationsdrift denke oder sowas?
Jetzt mal ganz blöd gefragt, ist Terraform dann nicht jetzt schon überholt?
Also es gibt ja zum einen den Aspekt, den ich gerade genannt habe,
ich möchte mein Setup im Code festhalten,
möchte es in Form des Codes dokumentieren und weiterentwickeln.
Es geht natürlich mit Cloud-Umgebungen auch immer mehr dahin,
dass man gar nicht einen Server langlebig,
betreibt, sondern eher sagt, wenn dort etwas zum Beispiel nicht funktioniert,
ich habe ihn ja definiert in Form eines Terraform Setups,
kann ihn leicht produzieren, dann kann ich auch sagen, ich schmeiße so eine Instanz weg
und erzeuge sie einfach neu und tausche sie gegen die alte aus.
Oder wenn man jetzt an Cluster-Umgebungen denkt, Docker, Container, Kubernetes,
dass man einfach sagt, ich habe eine Vielzahl immer wieder ähnlicher Umgebungen,
versuche die auch möglichst simpel zu halten, auf ein Basis-Setup zu beschränken,
versuche dort auch gar keine Software zu installieren,
sondern das alles in Form von Containern zu betreiben,
dann kann es dahin gehen, dass ich halt einfach eine Vielzahl in meinem Cluster
von identischen Containern habe.
Oder ein weiterer Aspekt wären jetzt noch so etwas wie verschiedene Umgebungen
für Test, für Staging, für Entwicklung, für Produktion,
wo man einfach die Änderungen durch verschiedene Instanzen hinweg schleust
im Rahmen des Entwicklungsprozesses, vielleicht dann auch verknüpft
mit der Versionsverwaltung und entsprechenden Feature-Branches
oder Branchen.
Interventionsverwaltung, die ich dann ausrolle auf Kopien des jeweiligen Setups.
Ich denke so an meine Urzeiten in der IT zurück, ist ein bisschen länger her
und damals war Krawatte tragen noch wichtig.
Gerade wenn man als Berater zum Kunden ging, sollte man eine Krawatte anhaben.
Das ist natürlich für die Berater, die sich die Hände nicht schmutzig machen,
kein Problem gewesen.
Aber für die Berater, die Server aufgesetzt haben,
die vielleicht auch mal unter den Tisch krabbeln mussten,
war ganz blöd gesprochen.
Da sah das manchmal ein bisschen komisch aus.
Das heißt, das ist ja, wenn man es mal ganz platt formuliert,
ein schöner Vorteil.
Der Berater, der einen Server aufsetzt, der kann sich jetzt wirklich
mit Krawatte ins Büro setzen, wird er wahrscheinlich nicht machen.
Gibt es noch ein paar andere Punkte, die für einen Administrator,
sag ich mal, von Vorteil sind, wenn er über Infrastructure as Code arbeitet?
Denn ich hätte in den ersten Schritt, hätte ich jetzt sozusagen Angst,
dass mein Job in Gefahr ist.
Richtig.
Es gibt natürlich diese Administratoren, die versuchen,
sich unersetzlich zu machen und den Server über Jahre hinweg pflegen,
vielleicht sogar Änderungen vornehmen, den Kernel patchen,
irgendwo Dinge einbauen, die hinterher keiner mehr nachvollziehen kann
und wenn es diesen Entwickler nicht mehr gibt, reproduzieren kann.
Generell, wenn man jetzt an unser Thema DevOps denkt,
geht es ja auch darum, dass der Administrator und die Rolle des Entwicklers
zusammenwachsen und miteinander harmonisch zusammenspielen in einem Prozess.
Und beim Thema DevOps hat man ja auch die Anforderung,
in immer kürzeren Zyklen Releases auszurollen oder Entwickler möchten nicht.
In vielen Unternehmen ist es noch so, da muss ich irgendwie einen Antrag stellen
auf einem Server per Papier oder muss eine virtuelle Maschine beantragen
und dann muss ich begründen, warum brauche ich sie und später kriege ich sie.
Und mit dem ganzen Thema Cloud und solchen, die im Grunde self-managed sind,
wo ich selber mir Dinge aufsetzen kann,
wachsen diese Rollen des Entwicklers und des Admin immer mehr zusammen,
weil ja auch die Infrastruktur ja dort dokumentiert ist.
Vielleicht nimmt der Entwickler sogar dort Modifikationen vor
oder testet sie in seiner lokalen Umgebung auf seinem Rechner,
probiert dort das Setup auch schon aus und rollt es dann auf die spätere Infrastruktur aus.
Ja, du hast ein Stichwort gegeben und hast mich damit implizit daran erinnert,
dass ich ja die Eingangsfrage vergessen habe.
Wir fragen unsere Gäste ja immer, was verstehen sie unter DevOps?
Und insofern, da du jetzt das Thema DevOps angesprochen hast und ja,
ich würde sagen, wir holen die Frage einfach nach.
Helge, was verstehst du, wie würdest du DevOps beschreiben oder definieren?
Weil ich glaube, ein paar Punkte hast du ja eben ja auch schon gesagt.
Aber insofern, wie würdest du DevOps definieren?
Also es gibt ja diese klassische DevOps-Grafik, diesen DevOps-Seigel,
der aussieht wie so ein Endlichzeichen oder eine liegende Acht,
wo es zum einen die Schritte drin sind, die in der Entwicklung vorgenommen werden.
Das geht von der Spezifikation los, wo man noch gar nicht programmiert,
erst mal seine Anforderungen zu managen mit Tools wie Jira, Confluence
und was es dazu gibt mit Ticketsystemen, die Anforderungen zu beschreiben.
Dann geht es irgendwann in die Entwicklung.
Dann gibt es so Themen wie automatisiertes Testen.
Dann gibt es Themen, das ganze Rollen auf die Infrastruktur,
wo dann CI, CD-Tools für Continuous Integration, Continuous Delivery zum Tragen kommen,
damit dieses ganze Ausrollen einer Software eines neuen Releases automatisiert wird.
Und damit kommen wir dann in den Bereich rein, der klassischerweise vom Admin betrieben wird,
nämlich dann die Infrastruktur auch zu überwachen, zu monitoren,
also um den Betrieb stabil zu halten, Ausfälle automatisch zu erkennen,
Fehler vielleicht irgendwie automatisch zu beheben, wenn eine Instanz nicht mehr funktioniert,
sie automatisch neu zu starten.
Und natürlich dann auch irgendwie sowas wie Dashboards, Monitoring Tools.
Ja, okay. Das waren jetzt alles ziemlich viele technische Themen.
Das heißt, wenn ich das richtig interpretiere, ist für dich DevOps
zu einem sehr großen Anteil von Technik betrieben oder durch Technik umgesetzt.
Also ich komme jetzt aus der technischen Ecke, darum habe ich es vielleicht jetzt so formuliert.
Ich sehe aber auch den Aspekt, ja einmal das Zusammenarbeiten,
die enge Zusammenarbeit zwischen Administration und Entwicklung,
um halt Betrieb und Entwicklung näher aneinander zu bringen und sehe auch dort die Vorteile
in einfach kurzen Release-Zyklen, Automatisierung von Prozessen,
die dann in Projekten, wo ich sehr kurze Zyklen habe und immer wieder Releases bereitstellen wollen,
einfach extrem weiterhelfen. Ich erinnere mich noch an alte Zeiten,
wo ich bei einem ERP-Hersteller gearbeitet habe.
Da war es noch üblich, dass alle ein, zwei Jahre ein Release ausgerollt wurde.
Das ist heute gar nicht mehr denkbar.
Da werden Zwischenreleases gemacht und wenn es Richtung Cloud geht,
ja dann ist es ja eigentlich gang und gäbe, dass man auch von den Releases
gar nichts mehr mitkriegt, sondern eigentlich, wie man es von Plattformen wie Facebook singt,
das System einfach immer kontinuierlich weiterentwickelt wird oder in kurzen Zyklen entwickelt wird.
Ja, aber wenn wir jetzt gerade einen Techniker, ich sage jetzt mal Techniker, hier an Bord haben im Podcast,
was erlebst du denn, wenn Entwickler und Administratoren zusammenarbeiten?
Der eine muss auf den anderen zugehen. Was sind denn deine Erfahrungen?
Wie reagieren denn diese Experten? Weil dann menschelt das ja auch.
Ja, das ist dann schon natürlich erstmal, jeder sieht dann irgendwo sein Hoheitsgebiet bedroht
oder sagt, das zählt ja eigentlich gar nicht zu meinen Aufgaben, das jetzt auch noch zu tun und mich damit befassen zu müssen.
Da ist, glaube ich, einfach eine gewisse Phase erforderlich, um das Team dafür zu begeistern,
diese Bedenken auszuräumen einfach und die Vorteile dann zu sehen.
Also das erlebe ich auch in meinen Projekten. Das gilt auch für andere Themen wie Testautomatisierung,
dort den Nutzen und die Vorteile zu sehen.
Okay, und sie auch vielleicht gemeinsam zu erarbeiten, weil du kommst ja mit der Erfahrung, dass du quasi beide Seiten kennst,
dass du beide Seiten ja auch ansprichst.
Und kannst dann auch halt über die technische Ebene, über die technischen Aspekte die Vorteile aufsehen,
die du dir auch jetzt teilweise schon im Podcast hier aufgezählt hast.
Genau. Was zum Beispiel auch noch so Punkte sind, wenn man Entwicklung outsourced,
nearshoring betreibt oder offshoring in Indien oder sonst wo entwickeln lässt,
dass oft die Auftraggeber, wenn die jetzt eher managementlastig sind, gar nicht darauf achten,
dass sie auch den Code zur Verfügung haben, dass der Prozess automatisiert ist,
falls man mal mit dieser Einheit dann nicht mehr zusammenarbeiten möchte,
dass man wirklich über alle Dinge verfügt.
Und das fördert dieser Ansatz hier natürlich auch noch, wenn man alles in der Versionsverwaltung hat
und in der Lage ist, das Setup wieder zu reproduzieren, dass man dann diese Abhängigkeit auch zu den externen Dienstleistern hin verringert.
Ja, das leuchtet mir sehr ein, auch insbesondere dann im Zusammenspiel mit Continuous Integration,
dass man sagt, ich weise ständig nach, dass einerseits mein Produkt noch geht
und dass es zweitens auch immer noch zu meiner Plattform passt, zu meiner Infrastruktur passt,
die ich dann zum Beispiel mithilfe von Terraform definiert habe.
Genau. Und da spielen dann natürlich auch automatisierte Tests mit rein, die noch vor dem Deployment ausgeführt werden,
in Form von Unit-Tests oder Integrationstests, um einfach sicherzustellen, dass auch noch alles weiterhin funktioniert,
was dort so im Git eingecheckt ist, nicht Dinge fehlen.
Frage von mir nochmal, wenn wir jetzt wieder so ein bisschen auf das Thema Infrastruktur denken,
also, wie kann man mit dem AWS Code zurückkommen?
Wir reden ja unter anderem, oder wir reden ja über das Produkt Terraform.
Wie kann ich mir das vorstellen? Ich kenne so Produkte wie Docker, Ansible, Kubernetes, hast du ja auch schon eben angesprochen.
Wie muss ich mir da Terraform quasi gedanklich, wie muss ich das einsortieren?
Übernimmt das die, ersetzt das Docker beispielsweise? Also, wie muss ich mir das vorstellen bei Terraform?
Bei Terraform ist, oder bei Terraform liegt der Schwerpunkt drauf, muss man sagen, die Infrastruktur bereitzustellen
und weniger die Provisionierung von Software vorzunehmen, während Ansible versucht, beides abzudecken.
Da kann ich ja, kann ich auch Infrastrukturen aufsetzen oder mit Tools wie Chef oder so etwas.
Aber Terraform versucht eigentlich nicht, Software zu provisionieren, Pakete zu installieren, dann auf dem System oder Docker-Container zu installieren.
Das sind dann klassischerweise nachgelagerte Schritte.
Bei Terraform geht es erstmal darum, wenn ich eine Cloud-Umgebung nutze, zu definieren,
was brauche ich für Instanzen, was brauche ich für Volumes im Bereich Speicher,
was brauche ich für Rollen und Berechtigungen für User-Zugänge per SSH bereitzustellen.
Vielleicht gemanagte Services der Cloud-Anbieter mit einzubinden, wie gemanagte Datenbank-Instanzen
oder irgendwelche weiteren Services wie Elasticsearch.
Oder was es sonst noch so geben könnte.
Und nachgelagert auf dieser Infrastruktur ist dann zu sehen, das auf der Maschine Software zu installieren.
Sei es jetzt klassisch in Form von Paketen, die ich dort installiere oder in Form von Docker-Containern.
Um da nochmal ein bisschen nachzufragen und das vielleicht noch ein bisschen schärfer zu konturieren.
Bis jetzt hast du das ja immer so im Kontext von Maschinen erzählt.
Aber wäre dann Terraform zum Beispiel auch geeignet, um, ich sage jetzt mal, virtuelle Netzwerke aufzuspannen zwischen mehreren virtuellen Maschinen?
Oder ist das dann auch schon wieder etwas, was, sagen wir mal, nicht mehr zu Terraforms Spezialitäten gehört?
Ja, doch. Das gehört dort noch alles dazu.
Und je nach Cloud-Anbieter, vielleicht nochmal um auszuholen, bei Terraform gibt es sogenannte Provider.
Das ist sozusagen die Schnittstelle zu einem bestimmten Cloud-Anbieter oder zu einer bestimmten Virtualisierungssoftware.
Also zu klassischerweise Amazon, Azure von Microsoft, Google Cloud oder auch kleinere Anbieter wie Hetzner.
So etwas oder auch Virtualisierungsumgebungen, die man dort anbindet.
Und bei Amazon oder Azure oder Google Cloud hat man dort eine sehr große Bandbreite an Services, die man dort einbinden kann.
Wo dann auch wirklich alle weiteren Bereiche mit abgedeckt sind.
Und um zur Frage zurückzukommen, da zählt dann auch das Thema Netzwerk dazu.
Da zählt dann auch das Thema Firewall-Konfiguration dazu.
Wie möchte ich die…
Man hat vielleicht auch verschiedene Netzwerke, die man aufbauen möchte.
Wenn ich jetzt ein Cluster betreibe, möchte ich den beim Cloud-Anbieter zum Beispiel vielleicht in verschiedenen Rechenzentren,
in verschiedenen Regionen des Rechenzentrums betreiben, um Ausfallsicherheit zu gewährleisten, wenn jetzt ein Knoten dort nicht verfügbar ist.
Und dieses ganze Setup, wo soll das Ganze liegen, wie ist das Netzwerk technisch miteinander verknüpft, kann man dort auch definieren.
Okay, das heißt, vielleicht kann man es dann tatsächlich so zusammenfassen, dass Terraform, so wie du es ja eigentlich schon gesagt hast,
seine Stärken darin hat, salopp gesagt, das Blech im Keller zu verwalten, auch wenn es virtuelles Blech sein mag.
Und die Sachen, die obendrauf kommen, in Form von Paketen, in Form von dann vielleicht Applikationen oder sowas,
das ließe sich dann vielleicht sogar besser abbilden mit Hilfe von beispielsweise Docker oder mit Hilfe von beispielsweise Ansible oder sowas.
Ganz genau, darum würde ich auch sagen, es steht nicht in Konkurrenz, sondern es ergänzt sich eigentlich sehr gut.
Und was auch noch ein Vorteil ist, es steht ja auch Terraform in Konkurrenz.
In Konkurrenz zu den Tools der jeweiligen Cloud-Anbieter.
Und Terraform verfolgt halt den Ansatz, Multicloud fähig zu sein.
Und was ja die Tools der Cloud-Anbieter naturgemäß nicht sind, weil dort die Anbieter versuchen natürlich eine Bindung zu schaffen,
ein Login zu schaffen an die jeweilige Cloud-Plattform.
Wenn man mit Tools wie Terraform arbeitet, für die Infrastruktur und mit Docker, genau.
Das haben wir vorhin schon gesagt, die Administratoren haben, wenn sie sich dem Thema öffnen,
einen Vorteil, sie können vor der Konsole sitzen bleiben, sie müssen nicht unter den Tisch krabbeln.
Sie können sich ganz normal anziehen, müssen keine Krawatte oder können die Krawatte anziehen.
Du hast eben gesagt, ich werde unabhängiger von verschiedenen Cloud-Anbietern.
Ich kann das im Prinzip auch nutzen, um mit verschiedenen Cloud-Anbietern zu arbeiten.
Gibt es noch ein paar andere Punkte, die quasi Terraform von Vorteil sind, die wir auch insgesamt auf Infrastructure as Code ausdehnen können?
Also ein Punkt ist natürlich so verschiedene Umgebungen, was ich vorhin schon mal ausgeführt habe,
wenn ich Entwicklungsumgebung, Staging, Produktion habe, immer wieder ähnliche Setups ausrollen will.
Oder ein Thema wäre jetzt wiederholte Verwendung ähnlicher Setups, wenn man jetzt irgendwie an Web-Agenturen oder so etwas denkt,
die immer wieder Content-Management-Systeme in Kombination mit anderen Komponenten einer bestimmten Datenbank,
vielleicht Suchmaschinen wie Elasticsearch verwenden.
Dann kann man halt so ein ganzes Setup, was ich immer wiederholt bei Kunden verwende, auch automatisiert duplizieren und dann erneut ausrollen.
Dann generell natürlich Thema Testumgebungen aufsetzen, einen Server einfach mal so und noch mal so aufsetzen, wie er woanders läuft.
Okay. Wir hatten ja den Punkt Dokumentation als Vorteil.
Jetzt würde ich gerne noch mal so ein bisschen in deine praktischen Erfahrungen einsteigen, weil du ja gesagt hast,
ich habe quasi Dokumentation in Form von Code. In deinen Projekten, ist das wirklich eine Anforderung deiner Auftraggeber,
dass man das wirklich umsetzen kann? Sehen die das auch als Vorteil oder ist das einfach nur so ein Marketing-Gag,
zu sagen, hey, wir müssen nicht mehr dokumentieren. Wir haben die Dokumentation in Form von Code.
Also ist das wirklich aus deiner Erfahrung heraus ein wirklich genutzter Vorteil?
Also erstmal hängt es natürlich vom…
sage ich mal, Reifegrad und Wissensstand der Kunden ab, ob man erst diese Vorteile erläutern muss
oder ob sie schon sagen, was ich nicht… Startups sind ja vielleicht eher technikaffin, wo sie dann schon sagen,
wir wollen so etwas, wir wollen Kubernetes, wir wollen Infrastructure as Code, wir wollen das in einer Cloud-Infrastruktur betreiben.
Und andere Softwareanbieter, die schon sehr lange am Markt sind, aus alten Zeiten gewachsen sind,
die sehen dann vielleicht diese Vorteile noch nicht.
Die dann aber, wenn es auch darum geht, Änderungen durchzuführen, Infrastruktur vielleicht auch zu konsolidieren auf eine Cloud-Plattform
oder generell die Migration erstmal in die Cloud zu vollziehen.
Und dann spielt es dort natürlich dann seine Vorteile aus, die ich eben auch schon genannt hatte,
dass ich dann eben sehr schnell Umgebungen reproduzieren kann, wiederholt aufsetzen kann.
Und dort…
Wenn es Probleme gibt, natürlich auch irgendwie viel schneller reagieren kann.
Jetzt frage ich mich gerade eins.
Also ich meine, wenn ich auf der grünen Wiese anfange, wenn ich zum Beispiel ein neues Startup habe oder sowas,
dann leuchtet mir das sehr ein, dass man vielleicht direkt sagt, gut, wir machen es gleich von Anfang an richtig und wir führen Terraform ein.
Aber wie gehe ich denn jetzt vor in einer gewachsenen Infrastruktur mit einem Unternehmen, das schon Jahrzehnte alt ist,
das natürlich auch schon seit was weiß ich wann irgendwie verschiedenste Jahre ist.
Und das ganze Produkt im Rechenzentrum oder vielleicht sogar mittlerweile in der Cloud hat.
Wie kriege ich denn da mit Terraform sinnvollerweise den Fuß in die Tür?
Was es gibt in Terraform ist die Möglichkeit auch, wenn ich schon eine Umgebung in der Cloud habe,
auch dort entsprechend diesen Ist-Zustand, wie er in der Cloud ist, dann auch zu importieren in Terraform.
Das heißt, ich kann meine Ressourcen, die ich schon bei Amazon angelegt habe, in ein Terraform-Setup importieren
und diesen Bezug dann erstmal herstellen zwischen meiner lokalen Definition der Infrastruktur
und kann sagen, diese Instanz oder diese Datenbank, die gibt es schon,
die ist unter diesem Namen bei Amazon angelegt, unter dieser ID angelegt.
Und dann kann ich auch ein bestehendes Setup in ein Terraform-Setup überführen auf diesem Weg.
Der andere Ansatz wäre halt, ich soll sagen, man zieht in die Cloud um oder man stellt sein Setup um.
Dann muss ich es ja neu aufsetzen und dann habe ich aber da natürlich auch den Vorteil,
dass ich dann anfange, mein Setup auch nachzudokumentieren und zu automatisieren.
Ja, jetzt kommt vielleicht eine ganz blöde Frage.
Aber wenn ich als Manager, nee, nicht als Manager, wenn ich als BWLer höre, ich habe eine Importfunktion,
könnte ich nicht auch oder macht es Sinn, wenn Terraform sich quasi meine Infrastruktur,
meine physische Infrastruktur automatisch anguckt und das genauso quasi importiert,
zumindestens die Beschreibung? Geht das? Macht das Sinn oder ist das eine abstruse Idee?
Also die komplette Beschreibung erzeugen geht nicht. Bei dem Import geht es eher darum, diesen Bezug herzustellen,
zu sagen, ich habe dort eine Instanz, die gibt es schon und jetzt definiere ich sie in dieser Konfigurationssprache
und sage dann, diese Ressource, die existiert schon und stellt dort die Verknüpfung her,
dieses ganze Setup jetzt automatisch zu generieren.
Aus einer Infrastruktur. Das ist mit Terraform so nicht möglich.
Ist denn die Frage dumm oder wäre das eine coole Sache?
Das wäre vielleicht initial eine interessante Sache.
Man müsste dann aber anfangen, auch Dinge zu modularisieren, zu parametrisieren.
Gerade wenn ich Setups wiederverwenden will, dann sollte man auch schauen, dass man diese Setups auch wirklich parametrisiert hat,
sprich in verschiedenen Umgebungen.
Mit einer gewissen Variation auch wiederverwenden zu können und da bietet Terraform dann Mechanismen wie Module zu bilden
oder gewisse Einstellungen zu parametrisieren, den Namen der Instanz, die IP-Adresse der Instanz, wie viel Speicher hat sie, welche CPU.
Also so gesehen ist es wahrscheinlich dann wirklich besser, dann eben manuell anzufangen und das Ganze manuell quasi nachzubilden,
um sich nicht, ich sage mal, gleich mit dem Start alles zu verbauen.
Also dann habe ich so verstanden, es macht Sinn, dass man dann sich einfach hinsetzt und das manuell erfasst, um Terraform auch richtig zu konfigurieren.
Ja, so ein bisschen so wie mit Tools, die auch es gibt, um eine Programmiersprache vielleicht in irgendwie eine neuere Programmiersprache zu überführen,
wo ich dann aber im Grunde natürlich auch alten Code von Programmiersprache A in Code der Programmiersprache B umwandle und dann eigentlich auch anfangen müsste zu refactoren, zu überarbeiten.
Ja, okay.
Wenn nur das alte Gewachsene dann überführt hätte in etwas Neues.
Ja, ich denke, der Vorteil von so einer Importfunktion besteht halt darin, dass man, man weiß zwar nicht genau, was drin ist, aber man hat immerhin mal einen bekannten und benannten Stand
und kann sich auf den beziehen, kann vielleicht auch wieder sich auf den zurück retten, wenn man irgendwie versucht hat, vorwärts zu schreiten und festgestellt hat, die Richtung war irgendwie die verkehrte.
Aber eine Importfunktion, die dann wirklich ein System auseinanderdröselt und das dann in eine,
und das dann versucht, den tatsächlichen Code umzumünzen, ich glaube, das läuft dann ein bisschen so wie mit Hieroglyphen oder sowas.
Du siehst dann da irgendwie so eine Säule und da stehen dann halt irgendwie Zeichen drauf und weißt schon, naja, das ist irgendwie ein Vogel und das da drüben ist ein, was haben die denn noch, die Eulen und sowas.
Aber du hast keine Ahnung, was wir eigentlich damit sagen wollten. Ich glaube, das wäre das, was dann passieren würde.
Okay. Ich habe ja gesagt, ich stelle die doofen Fragen und lerne heute auch was. Okay.
Ich mache dann die doofen Analogien, können wir uns da drauf einigen.
Okay, gut, okay. Du hast eben schon so ein bisschen…
darauf angesprochen oder wir sind ein bisschen in die Richtung gegangen, wo Terraform zum Einsatz kommt.
Hast du es schon auch mal erlebt, dass quasi in deinen Projekten Terraform zum Einsatz kommen sollte, wo du gesagt hast, das macht gar keinen Sinn?
Also wenn ein stabiles Setup da ist, wenn da eine gewachsene Infrastruktur da ist, die läuft, die funktioniert und die auch vielleicht sogar schnell auf Änderungen reagieren kann,
ist dir so etwas schon mal passiert, dass du gesagt hast oder hättest, Mensch, eigentlich müssen wir das gar nicht in Terraform überführen?
Ja, die Fälle gibt es durchaus und das ist halt gerade, wenn ich sehr gewachsene, sehr stabile Umgebungen habe, wenn es jetzt nur um den Betrieb einer Software geht
oder vielleicht auch um Software, die man gar nicht selber entwickelt, die lediglich auf diesem Server betrieben wird, könnte jetzt sein ein Content-Management-System
oder könnte sein ein webbasiertes ERP-System oder ein…
CRM-System, wo es einfach nur darum geht, diese Software zu betreiben und dort vielleicht vorhandene Update-Mechanismen der Hersteller zu benutzen, dann macht so ein Setup weniger Sinn.
Wenn es aber darum geht, dass ich wirklich an Software entwickle, dann spielt Terraform eigentlich immer Vorteile aus, wenn es nicht nur rein um den Betrieb geht,
sondern um die Verknüpfung mit Entwicklung und dort einfach schnell und agil zu werden.
Da werde ich jetzt immer an dich denken, Helge, wenn ich in unserem Phoenix-Projekt…
in unserer DevOps-Simulation, da gibt es so ein Fast-Deployment-Tool, was wir dann quasi spielen.
Das heißt, dann kommt dann der Chef und sagt, hey, ich war auf einer Messe und ich habe da so ein tolles Tool gesehen, das müssen wir unbedingt einführen.
Und da werde ich jetzt immer an dich denken, weil es gibt Teams, die verstehen das und dann gibt es Teams, die sind ganz überrascht, dass man ja auch Dinge automatisieren könnte.
Das heißt, da hat der Chef eigentlich den richtigen Riecher gehabt, aber wie gesagt, da werde ich jetzt immer an dich denken.
Jetzt haben wir gesagt oder ich habe eben so ein bisschen darauf abgezielt, was es bedeutet, wofür Terraform nicht so unbedingt seine Vorteile ausspielen sollte.
Gibt es noch ein paar andere Punkte, die man oder wo du sagen würdest, Mensch, die profitieren genau nicht von Terraform.
Wir haben ja davon gesprochen vorhin, es gibt Administratoren, die natürlich vielleicht ihre Server so wie so ein Haustier pflegen.
Also wenn was krank ist, dann versuchen sie das zu gesunden und so weiter.
Also gibt es noch andere Aspekte, noch andere Stakeholder, wie wir sie so gerne nennen, die eigentlich eher quasi gegen Terraform wären, weil sich für die etwas zum Negativen verändert?
Also es gibt natürlich zum einen Dinge, wo Terraform einfach eine Nummer zu groß wäre, wenn ein klassischer Mietserver auch ausreicht oder ein Webspace und man damit leben kann, dann wäre Terraform aus meiner Sicht einfach oversized.
Und es spielt natürlich seine Vorteile auch in Cloud-Umgebungen oder in virtualisierten Umgebungen.
Könnte jetzt auch die Private Cloud sein mit so etwas wie OpenStack, wo ich dann eine Cloud-Umgebung bei mir lokal betreibe.
Da spielt es seine Vorteile aus, wenn ich wirklich auch Maschinen über eine Cloud ähnlich oder über eine Virtualisierungsinfrastruktur dann auch schnell und automatisch aufsetzen kann.
Weil die Voraussetzung für Terraform hatte ich ja vorhin gesagt, ist dieser sogenannte Provider, den man so nennt.
Wenn man sich vorstellen kann, wie ein Treiber zu einer Infrastruktur und wenn diese Infrastruktur gar nicht dynamisch ist oder veränderbar ist, dann kann ich Terraform natürlich auch nicht nutzen.
Das bedeutet, und das liegt wahrscheinlich auch ein bisschen nahe, je größer meine Umgebung ist, desto wertvoller wird Terraform auch irgendwie.
Wegen der Maschine hier und der Maschine da. Lohnt sich die Mühe nicht? Höre ich das richtig?
Also ich habe es auch eingesetzt schon wirklich für einzelne Server.
Zum Beispiel meine Webseite.
Die habe ich ja auch betrieben auf einem Server bei Amazon, der mit Terraform aufgesetzt ist, wo ich dann das Ganze in Kombination mit Docker-Containern nutze.
Das heißt, ich habe dort mein, in dem Fall ist es ein WordPress, habe ich dann auch mit Docker virtualisiert und das ganze Setup automatisiert und betreibe das dort entsprechend.
Und da ist dann natürlich auch sehr einfach mal zu sagen, ich brauche jetzt eine größere Instanz, ich habe mehr Traffic auf meiner Webseite, meine CPU, mein Speicher reicht mir nicht mehr aus.
Dann kann ich dort im Betrieb diese Änderungen vornehmen.
Oder wenn es jetzt darum geht, ich bin mir bei einem neuen Release von WordPress unsicher, spielt das noch mit meinen ganzen Plugins zusammen?
Dann möchte ich mir vielleicht erst mal diese Instanz duplizieren, mir eine Testumgebung schaffen, dort alles nochmal auf, die Docker-Container dort dann nochmal aufsetzen und gucken, läuft dort alles?
Würde es funktionieren, wenn ich jetzt auf das nächste WordPress-Major-Release gehen würde?
Okay, wenn wir jetzt mal so ein bisschen nochmal überlegen.
Oder ich versuche ja trotzdem.
Zumindest in dem Podcast jetzt hier, wenn wir jetzt keinen Werbepodcast für Terraform machen, natürlich fällt das vielleicht quasi ab.
Wenn man jetzt mal überlegt, so eine Situation, eben ein, ich sage mal, ein normales und ein normales Unternehmen, eine handelsübliche Größe, die jetzt sagt, okay, wir möchten jetzt unsere Infrastruktur quasi as a Service, also wir möchten eine Infrastruktur as a Service bereitstellen wollen,
das mit Terraform in Code überführt.
Wie würde man das tun?
Also gibt es ein paar Vorgehensweisen, die du bei Terraform kennst, die du von Terraform her empfehlen würdest, die du auch gelernt hast, die man übertragen kann auf jedes andere Infrastructure-as-a-Code-Projekt?
Also erstmal würde ich als Empfehlung mitgeben, einfach zu starten, nicht jetzt von vornherein versuchen, alles zu parametrisieren, zu modularisieren, sondern sich erstmal heranzutasten, erstmal anfangen mit einem relativ einfachen Projekt.
Ja, genau.
Und dann ist es dann auch so, dass man sich mal anschaut, wo lohnt es sich zu parametrisieren, wo lohnt es sich, Module zu bilden, wo habe ich Wiederverwendbarkeit, ähnlich wie es auch in der Softwareentwicklung ist, wo man auch bei der Architektur Schritt für Schritt anfangen sollte und nicht von vornherein die nach der perfekten Architektur suchen sollte, die dann vielleicht hinterher gar nicht trägt.
Zweite wichtige Regel ist, keine Änderungen an dem Tool, an dem Infrastructure-as-a-Code-Tool vorbei.
Das heißt dann nicht auf dem Server.
Aber doch noch über die Oberfläche etwas umzustellen, weil es mal schnell gehen muss oder weil es so praktisch ist, die Oberfläche zu nutzen, weil dann könnte man in Probleme laufen, auch wenn der Zustand dann vielleicht noch dann wieder abgeglichen werden kann.
In manchen Fällen wäre es dann vielleicht aber nicht mehr möglich, weil dann irgendwie doch Bezüge verloren gehen und die Dokumentation natürlich verloren geht.
Da muss ich jetzt aber doch nochmal nachfragen, weil wenn jetzt die Hütte brennt, soll ich dann wirklich erstmal an der Terraform-Config rumbasteln und so?
Kann ich dann nicht mal eben in die Web-Oberfläche reingehen und da in Gottes Namen ein paar neue virtuelle Maschinen aufstellen oder virtuelle Netzwerk-Interfaces einrichten oder was auch immer da halt Not tut?
Also wenn es jetzt wirklich brennt, kann man natürlich auch bei Amazon aus einem Backup einer Instanz sehr einfach eine zweite herstellen.
Und in dem Fall würde ich sagen, kann man durchaus auch diesen Notfallmechanismus, den Amazon dort bietet, aus dem Backup jetzt wieder die Instanz so herzustellen, dass sie dann gleich wieder läuft, nutzen.
Ansonsten würde ich aber empfehlen, einfach auch darauf zu achten, dass mein Setup so ist, dass ich im Fall der Fälle schnell eine, die Instanz nochmal aufsetzen kann, so wie man es auch bei einem Backup, ein Backup nützt mir halt nichts, wenn ich nie die Rücksicherung getestet habe.
Und so ist bei Infrastructure as Code, muss ich getestet haben, dass ich es auch noch so, dass die Infrastruktur auch noch so neu erzeugt wird und nicht nur, wenn ich sie ein Jahr lang fortgepflegt habe, vielleicht meine Änderungen alle funktioniert haben.
Naja, das ist natürlich klar.
Also die Administratoren, die ich kenne, die testen das immer sehr, sehr gerne.
Also die, ja Luca, du guckst jetzt so komisch, das war der Ironie-Modus jetzt hier.
Also ich meine, gut, ich sage ja in meiner Entschuldigung immer Anwesende ausgeschlossen.
Also wenn ich jetzt hier gegen Administratoren, ja weiß nicht, piekse, dann ist das natürlich jetzt immer nicht persönlich gemeint.
Aber insofern, klar, man sollte das testen.
Gibt es da irgendwo Mechanismen, die ein Terraform bereitsteckt, die das Ganze einfach machen oder abwerten?
Absichern oder ist das einfach Standard?
Also was es noch gibt, nicht von Terraform selbst, aber von anderen Anbietern, die das Ganze Open Source gestellt haben,
dass es auch Test-Tools gibt für Infrastruktur, wie man es aus der Programmierung kennt mit Unit-Tests,
wo man dann auch Infrastruktur testen kann und gucken kann, wenn ich eine Infrastruktur ausgerollt habe,
sind dann die Komponenten, die ich dort erwarte, die Dienste verfügbar auf meiner Infrastruktur.
Dann könnte man hergehen mit Autos.
Diese Infrastruktur einfach über einen CI-CD-Server, über einen Automatisierungs-Server wie Jenkins oder so etwas wie GitLab.
Auch einfach automatisiert aus dem Setup zyklisch immer wieder zu erzeugen, zu gucken, laufen meine Tests durch, sind die Dienste danach verfügbar.
Also im Grunde kann ich, weil Infrastructure as Code bedeutet, ich programmiere meine Infrastruktur,
alle Mechanismen, die man aus der Softwareentwicklung oder aus der agilen Entwicklung kennt, auch dort übertragen auf die Infrastruktur.
Jetzt nochmal so.
Irgendwie ein paar Namen parat von entsprechenden Tools?
Es gibt ein Test-Tool, das kommt von der Firma Grundwork.
Die haben das Open Source gestellt.
Den Namen habe ich gerade nicht griffbereit.
Den können wir noch nachliefern.
Ich wollte gerade sagen, das packen wir einfach in die Shownotes.
Aber das ist bestimmt für viele wieder spannend, weil du hast mir da das Stichwort tatsächlich etwas weggenommen, Dirk.
Ich war nämlich auch total gespannt darauf, wie ich dann…
Wie man diese Mechanismen, die man auch aus der sonstigen Softwareentwicklung kennt, übertragen kann auf Infrastructure as Code.
Also, weil ich würde mir dann vorstellen, dass ich auch das dann, dass ich auch Terraform zum Beispiel testen werde, den Code, den ich da habe.
Dass ich womöglich sogar Testgetrieben entwickle.
Sind das Sachen, die dir begegnet sind?
Ist das Stand der Technik?
Also, was üblich ist, ist zu versionieren.
Automatisierte Tests auszuführen, würde ich jetzt eher als exotische bezeichnen.
Das wird seltener gemacht und auch das automatisierte Deployment, ja, wird auch seltener benutzt, weil ich sie auch auf der Kommandozeile ausrollen kann.
Das macht, macht aber natürlich auch Sinn, es durch zu automatisieren und darauf zu achten, dass ich wirklich GitOps betreibe, dass ich eigentlich nur Code in meine Versionsverwaltung stelle und dann alles Weitere dann den CICD-Server machen lasse.
Wenn ich so auf die Uhr gucke, dann…
Kommen wir so langsam zum Ende, zumindest unserem geplanten Ende.
Und wir fragen ja eigentlich immer auch nochmal die Gäste in unserem Podcast, ob es doch irgendetwas gibt, was wir noch nicht besprochen haben.
Also, gibt es noch irgendetwas, was du noch loswerden möchtest zu dem Thema Fachlichkeit, zum Thema Infrastructure as Code, was du jetzt noch, obwohl du nochmal einen kleinen Block kriegst dafür?
Warte ich, wir haben schon viele Bereiche jetzt.
Angesprochen, was ich wirklich nahelegen würde, ist die Kombination dann auch mit Docker-Containern, mit Virtualisierung zu nutzen und deren Vorteile dann zu nutzen.
Das muss nicht immer ein Kubernetes-Cluster sein, das könnte jetzt auch schon sein, einfach ein einfacher Docker-Container, die ich auf einer Maschine dann ausrolle.
Kleiner Tipp vielleicht noch in dem Zusammenhang, es gibt ein sehr schönes Linux-Betriebssystem, das nennt sich Flatcar-Container-Linux.
Das ist ein…
Stammt ab von dem ehemaligen…
Core-OS, was dann an Red Hat verkauft wurde und Red Hat pflegt das jetzt selber so nicht in der Form weiter und das wird von einer deutschen Firma, die glaube ich in Berlin ansässig ist, jetzt weiter betrieben.
Und dieses Flatcar-Container-Linux ist im Grunde ein ganz minimalistisches Linux, was keinen Paketmanager hat, was wartungsfrei betrieben werden kann, wo der Kernel immer wieder automatisiert aktualisiert wird und wo ich im Grunde alles, was ich dort aufspiele, in Form von Docker-Containern aufspiele.
Das heißt, um dieses Betriebssystem…
muss man sich nicht kümmern, es läuft, aktualisiert sich automatisch und ist nahezu wartungsfrei und eignet sich, wenn ich jetzt keinen, eignet sich dann schon, auch wenn ich keinen Kubernetes-Cluster betreiben will, wo ja doch einiges Wissen zu notwendig ist, wenn man nicht ein fertiges Setup oder einen Anbieter, der das als Managed Service anbietet, nutzt.
Und da kann man sehr einfach auch mit einem Knoten in eine, sage ich mal, Container-basierte Docker-Umgebung starten für die Produktion.
Sehr schön, gut. Wir hatten ja eben schon den Punkt, dass wir ein paar Tipps von dir in die Shownotes packen.
Vielleicht gibt es noch ein paar andere Fragen an dich. Wo findet man dich denn? Also wo kann man Kontakt zu dir aufnehmen?
Meine Webseite heißt container.sh, Container mit K geschrieben. Das ist eine Anspielung auf Kubernetes.
Und das ist H für die Shell, weil ich mich halt mit Infrastructure as Code, wo man auf der Shell arbeitet…
…auf der Kommandozeile arbeitet, befasse. Daher dieser Name und was ich dort anbiete, ist alles rund um das Thema DevOps, DevOps-Automatisierung.
Ich unterstütze Unternehmen bei der Einführung von DevOps, bei der Einführung von agilen Prozessen.
Ich biete Mentorings an für Entwickler, unterstütze Entwickler dann, sich mit diesen Tools vertraut zu machen, das Wissen zu erwerben.
Biete auch Tutorials an, biete ein Newsletter an auf meiner Webseite und plane für die Zukunft.
Auch noch weitere Angebote im Bereich Infrastructure as Code.
Tja, also ich finde das mit dem Mentoring klingt sehr, sehr interessant, weil da natürlich die Chance ist, quasi zu einer Vertrauensperson, die aber auch Experte ist, mit dem einfach in so ein paar Gespräche einzusteigen und diese Veränderung, über die wir ja mit DevOps eigentlich immer sprechen.
Wir reden ja über, natürlich über Technik, aber wir reden auch über Veränderung. Wir reden über andere Arbeitsweisen.
Wir reden darüber, dass der Job anders.
Und da denke ich, ist es wahrscheinlich ganz, ganz hilfreich, jemanden zu haben, der das sozusagen schon mal durchgemacht hat und der einen dann auch versteht und einem auch technische Tipps geben kann.
Genau, und ich habe dort auch bewusst nach einer anderen Form gesucht, als diese klassische Schulungen abdecken, wo man irgendwie seine Entwickler in ein Hotel schickt für zwei, drei Tage und die dann in einen Seminarraum setzt und dann versuchen sie an ihrem Rechner zwei Tage etwas auszuprobieren.
Vielleicht haben sie hinterher gar nicht die Möglichkeit, es in der Praxis dann auch anzuwenden.
Und in einem so längeren Mentoring-Prozess kann man den Entwickler wirklich längerfristig begleiten und immer wieder, wenn er Nachfragen hat, wenn er Bedarf hat an Schulungen, an Erklärungen oder vielleicht an einem Review dessen, was er gemacht hat, dann kann man ihn immer wieder unterstützen und ihn in diesem Prozess begleiten.
Gut, Helge, ich bedanke mich. Also ich habe jetzt keine Fragen mehr. Ich habe, glaube ich, genug kluge, aber auch genug dumme Fragen gestellt.
Also ich würde mich jetzt bedanken bei dir für diese, naja, es war ja fast schon eine Stunde, zumindest für die vielen, vielen Aussagen und ich glaube, ich kann das ganze Thema jetzt einfach noch ein bisschen besser einsortieren. Also von meiner Seite aus herzlichen Dank.
Ja, ich bedanke mich auch bei euch. Hat großen Spaß gemacht mit euch und fand es auch interessant heute die Kombination, weil ihr ja jetzt eher von der Beratungsseite herkommt, auch mal euren Blickpunkt auf das Thema zu hören und was ich jetzt auch noch so mitnehme, diesen Aspekt dann auch bei mir.
Ja, das ist, ich glaube, damit würdest du deinen Kunden einen gewaltigen Dienst erweisen, weil Jammel ist gleich geschrieben, aber die Gedanken, die man sich dahinter machen muss und die menschliche Seite, da, glaube ich, passieren die wirklich spannenden Sachen.
Aber ich möchte mich auch ganz herzlich bedanken, dass du bei uns im Podcast warst heute. Das war sehr spannend, war sehr interessant und ich bin zwar ein größerer Technik-Daddler als der Dirk, aber ich habe trotzdem auch sehr viel gelernt.
Insofern vielen Dank für alles, was du uns heute erzählt hast.
Sehr gerne.

„Workaround for Joe’s Problem“

Heute hörte ich von einem Team das jeden Tag eine .csv Datei mittels FTP herunterlädt, drei Zeilen löscht, und sie dann manuell woanders hin hochlädt.

Wieso? Weil eines Tages diese drei Zeilen nicht richtig in eine Datenbank geladen werden konnten, und ihr Workaround war, diese drei Zeilen eben zu löschen.

Und das machen sie nun Tag für Tag… seit 2009.

Teils natürlich auch einfach deshalb, weil sie in einer regulierten Industrie arbeiten, und dieser Prozeß wurde irgendwann mal dokumentiert und somit verpflichtend.

(Er ist dokumentiert als „workaround für Joe’s Problem“. Keiner kann sich erinnern, wer dieser Joe eigentlich war.)

Diese Geschichte ist einerseits amüsant, andererseits aber auch lehrreich.

Ähnliche Vorgänge finden sich in praktisch jeder Organisation. Seltsame Prozesse, die irgendwann von irgendwem eingeführt wurden, und mittlerweile selbst ein Eigenleben entwickelt haben.

Und unser aller Reflex ist vermutlich, kurzerhand den beschriebenen Prozess zu automatisieren. Das ist sicherlich eine gute Idee: die Qualität wird steigen (weil keiner mal versehentlich was verkehrt macht), die Mitarbeiter Zeit und mentale Kapazität zurückgewinnen für wichtigere, wertschöpfendere Dinge.

Andererseits ist das aber vielleicht gar nicht so eine tolle Lösung: einen etwas merkwürdigen Prozeß haben wir jetzt auch noch verewigt!

In der Tat frage ich mich, ob das dem Workaround zugrundeliegende Problem nicht in den letzten 12 Jahren irgendwann den Weg des Dodo ging. Und falls es noch existiert: ob es nicht eine gelungenere Möglichkeit gibt, diesem Problem zu begegnen, z.B. durch geeignete Validierung in der Datenbank, oder was einem auch sonst so einfällt.

Diese Geschichte weist neben der unmittelbaren Moral (automatisiere es!) aber noch eine zweite, etwas indirektere auf: auch eigenwillige Lösungen sind stets Reaktionen auf reale (oder als real empfundene) Probleme, entwickeln dann aber ein Eigenleben abseits dieser Probleme. Und können somit lange weiterexistieren, nachdem das Problem aufhörte, eines zu sein.

Insofern ist der erste Schritt einer Verbesserung durch Automatisierung ein ganz anderer: sich zu überlegen, ob das Problem weiterhin besteht und ob es weiterhin so gelöst werden muß.

Automation kann eben nicht nur segensreich zur Verringerung der Arbeitslast beitragen, sondern manchmal auch Ungünstiges erst recht zementieren.

DevOps ist keine IT-Philosophie, es ist eine Unternehmensphilosophie

„Unsere IT-Organisation führt jetzt DevOps ein“: famous last words. DevOps kommt aus der IT-Ecke, benutzt IT-Begriffe und -Denkweisen. Es ist also naheliegend, es als ein IT-Thema anzusehen.

Zugleich ist diese enge Auslegung eines der heikelsten Themen, die uns in unserer Arbeit regelmäßig begegnet.

Sei es in Schulungen oder in er begleitenden Beratung, die größten Schwierigkeiten zeigen sich erstaunlicherweise nicht in jenen Organisationsteilen, in denen DevOps eingeführt wird. Sondern an den Nahtstellen, wo die agile, DevOps einsetzende Organisation auf jene Unternehmensteile trifft, die sich eben nicht (oder noch nicht) umgestellt haben; seien es benachbarte Entwicklungsorganisation, das Controlling, die Unternehmensleitung, die Personalverwaltung oder gar der Kunde.

In einer Umfrage, die wir unter etlichen hundert IT-Verantwortlichen durchgeführt haben, zeigte sich das gleiche Bild: die größte Überraschung, so teilten viele mit, waren die Spannungen, die sich plötzlich außerhalb der IT auftaten.

Das ist ein derart überraschendes Resultat, daß ich es nochmal wiederholen möchte: die größten Schwierigkeiten mit einer DevOps-Transformation zeigen sich oft gar nicht innerhalb der IT-Organisation, sondern außerhalb davon.

Das klingt vielleicht wie eine schlechte Nachricht, aber eigentlich ist es ein gutes Zeichen: DevOps wirkt! Es führt zu so tiefgreifenden Änderungen darin, wie die IT-Organisation nach außen wirkt, daß andere Bereiche nicht einfach bei der Tagesordnung bleiben können. Sie müssen sich mit diesem Wandel auseinadersetzen: ein hervorragendes Zeichen dafür, wie groß der Unterschied tatsächlich ist.

Ob das nun heißt, daß Euner Controlling nun ein DevOps-Controlling werden muß, ist vielleicht die falsche Frage. Das Wichtige ist, daß Organisation und Prozesse zu den Veränderungen innerhalb der DevOps-Organisation passen.

Wenn auf der einen Seite die Budgetprozesse weiterhin davon ausgehen, zwei-Jahres-Pläne zu verfassen und diese dann systematisch abzuarbeiten, während auf der anderen Seite eine agile Organisation selbstbewußt darauf pocht, den maximalen Kundennutzen erst unterwegs zu erkennen und ihm Rechnung zu tragen — na dann muß es ja in Streit enden, unabhängig davon, wer überhaupt Recht hat!

DevOps demaskiert technische Schulden

Eins der großen Themen von DevOps ist Sichtbarkeit: Sichtbarmachen vorn Arbeit, von Zusammenhängen, von Abläufen.

Das ist sicherlich eine gute Sache, kann aber manchmal einen, sagen wir, beunruhigenden Nebeneffekt haben: DevOps Einführungen machen eben auch Dinge sichtbar, die nicht so schön anzuschauen sind.

Das mag verschiedenste Ebenen betreffen: von verbreiteten Schwächen der Unternehmenskultur bis hin zu unsauberem Handwerk einzelner Entwickler.

Konkret ist mir eine Situation in Erinnerung, in der ein Unternehmen continuous integration einführen wollte. An sich keine allzu große Sache, sollte man meinen. Sicherlich muß man etwas Energie hineinstecken, bis alles rund läuft, aber im Regelfall ist diese Umsetzung eher überschaubar.

Nicht so in einem bestimmten Team: dessen Produkt widersetzte sich standhaft allen Versuchen, die builds zu automatisieren.

Zug um Zug stellte sich nämlich heraus, daß sehr viele implizite Annahmen getroffen wurden: über die Art, builds anzustoßen; über Pfade, Nutzer und Rechte; über die Art, wie Parameter übermittelt wurden (auf der Kommandozeile, in Umgebungsvariablen oder in Dateien). Und nicht nur, daß diese Annahmen implizit waren und nun den Automationsentwicklern ohne Vorwarnung um die Ohren flogen, sondern jeder Entwickler hatte seine eigenen Vorlieben (…die sich bei manchen auch noch über die Zeit änderten).

Bald setzte ein allgemeines Grummeln über DevOps im Allgemeinen und Automation im Speziellen ein: kostet wohl doch mehr als von Automationsverfechtern gern angegeben!

Aber die Kosten entstanden natürlich im Wesentlichen nicht aus den Mühen der Build-Automation: sondern daraus, daß nun die technischen Schulden wieder beglichen wurden, die sich über einenm langen Zeitraum aufgebaut hatten.

(Ich weiß übrigens nicht, wie’s in dieser Geschichte ausgegangen ist — ich schied bald darauf aus dem Projekt aus).

Diese Geschichte ist insofern sehr erzählenswert, als sie einem oft beobachteten Muster folgt: die agilen / DevOpslichen Ansätze führen zu mehr Sichtbarkeit — und nicht alles, was man zu sehen bekommt, gefällt einem auch.

Die technischen Schulden waren natürlich schon vorher da, aber jetzt sind sie sichtbar, fühlbar, und müssen behandelt werden.

Vermutlich bringt jegliche Transformation solche Effekte mit sich, aber Agile mit seinem Fokus auf klare Konturen ist da vielleicht besonders… intensiv; im Guten wie im Schlechten.

Folge 52: DevOps in Small Companies with Jonathan Hall [EN]

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In this episode our guest is Jonathan Hall of Tiny DevOps. We invited him because he specialises in a very interesting and little-talked-about niche: DevOps for small companies.
DevOps is usually viewed in the context of large organisations. But what does DevOps look like in small organisations? Does DevOps make sense in this context? Is it even feasible?

In this episode, Luca and Falko from „DevOps auf die Ohren und ins Hirn“ are joined by Jonathan Hall from TinyDevOps. Jonathan shares his insights on adapting DevOps practices for small teams, emphasizing the importance of cooperation, continuous deployment, and cultural shifts in organizations. He challenges common perceptions about the role of QA and automation in DevOps, advocating for a more integrated and responsible approach by developers. The episode covers various aspects of implementing DevOps in small companies, including overcoming fears and resistance to change, the role of QA in a DevOps environment, and the effectiveness of continuous deployment.

Inhalt

  • Introduction and Background of Jonathan Hall
  • Jonathan’s Definition of DevOps and its Importance in Small Teams
  • Continuous Deployment and Its Impact on Developer Responsibility
  • The Role of QA in DevOps: From Testing to Advisory
  • Challenges of Implementing DevOps in Small Companies
  • The Concept of Blameless Postmortems and Learning Culture
  • Automating Deployment First vs. Automating Tests
  • Real-life Example of Transforming QA Roles
  • Recommendations for Small Companies Adopting DevOps

Shownotes

Find Jonathan at: https://jhall.io
He writes daily posts at: https://jhall.io/daily/

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

Welcome to a new episode of DevOps auf die Ohren und ins Hirn.
Or in English, DevOps from your ears straight to your brain.
Usually this is a German language podcast, but we sometimes make exceptions for international guests.
Today is one such exception.
My name is Luca and Gianni and I host this podcast together with my colleagues Dirk Söllner and Falco Werner.
We’re DevOps consultants, trainers and coaches trying to get teams to work together better and create better products for their customers.
Today it’ll be Falco and me running the episode and we’re joined by Jonathan Hall of TinyDevOps,
who specializes in bringing DevOps not to big corporations, but to small organizations or even sort of practitioners.
Hi Jonathan, thanks for being on the show today.
Hi Luca, thanks for having me. It’s a pleasure.
Did I summarize your line of work well or is there something you would like to correct me on?
Yeah, I think you did.
We get a lot of attention is paid to DevOps at FANG companies, Google and Netflix.
And that’s fun and exciting, but most of us never work in companies that large or that small.
So I try to focus on the other end of the spectrum, the small companies, you know, maybe a company of five people or ten people or even like you said, a solo practitioner.
I try to help those sorts of groups and those people do DevOps as well as possible.
Interesting. Now we have a stunning feature on the show where everybody who comes on comes on the show must give us their definition of DevOps.
So Jonathan, what’s yours?
It’s a team and it’s an engineer, of course.
I’m kidding. It’s not.
It’s neither of us.
It’s neither of those things.
My definition of DevOps, I like to, it’s an oversimplification, but I think it gets at the heart of what DevOps is about.
It’s one word cooperation.
DevOps to me is about Dev and Ops and other teams, QA and data science or whatever, cooperating towards the same business goal of delivering software.
I hear a lot of people talk about automation as DevOps or CI CD pipelines.
But I see that you can do those things if you still are not cooperating with each other.
You’re not really doing DevOps.
So to me, it boils down to are your different teams or different functions working together towards the same goal?
That’s how I like to define DevOps.
Oh, nice focus point.
Further, I’d like to say if you hear somebody talk about DevOps or job description, replace the word DevOps with cooperation.
And if it doesn’t make sense, they probably don’t understand DevOps.
Oh, that’s an awesome trick.
I’ve never heard of that.
That is not a bad way of looking at it, right?
Because, you know, I like to quip that, especially in job adverts, oftentimes DevOps is just a shorthand for an admin who can code badly.
Right.
Yeah.
If you see a job description for a DevOps engineer, replace the word DevOps.
Is it a cooperation engineer?
Not really.
They’re not engineering cooperation.
So there’s probably not really a DevOps engineer either.
It’s probably an admin, like you said, or an operations engineer or a CI, CD pipeline specialist or something like that.
And there’s nothing wrong with either of these things.
Of course not.
Yeah.
Just don’t call it DevOps.
Exactly.
Yeah.
I visualize if someone talks about a person, DevOps engineer, kind of like, I visualize it sitting on the wall of confusion between DevOps and helping to one side lower the height of the wall.
And maybe punching holes in it.
And maybe also, yeah, heaving packages that need to be deployed from the development side to the operations side, which is kind of like what cooperation or collaboration is about, right?
Exactly.
Yeah.
Yeah.
But that brings me to a good question, I guess, which is, does a small organization,
have walls of confusion, do small organizations even need DevOps?
Because it sounds like they shouldn’t.
Yeah.
I see what you’re saying.
We’ve already mentioned briefly the idea of solo practitioners doing DevOps.
And you can ask yourself the question, does it make sense if I’m a solo, maybe a solo founder, or maybe working on a hobby project, can I do DevOps?
Can I literally do it as a single person?
Am I cooperating with myself?
And maybe in the strictest sense, not really.
I don’t know.
It’s up to the dictionary writers to decide whether a person can cooperate with themselves.
But I certainly think you can take the mindset of DevOps, which is that DevOps should have their goals aligned to produce value for the customer.
I think you can do that.
And maybe in another sense, you automatically do that if you’re a solo practitioner.
I suppose you could imagine a way to throw something over that wall of confusion if you’re by yourself.
I don’t know what that would look like.
Maybe you write your code.
And then you leave.
And then you leave for a week and come back and then deploy it.
I don’t know.
So in that sense, maybe everybody who’s a solo practitioner already does DevOps in the strictest sense.
But if we go up just a step from there to two to five people, I definitely see this wall of confusion in companies I work with.
And part of it often is that these companies are trying to be bigger than they are.
They want to look like an enterprise.
So they set up their DevOps team or their operations team.
They have a team of two people or one person, maybe.
And they have their developers on another team.
And the developers write their code.
And then they package it.
And they send it over to the operations guys.
Maybe they don’t need that.
But they feel like that’s the way enterprises do it.
So that’s the way they should do it.
So they sort of adopt this oversized mentality.
If it works for Google, it works for me, right?
Right, right.
Yeah.
And I think you bring up a good point about cooperating with yourself.
If it’s really just a one-person endeavor, then, you know, there’s still present you having to work together with future you.
Definitely.
Definitely.
Yeah, I really like that concept.
I’m glad you brought that up.
That you never really work alone, even if you’re working alone, right?
There’s always the present, the past, and the future yourself.
And when I write code today, one of my best teachers as a coder has been my past self and how stupid I was six months ago.
Oh, six months.
Try six hours.
Fair enough.
But, you know, what was I thinking back then when I did it that way?
Why did I design that code that way?
You know, that’s a great teacher when it comes to documenting your code and building even a CICD pipeline for a solo project.
It’s easy to think, oh, I don’t need CICD.
This is a simple thing.
I only change it once every three months.
And when I do, I can type the commands myself and upload it to the server or whatever.
Maybe it’s a hobby website or something.
But three months later, you’re going to forget what those commands were.
Maybe you put a readme or something like that.
But then you’re going to forget to update that readme when you change it.
Just put it in CICD as a pipeline.
It works as living documentation.
So that’s kind of what I focus on.
Those sorts of things when I’m working at the solo practitioner level.
You can still do these things because, as you said, you are working with your future self, if nobody else.
And your future self will really…
You will really appreciate that CICD pipeline when it comes time to deploy something and you’re in a hurry and you don’t remember what was that thing you did last time that fixed it.
I was just wondering, do you have something…
Do you have an example to illustrate this situation where you really have a lack of communication or where you have worlds of confusion within even, I don’t know, a five-person shop or something?
Let me think about that.
Yes.
So a client I was working for…
Just a few years ago, a couple of years ago, actually.
They were a small startup.
They were growing quickly.
But when I joined them, I think there were about eight engineers.
So it wasn’t quite a five-person shop.
But it was very compartmentalized.
The CTO had designed the architecture of the system and designed it for a team of probably 100 people.
So there were maybe too many moving parts, too many microservices.
But that did mean that we had these teams working in small, isolated areas.
And what should have been an API contract between teams really wasn’t.
It was a human barrier.
So when they needed to do something, they had to ask another person, can you do this thing for me or can you tell me how to do it?
And that other person was, if you’ve read the Phoenix Project, what was the character’s name?
Brent?
Brent, yes.
This was the Brent of our company.
Everybody went to Brent for these things rather than an API contract or whatever.
So that definitely happened in that scenario.
And this…
And this…
And this solution was…
To the extent that we found a solution, it was adopting some of these DevOps types of practices.
We did institute a sort of platform team.
We called it an SRE team.
Some people incorrectly called it a DevOps team.
But they managed the infrastructure.
They provided the…
They also provided the core libraries that were used for logging and monitoring and things like that.
So they provided that sort of infrastructure that everybody…
Everybody else then could use.
Okay.
So since we’re already starting down that road.
So how would you do DevOps at a small organization, especially in contrast to a large organization where you probably have like a bunch of teams, maybe one per microservice or something?
If you’re just three guys, what does DevOps look like?
Yeah.
Well, before I answer that question, I’d like to talk about a related topic that I think is relevant to the answer.
And that is…
Yes, please.
I see two really, really high level ways that DevOps is usually implemented.
And if you come from a Scrum background, you’ve already had it drilled into your head that every team should be cross-functional.
And that tends to be the way a lot of Scrum practitioners approach DevOps.
So they put a DevOps engineer, so to speak, an operations person on each Scrum team.
And that’s fine.
That works.
But it only works for really small organizations.
As soon as you get past three to five teams…
…this cross-functional DevOps team model starts to break down because you have your operations knowledge scattered around all these teams.
And that’s when I think it makes the most sense to approach more of a platform team, which is more like what Google does with their SRE model.
The book Team Topologies talks about this approach.
And that’s what I did at this company I just mentioned, is we implemented an operations team that handled this platform and provided services to developers.
So…
So…
So, now to your question, how does DevOps differ between small and large organizations?
In large organizations, you almost certainly need to adopt some sort of platform approach.
You simply…
That doesn’t mean you can’t do a hybrid.
You might also have an operations person on some or even every team.
But they need some sort of central knowledge repository that I refer to as a platform team.
So large companies like Google and Netflix must do that.
If you’re a small company, maybe below 30, maybe even 50 engineers, you can maybe get away with this cross-functional approach.
If you’re three, you almost certainly should do the cross-functional approach.
It doesn’t probably make sense to have…
In fact, I’ll go out on a limb and I’ll say it doesn’t make sense if you’re only three engineers to split the responsibilities that way.
Because you’re just…
You’re going to have a bus factor of one if you do that.
I mean, either you have…
One developer and two operations people or you have one operations person and two developers.
Either way, you’re in trouble if somebody goes on holiday.
So if you’re that small, you really need to do the cross-functional approach.
Which maybe you still have one of those three who is the primary operations person.
Maybe they’re the one who knows how to do the deployments the best.
Maybe they write the CICD scripts and so on.
But the others should at least have a basic understanding of how it works.
So that when that brand is on holiday, they know how to fix things.
So that’s probably the biggest difference, at least from the 10,000-foot view.
The biggest difference between large and small organizations is that when you start to get really small, cross-functional makes perfect sense.
At some point, you have to start transitioning.
If you’re going to grow, you have to start transitioning to that platform model.
How many levels of platform do you think is appropriate?
Can you map this to kind of…
…organization size?
Yeah, that’s a good question.
I don’t think there’s a single answer.
I think it depends a lot on what you’re doing and how complex your platform is.
Let’s just say you decide to go with Kubernetes.
You probably need to go to that platform level sooner than if you’re deploying to an SFTP server, for example.
The management overhead to just SFTP something to a website.
And it runs some PHP scripts.
That’s pretty low overhead in terms of the operations side of things.
If you’re doing Kubernetes, you probably need…
You have more overhead there.
You get a lot of benefits as well, of course.
But you have more overhead.
You probably want more people who have an intimate understanding of Kubernetes to do that sort of thing.
So it’s going to depend a little bit on what tech stack you choose.
And hopefully that’s driven by your business needs and not just because you think Kubernetes is a good thing.
So it depends a lot on what your business needs are.
How much availability do you need?
Do you need high availability?
Is it okay if your website goes down during upgrades?
If it is, then just SFTP, you’re probably fine.
If it must be up all the time, even during upgrades, you need some sort of rolling upgrade mechanism.
And that requires additional manpower.
And if you need alerting…
It depends a ton on what you need from a business standpoint.
And how you choose.
And how you choose to implement those.
But if I try to answer the question a little less like a consultant…
I’m just going to pull some numbers out of the air here.
But I would say less than 25 or so engineers, cross-functional, is probably a good idea.
If you expect to grow beyond that, you should start looking at a platform team.
Once you get to the point that your platform team is more than functional…
… then you want to start looking at multiple platform teams.
And how you split that is going to depend on a lot of things also.
For example, the company I mentioned earlier…
We had a single platform team, but then we also had a data team that also managed some of their own infrastructure.
So maybe that’s a logical split in your case, to have a data platform team as the second platform team.
Maybe you split your Kubernetes management from your monitoring or something like that.
There are many ways you can split.
And I don’t even want to try to tell anybody who I haven’t met and spoken to what they should do.
Because it so depends on business needs and what problems you’re facing.
But the same rule with your scrum team size.
You don’t want more than 5 to 8.
12 is probably an absolute maximum.
If you have 12 people on a team, it’s already a hard advantage.
So the same sorts of team size rules apply to your platform team.
Start to split that when they grow.
Just to ask the opposite question.
How small should a platform team be allowed to get?
I think you should have two minimum.
And that’s why I was talking earlier about if you have three engineers total, you probably should do cross-functional.
And the main reason for that is this bus factor idea.
You don’t want to be high and dry when your only operations person goes on holiday.
Or when they quit and you can’t hire somebody to replace them for three months.
So I would say absolute minimum two.
If you have fewer than two, you’re taking on some risk.
Maybe that’s appropriate for some business situations.
But you’re taking on a high level of risk.
All right.
Assuming that there is a company that wants to move towards DevOps.
You know what?
What’s the best way to do that?
What’s the best way to do that?
What’s the typical pitfalls?
What’s the typical ways of messing this up?
The easiest way to mess it up is just give somebody a title.
Say they’re the DevOps guy.
And then don’t change anything about what they’re doing.
And I’ve worked with companies that do this.
They just think, oh yeah, DevOps, it’s just a new word for deploying software.
So he’s our DevOps guy.
That’s not DevOps.
If it works for you, of course, fine.
Go ahead.
But don’t fool yourself into thinking you’re doing DevOps.
Yeah.
Just to jump in.
I’ve met companies that, you know, they really meant well.
And they were trying to, you know, move towards DevOps.
But they essentially never got past that stage of giving somebody a new title.
But they didn’t really get as far as changing the way of working.
I don’t even know why out of reluctance or out of thoughtlessness.
They thought, yeah, you know, now we’ve given this guy a new title.
And now he’s doing Kubernetes.
So we’re done, right?
Yeah.
You know, I have to be sympathetic to people who do that.
Yeah.
You can’t expect every hiring manager, every team lead, every CEO, every CTO to understand what DevOps is.
Especially considering how terribly abused that word has become.
It’s probably worse even than Agile.
And Agile is terribly abused.
So you have my sympathy.
If you’re listening to this and thinking, what?
I changed the guy’s title to DevOps.
I thought that I was done.
You have my sympathy.
I’m not picking on you.
I’m sorry that you were.
Hopefully we can help you get back on track.
It’s so easy to do that.
Because that’s the buzzword these days.
All the recruiters are looking for DevOps engineers.
And they’re trying to blah, blah, blah, blah, blah.
Back to the original comment I made.
DevOps is about cooperation.
If you’re a DevOps guy.
If you have a DevOps guy.
And you have people in your organization saying, I’m waiting for the DevOps guy.
Or that’s the DevOps guy’s job.
Or I’m going to.
Give this to the DevOps guy.
That’s not DevOps.
The DevOps is about cooperation.
If you are not cooperating, you’re not doing DevOps.
So how can you start to approach this?
I have two answers to that.
And I think they can run in parallel.
And these are the two approaches I use whenever I go into a new company.
I try to do these simultaneously.
The first one is the hardest.
And the most complicated.
And the scariest.
But I’ll mention that.
And we can talk about the details in a moment.
If you want.
And that is to get continuous deployment working as soon as possible.
Continuous deployment is the idea.
The way I define it.
As soon as the developer hits the merge button.
On GitHub or Bitbucket or whatever version control you’re using.
As soon as the developer hits the merge button.
An automated series of events occurs.
That puts that software in front of live customers.
Immediately.
There’s no additional manual check.
You don’t hit the merge button.
And then a week later, the QA guy comes along and says, yes, this is good.
And then we’ll hit it in front of customers.
You go from merge to in front of customers as quickly as possible.
You can still have all your manual QA.
You can do all of that before the merge button happens.
There are some technical complications there.
But we can talk about that.
But the basic idea is get this continuous deployment in place as quickly as possible.
And the reason for that is because it changes the mindset of the developers.
For one thing, it gives you faster feedback.
And that’s always useful.
And that’s one of the core.
Ideas behind Agile and DevOps is to get get our stuff in front of customers quickly so we can get feedback from our customers quickly and we can make changes if we need to.
That’s all important.
That’s great.
And I love that.
But for the purpose of DevOps, the main reason I like to get continuous deployment in place is immediately is because it changes the mindset of developers and the developers as soon as they know that when they hit that merge button, that customers are going to see their changes in within five or 10 or 20 minutes, it puts a new weight on their shoulders.
They take on a new level of responsibility and a new sense of ownership for that code that they’re writing.
And and and you know, I’m not I’m not trying to pick on anybody.
I see I’m saying this from my own heart, from my own experience as a developer, when I know that my code is not going in front of customers for another week because it’s going to be batched up with a bunch of other changes.
I’m a little bit more lazy and I don’t check quite as closely at those changes when I on the other hand, when I do know that it’s going to be in front of customers in five minutes.
I will review my own code one more time.
I will do those extra checks.
I just am a little bit more careful.
I hesitate a little bit longer before I hit that merge button.
Did I forget anything?
And so it’s that extra sense of responsibility and ownership that I think is most important for the purpose of adopting DevOps.
With that new sense of ownership in place, the developers will then do everything they can, at least we hope, just the responsible ones will do everything they can to make sure that code is of high quality.
That it’s been properly tested, that it’s gone through all the checks, the configurations are correct and so on and so forth.
It goes back to what a lot of people describe DevOps as is you write it, you ship it.
So it gets you into sort of that mode.
So that’s the first thing I like to start to get in place is continuous deployment.
Once that’s in place, then we can go back through and start filling in gaps where maybe we can automate some testing.
Maybe we need to do other things.
But to start with.
That merge button to deployment automated and then everything before the merge button, which can include manual QA, if you need that or you want that, it can include writing documentation, it can include feature flags, it can include a million other things.
And those might even be slow and painful, but make that merge button the last human interaction before that code goes live.
And that is one of the first things I do.
The second thing I do, and I do this in parallel, is I advise companies to start doing blameless postmortems.
As soon as they have an outage.
I’ve been at a couple of companies where I was sort of waiting on the edge of my seat for the next outage because I was excited to pull everybody into a postmortem.
I won’t tell you those companies because I don’t want those companies to come after me later and say, I can’t believe you were waiting for us to fail.
But that’s the second approach.
And the reason I like postmortem.
Well, let me contrast those first to retrospectives.
If you’ve been doing.
Scrum, you’re already familiar with the concept of retrospectives, and I believe those are really valuable, too.
But retrospectives are often dry and boring.
And I think that’s why we often have lots of scrum masters trying to find new ways to gamify retrospectives.
And they give you these new charts and these new ways to do it.
And that’s all fine and that’s good.
And I think it’s important to do retrospectives on a regular cadence every two weeks, typically in scrum even more often is great.
But the reason I like postmortems even more.
And in fact, if I had.
To choose between if I joined a company that was not doing either one, I would be postmortems first and I would use that to build into retrospectives.
The reason is because postmortems by definition happen after something is broken and everybody’s already eager to figure out how to solve that problem.
With a retrospective, you often have people trying to think what’s something that we could have improved last week.
I don’t know.
Let me think about it.
Oh, yeah, there’s that one thing.
So, you know, there’s this sort of you have to dig sometimes to find things to improve.
And with a retrospective, I’m sorry, with a postmortem, nobody has to do that because we know the database went down yesterday and we lost 10,000 euros of sales or whatever the thing is.
It’s fresh in everybody’s mind.
We know what happened.
We know what the problem was.
And we hopefully know how we fixed it.
Hopefully it’s been fixed by then.
So it’s fresh.
It’s clear.
And we have an objective.
And the objective is, let’s make sure this doesn’t happen again.
So that’s the second thing I do is I lead a team through.
Doing postmortems.
Every postmortem needs follow-up.
And that follow-up becomes a perfect retrospective if you’re not already doing those.
So that’s my two-pronged approach.
Get CD in place as quickly as possible and start doing blameless postmortems as quickly as possible.
And those two things snowball on each other.
And they help you to start developing this culture of learning and improvement and help you to adopt the DevOps cooperation mindset.
Yeah, that’s great.
That’s really interesting because it also, I think, dovetails into, you know, building out essentially the three ways of Dean Kim, right?
Getting into the habit of doing systems thinking, building feedback loops and opening yourself up to experiments, even if those experiments might be inadvertent and they come in the form of, you know, things going wrong.
Yeah, definitely.
Those things, those all apply to the three.
I mean, the first way, of course, is about the flow of work.
Work should flow in one direction only.
That’s related to the CD idea.
If you have code that’s quote ready, but then it has to go through approvals, whether it’s some sort of change board or QA or who knows what, some product owner has to approve it.
And then maybe they don’t approve it.
It goes back to the developer to do some tweaks.
And, you know, you have this back and forth.
That’s not a good flow approach, according to the first way of DevOps.
The second way is all about feedback loops.
Both of these.
I mean, the postmortem is an obvious example of a feedback loop.
Something’s gone wrong.
We’ve investigated it and we’re trying to fix it.
So, you know, that’s feedback and acting on feedback.
And the third way is experimentation and learning.
And both of these, I think, fit into that.
I mean, the CD idea itself.
I mean, you could just implement CD and stop.
But that’s not the starting point, not an end state.
Right.
So once you have.
My idea of this sort of lean CD approach in place, you start building on top of that.
You don’t stop.
You then start to iterate and improve the process, find ways to make it faster, to reduce the feedback times, to reduce the manual toil.
Exactly.
And I think especially once you set up, for example, CD, it comes kind of naturally to want to improve on it and automate more things.
You don’t have to prod people say, you know, what else could we do now?
They’ll be bursting with ideas.
If you know if your customers.
Are anything like mine.
Absolutely.
And, you know, the book accelerate talks about this, that the companies that do CD have a more mature culture in terms of these sorts of things.
And they should they report higher workplace happiness.
They report, you know, obviously also report better business outcomes in terms of faster software delivery and things like that.
And maybe that’s the reason that a CEO wants to implement that.
But it has other other impacts that are at least as meaningful in my opinion.
You know.
It feels good as a developer.
I get a little bit of a dopamine hit every time I release something in a production.
If I release something and it just sits there in a bucket for three months before it’s released, that dopamine, there’s nothing there.
I don’t care anymore.
But if I can release something now and I can see it in front of customers in ten minutes, that feels good.
And I like that.
And I want more of that.
And I think that gets back to something or it relates to something that I think is really important and one of the main reasons I like to do CD before automating.
I don’t know how everybody thinks about this, but I know that when I first learned about CI and CD, my approach and I think I’ve seen this in many companies and it seems to be the general concept around it.
Well, let’s start.
Let’s start writing some tests.
You know, so imagine you have a code base and everything is manual.
You still do manual zip files to deploy.
Everything’s 100 percent manual.
But you want to move to CI CD if you ask a hundred developers or a hundred engineers.
Yeah.
I think most of them will say, well, the first step is to start writing some automated tests, maybe adopt TDD, get some good code coverage in place, automate that so that whenever you make new changes, the CI pipeline runs and gives you a green check mark.
Do that first.
Once you’re confident that you have a good code coverage, you can fire all your manual QA people.
I don’t know if that’s a good idea, but that’s kind of the mentality right now.
You can fire your QA people because we have our automated tests.
They’re up.
They’re good enough.
Now we have 98 percent coverage or whatever.
Okay, now that’s in place.
Now let’s look about automating our deployments.
And I think that’s entirely backwards.
I think it makes much more sense to automate your deployments first and then worry about the tests.
Because for one thing, maybe firing your your manual QA isn’t a good idea in the first place.
Maybe they maybe they provide some value.
Who knows?
But you don’t.
I mean, whatever whatever checks you’re doing right now with your manual process, whatever it takes to become confident.
If you’re confident with the next release, you can still do every single one of those things, just do it before the developer hits the merge button, not after.
Just change your thinking in that small way and you have continuous deployment.
That’s that’s all it takes.
I say that’s all it takes.
It’s really scary to do that.
It’s it’s it’s it’s a big mindset shift.
It sounds simple, but it’s it’s much easier said than done.
But if you can get over that hump and start doing your CD.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Regardless of everything that comes before and you can still have your manual QA checks if you want to, then that puts you in that mindset where that dopamine hit starts coming through that extra sense of ownership comes through on those developers and the desire to start improving everything else you haven’t you have it becomes much more clear what the next step for improvement is.
I’m just wondering if you do everything else before hitting the merge button, you have to.
Have some kind of environment where testers can do manual tests.
What do you have to have in mind that’s relevant to be done in an usual case before merging and doing the continuous deployment?
That’s an excellent point.
Yes, you definitely need the ability to do your testing before merge in that case.
Ideally manual testing and whether you have dedicated QA people or not.
Your engineers, your developers should be able to do manual testing on the code they’re doing anyway.
So, yes, you need some sort of test environment.
The ideal, the sort of gold standard, in my opinion, is that every time you create a pull request,
it should fire up a temporary review environment that you can test against.
Now, that’s not applicable in all situations.
If you’re building a mobile app, maybe that’s not even possible,
because you need to install that mobile app on a mobile device or an emulator or something like that.
But that’s the gold standard, and you should aim for as close to that as you can get.
For many small teams, it’s good enough to just have a single test environment.
Maybe you have your production in a test environment,
and the developers can, whenever they want to, push a code change to test, and then test it there.
That’s usually good enough for a small team, maybe three to five developers.
Once you get beyond that size and you start having contention and developers are fighting over,
I’m waiting for Bob to finish his testing before I do mine,
that’s when it’s time to start finding a solution.
Maybe you add a second test environment, or maybe you can, depending on their tech stack and so on,
maybe you can build these temporary environments that come up per developer or per pull request or something like that.
But yes, the core answer is yes, you need a test environment.
In some cases, you can maybe test on your local machine.
In many cases, not. It depends on what you’re doing.
You need a test environment that the developers at least,
and if you have manual QA people, that they can use as well.
One thing I’d like to point out, when people start exhibiting skepticism about this idea,
humans shouldn’t be doing this testing, it needs to be automated or whatever.
Remember, humans are Turing-complete machines.
Anything a computer can do, we can also do.
It takes longer, no doubt, but we can do it.
I mean, the first Turing machine was invented by a human, right?
It happened to be Turing.
Since then, every other Turing machine can emulate every other Turing machine.
So, you know, anything you can automate, a human can also do.
And so that’s actually the first step I advocate when implementing this, is write a checklist.
And that’s your human programming instruction, so to speak.
Just write a checklist of the things that should happen before you hit merge.
QA should sign off. We should write documentation.
We need to run the linter. We need to run the unit tests.
You know, whatever. Your list could be 50 things long, it might be five things, it doesn’t matter.
Just write a checklist.
And over time, you can start to automate those and turn those into machine-readable instructions instead of human-readable instructions.
That’s fine.
But remember, anything you can automate, humans can do.
In fact, anything you can automate, humans probably should do before you automate it to make sure you’re doing it right.
And make sure that it needs to be automated.
Don’t fall into the trap of automated things just because you can, if there’s no business value.
Okay. Your checklist that you just mentioned sounds very much like a definition of done to me.
What’s your point?
I agree.
I have an email course on this topic.
And the first lesson or the second one is build a checklist.
If you already have a DOD, start with that.
So definitely, it is a definition of done.
Sometimes your definition of done will vary a little bit depending on how you write your definition of done.
But yeah, they’re essentially the same thing.
Put your document, whatever you need.
And I hear people complain, or not complain, but express worry, like,
well, we can’t do continuous deployment because we need to let our partners know about upcoming changes.
Okay, make that part of your DOD.
Make that part of your checklist.
Send an email blast that says, this is what’s going to change when I hit merge tomorrow, or whatever it is.
So sometimes the definition of done might be exactly what you need.
It probably needs to be adjusted a little bit.
Just try it a few times and see what’s missing.
What’s that one step that you did?
That isn’t documented?
Edit the document.
Yeah.
And I think good teams are the ones that improve.
And you often see that in changes in the definition of done.
So things that you automate can be taken out of the manual part of the definition of done
and moved into the deployment pipeline part of the definition of done.
And when you see new things like outcomes out of a blameless postmortem, for example,
you can add.
There’s a new checklist point to the definition of done.
And when you see you have to do it very often, it takes time.
It’s good to automate.
Put it into the automation part.
Yeah.
And just to point out, there doesn’t even have to be a separate automated and manual part.
I’m not sure whether you’re familiar with the term null automation.
It’s one of my favorite tiny, tiny tricks that make such a big difference, which is,
you know, if you want to.
You write an automated CD script or something, but you for some reason don’t want to automate
all the steps yet, either because you don’t really know how to do it yet or it’s too much
effort or you just want, you know, you just want to brain dump all of the steps into the
script.
You can just have the script and have essentially a print statement, you know, echo, send an
email blast and then echo, do the acceptance test or something.
And so you can stick that into your CD and obviously like it doesn’t do anything but give
you a checklist and then over time you can take some of those elements and replace them
by actual automation.
And that’s just such an awesome trick to use to also maybe take away some of the fear of
automation and say, you know, this is such a big deal and so much effort and should we
really, you know, just do the simple thing, just do null automation.
I love it.
I love it.
Okay.
So now it’s easy, right?
Now everybody can just do DevOps.
Ha!
The hard part is never the technology.
I know.
I know.
As long as we’re working with other people, it’s never going to be easy.
That doesn’t mean it’s not rewarding, but it’s not easy.
Always those pesky humans.
Sorry.
Sorry.
And the more people…
Yeah, the more people you add, the harder it gets, too.
But yeah, that’s a common theme I have seen for years.
The hard part is not the technology.
I mean, we spent 20 minutes talking about how to do CD without automation.
You know, if I can describe it in 20 minutes, it can’t be that hard.
The hard part is convincing somebody that they ought to do it and that it’s a good idea
and that it’s not going to destroy their business.
These are the hard parts.
And then once you’ve done that, convincing the developers on the team that this way,
it works, and even though it’s different than what they did at the last company,
these are the hard parts.
Building the culture of learning and experimentation,
just making people feel safe to experiment with these things,
is half of the battle, I think.
Whether that person is your CTO or your boss or your colleague sitting next to you in the cubicle,
everybody involved needs to feel safe to experiment with these things
or they’re not going to do it.
They’re going to keep doing what they’ve been doing,
even if what they’ve done is not going to work.
They’re going to keep doing what they’ve been doing doesn’t work very well
because they’re comfortable with it.
So that’s the biggest part.
Make it safe for people to express their opinions and their concerns.
Give them the confidence that what you’re doing will either work or can be reversed if it doesn’t.
And yeah, make people feel safe, both emotionally and technically.
And that’s the hardest part.
For all my years doing this, that’s always been the hardest part.
What’s your trick?
Keep trying.
Yeah, I don’t have a silver bullet.
Persistence.
Persistence, absolutely.
You have to say the same things over and over again, sometimes to the same people.
Sometimes you just have to take somebody by the hand and say,
I understand how you feel.
Maybe not literally, that’s kind of creepy, unless you’re working with your spouse or something.
But take them by the hand figuratively and explain,
I understand how you feel.
I understand why this is scary.
I’ve done it before a couple of times and nothing disastrous has happened.
I can talk about the time I fired my QA team and the world didn’t blow up.
So it helps to have some experience under your belt.
But nobody else has had the same experience I have had or that you have had.
So you can’t assume, of course, that everybody else understands where you’re coming from.
And communicating that to someone is difficult,
especially because they’re in a different emotional state than you.
So, yeah, learn communication skills, learn empathy and patience.
Those are the best pieces of advice I can offer in that regard.
Yeah, that’s really the magic, isn’t it?
If you want to make those kinds of changes,
you really have to acknowledge everyone’s humanity
and acknowledge that they might feel apprehensive about the changes
and that they don’t want to mess up because, you know,
everybody wants to do a good job and everybody wants to feel effective.
It doesn’t matter whether you’re four years old or 40.
That’s, I guess, just how humans are, isn’t it?
Exactly.
But I’m so curious about the story about when you fired your QA team.
Didn’t you just say that we need them?
Yes. So I didn’t fire all of them.
There’s a spoiler alert right there.
So I was working with a company.
It was an e-commerce department in a retail company.
So the developers were responsible for building an e-commerce platform
that sold their products online.
And we had…
I think we had five scrum teams when I joined.
And they were doing releases every couple of months or something like that.
So it was a bad situation to begin with.
Part of the makeup of the team was we had a QA person on each scrum team.
So five scrum teams, five QA people.
Only one of those QA people was an in-house employee.
The others were offshore from another country.
So a completely different office.
They all worked in the same office, but in a different office.
And payroll…
They were all paid by a different company.
And over time, the problems with this arrangement started to become more evident.
On the one hand, there’s a bit of an adversarial relationship,
which I think often happens when you have QA doing manual acceptance testing.
Because you end up with a situation where developers are trying to push code through,
and QA acts as sort of a goalie.
And they maybe kick things back every now and then.
And…
Even if…
You have the best personal relationship between your dev and your QA,
there’s a little bit of an adversarial relationship there.
Even if it’s professional and friendly.
It wasn’t always professional and friendly in this case.
We had in particular one developer and one QA who just did not get along well.
And it didn’t work.
Aside from that, perhaps the bigger problem…
We can just chuck that up to personality differences if we want to.
But the problem that didn’t come down to that was that at the beginning of every sprint,
the developers were busy building their new features.
And the QA people were bored with nothing to do.
Because the stories hadn’t been completed yet.
And then the second half of the sprint, the QA was busy testing things away.
And the developers were bored because they’d already finished all their work.
So we had this huge disconnect and complete inefficiency in terms of the flow of work.
We spent several months worrying about this
and trying to find ways to tweak this.
And nothing worked.
Eventually I made the decision to bring in a freelance test automation engineer
for a six-month contract.
She came in and helped us build a test automation platform with Selenium.
And I don’t remember all the tools she used.
And trained our in-house QA on how to use these new tools
and to write tests in Cucumber and Gherkin and all this stuff.
Of course, everybody was apprehensive about this change.
We’ve talked about this fear is a big problem with these sorts of changes.
And that was definitely the biggest problem here.
Everybody was concerned.
All the POs were concerned.
Once the QAs are gone, our quality is going to plummet.
We’re going to have all these customer complaints.
It’s going to be terrible.
So we set up.
So I don’t remember the timing exactly,
but whatever date was the last day for our offshore QAs.
Of course, we had a little farewell party for them, a virtual one.
And then the next week we scheduled regular meetings with meetings.
Me and the two remaining QAs,
the permanent one and the freelance one who was there for another month.
We were going to have regular meetings to discuss all of the crap that went wrong
and how to respond to it quickly.
We canceled the meeting after two weeks because nothing was happening.
Nothing broke.
Nothing went wrong.
Nobody’s hair caught on fire.
We had nothing to do.
Everything was fine.
Now, the developers on these teams were a little bit apprehensive.
And after the fact, some of them told me,
it was a little bit annoying that we had to write tests ourselves
because we really wanted to keep focusing on writing our code.
But it was so much better than before when we had to wait on the QA.
Okay, that’s cool.
Great.
So we still kept our in-house QA.
And then, of course, the freelancer, her contract expired and she went on to another company.
So we still had one dedicated QA in-house and he took on a support role.
So his role was essentially, he became this platform team.
I said earlier, you shouldn’t have a platform team of one.
We did in this case.
He was our QA partner.
We were a platform team.
He maintained the testing infrastructure and he was available to help the developers if they had questions.
How do I write this sort of test or how do I test this thing?
He was available to help them with that, but he didn’t do the testing for them.
And that was the key.
So he became a support.
He took on a support role, maintained the platform and provided training and assistance to the developers who were writing their own.
So interesting to hear you say that, because you’re probably not aware, but Falco and I wrote a big training.
It’s called DevOps Specify and Verify on, well, on exactly those topics, right?
And one of the things we keep banging on about during the training is that you shouldn’t have a QA person who actually writes tests.
Instead, you should have somebody who’s just like you described, some kind of a QA advisor.
Somebody who takes care of the plumbing, somebody who is available to answer questions on how do you test this?
Is this tested well enough?
Are you happy with the coverage?
Are you happy with the coverage that you’re seeing, et cetera, et cetera?
And that’s just such a game changer, isn’t it?
Definitely.
And it frees up the developer to, once again, to own what they’re doing.
They can feel that ownership and that responsibility.
They’re responsible for the quality.
Who would hire a plumber that says, okay, I finished installing the toilet.
Now let me have my tester come in and see if it’s working right.
Nobody’s going to do that.
Why do we have such low standards of developers that we don’t expect them to write code that works?
I feel like it.
If you can’t as a developer be at least relatively confident that your code works because you’ve tested it,
you shouldn’t be calling yourself a developer yet.
You’re still learning.
So I completely agree.
I look at the Dev-QA relationship as almost a parallel to the DevOps relationship that DevOps is supposed to solve.
Your operations people shouldn’t be doing the deployment for your developers.
They should be supporting the deployment for your developers.
They maintain the infrastructure of the platform and they support them.
If a developer doesn’t know how to write a Kubernetes manifest, we don’t blame them.
The operations people can help with that, but they’re not going to do it for you.
But it’s interesting.
I teach a lecture on software QA at the local university.
And so this is a course for students who study in the evenings and they work at regular companies during the day.
I always have this little survey in the beginning about who of you software developers,
writes tests and there’s like one or two hands, very tentatively going up out of, I don’t know, 25 people.
And I just, I could never work this, it feels so unsafe once you’ve gotten used to having a solid test suite behind you.
I can understand the debate between test first and test after.
I’m a TDD guy myself, but I understand a lot of people aren’t, that’s fine, but no tests at all, no tests at all.
And that’s, that’s.
Essentially the way it is everywhere.
Are they doing tests?
Are they doing manual tests?
Are they sitting there running through their thing a hundred times manually?
Because if you are, you’re a developer, the first thing you should think is.
True, right?
I mean, that’s one of the, one of the virtues of the programmer, right?
What is it?
Laziness, confidence and hubris or something?
I forget.
Anyway.
Yes.
I suppose the point is.
For example, with you arguing to start out with CD, it makes it easy to be, to be lazy in a very productive way.
I say, why on earth should I do this twice?
I’ll do it manually once and then I’ll automate it and never worry about it again.
Exactly.
And it gives you a clearly defined boundaries for where should we automate things?
We know when we start writing code, we know when it’s deployed, everything in the middle, optimize that.
If you go the other way and you start, I’m writing code.
I’m going to start, I’m going to start automating things.
Until.
Someday I’m confident to deploy manual automatically.
You’ll never be confident.
Oh, wow.
This is so interesting.
I feel that we’ve given our listeners so much stuff to chew on.
Especially those of, of you, dear listeners who maybe come from a smaller company and have been wondering how to take all of those great ideas and, and make them work for you, especially given that you don’t really have all that many people to work with.
Right.
So hopefully Jonathan has given you some, some really good food for thought.
Um, so I’m wondering, Jonathan, I guess you do this sort of thing for a living if people, if people want to, um, find you and, and ask you to help them, how would they do that?
Where could they find you?
Good question.
My, my website is jhall.io.
J H A L L.
Just like my first.
Initial, last name.io.
And you can find me there.
Uh, if you’re interested, I have a daily mailing list.
Uh, I’d love to, to be in contact with you there, jhall.io slash daily and sign up and I’ll send you nice little funny stories about firing QA teams every now and then, uh, through your inbox.
Wonderful.
So Jonathan, once again, thanks so much for being on the show.
This was a really fun episode.
Thank you very much.
Thank you.
I love talking about this.
So excellent.
I enjoyed it.
So maybe you can come back another time and we can have round two of that.
Jonathan sounds great.
Thank you very much.
Goodbye.
Thank you.
Bye.
Bye.

Folge 51: DevOps Skalieren 2/2

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Erneut haben wir Falko Werner zu Gast, mit dem wir uns über das Thema Skalierung in DevOps unterhalten: warum muß man skalieren (oder nicht?), wie geht man es an, sowie ein Überblick über verschiedene Skalierungsframeworks wie SAFe, LeSS, Flow Framework und einige weitere.

In dieser Folge diskutieren die Gastgeber und der Gastexperte Falko Werner über die Skalierung von DevOps in Unternehmen, wobei sie sich auf die praktischen Herausforderungen und Lösungsstrategien konzentrieren. Es werden verschiedene Frameworks wie SAFE, Less und andere erwähnt, und es wird betont, dass eine erfolgreiche Skalierung von der jeweiligen Unternehmensstruktur und den spezifischen Problemen abhängt. Die Diskussion berührt auch das Thema der kontinuierlichen Verbesserung und die Notwendigkeit, Veränderungen schrittweise und adaptiv anzugehen, sowie die Bedeutung von Kommunikation und Zusammenarbeit über Abteilungsgrenzen hinweg.

Inhalt

  • Skalierung von DevOps in verschiedenen Unternehmensgrößen
  • Unterschiedliche Skalierungsframeworks (SAFe, LeSS, Spotify etc.)
  • Praktische Herausforderungen der Skalierung und Lösungsansätze
  • Wertstromanalyse und ihre Bedeutung in der Skalierung
  • Die Rolle von Kommunikation und Zusammenarbeit in skalierten DevOps-Umgebungen
  • Iterative Vorgehensweisen und kontinuierliche Verbesserung
  • Feedback und Erfahrungen aus Schulungen zu DevOps-Skalierung

Shownotes:

https://vempio.de/produkt/skalierung-von-devops-deutsch/

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)