In diesem Konferenzvortrag bespreche ich eines der grundlegendsten Themen in DevOps: das Denken in Systemen und Wertströmen. Wenn ich mit Unternehmen an ihren DevOps-Transformationen arbeite, sehe ich immer wieder dieselben Muster. Das Business hat tolle Ideen. Diese werden in Word-Dokumente und Jira-Tickets geschrieben. Dann werden sie über die Mauer der Verwirrung zum Entwicklungsteam geworfen. Das Entwicklungsteam baut etwas und wirft es zum Testing. Das Testing vergleicht die Spezifikation mit dem Gebauten (was nie ganz übereinstimmt), testet etwas und wirft es zum Betrieb. Der Betrieb fragt: “Wie sollen wir das betreiben?” Und irgendwie, mit grossem Aufwand, bringen sie es zum Laufen. Dann sieht der Kunde das Ergebnis und sagt: “Was ist das? Das haben wir nicht bestellt.”
Von Projekten zu Produkten#
Die Wurzel des Problems liegt oft darin, wie Organisationen über Arbeit denken. Früher machten wir alle Waterfall: Scope war fix, Budget war fix, Zeit war fix. Dann kamen wir zu Agile und arbeiteten inkrementell. Aber in vielen Organisationen arbeiten wir immer noch in Projekten, nur eben inkrementell. Was wir tun sollten, ist in Produkten arbeiten, denn das ist es, was unsere Kunden wirklich wollen.
Der Unterschied ist fundamental. Projekte fokussieren auf Output: die Anzahl gelieferter Features, User Stories, Tasks oder Codezeilen maximieren. Produkte fokussieren auf Outcome: das Kundenbedürfnis verstehen, das echte Problem lösen, Verhalten verändern und Wert liefern. Der eine Ansatz zählt, was geliefert wird. Der andere misst, ob es einen Unterschied gemacht hat.
DevOps hilft uns bei diesem Wechsel. DevOps ist ein Mindset, eine Kultur und ein Set von technischen Praktiken, das Kommunikation, Integration, Automatisierung und enge Zusammenarbeit über den gesamten Wertstrom ermöglicht.
DevOps ist für alle#
Der Begriff “DevOps” ist völlig irreführend. Man denkt, es geht um Development und Operations. Manche versuchen es zu korrigieren: “DevSecOps” (mit Security) oder “BizDevOps” (mit Business). Aber all diese Begriffe schliessen jemanden aus. Was wir eigentlich bräuchten, ist so etwas wie “DevSecBizArcCompQAOps.” Oder wir nennen es einfach DevOps, denn DevOps bedeutet, alle Menschen, alle Prozesse und alle Technologien zusammenzubringen, um kontinuierlich Wert zu liefern. Das ist DevOps.
Warum ist das wichtig? Im Jahr 2000 begannen kleine Firmen mit lustigen Namen wie Netflix und Google, mit Agile und DevOps zu experimentieren. Heute dominieren sie den Markt. Dasselbe passiert gerade in der Hardware-Branche. Tesla experimentiert mit DevOps und agilen Arbeitsweisen, und die Auswirkungen sind enorm.
Ein konkretes Beispiel von Elon Musk: Im Oktober 2021 veröffentlichte er ein Autopilot-Update an 1.000 Autobesitzer mit perfektem Safety Score. Das ist ein Canary Release für Autos. Acht Tage später, nach positiven Ergebnissen, erweiterte er die Gruppe. Dann wurde ein Problem gefunden, und er machte einen Rollback. Das sind Autos auf der Strasse, und er macht einen Software-Rollback. Viele Unternehmen schaffen das nicht einmal mit normaler Software. Keine 24 Stunden später war der Fix deployed. So sieht DevOps in der Praxis aus.
Value Stream Mapping#
Bevor man das System verbessern kann, muss man das ganze System sehen. Value Stream Mapping ist eine einfache und wirkungsvolle Technik. Man bringt alle Personen, die in einem Wertstrom arbeiten, in einen Raum, gibt ihnen Post-its und fragt: Welche Schritte braucht es von der Idee bis zur Produktion?
Für jeden Schritt identifiziert man die Verantwortlichen und misst drei Dinge:
- Lead Time: Die Gesamtzeit vom Ende eines Prozessschritts bis zum Ende des nächsten, inklusive aller Wartezeiten.
- Process Time: Die tatsächliche wertschöpfende Arbeitszeit innerhalb eines Schritts.
- Percentage Complete and Accurate (%C&A): Wie oft der Output eines Schritts vom nächsten Schritt ohne Nacharbeit genutzt werden kann.
Die Ergebnisse sind oft augenöffnend. Zum Beispiel könnte ein Testing-Schritt 8 Stunden tatsächliche Arbeit zeigen, aber 336 Stunden Lead Time, was massive Wartezeiten offenbart. Wenn der Code-Schritt nur 60% C&A zeigt, bedeutet das, dass in 40% der Fälle Arbeit zurückgehen muss. Diese Engpässe werden sichtbar, und Teams können systematisch daran arbeiten, sie zu beseitigen.
Die Continuous Delivery Pipeline#
Dieser Wertstrom ist nichts anderes als eine Continuous Delivery Pipeline. Um sie zu verstehen, müssen wir die Begriffe klären:
Continuous Integration (CI): Entwickler schreiben Code auf ihren Maschinen und committen in ein Source-Code-Repository. Der CI-Server baut den Code, führt statische Analyse, Security-Checks und Unit Tests durch. Das Feedback muss den Entwickler in Minuten erreichen, nicht in Stunden oder Tagen. Das Ergebnis ist ein deploybares Artefakt.
Continuous Delivery (CD): Das deploybare Artefakt wird automatisch in eine Staging-Umgebung (eine produktionsnahe Umgebung) installiert, wo weitere Tests ausgeführt werden. Das Feedback geht wieder an den Entwickler.
Continuous Deployment: Alles von CI und CD geschieht automatisch, und wenn alle Tests bestanden sind, wird das Artefakt automatisch in die Produktion deployed. Die meisten Unternehmen machen CI und CD. Sehr wenige machen Continuous Deployment. Das ist völlig in Ordnung.
Shift Left: Qualität einbauen#
Im traditionellen V-Modell wurden Tests mit verzögerten Feedback-Zyklen von drei bis sechs Monaten geschrieben und ausgeführt. Im agilen Umfeld machen wir Shift Left. Wir nutzen Behavior Driven Development (BDD), um Akzeptanzkriterien im Given-When-Then-Format zu schreiben und so ausführbare Spezifikationen zu erstellen. Wir nutzen Test Driven Development (TDD) als Test-First-Ansatz. Durch testbare Spezifikationen von Anfang an schreiben wir Tests vor dem Code und erkennen Probleme sofort.
Auch die Testpyramide verändert sich. Der traditionelle Ansatz versuchte, alle Bugs mit vielen End-to-End-Tests (oft manuell), einigen Integrationstests und wenigen Unit Tests zu finden. Der agile Ansatz will Bugs verhindern: viele schnelle Unit Tests, einige Integrationstests und nur wenige End-to-End-Tests. Es ist ein fundamentaler Wechsel vom Finden zum Verhindern von Bugs.
Architektur für den Betrieb#
Etwas, das ich viel zu oft sehe: Teams bauen Dinge, ohne darüber nachzudenken, wie sie in der Produktion funktionieren. You build it, you run it, and when it breaks, you fix it, als ganzes Team. Dafür braucht man Monitoring mit Toleranzschwellen und Alerting, eine klare Benachrichtigungsstrategie und geübte Disaster-Recovery-Verfahren. Kein Word-Dokument, das veraltet ist, wenn die Katastrophe eintritt. Tatsächlich geübte Verfahren.
Teamübergreifende Zusammenarbeit ist essenziell. Alle sind verantwortlich für ein grossartiges Produkt. Und Incident Post-Mortems sind unschätzbar wertvoll für die kontinuierliche Verbesserung. Infrastructure as Code, Full-Stack-Telemetrie (inklusive Infrastruktur, nicht nur Anwendung), Feature-Nutzungsmetriken zur Unterstützung von Geschäftsentscheidungen: all das wird gebraucht.
“Das grösste Hindernis bei DevOps-Transformationen? Das mittlere Management. Sie wollen die Transformation nicht, weil sie ihre Silos aufbricht und sie einen Teil ihrer Macht verlieren.”
Kernaussagen#
- Von Projekten zu Produkten wechseln. Auf Outcomes (gelöste Kundenprobleme) fokussieren statt auf Outputs (gelieferte Features).
- Ganzheitliches Systemdenken anwenden. Alle im Wertstrom brauchen eine klare Sicht auf den gesamten Fluss, nicht nur auf ihren Teil.
- Den Wertstrom visualisieren. Alle Schritte von der Idee bis zur Produktion identifizieren, Lead Time, Process Time und Qualität messen und Engpässe systematisch beseitigen.
- Die Continuous Delivery Pipeline automatisieren. CI/CD ist die Automatisierung des Wertstroms. Qualität von Anfang an einbauen mit BDD und TDD.
- Für den Betrieb architekturieren. Von Tag eins an die Produktion denken. Telemetrie einbauen, Disaster Recovery üben und Post-Mortems für kontinuierliche Verbesserung nutzen.
- DevOps ist für alle. Es geht nicht um Dev und Ops. Es geht darum, alle Menschen, Prozesse und Technologien zusammenzubringen, um kontinuierlich Wert zu liefern.