Folge 59: Observability mit Alden Peterson 2/2 [EN]

Observability (kurz: O11y) ist eine wichtige Komponente von DevOps. Darüber sprechen wir mit dem QA-Experten und Observability-Fanatiker Alden Peterson von Netflix.

Dies ist der zweite Teil der Unterhaltung, die wir in der vergangenen Folge begonnen haben.

Folge 58: Observability mit Alden Peterson 1/2 [EN]

Observability (kurz: O11y) ist eine wichtige Komponente von DevOps. Darüber sprechen wir mit dem QA-Experten und Observability-Fanatiker Alden Peterson von Netflix.

Diese Unterhaltung war so fruchtbar und interessant, daß wir uns ein weiteres Mal dazu entschlossen haben, sie in zwei Teile aufzuspalten.

Dierk und Luca bei APMG LevelUp

Dierk und Luca waren beim APMG LevelUp Event als Diskussionsteilnehmer eingeladen. Das Thema war: „After Service Management, should I learn DevOps and SRE?“

Die Unterhaltung streifte verschiedene Sichtweisen auf SRE, DevOps und ITIL, und wie man die drei Ansätze am besten in Einklang bringen könnte.

Dierk und mir hat es gut gefallen: die Diskussionen waren fachlich spannend und menschlich sehr angenehm.

Wer sich die Aufzeichnung ansehen möchte, findet sie unter diesem Link: https://www.youtube.com/watch?v=0BLYZJgM-3w

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

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.

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

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.

Folge 55: DevOps in 2022

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?

Folge 53: Terraform

 

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?

Shownotes:

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

 

„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!