01 — Warum DevOps

Teil A — Warum überhaupt. Zurück zur Übersicht.

Stell dir zwei Teams vor, die beide hervorragende Arbeit leisten und sich trotzdem gegenseitig blockieren.

Die Entwicklung wird daran gemessen, wie viele Funktionen sie liefert. Ihr Erfolg ist Veränderung. Je mehr sie ausliefert, desto besser ihre Bilanz.

Der Betrieb wird daran gemessen, wie stabil die Systeme laufen. Sein Erfolg ist Beständigkeit. Und die größte Einzelursache für Störungen ist — statistisch belegbar — die Veränderung.

Beide Teams verhalten sich also völlig rational, wenn sie das jeweils andere ausbremsen. Die Entwicklung wirft Änderungen über den Zaun, der Betrieb baut immer höhere Zäune. Man hat dafür einen Namen gefunden: die Mauer der Verwirrung.

   ENTWICKLUNG                    │                    BETRIEB
                                  │
   "Bei mir lief es."             │   "Dann lass es doch
                                  │    bei dir laufen."
   Ziel: Veränderung              │   Ziel: Stabilität
   Erfolg: neue Funktionen        │   Erfolg: keine Störung
   Zeithorizont: bis zum Release  │   Zeithorizont: die nächsten Jahre
                                  │
              ──── Änderungen ───►│
              ◄─── Beschwerden ───│
                                  │
                            die Mauer

Das Bemerkenswerte daran: Es gibt keinen Schuldigen. Niemand ist faul, niemand ist böswillig. Das Problem steckt in der Zielvorgabe, nicht in den Menschen. Wer das verstanden hat, hat die halbe Miete — denn jeder Lösungsversuch, der auf „die Kollegen müssen sich mal zusammenreißen„ hinausläuft, ist damit schon widerlegt.

Der Wertstrom ist der gesamte Weg einer Idee bis zu dem Moment, in dem ein Kunde etwas davon hat. Bei Software heißt das: von „jemand hat einen Wunsch“ bis „die Änderung läuft in Produktion„.

Interessant ist dabei weniger die Summe der Arbeitszeit als das Verhältnis zwischen Arbeiten und Warten. Ein realistisches Beispiel:

Die eigentliche Arbeit macht keine fünf Prozent der Durchlaufzeit aus. Der Rest ist Warten — auf Freigaben, auf Umgebungen, auf Termine, auf andere Menschen.

Jede Übergabe zwischen zwei Teams kostet mehr, als sie auf dem Papier sollte:

• Wissen geht verloren. Was der Entwickler über die Änderung weiß, steht nie vollständig im Ticket.
• Es entsteht Wartezeit. Der Empfänger arbeitet gerade an etwas anderem.
• Rückfragen dauern. Jede Rückfrage ist ein weiterer Wartezyklus.
• Verantwortung verdunstet. Nach drei Übergaben fühlt sich niemand mehr zuständig.

Bei sieben Übergaben von der Idee bis zur Produktion — was in großen Organisationen keineswegs viel ist — potenziert sich das. Die Arbeit ist irgendwann fertig; das Warten nicht.

Man kann sich das wie die Bearbeitungswege einer Verwaltung vorstellen, in der jeder Antrag in dreifacher Ausfertigung an eine andere Stelle weitergereicht wird, wobei mindestens eine Ausfertigung stets im Keller landet. Wer die Anhalter-Bücher kennt, weiß, dass die Umgehungsstraße dann trotzdem gebaut wird — nur eben ohne dass jemand vorher davon erfahren hätte.

Der Begriff entstand 2009. Auf der Velocity-Konferenz zeigten zwei Mitarbeiter von Flickr, dass ihr Unternehmen mehr als zehnmal am Tag ausliefert — zu einer Zeit, als vierteljährliche Releases als ambitioniert galten. Wenige Monate später organisierte Patrick Debois in Gent die ersten devopsdays. Das Kunstwort aus Development und Operations blieb hängen.

DevOps ist:

• eine Arbeitsweise, die den gesamten Wertstrom betrachtet statt einzelner Abteilungsziele
• geteilte Verantwortung für das Ergebnis, nicht nur für den eigenen Arbeitsschritt
• Automatisierung von allem, was wiederholt und fehleranfällig ist
• kurze Rückmeldeschleifen

DevOps ist nicht:

Ab hier begleitet uns durchgehend dieselbe Anwendung.

Ausgangslage. Der KFZ-Rechner ist ein kleiner Webdienst, der aus Fahrzeugtyp, Alter und Schadenfreiheitsklasse eine Prämie errechnet. Er besteht aus etwa 400 Zeilen Python und läuft seit drei Jahren.

Nichts davon ist ungewöhnlich. Genau so sehen sehr viele gewachsene Anwendungen aus, und meistens funktionieren sie sogar — bis sie es nicht mehr tun.

Zielzustand am Ende dieser Unterlage. Der Code liegt in Git, jede Änderung wird automatisch getestet, gebaut und containerisiert, mehrmals täglich ohne Wartungsfenster ausgeliefert, überwacht, und ein Rollback dauert unter einer Minute.

Wir kommen dorthin in neunzehn kleinen Schritten. Nicht in einem großen.

Für dieses Lab brauchst du keinen Rechner, sondern Papier.

1. Wähle eine echte Änderung, die zuletzt in Produktion gegangen ist.
2. Zeichne jeden Schritt vom ersten Wunsch bis zum Produktivgang auf — auch die, die dir selbstverständlich erscheinen.
3. Notiere je Schritt zwei Zahlen: die reine Bearbeitungszeit und die Wartezeit davor.
4. Markiere jede Übergabe an eine andere Person oder Abteilung mit einem Kreuz.
5. Rechne aus: Bearbeitungszeit geteilt durch Gesamtdauer. Das ist deine Flow-Effizienz.

Werte zur Einordnung: Unter 5 Prozent ist üblich. Über 25 Prozent ist bereits sehr gut. Wer 100 Prozent herausbekommt, hat vermutlich falsch gemessen.

Wie lange dauert es in deinem Betrieb von der fertigen Codeänderung bis zum Produktivgang — und welcher einzelne Schritt darin ist der längste?

Wenn die Antwort „das weiß ich nicht“ lautet, ist das keine Wissenslücke, sondern schon der erste Befund.

Weiter mit Kapitel 02 — Kultur und Prinzipien