Mein letzter Blogartikel zum Thema DevOps ist jetzt ueber 6 Jahre her. Damals gings noch um Schatten-IT und dem steten Grabenkampf zwischen Entwicklung und Betrieb. Mittlerweile bin ich selt einiger Zeit Mitglied in einem DevOps-Team, was ein Paradoxum an sich ist, denn sowas wie DevOps-Teams gibt es gar nicht. Stattdessen geht es um den Flow.
Heutzutage soll IT sowas sein wie ein Fluss, ein Fluss an Arbeit. So wird der erste von drei Wegen aus dem “Phoenix Project” beschrieben. Continuous Integration, Continuous Delivery und Continuous Deployment sind hier die Schlagwörter. Entwickler sollen also ihren Code immer in ein Repository einchecken, damit die Software staendig in einem auslieferbaren Zustand ist und letztlich nach Durchfuehrung diverser Tests automatisch ausgerollt werden kann. Alles ist also schoen im Fluss.
Der zweite Weg heisst Feedback. Feedback erhaelt man zum Beispiel durch die automatisierten Tests. Durchlaufen diese fehlerfrei, gibts ein OK zurueck. Sonst gibts eine Fehlermeldung. Monitoring oder Auswertung von Logfiles gehoeren aber auch zum Feedback. Peer Reviews beim Programmieren sind Feedbacks. Viele Bestandteile von ITIL wie Change-, Incident- und Problemmanagement beschreiben Feedbackloops, genau wie etwa Knowledge Management.
Der dritte Weg ist dann schon die Koenigsklasse: Continuous Experimentation and Learning. Lebenslanges Lernen, hoert man heutzutage immer oefters. In diesem Weg soll immer nach Verbesserungen gesucht werden. Deming-Cycle ist hier ein Schlagwort (Plan-Do-Check-Act). Improvement Kata ist auch so ein Schlagwort hier. Ich wuerde es als Weg der kleinen Ziele beschreiben. Man soll immer erst ein kleineres Ziel vor Augen haben und nicht monate- oder jahrelang an irgendwas ganz Grossem basteln. Dafuer hilft zum Beispiel eine Vision, was man eigentlich erreichen will. Die sollte man am Anfang vom dritten Weg definieren.
Okay, und wer sind jetzt diese DevOps? Dev sind zum Beispiel die Kunden (ja, richtig!), Architekten, Analysten, Leute vom Business, Produktmanager, Projektmanager, Tester, Lieferanten. Sicherlich gehoeren auch Entwickler dazu, weil sie natuerlich mit an der Entwicklung von Softwareprodukten und Services beteiligt sind. Wichtiger hier ist aber das Business. IT ist kein Selbstzweck. Das Geld kommt vom Business und wie heisst es so oft: Folge dem Geld. Auf der Ops-Seite stehen alle Personen, die mit dem Ausliefern und dem Betreuen der Software und Services betraut sind. Also alle Arten von Administratoren (Netzwerk, Security, Datenbanken, Dienste), Kundendienst, Lieferanten. Diese beiden Gruppen standen bisher an der Wall of Confusion. Die eine ist extrem fokussiert auf Veraenderungen, die andere Gruppe moechte eher Stabilitaet. Wozu das Thema also weiter stressen? Nun, die Welt da draussen dreht sich immer schneller. Informationen werden schneller ausgetauscht, Produkte kommen schneller auf den Markt, Services bekommen neue Funktionen, die der Kunde nachfragt oder ueber die er noch gar nicht nachgedacht hat. Wer da nicht auf der Strecke bleiben will, brauch eine leistungsfaehige IT, die schnell, aber fehlerfrei liefern kann. Die Theory of Constraints steht im Ersten Weg noch im Weg, beschrieben im Buch “Das Ziel”. Kurz erklaert: Jeder Prozess hat seinen Flaschenhals und kann deswegen nur genauso schnell sein wie dieser. Ein Constraint kann zum Beispiel eine verspaetete Softwarelieferung sein, eine Serverumgebung, die noch nicht fertig ist, fehlgeschlagene Tests, aber auch komplexe und buerokratische Prozesse. Diese Flaschenhaelse zu verbessern, ist der schnellste Weg, um den ganzen Produktionsablauf zu verbessern. Okay, und was ist jetzt dieses DevOps? DevOps = CAMS (Culture, Automation, Measurement, Sharing) DevOps ist also Kultur. Ja! Nein! DevOps ist erstmal alles zusammen. Wenn ich alles automatisiere, ist das zwar sehr schoen, aber es sind nur 25% vom Prinzip DevOps. DevOps ist also Kultur. Ja, und wie es bisher so verlaeuft, ist unsere Kultur schon viele tausend Jahre alt. Nur wird man fuer eine DevOps Kultur nicht so lange brauchen, aber von heute auf morgen wird das auch nicht klappen. Cultural Dept wird das auch genannt, was man sich jahrelang aufgebaut hat, Silo-Organisationen, Silo-Denken, abgeschottete Teams. Kultur ist fuer mich vor allem Vertrauen. Vertrauen und Respekt. Transparenz gehoert dazu wie ein offenes Meinungsbild. Kollaboration und Sharing zaehlt noch dazu, wir kommen nochmal drauf zurueck. Pride of work. Wir haben das bei uns als #Werkstolz zusammengefasst. Eigentlich ganz witzig, dass es ueberall schon viele Facetten von DevOps gibt, die Kultur also schon angefangen hat, sich zu aendern. Die beste Moeglichkeit besteht darin, die Leute mit einzubeziehen. Angefangen von verbessertem Tooling wie bei ChatOps, wo sich Menschen in Slack-Channels, Hipchat oder IRC zusammenfinden und auch Robots Statusmeldungen in den enstrechenden Kanal posten. Team-Building steht wieder auf der Tagesordnung, denn nur wer sich kennt, wird sich moegen. Interne DevOps Tage helfen fuer einen Austausch und ein gemeinsames Verstaendnis, genauso wie Job Shadowing, Hackathons und Simulationen. One Team, One IT sind noch weitere Schlagwoerter, aber wie schon erwaehnt: Die Leute muessen das auch wollen, sonst wird das nichts und den naechsten Schritt kann man sich sparen. Zu Automatisierung haben wir weiter oben schon gelesen. Zu CI/CD gibt es diese schoene Infografik von Gitlab, ein Automatisierungs-Tool zur Codeverwaltung:
Sehr schoen ist der Flow zu sehen, vom Schreiben des Codes bis zum Abheben der Rakete. Welche anderen Tools noch dabei helfen, hat Xebialabs in einem Periodensystem dargestellt:
Es wird noch extra darauf hingewiesen, dass man Open-Source-Tools bei der Auswahl seiner Werkzeuge fuer DevOps bevorzugen sollte.
Zum Thema Measurement gehoert auch Lean. Lean Thinking bedeutet einen Mehrwert zu schaffen aus Sicht des Endkunden. Dazu gibt es einen Value Stream von der Kundenanforderung bis zur Auslieferung des Features oder des Produkts. Dabei soll jegliche Art von Abfall (Waste) beseitigt werden. Waste wird auch als Muda bezeichnet, Varianten sind Muri und Mura und unterzeichnen sich in den Quellen des Abfalls (Source of Waste). Das koennen zum Beispiel Defekte sein, eine Ueberproduktion, Wartezeiten, Transportzeiten, Inventur, exzessive Prozesse. Vermeidung von Waste zahlt auf Kata Improvement ein (siehe oben). Wie wir vielleicht schon erkannt haben, kann DevOps nicht fuer sich alleine stehen. Wir haben ganz oben schon Bestandteile von ITIL erkannt. Gerade haben wir von Lean gelesen. Und natuerlich gehoert Agile noch dazu, das gefluegelte Wort fuer Agilität (Agility). Den Begriff kannte ich eigentlich nur aus dem Hundesport: [video:youtube:LbQZ4FGv9ug]
Schnell auf Ereignisse und Situationen reagieren, das gehoert zum Agilen Service Management. Die zwei bekanntesten Arbeitsmethoden sind Scrum und Kanban. Scrum in einem Satz erklaert: Es gibt verschiedene Rollen: Scrum-Master, Product-Owner, Scrum-Team, es gibt verschiedene Meetings: Grooming, Daily, Retrospektive, gearbeitet wird in Sprints, was eine zeitlich begrenzte Miniprojektphase ist und Arbeit wird an einem Scrum-Board visualisiert, wo tausend kleine Zettelchen dranhaengen. Kanban hat auch ein Board, das sogenannte Kanban-Board. In horizontalen Saeulen wird der Flow der Arbeit dargestellt. Angefangen von dem was zu tun ist (ToDo), dem was gerade gemacht wird (InProgress) und das was fertig ist (Review/Done). Wer im Kanban-Team arbeitet, “zieht” sich die Task (pull), an denen er arbeiten moechte. Kanban an sich ist wenig kollaborativ. Vielmehr geht es um Arbeitsorganisation und Planung. Bei Kanban sollte man jederzeit Aussagen treffen koennen, wann eine Arbeit fertig ist.
Aber genug von der Arbeit. Kommen wir zum letzten Bestandteil von DevOps: Sharing Das Teilen von Wissen, Informationen zu Problemen und Loesungen, Use Cases, Lesasons Learned ist nicht etwa die Kuer von DevOps. Wie ich weiter oben schon schrieb, ist es ein fester Bestandteil. Die Kultur des Teilens kann auf vielerlei Arten ausgepraegt sein: Code-Sharing auf Github, Blog-Beitraege, Video-Tutorials auf Youtube erstellen, interne DevOps-Tage, lokale Meetups, Summits. Andere Methoden zahlen darauf ein wie Working Out Loud (WOL). WOL ist vom Erfinder John Stepper kurz hier erklaert: und ist gerade fuer nicht so extrovertierte Leute interessant. In kleinen Gruppen (Circle) treffen sich Leute, um in einem Zeitraum von 12 Wochen jeder fuer sich ein bestimmtes Ziel zu erreichen und andere in der Gruppe daran teilhaben zu lassen. Die Erfahrungen und Ergebnisse werden miteinander geteilt. An dieser Stelle schliesst sich auch der Kreis von DevOps. Weiter oben habe ich vom Einsatz von Open-Source-Software geschrieben. Aber wo kommt diese Software eigentlich her? Die Open-Source-Community lebt nur vom Teilen, ohne dem waere sowas gar nicht moeglich.
Und wie geht DevOps jetzt los? John P. Kotter hat das in seinem Buch “Leading Change” so beschrieben:
“Leadership defines what the future should look like, aligns people with that vision, and inspires them to make it happen despite the obstacles.”
Fuer DevOps muss es vom Management gruenes Licht geben. Es muss einen Sinn fuer die Notwendigkeit bestehen. Eine Strategie und eine Vision muss wohl formuliert und breit kommuniziert sein. Gewinnbare Ziele sollten kurzfristig erreichbar sein. Experimentieren und ausprobieren gehoeren mit dazu.