In dieser Episode erörtern Dierk Söllner und Alex Lichtenberger detailliert die Welt von DevOps, beginnend mit einer Diskussion über die Philosophie und Entwicklung von DevOps, den Unterschieden zu anderen Frameworks wie ITIL und Scrum und den spezifischen Herausforderungen in der Implementierung. Sie gehen auf verschiedene Praktiken wie Continuous Integration und Delivery, Kanban, Value Stream Mapping und DevSecOps ein, betonen die Bedeutung von Kultur und Kommunikation in der DevOps-Praxis und diskutieren, wie DevOps in verschiedenen Unternehmensgrößen skalierbar ist. Der Podcast schließt mit Überlegungen zur Integration von DevOps in traditionellere IT-Strukturen und einem Ausblick auf zukünftige Episoden.
Inhalt
- Einführung in DevOps
- Was ist DevOps und wie hat es sich entwickelt?
- Unterschiede zu anderen Frameworks wie ITIL und Scrum.
- DevOps-Philosophie und Praktiken
- Die „Three Ways“ des Feedbacks.
- Bedeutung von Kultur und Kommunikation.
- Umsetzung von DevOps in Unternehmen
- Herausforderungen und Ansätze für verschiedene Unternehmensgrößen.
- Beispiele für DevOps-Praktiken: Continuous Integration und Delivery, Kanban, Value Stream Mapping.
- Technologische Aspekte in DevOps
- Rolle von Automatisierung, ChatOps und künstlicher Intelligenz.
- Integration von Sicherheit in DevOps (DevSecOps).
- DevOps in traditionellen IT-Strukturen
- Anpassungen und Skalierung von DevOps-Methoden.
- Ausblick auf zukünftige Episoden und Kontaktinformationen
Transkript (automatisiert, daher keine Gewähr 🙂 )
Hallo und herzlich willkommen zum Podcast
DevOps auf die Ohren und ins Hören.
Ich begrüße Sie zu der ersten Folge
und wenn ich sage, ich begrüße Sie,
begrüße ich alle Zuhörer
und ich begrüsse natürlich auch Alex Lichtenberger,
mit dem ich zusammen diesen Podcast erstelle und bespreche.
Insofern würde ich sagen, Alex, stell dich doch mal ganz kurz vor.
Vielen Dank, Dirk, und willkommen von meiner Seite.
Mein Name ist Alex Lichtenberger.
Ich bin seit rund 20 Jahren in der IT,
damals begonnen in der Softwareentwicklung bei IBM.
Wir haben damals schon iterativ, adaptiv entwickelt,
um nicht das Wort agil zu nennen.
Ich bin dann später sehr stark im Operation-Umfeld gewesen,
auch im Outsourcing.
Und etwas, das ich dann immer gesehen habe, ist,
dass so Dev und Ops, das sind schon zwei verschiedene Welten.
Und als ich mich vor ein paar Jahren beschäftigt habe mit DevOps,
habe ich gesehen, dass das eine sehr gute Lösung bietet,
um dieser Problematik zu begegnen.
Deshalb würde ich mich als DevOps-Enthusiasten bezeichnen.
Und ich arbeite…
Ich arbeite als Berater zurzeit,
auch als Trainer im Bereich DevOps, Agile und Scrum.
Jetzt mal von meiner Seite.
Vielleicht du, Dirk, möchtest du dich auch kurz vorstellen?
Ja, Dirk Söllner, mein Name.
Ich bin ähnlich wie der Alex schon etwas länger im Geschäft.
Ich bin sogar 25 Jahre im Geschäft, habe gestartet,
bin gestartet als Berater für klassische Themen wie ERP-Software,
Controlling-Applikationen und bin dann später zu dem Thema IT gekommen,
zum Thema IT-Service-Management und bin heute Berater, Trainer und Coach
für IT-Service-Management und agile Organisationsentwicklung.
Das ist genau das, was auch Alex schon bei sich angesprochen hat.
Wenn ich mir die klassische IT-Welt angucke,
die klassische IT-Service-Management-Welt,
bin ich so vor vier, fünf Jahren auch auf das Thema Scrum und Agile gestoßen,
habe das für mich als Geschäftsmodell entdeckt, weiterentwickelt
und bin eben dann heute auch als Trainer aktiv, bin auch als DevOps-Trainer aktiv.
Seit drei, vier Jahren bin ich wirklich sehr stark als agiler Coach unterwegs
und helfe da eben Unternehmen und einzelnen Personen,
das ganze Thema Agilität für sich zu entdecken und weiterzuentwickeln.
Das heißt, bei mir ist es eben genauso wie bei dir, Alex, Enthusiasmus,
was das Thema Agilität angeht, aber natürlich mit einem klassischen Background,
mit einem Background-IT-Betrieb.
Danke, spannend.
Das ist ja jetzt das erste Mal, dass wir diesen Podcast machen.
Eine erste Frage, die sich aufdrängt, ist ja, wieso überhaupt so ein DevOps-Podcast?
Ich glaube, es war ja du, Dirk, der die Idee hatte.
Vielleicht kannst du da ein bisschen ausführen.
Jawohl. Ja, ich hatte die Idee, weil ich mir gesagt habe,
Blogbeiträge schreiben, Vorträge halten, Veröffentlichungen dazu schreiben,
das ist sicherlich eine interessante Sache, aber es fehlt noch irgendwas Neues.
Und da ich selber gerne Podcasts höre und auch den einen oder anderen recht gut finde,
habe ich mir überlegt, Mensch, das wäre auch mal ein Thema,
wo ich mich einer neuen Technik widmen kann und habe dann auch geschaut,
gibt es deutschsprachige DevOps-Podcasts, die mir gefallen, die mich ansprechen.
Und ja, ich habe keinen gefunden.
Und dann habe ich für mich gesagt, so, jetzt musst du einen Podcast machen,
das ist was Neues, kannst du deine Freude an diesem Thema eben auch mit rüberbringen.
Und habe dann überlegt, mit wem mache ich das am besten zusammen
und habe dann eigentlich sofort auch an die Schweiz gedacht.
Das ist natürlich thematisch was ganz Schönes, da mit dir, Alex, das zusammen zu machen.
Außerdem finde ich es sehr interessant, wenn wir nicht nur so eine hochdeutsche Sprache haben,
wie ich habe, sondern dass wir auch so ein bisschen
schweizerisch da reinbringen.
Also insofern, das Ziel, was ich dabei verfolge, und das siehst du ja genauso,
dass wir das versuchen, das Thema DevOps ein bisschen locker rüberzubringen,
authentisch rüberzubringen und auch ansprechend gestalten.
Ja, und ansprechend heisst, man kann einfach auch mal reden dazu,
man muss nicht immer nur schreiben.
Wie sieht es bei dir aus? Warum machst du mit?
Ja gut, für mich ist Podcasts so wie ein neuer Kanal, der für mich persönlich sehr spannend klingt.
Ich bin bereits recht aktiv in der DevOps-Szene, schreibe viele Blogs,
auch war letztens an den DevOps-Days dort in Zürich, habe einen kurzen Speech gehalten.
Und Podcasts, ich habe es früher persönlich auch schon oft genutzt,
wenn man zum Beispiel im Auto sitzt und man kann halt nicht lesen während dem Autofahren,
ausser man hat ein selbstfahrendes Auto, aber da ist der Podcast eigentlich ein idealer Kanal.
Da dachte ich ja, mache ich mit.
So, das heisst, wir beide gestalten diesen Podcast.
Von der Idee her werden wir natürlich das nicht nur alleine machen,
wir werden uns Gäste dazu holen, wir werden uns thematisch natürlich breit aufstellen.
Aber die Frage ist ja überhaupt, was ist DevOps überhaupt?
Das sollte man als allererstes klären, bevor man überhaupt in so eine DevOps-Podcast-Folge einsteigt.
Alex, was ist DevOps?
Ja, die Frage tönt einfach, aber die Antwort ist gar nicht so trivial,
weil DevOps ist ja kein Standard, kein Framework.
Es ist nicht wie ETIL oder Scrum, wo man auch im Buch nachlesen kann,
kodifiziert, Regeln etc., sondern DevOps ist mehr eine Bewegung,
wo sich viele Dinge verändern zurzeit.
Und vermutlich ist es auch die falsche Frage, um zu starten, nicht was ist DevOps,
sondern eher, wieso ist DevOps überhaupt entstanden und ein Thema geworden.
Und diese Frage nach dem Wieso und sich auch im Klaren zu werden,
was ist Ihr Wieso, das Wieso Ihrer Firma, das kann sehr individuell sein.
Aber in der Regel gibt es so zwei Wieso, warum DevOps.
Das eine Warum, das hat wirklich mit Digitalisierung zu tun.
Wenn man da ein bisschen zurückschraubt in der Zeit,
sagen wir so 90er Jahre, wenn man schaut, wie Projekte gemacht wurden,
das war damals noch klassisch, Wasserfall-Vorgehen.
Man hat halt auch sehr lange gebraucht für Projekte,
also ich spreche jetzt auch von Software-Projekten.
Was dann plötzlich gekommen ist, ist auch so IT als Innovationstreiber.
Also ich spreche jetzt nicht von Business IT allein, sondern mehr IT im Business.
Also beispielsweise bei uns in der Schweiz,
die Banken, die haben angefangen, E-Banking-Lösungen zu bauen.
Und das ist dann halt zwei, drei Jahre gegangen, bis mal was live gegangen ist.
Und jetzt könnte man sagen, ja gut, das ist kein Problem.
Zwei, drei Jahre, that’s how it is.
Aber was, wenn plötzlich der Konkurrent, die andere Bank,
die gleiche Lösung in einem halben Jahr zustande bringt.
Dann wird das zum echten Problem für das Business, zum Wettbewerbsnachteil.
Was dann eben passiert ist, und das ist einfach passiert,
ist, dass die Software-Entwickler, die haben angefangen, auf agil umzustellen.
Also vor allem dort, wo halt auch die Antworten nicht von Anfang an klar waren.
Man hat in Sprints gearbeitet, beispielsweise nach Scrum Feedback abgeholt.
Weil die Idee, dass man da alle zwei Wochen
schon ein Potentially Releasable Increment hat.
Aber das Problem war halt immer noch, was nützt das Ganze,
wenn eigentlich das ganze System nicht erlaubt,
dass man beispielsweise alle zwei Wochen mit was live geht.
Also ein bisschen das Problem war so schon ein bisschen Operation.
Und der nächste logische Schritt, und das ist dann halt auch einfach passiert,
und das waren dann nicht so die grossen Firmen, die damit angefangen haben,
sondern mehr die Startups zu jener Zeit, so wie Google, Netflix.
Die haben angefangen mit Continuous Delivery.
Continuous Delivery heisst, that software is always in a releasable state.
Das heisst, nach jedem, wenn eine Anforderung implementiert wird, Check-in,
dann durchläuft man halt alle Tests, vorzugsweise automatisiert,
dass man jederzeit live gehen könnte.
Also plötzlich waren grosse Firmen konfrontiert mit diesen kleinen Startups,
die sehr schnell Features am Markt testen konnten,
mit Features live gehen konnten.
Und das waren dann plötzlich Konkurrenten.
Also your next competitor could be a startup with an app.
Und das betrifft inzwischen fast jede Branche.
Das ist so das eine Warum.
Und es gibt noch ein anderes Warum.
Das hat mit dieser, vielleicht haben Sie schon davon gehört,
Dev und Ops, also Entwicklung und Operation, und dazwischen die Wall of Confusion.
Das ist halt schon so, wenn man die Entwickler anschaut, die sind getrieben von Change.
Was wollen die? Die wollen in Projekten arbeiten, Änderungen umsetzen.
Während Operation hat eine ganz andere Motivation.
Die wollen Stabilität.
Jeder, der mal in Operation gearbeitet hat, weiss genau, was ich meine.
Und das ist dann der klassische Zielkonflikt.
Also man hat, Dev will Flexibilität, Ops will Stabilität.
Und was dann verloren geht manchmal, ist so die gemeinsame Sicht auf die Services.
Weil das will ja beides.
Und man hat dann angefangen, Value Streams zu identifizieren, gemischte Teams zu bilden, um diese,
und das war wahnsinnig erfolgreich.
Und das dann halt unter dem Label DevOps.
Das sind so diese zwei Warums.
Das eine Digitalisierung, so wirklich DevOps als Enabler für die Innovation.
Das andere, diese Dev und Ops-Geschichte mit der Wall of Confusion,
wo sich auch die meisten Leute in der IT können sich mit der nicht zufriedenstellenden Situation identifizieren.
Das ist halt die Motivation, wie es entstanden ist.
So, mal das Warum.
Und jetzt zur Frage, was ist DevOps, ist vielleicht, weil ich habe jetzt ziemlich viel gesprochen,
vielleicht die Frage an dich, Dirk, weil du kennst dich auch bestens aus im Bereich DevOps.
Was ist denn so für dich denn die Philosophie von DevOps, nachdem wir jetzt das Warum verstanden haben?
Ja, ich würde gerne, bevor ich auf diese Frage eingehe, nochmal einen weiteren Punkt ergänzen.
Was du gesagt hast, diese beiden Warums, stimme ich natürlich vollkommen zu.
Was ich glaube, was auch noch ein wichtiger Punkt ist, ist das Thema Automation,
ist das ganze Thema Software-Unterstützung.
Das, was so Firmen wie Netflix, Spotify und so weiter, du hast ja ein paar Beispiele genannt,
was die einfach nach vorne getrieben hat, ist natürlich auch das Thema das, was wir unter DevOps verstehen,
Continuous Delivery und so weiter.
Das hängt eng auch mit Software zusammen.
Natürlich wollen wir jetzt hier keine Software-Werbung machen, keine Software-Produkte vorstellen.
Wir werden sicherlich das eine oder andere nochmal in späteren Podcast-Folgen behandeln.
Aber für mich ist immer ein weiterer Punkt, dass wir dort auch einen Technologietreiber haben,
dass wir Software haben, die das ganze Thema unterstützt und damit auch eben dazu beiträgt,
dass wir überhaupt über DevOps reden.
Denn das, was wir eben als Warum haben, das ist natürlich etwas, was nicht unbedingt im ersten Moment
für große Firmen wie Automobilindustrie, wie Versicherungsbranche wirkt,
weil die natürlich sagen, Spotify ist nicht mein Konkurrent, Amazon ist nicht mein Konkurrent, nicht mein Mitbewerber.
Also es gibt noch ein paar Gründe mehr, das wollte ich vielleicht nochmal ganz kurz ergänzen.
Und wenn ich da eben schon so ein paar Namen genannt habe, große Firmen, dann sind das auch die Firmen,
die genau mit dem, was du vorhin gesagt hast, aus meiner Sicht manchmal ein Problem haben.
Wenn ich in den Trainings bin und dann erzähle, dass hinter DevOps kein Framework steckt,
dass da kein Eigner hinter steckt, der eine Deutungshoheit hat, sondern dass es eigentlich eine Bewegung ist,
so wie du das ja eben auch gesagt hast, dann kommen schon die ersten Fragezeichen.
Warum steht denn der da vorne und will mir als Trainer was erzählen? Ist aber gar kein Framework.
Und insofern würde ich jetzt genau auf den Punkt überleiten, den du eben angesprochen hast.
Gibt es denn überhaupt eine DevOps-Definition? Was ist DevOps?
Und ich sehe das ja auch als eine Philosophie, das hast du ja selber auch schon angedeutet.
Und unser beliebter Rob England hat sich dem Thema ja auch mal gewidmet.
Er hat eine wunderschöne Webseite dazu gemacht, weil er wohl mal gefragt wurde von einem seiner Leser,
er sollte doch bitte mal eine Definition von DevOps geben.
Und was ich interessant finde, ist, dass er doch einige Punkte auf seinem Blogbeitrag eingestellt hat, wo ich sagen würde, interessant.
Also für uns, für mich ist das,
das ist auf jeden Fall eine Philosophie. Und der Rob England sagt zum Beispiel,
dass einer der Begründer von DevOps, falls man überhaupt von so etwas sprechen kann, der Patrick Dubois,
dass der zum Beispiel überhaupt nichts zu einer Definition sagt.
Das heißt, wie gesagt, einer der Begründer, der Initiatoren von einer DevOps-Bewegung, der sagt dazu gar nichts.
Und wenn man dann beispielsweise mal bei Wikipedia reinschaut, dann finde ich, kommt man genau schon auf den ersten falschen Weg.
Auf Wikipedia steht ja zum Beispiel, dass das ein Zusammenschluss ist, eine Verballordnung von dem Begriff Software Development.
Und Wikipedia sagt, DevOps is a software development method that stresses communication, collaboration and integration between software developers and information technology professionals.
Da sage ich mal, es ist nicht nur eine Softwareentwicklungsmethode, es ist mehr.
Es ist eben die Philosophie. Und wenn ich sage Philosophie, heißt das für mich, dass ich dort in den Betrieb eigentlich auch die agilen Gedanken hineinbringe.
Dass ich das, was wir beide unter Agilität verstehen, was wir auch da so interessant daran finden, das ist etwas, was wir mit DevOps eigentlich in den Betrieb einbringen.
Ich denke, was sagst du? Haben wir die Philosophie halbwegs erklärt oder sollten wir noch ein bisschen was dazu aufhören?
Ja, absolut. Also ich schließe mich da an.
Das ist sehr gut zusammengefasst. Da habe ich ergänzt.
Aber warum machen wir dann überhaupt DevOps? Was sind denn die Ziele von DevOps?
Genau, die Ziele. Du hast ja auch gesagt, die Frage, was ist DevOps? Dass es auch eben mehrere Definitionen gibt oder sogar Leute, die sich da gar nicht rauslassen und sagen, es gibt keine definitive Aussage dazu.
So ja, Ziele. Dirk, was sind denn die, mal ganz kurz zusammengefasst, was sind die Ziele von DevOps?
Also aus meiner Sicht, wenn ich DevOps als eine Philosophie betrachte, würde ich sagen, wir wollen schneller und besser werden.
Wobei ich dieses schneller eigentlich so ein bisschen in Klammern setzen möchte. Also eigentlich heisst es für mich nur besser werden.
Wenn ich an meine Scrum Projekte denke, dann sind die großartig.
Ich glaube, dass die Kunden, die die Ergebnisse dieser Scrum Teams bekommen, häufig erfreut und für die ist es quasi vollkommen ausreichend, bessere Lösungen zu bekommen.
Die meisten Kunden, die in Fachbereichen sind natürlich auch daran interessiert, etwas schneller zu bekommen.
Aber wie gesagt, der Hauptfokus, der Hauptvorteil sehen sie als von Scrum und damit in der Folge auch von DevOps, dass sie bessere Ergebnisse bekommen.
Das heisst, für mich ist ein ganz wichtiger Punkt.
Dass wir mit DevOps, wenn wir eine Organisation nach DevOps-Philosophie aufbauen, dass wir bessere Ergebnisse liefern.
Und bessere Ergebnisse heisst, dass sie natürlich dann auch in der Folge schneller werden, weil wir keine Nacharbeiten haben und so weiter.
Aber wie gesagt, ganz klar für mich, bessere Ergebnisse, damit wir besser auf die Kundenanforderungen reagieren können und die dort besser umsetzen können.
Passt das für dich auch, Alex?
Ja, ich finde das spannend ist ja, dass diese schneller und wie du sagst, vor allem schneller,
besser, das wird ja klassischerweise als Zielkonflikt angeschaut.
Also wenn ich schneller werde, ich was schnellere, kürzere Time-to-Market, dann leidet die Qualität darunter und vice versa.
So, DevOps versucht auch ein bisschen diesen Zielkonflikt aufzulösen, in dem dann halt, sehen wir dann später, Automatisierung etc.
Und auch aus der Agilität heraus, es geht ja nicht, schneller stimme ich dir zu, ist vielleicht ein bisschen falsch, sondern was ich eben will, ist,
wenn ich mir am Anfang noch nicht sicher bin, was die Anforderungen sind, ich will Feedback vom Kunden, ob ich auf dem richtigen Weg bin.
Also fail-offen, fail-early, aber ich will echtes Feedback.
Das heisst, ich will halt das so bauen, wie es dann auch in der Produktion ausschauen würde.
Das so als Ergänzung.
Jetzt haben wir ja über die Ziele auch gesprochen, was auch noch spannend wäre mal generell.
Was sind denn so Handelsteine?
Was sind so Handlungsfelder?
Also wenn ich jetzt diese Ziele erreichen will, was sind so die verschiedenen Dimensionen, Handlungsfelder, in denen ich mich auf dem Weg dorthin bewegen kann?
Dirk?
Ja, also ich persönlich sehe dort fünf Handlungsfelder.
Und wenn ich sage Handlungsfelder, meine ich damit, das sind Gebiete, wo Unternehmen etwas tun müssen oder auch tun können, um sich in Richtung einer DevOps-Organisation zu entwickeln.
Und ich habe gesagt, DevOps ist kein Framework, es ist eine Philosophie.
Das heisst, ich kann nicht wie bei ITIL oder Scrum irgendwo mir ein Buch kaufen, sei es 17 Seiten Scrum Guide, sei es 2000 Seiten ITIL und dann sagen, ich mache das.
Nein, für mich ist das eben wirklich etwas, wo ich Organisationsentwicklung betreiben muss.
Und diese fünf Handlungsfelder, von denen ich eben gesprochen habe, das ist für mich das Wichtigste ist zuerst die Kultur.
Ich muss eine Kultur schaffen dafür und wenn man sich da in den DevOps-Blocks mal umtut, dann ist das ein Punkt, der sich eigentlich überall durchzieht.
Das heisst, selbst die Automatisierungsurus, die Automatisierung als einen ganz wichtigen Punkt von DevOps ansprechen, selbst die sagen, man braucht eine entsprechende Kultur.
Und das ist genau das, was letzten Endes, denke ich, auch die Arbeit ist, wenn ich über DevOps nachdenke, dass ich einfach eine Kultur schaffe für DevOps.
Zweiter Punkt wäre Organisation.
Ich denke, es reicht nicht einfach nur zu sagen, wir machen jetzt DevOps und wir haben vielleicht ein paar Scrum Teams, die machen den Betrieb jetzt mit.
Also, ich muss natürlich ein bisschen was organisieren.
Und da habe ich natürlich auch den Punkt, dass bei der Organisation ich auch mir überlegen muss, wie gestalte ich eine Organisation.
Dann dritter Punkt die Prozesse.
Ich habe natürlich in einem größeren Unternehmen habe ich das schon.
IT-Service-Management-Prozesse und die prallen natürlich jetzt mit ihrer
Stabilität auf die agilen Softwareentwickler und umgekehrt
natürlich. Insofern muss ich mir auch Gedanken machen über die Prozesse.
Das heißt, diese drei Themen sind so ein bisschen was Allgemeines,
sind etwas Organisatorisches. Und dann ein ganz wichtiger Punkt,
das Thema Automation. Ich habe es vorhin schon angesprochen. Ich glaube,
dass das eben ein ganz wichtiger Punkt ist. Die IT hat die letzten
Zehnte damit verbracht, andere Bereiche zu automatisieren,
Abläufe zu automatisieren. Jetzt ist die IT selbst
dran. Jetzt muss die IT ran und die eigenen Abläufe automatisieren.
Das heißt, das wäre für mich das vierte Handlungsfeld, wo man etwas tun muss,
um in Richtung DevOps zu gehen. Und dann mein Lieblingsthema,
die wir nicht kennen, ich weise immer wieder darauf hin, kontinuierliche
Verbesserung. Das ist für mich eigentlich das A und O, weil ich eben
sehr viele Implementierungen von IT-Service-Management gesehen habe,
aber auch von Scrum, die einfach für sich sagen, wir haben einen Status erreicht
und da bleiben wir jetzt stehen. Und ich glaube, dass man mit kleinen Schritten,
also mit diesem berühmten iterativen, inkrementellen Vorgehen,
dass man dort auch die DevOps-Organisation bauen kann,
sprich kontinuierliche Verbesserung von Anfang an aufsetzen. Und natürlich
hängt die kontinuierliche Verbesserung zusammen mit dem Thema Automation.
Das ist ein sehr wichtiger Punkt. Das ist ein sehr wichtiger Punkt.
Das ist ein sehr wichtiger Punkt. Das ist ein sehr wichtiger Punkt. Das ist ein sehr wichtiger Punkt.
Und das, was ich messen kann, kann mich auch beeinflussen.
Ja, also ich denke, du hast zuerst angesprochen Kultur.
Und ich denke auch, das ist die wichtigste Voraussetzung, die richtige
Kultur zu haben, sich dorthin zu bewegen. Es gibt auch den schönen Spruch
Culture eats strategy for breakfast. Und das stimmt wirklich.
Man kann die schönsten Pläne haben oder das Management kann
die schönsten Pläne haben. Wenn die Leute das nicht wollen,
dann kann man es gerade vergessen. Und ganz praktisch
heisst das ja dann auch, wenn, das sind dann vor allem halt die
Ex-Operation-Leute, wenn die sich nicht mit der agilen Idee
anfreunden können, dann wird es schwierig, sich Richtung
DevOps zu bewegen. Also man muss sich zuerst mal den Kulturaspekt
den anschauen. Das sehe ich schon auch als
die wichtigste Voraussetzung.
Ja, vielen Dank, Dirk.
Du hast gesprochen über die Ziele von DevOps, schneller, besser, die
Handlungsfelder, die Werte.
Jetzt hört man ja auch oft über diese sogenannten Three Ways.
Das sind drei unterschiedliche Philosophien, wie die Ziele von DevOps
angegangen werden.
Die wurden ja das erste Mal beschrieben in dem berühmten Buch von
Jin Kim, The Phoenix Project, ein Buch, das ich sehr empfehlen kann.
Dirk, willst du uns diese Three Ways vielleicht mal ein bisschen näher
bringen?
Ja, gerne.
Vielleicht, bevor ich auf diese drei Wege, drei Prinzipien eingehe.
Das Buch, was du angesprochen hast, ist für dich auch sehr, sehr lesenswert.
Interessant finde ich, wenn ich das meinen IT-Service-Management-Kollegen empfehle oder
mit denen ich darüber austausche, über meine Freude an DevOps.
Die meisten, die das Buch lesen, die ertappen sich, dass sie sagen, stimmt, habe ich auch
erlebt.
Also insofern, wer das Buch noch nicht gelesen hat.
Das ist sehr interessant.
Sehr nett, sehr locker geschrieben, lässt sich eben gut lesen, ist vielleicht nicht
eine Urlaubslektüre, aber zumindest eine Lektüre, die man sich gerne so am Wochenende
mal antun könnte.
Und wie gesagt, viele Leute, die ich mit dir darüber spreche, die sagen, ja, das habe
ich genauso erlebt, das ist bei uns auch so.
Also insofern, das kann man einfach nur empfehlen.
Ja, Jin Kim, hast du eben gesagt, der hat drei Wege für Feedback aufgezeigt.
Three-Ways-Principles, drei Prinzipien, wie Feedback laufen kann.
Das Feedback brauchen wir natürlich, wenn wir uns verbessern wollen.
Und wenn wir Dinge verbessern wollen, müssen wir Feedback-Schleifen einbauen.
Und seine drei Wege, im Prinzip der einfachste, der erste Weg ist der, der auch noch auf einer
Silo-Organisation aufbaut.
Der sagt, wenn ich eine Silo-Organisation habe, dann habe ich Projekte, ich habe eine Entwicklung
und die Entwicklung hat einen ganz einfachen Weg.
In Richtung Ops, das heisst, ich habe eigentlich nur einen Weg, wie Informationen laufen.
Wir haben eben noch nicht mal ein Feedback.
Es gibt nur Informationen von dem Bereich Development, von der Entwicklung an den Betrieb,
an Operations.
Und da gibt es den zweiten Weg, Alex, aber ich denke, den kannst du auch erzählen.
Ja, der erste ist ja recht offensichtlich mal.
Da geht es ja darum, wie du gesagt hast, Dirk, wenn man sich jetzt praktisch vorstellt, in
der Entwicklung, man definiert Anforderungen, es wird entwickelt, Check-in, verschiedene
Tests und dann geht es Richtung Deployment bis hin in die Produktion, so First Way.
Was der Second Way zusätzlich reinbringt, ist Feedback-Loops und zwar nicht einfach
Feedback, sondern schnelle, kurze Feedback-Loops, beispielsweise automatisiertes Testing.
In einem agilen Umfeld.
Wenn ich was mache, ich will wissen, ob ich das Richtige mache und deshalb brauche ich
diese Feedback-Loops.
Also idealerweise, so der Traum auch aus dem Continuous Integration Delivery, ich check
Code ein, ich bekomme sofort Feedback aus den automatisierten Tests, ob ich das Richtige
mache.
Wenn nicht, stop the line and go back, eine Philosophie, die sehr alt ist, die aus dem
Lean herauskommt.
Entstanden.
Es gibt viele andere Beispiele für Feedback-Loops, beispielsweise das klassische Problem-Management,
man hat wiederkehrende Störungen, man will jetzt mal die Ursache herausfinden, dauerhaft
beheben, Feedback nach links geben, Monitoring ist auch, Continuous Monitoring ist ein gutes
Beispiel.
Das sind so diese Feedback-Loops, der Second Way, man versucht, das überall reinzubringen.
Und so schlussendlich auch die Qualität zu erhöhen.
Und dann gibt es ja noch den Third Way, soll ich kurz erklären oder willst du?
Also Third Way geht dann wieder in eine ganz andere Richtung, das hat mit kontinuierlichem
Experimentieren und Lernen zu tun, das hat auch mit Fehlerkultur zu tun, weil Fehler
passieren, das ist absolut menschlich.
Das Problem ist, wenn man aus Fehlern nicht lernt, dann ist es einfach nur ein Fehler.
Also erstens hier eine Kultur aufbauen, der kontinuierlichen Verbesserung und andererseits
auch Experimente nutzen, um zu lernen.
Also ich mache hier das Beispiel von Google, bei Google ist alles ein Experiment, beispielsweise
Google Maps hat als Experiment, ist das entstanden, hatte einer eine Idee, man hat das implementiert,
geschaut, man weiss halt nicht zum Vornherein, funktioniert das oder nicht.
Und das ist dann wirklich auch ein Mindset-Shift, weil oft wird zu Tode argumentiert, ist jetzt
Lösung A oder B richtig, soll ich zwei oder drei Fenster haben auf meinem kleinen Client?
Und die Sache ist die, keine Ahnung, niemand kann das wissen.
Beides ausprobieren, Experiment machen, Impact messen, Feedback, das ist das, was wir hier
machen.
Und das, was funktioniert, das behält man.
Kontinuierliches Experimentieren und Lernen, das ist so der third way.
Und dann eben auch den Leuten die Zeit geben, Experimente einzugehen.
Es gibt Firmen, auch in der Schweiz, die machen dann zum Beispiel so Hackathons oder sie geben
den Leuten 10% der Zeit, wo sie eben so Experimente durchführen können und ihre Hypothesen testen.
Das wäre so von meiner Seite so der third way.
Ja, was ich da interessant finde ist, aus meiner Sicht, wenn man diese drei Wege mal
sozusagen nebeneinander stellt, dann brauche ich für den zweiten und dritten Weg eine
andere Organisation, dann brauche ich autonome Teams, brauche Teams, die das, was du eben
aufgeführt hast, für den zweiten und dritten Weg, die das quasi im Team umsetzen können.
Denn wenn ich natürlich lange Rückmeldezyklen habe.
Ich muss über irgendwelche Anzeichen gehen.
Ich muss über irgendwelche Anzeichen gehen.
Ich muss über irgendwelche Anzeichen gehen.
Ich muss über irgendwelche Gremien gehen.
Ich muss über Abteilungen gehen.
Ich muss Projektwege, Reportingwege einhalten.
Dann funktioniert das alles nicht.
Das heißt, das Ziel ist ja nicht nur diese Zyklen einzubauen, das Feedback einzubauen,
sondern auch schnell einzubauen.
Du hast das eben gesagt.
Schnell heißt nicht zwei Wochen.
Schnell heißt im Extremfall stündlich oder heißt zumindest sehr, sehr zeitnah zu dem
Start eines möglichen Experiments.
Das heißt ganz.
klar, für mich, was ich interessant finde und dann auch als Herausforderung
für die Unternehmen sehe, der Weg 1 auf 2
oder 1 auf 3 bedeutet eine Veränderung der Organisation.
Ich muss meine Organisation anders aufbauen und
das, glaube ich, ist noch ein wichtiger Punkt, den wir behandeln sollten.
Wir reden immer davon Netflix, wir reden von Amazon, wir
reden von Google, ganz tolle Firmen. Die Frage ist ja, können
wir das, was diese Firmen praktizieren, was wir hier auch so schön als
DevOps darstellen, können wir das einfach so in die deutschen
Unternehmen bringen? Wenn wir uns ein Mittelständler anschauen, wenn wir uns große Unternehmen
angucken, kann man das einfach so übertragen? Wie können
diese Firmen das, was wir so erzählen, eigentlich auch nutzen und
zufrieden bringen?
Ja, das Ganze hat ja, wie du sagst, angefangen mit diesen sogenannten
Unicorns. Für die ist das
eine Notwendigkeit, DevOps zu machen und
die grossen Firmen oder diese sogenannten Horses, sagt man
im DevOps-Slang, Enterprise-IT, wollen das nun
adaptieren. Und es ist ja nicht so, dass man DevOps
machen kann. Was man aber beispielsweise machen kann und
das ist auch schon recht etabliert in vielen grösseren Firmen ist
beispielsweise all diese Continuuses, Continuous Integration,
Delivery, Deployment.
Es gibt auch Praktiken wie beispielsweise Kanban, Value Stream
Mapping. Wenn wir das jetzt alles versuchen würden, ein bisschen auf die Reihe
zu bringen, nicht so anknüpfen nach, was du gesagt hast, Dirk,
mit den Three Ways, vor allem der First Way, weil was
ein bisschen verloren gegangen ist in den grösseren Firmen, ist die Sicht
des Value Streams. Man hat stark funktionale
Organisationen, man hat viele Handoffs, man hat
überall Prozessmanager, aber
wer ist eigentlich noch irgendjemand, wo der Value Stream
für die einzelnen Produkte und Services ist? Also von der Anforderung
bis hin ins Deployment. Also ein erster
Schritt ist mal, dass man sich vielleicht irgendeinen Service
rauspickt und man macht beispielsweise ein Value Stream Mapping.
Man identifiziert mit den Leuten, die da involviert sind,
nicht zuerst mal, wie der Prozess
theoretisch ausschauen soll,
sondern wie es im Moment läuft. Die Japaner sagen dem auch so
Gemba, also Gemba heisst dort, wo es passiert, Gemba Walk.
Man schaut durch, wie wird zur Zeit gearbeitet
und dann, wenn man dieses Bild hat, versucht man die
Bottlenecks oder Verschwendung auch zu identifizieren. Das kommt aus
dem Lean raus. Man sieht dann beispielsweise, dass man wahnsinnig
viel Zeit braucht für das Deployment oder dass man
sehr viel manuelle Arbeit, alle Tests manuell
und wenn man das sieht, dann denkt man an schrittweise Verbesserungspotenzial
zu identifizieren. Dirk, du hast ja gesagt, du bist ein Fan
von kontinuierlicher Verbesserung. Genau die Philosophie
kommt da rein. Also aus dem Value Stream Mapping,
das ist jetzt ein Beispiel von einer DevOps Praxis.
Wir haben zur Zeit ein Projekt, wo wir das beim Kunden machen
und wo wir kontinuierlich versuchen, schneller und besser
zu werden. Das ist mal so eine Möglichkeit. Eine andere
ist, das geht dann eigentlich so Richtung Kultur, weil
die Leute sind ja oft skeptisch gegenüber agiler
Vorgehensweise, DevOps, vor allem aus dem Bereich
Infrastruktur. Die haben ja oft auch ein Leben lang gekämpft gegen die Agilen
und da kann zum Beispiel ein erster Schritt sein,
in einem Team seine Arbeit zu organisieren mit Kamban.
Kamban ist ein einfaches Tool.
Viele von euch haben sicher auch schon diese Boards, Kamban Boards gesehen,
To Do, Doing, Done, wo man eben entlang des Value Stream
versucht, seine Arbeit zu visualisieren,
regelmässig zusammenzukommen, Fortschritt
zu diskutieren, den Work in Progress zu
managen. So ein erster Schritt. Was dann natürlich das andere
das ist ein riesen Thema, weil so der Kern von DevOps ist
für viele schon das Continuous Delivery.
Der Anfang von Continuous Delivery ist auch zuerst mal
sich über den Value Stream im Klaren zu werden. Also ganz simpel, wenn
Sie jetzt an eine Ihrer Applikationen denken,
es muss nicht eine Applikation sein, aber von der Anforderung
übers Bauen, Testing bis Deployment sich zu sehen,
wie es im Moment läuft und dann sich Richtung Continuous Integration
and Delivery zu bewegen. Also angefangen mit Continuous Integration,
das heisst, es ist eigentlich ein alter Zopf, Continuous Integration.
Das ist die Praxis, dass man mindestens auf täglicher
Basis Code eincheckt, in ein gemeinsames
Repository und ein paar automatisierte Tests läuft.
Das Ganze wird dann erweitert durch Continuous Delivery,
was dann heisst, dass man versucht konsequent diese
Value Chain, auch die Tests vor allem, die stattfinden,
die zu automatisieren und auch zu erweitern,
weil klassisch, wenn man schaut aus der Entwicklung, ein Problem ist ja
der Entwickler, der konzentriert sich immer auf Features,
funktionale Anforderungen. DevOps heisst jetzt,
dass man nicht funktionale Anforderungen,
sondern funktionale Anforderungen einbezieht,
dass man auch Tests dafür, beispielsweise Performance Tests,
Security Tests, man identifiziert
die, man automatisiert
die und macht sie Teil dieser Continuous Delivery
Pipeline. Ganz praktisch gesagt, nach jedem Check-In
vom Entwickler werden auch die Tests automatisch durchlaufen,
sodass man Software dann theoretisch immer in einem
Releasable State hat. Und das klingt jetzt, wenn man sich
im Legacy-Umfeld bewegt, dann klingt das natürlich nach
Mission Impossible, weil niemand hat gesagt, es ist einfach,
aber es ist eher ein Weg, den man beschreiten muss,
hier automatisieren, dort automatisieren, bis hin an so eine
Continuous Delivery Pipeline und eine Tool Chain.
Das ist ja auch was, wenn man irgendwo einen Bruch hat,
einen manuellen Bruch.
Dann habe ich kein Continuous Delivery.
Das sind so ein paar Beispiele. Es gibt ja noch so, und das kommt
da zum Teil wie Pilze, schiesst das jetzt heraus,
so neue Praktiken wie zum Beispiel ChatOps.
Das ist relativ neu. Es gibt dann so
Dinge wie, jeder von euch kennt WhatsApp.
Jetzt könnte man das gleiche Mechanismus nutzen für die
IT-Welt in der Zusammenarbeit. Also beispielsweise das
man so ein Chat-Tool nutzt, das ist dann integriert in die
bestehende Umgebung. Und wenn irgendwo ein Instant aufpoppt,
dass man direkt einen Kanal aufmachen kann, auch mit dem
Second Level, Third Level und gemeinsam an den Problemen
arbeiten kann. Da gibt es ja ganz verrückte Dinge, wie zum
Beispiel, es geht in Richtung Artificial Intelligence, dass
man solche Bots einbaut dort. Man will beispielsweise in diesem
Chat und sagt ja, bitte bring mir das jetzt in die Produktion
und der Bot verarbeitet das dann und agiert entsprechend.
So eine Art Siri für DevOps. Das ChatOps. Es gibt weitere
Beispiele, was jetzt gross am Kommen ist, ist Rucked DevOps
oder DevSecOps. Da geht es darum, Security Praktiken oder
Security Tests. Eben nicht wie früher, wenn man so eine
Partie macht, dass man sagt, ja, das ist ein separates Team,
das dann irgendwann später die Security Tests macht, sondern
dass man das versucht, früh in die Pipeline zu bringen, Tests
zu automatisieren. Das ist so die Idee dahinter. Ja, es gibt,
ich meine Dirk, du hast das sicher auch aus deiner Erfahrung,
oder? Da gibt es vielleicht noch so weitere Praktiken oder
Dinge. Man kann nicht DevOps machen, aber man kann eben
so diese, da hast du ein paar Ideen da. Ja, ja, wenn ich mir
das anhöre, was du jetzt auch gerade zum Schluss so erzählt
hast, das sind natürlich tolle Ideen, tolle Umsetzungsmöglichkeiten.
Wenn ich das so mir anschaue, das ist ja alles sehr stark in
Entwicklungsgebung. Und dann sehe ich vor mir den Delivery Manager,
sehe den Leiter des Rechenzentrums, den Leiter der IT-Infrastruktur
und der sagt sich, was soll ich damit anfangen? Das heißt, für
mich würde ich bei diesem ersten Schritt, von dem du angefangen
hast in deinen Ausführungen, ich würde diesen ersten Schritt
nochmal ein bisschen praktisch umsetzen, praktisch erläutern.
Was kann man denn tun, um mit DevOps zu starten? Und das heißt
für mich ganz klar, Kommunikation. Ich muss es hinbekommen, ein
Unternehmen muss es hinbekommen, die beiden Bereiche zusammenzubringen.
Die beiden Bereiche müssen miteinander reden, die müssen
miteinander Verständnis entwickeln. Das heißt, die beiden Bereiche
müssen zusammenarbeiten. Und das glaube ich, da sind viele Unternehmen
schon auf einem sehr guten Weg, dass sie einfach sehen, die beiden
Bereiche müssen im Sinne des Kunden zusammenarbeiten. Und dort glaube ich,
wenn ich jetzt auf die Betriebsseite schaue, ist es einfach auch interessant
und sehr gut, sich zum Beispiel mit den Community of Practice
zusammenzusetzen. Das heißt, in einem agilen Umfeld, dass ich meine
Betriebsanforderungen eben von Anfang an einbringe. Ich kann sie einbringen,
indem ich, wie gesagt, den Community of Practice gründe, wo ich mich mit
den agilen Teams auseinandersetze, wo wir gemeinsam darüber sprechen, wie
kriegen wir die agile Entwicklung dann auch schnell in einen Betrieb?
Das heißt, Kommunikation. Dann glaube ich, wird noch viel zu selten der
Standardweg benutzt, dass ich die Definition of Done vernünftig formuliere,
dass ich wirklich meine Betriebsanforderungen in eine Definition of Done
reinschreibe, dass ich meine Betriebsanforderungen auch in den User Stories
als Akzeptanzkriterium reinschreibe. Das sind für mich auch ganz praktische
Hinweise. Und an diesen Punkten, da wird schon viel diskutiert. Da gibt es
sicherlich viel Kommunikation, aber das, denke ich, ist neben den anderen Themen,
die du vorhin genannt hattest, einfach auch ein ganz wichtiger Punkt, dass ich
eben praktisch das hinbekomme, DEV und OBS zusammenzukriegen. Und was ich auch
noch wichtig finde, was meine Rednerin schon gesagt hat, ist, dass ich auch
in diesem Podcast nicht klären kann, was man regeln muss. Was wir sicherlich
heute hier in diesem Podcast nicht klären können, ist das ganze Thema Skalierung.
Wenn wir jetzt davon reden, das hast du ja selber gesagt, ich habe einen
Value Stream, ich habe eine Applikation, ich gucke mir einen Teil an, dann steckt
dahinter vielleicht auch wirklich nur ein Scrum Team. Dahinter stecken vielleicht
ganz wenige Scrum Teams. Aber die Frage ist ja, wie kriege ich meine gesamte
Umgebung, meine ganze Entdeckungsabteilung mit meinem Betrieb zusammen? Und da,
glaube ich, müssen wir uns in einem späteren Podcast nochmal ein bisschen so
auslassen, wie kriege ich das einfach skaliert? Wenn ich das jetzt hier nochmal
zurückführe auf den ersten Schritt, von dem ich eben gesprochen habe, glaube ich,
dass es einfach ganz wichtig ist, Kommunikation hinzubekommen, Offenheit auf
beiden Seiten hinzubekommen und dann einfach, dass beide an einem Ziel arbeiten.
Und das Ziel heißt, Kunden zufriedenstellen. Und das, glaube ich, ist ganz wichtig.
Und dort auch das, was wir vorhin schon hatten. Du hast ja gesprochen, dass die
Kunden zufriedenstellen. Und das, glaube ich, ist ganz wichtig. Und dort auch das, was
wir vorhin schon hatten. Du hast ja gesprochen, Culture eats strategy for breakfast.
Es muss an einer gemeinsamen Kultur arbeiten und das, glaube ich, ist eine der
großen Herausforderungen an DevOps. Und da würde auch ein Framework nicht helfen.
Das hatten wir vorhin auch als Punkt. DevOps als Philosophie, ja, es kann
kein Framework geben, was eine Kultur schafft. Dass die beiden Bereiche
miteinander sprechen, dass beide Bereiche zusammenarbeiten. Gut, also insofern,
Das wäre so meine Ergänzung dazu, zu dem Thema ersten Schritt.
Und ich glaube auch, ich habe dir eben gesagt, Betriebsseite,
ich glaube auch, dass wir dort sehr viel aus dem IT-Service-Management
an Wissen und an Erfahrung mitbringen können.
Und wenn ich das Thema DevOps als organisatorische Komponente betrachte,
dann komme ich ja dazu, ich habe es vorhin gesagt, autonome Teams zu bilden.
Und diese Teams, die kommen dann häufig sicherlich aus der agilen Entwicklung
und ich packe jetzt ein bisschen Betriebsaufgabe dazu.
Das klingt jetzt so einfach, heißt aber, dass ich ja eigentlich den gesamten Bereich
Service Design, Service Transition, Service Operation und natürlich
Continuous Service Improvement, dass ich diese Bereiche alle in das Team reinpacke.
Und das geht natürlich nicht in einem großen Framework,
aber die muss ich schon irgendwie regeln.
Es reicht eben jetzt nicht nur zu sagen, hey super, wir testen automatisiert
und haben eine Kontinente.
Wir haben das Delivery Pipeline, ich muss das Ganze ja auch organisatorisch regeln.
Und das, glaube ich, ist auch ein Punkt, wo DevOps einfach auch diese beiden Bereiche zusammenbringt.
Das heißt, wir haben schon eine agile Entwicklung, wir haben dort viele, viele Vorteile,
wir haben ein Schlangenprinz-Vorgehen und wir bringen aber IT-Service-Management-Gedanken
und Wissensgut mit ein.
Das würde ich noch einfach mit dazu packen, wenn wir nämlich über DevOps reden,
das ist ja Thema unseres Podcasts heute hier, was ist DevOps?
Dann wäre das quasi so ein bisschen mein Schlusswort, meine Erklärung, was ist DevOps?
Natürlich ist es eine Philosophie, es ist aber eigentlich nichts Neues.
Ich glaube, DevOps besteht eigentlich nur darin, dass ich die bestehenden Ansätze
wie agile Softwareentwicklung, Scrum beispielsweise, wie Lean Management,
mit Kanban als Beispiel und IT-Service-Management, ITIL oder andere Frameworks,
dass ich das zusammenbringe.
Ich glaube, das ist das, was ich unter DevOps verstehe und da denke ich,
dass wir in diesem Podcast noch das eine oder andere auch mal die einzelnen Bereiche beleuchten werden,
dass ich auch unsere Aufgabe in diesem Podcast quasi auch für Verständnis
auf der jeweiligen Seite zu werben, denn das hast du ja auch erzählt von deinem Freund.
Wenn wir mit DevOps zu klären sind, dann ist das, was ich unter DevOps verstehe,
das ist das, was ich unter DevOps verstehe, und das ist das, was ich unter DevOps verstehe.
Wenn wir zu kleineren Softwarehäusern kommen, die das schon lange machen,
dann machen die das schon so, aber die nennen das nicht DevOps.
Das heißt, das, worüber wir hier philosophieren, das ist für die Standard,
das ist für die Tagesgeschäft und das, was wir hier so schön ausbreiten,
ist etwas, was die schon seit Jahren leben und insofern glaube ich,
dass wir die einzelnen Bereiche mit diesem Podcast auch zusammenbringen.
Gut. Ja, es gäbe natürlich noch viel zu sagen.
Auch über DevOps, eben auch über die einzelnen Praktiken.
Und ich denke mal so jetzt als erster Podcast, mal so auch eine Einführung ins Thema,
warum DevOps, was ist DevOps, DevOps-Praktiken, das mal für den ersten Podcast gut ist.
Was ich jetzt lohnen würde für einen Nachfolge-Podcast,
mal sich ganz konkret so eine DevOps-Practice anzuschauen.
Und ich habe ja erzählt vom Value-Stream-Mapping.
Das ist etwas, das sich grosser Beliebtheit erfreut, mal zu identifizieren,
was sind eigentlich meine Value-Streams, so als Ausgangspunkt.
Und was wir da planen für den nächsten Podcast, ist ein Interview mit dem Kunden,
ein Real-Life-Beispiel, wie das dort umgesetzt wurde und wieso innerhalb von relativ kurzer Zeit
auch effektiv Ziele von DevOps erreicht wurden, nämlich schneller und besser zu werden.
Das so als…
Aussicht auf den nächsten Podcast.
Dirk, hast du da noch was zu ergänzen?
Ja, ich freue mich.
Das war eine sehr schöne Zeit mit dir hier, diese dreiviertel Stunde so circa.
Und ich bin zufrieden mit dem Ergebnis, aber vielleicht geht es ja unseren Hörern nicht so.
Vielleicht gibt es ja Rückmeldungen, vielleicht gibt es Hinweise.
Also insofern, wir freuen uns natürlich, wenn wir die Hörerschaft erweitern.
Ähm…
Da die Bitte natürlich, wenn es ihnen gefallen hat, weitergeben, den Hinweis auf diesen Podcast.
Und, wenn es Rückmeldungen gibt…
Alex, wie kann man dich erreichen?
Mich kann man erreichen auf alex.lichtenberger at ponthein.ch
oder auch auf Twitter, also wenn ihr da einfach nach a-lichtenberger sucht.
Ich bin da recht aktiv auf Twitter.
Und ich würde mich freuen über Feedback.
Also ganz im Sinn.
Im Sinne von Continuous Improvement, also wir versuchen auch diesen Podcast natürlich zu verbessern.
Dirk und ich würden uns auf Feedback freuen.
Wie kann man dich erreichen, Dirk?
Ja, mich kann man ähnlich erreichen.
Bei Twitter bin ich genauso erreichbar, at Söllner Dirk.
Beziehungsweise natürlich auch über meine E-Mail-Adresse dirk.söllner.de.
Ganz richtig, dirk.söllner at de.söllner.de.
Aber ich glaube…
Die meisten, die diesen Podcast hören, diesen ersten Podcast hören, kennen dich oder kennen mich.
Also insofern würde ich mich freuen, würden wir uns freuen, wenn wir Rückmeldungen bekommen.
Sei es, dass es uns gefallen hat, sei es, dass wir ein paar Dinge verändern können.
Und insofern freuen wir uns auf den nächsten Podcast und auf die Rückmeldungen unserer Hörer.
Vielen Dank, sagt Dirk Söllner und…
Vielen Dank, sagt Alex Lichtenberger.
Vielen Dank, Dirk Söllner.