Was DevOps Excellence wirklich bedeutet
Mein heutiger Gesprächspartner, GPT 5.4 Thinking, beschreibt DevOps Excellence als eine interessante Eigenschaft von Organisationen:
Die Fähigkeit, Produktionssysteme sicher, häufig und bewusst zu verändern.
Diese Eigenschaft ist also weniger eine Liste von Checkboxen, die man einfach abhaken kann – IaC, Cloud-Migration, Pipelines, Daily Scrum, Plattformteam und so weiter – und weit mehr das Ergebnis der konzeptionellen Grundlagen von DevOps sowie ihrer konsequenten Anwendung im Alltag.
Der DevOps Lifecycle basiert auf kontinuierlichen Feedbackschleifen zwischen Entwicklung, Deployment und Betrieb. Diese zeigen sich in allen Etappen des Loops in Form von vor- und nachgelagerten Stufen:
- Eine Software-Revision, die die Tests nicht besteht, muss so lange überarbeitet werden, bis sie es tut.
- Ein Software-Release, das sich nicht ausliefern lässt, muss neu gebaut – wenn nicht gar weiterentwickelt – werden, bis es auslieferbar ist.
- Ein Deployment, das sich nicht zuverlässig betreiben lässt, muss untersucht werden, insbesondere mithilfe adäquaten, sinnvollen Monitorings.
Die genannte Organisationseigenschaft stützt sich implizit auf genau diese Feedbackschleifen. Optimierte Prozesse sind nötig, um häufig deployen zu können; zugleich müssen sie dort unterbrochen werden können, wo es erforderlich ist – durch Quality Gates, durch Reviews und durch Mechanismen, die sichere Entwicklung gewährleisten und die Absicht der Entwickler widerspiegeln.
Mit dieser Entwicklerabsicht geht auch die Bereitschaft einher, Verantwortung für Liefergegenstände und deren Folgen zu übernehmen. Genau das sehen wir uns im nächsten Abschnitt näher an.
Verantwortung und Kontrolle aus einer Hand
Wenn Software effizient entwickelt, effektiv ausgerollt und nachhaltig betrieben werden soll, dann lautet eine der zentralen Einsichten von DevOps Excellence:
Verantwortung und Kontrolle gehören in dasselbe Team.
Das klingt banal. In der Praxis ist es das erstaunlich oft nicht.
Ein klassisches Gegenbeispiel sieht so aus: Ein Entwicklungsteam schreibt die Software. Ein Systemteam rollt sie aus. Ein Betriebsteam versucht, sie am Laufen zu halten – gern auch um 02:00 Uhr morgens, selbstverständlich ohne On-Call-Begleitung der Entwickler.
Im Privatleben verstehen wir intuitiv, dass gute Ergebnisse dort entstehen, wo Verantwortung, Kontrolle und Konsequenzen zusammenfallen. In Unternehmen hingegen verbringen nicht wenige Menschen acht Stunden am Tag damit, so zu tun, als sei genau dieses Prinzip für zentrale Geschäftsprozesse entbehrlich – eine durchaus bemerkenswerte Einsicht.
Wer seine Softwareorganisation befähigen will, gute Systeme zu liefern, sollte die Verantwortung über die Software daher dort ansiedeln, wo Planung, Entwicklung und Releases bereits stattfinden: im Team selbst.
Das führt fast zwangsläufig zu schnelleren und wahrheitsgetreueren Feedbackschleifen – und damit zum nächsten Punkt.
Tools lesbar und verständlich halten
Ich habe in der Vergangenheit mit mehreren Big-Data-Frameworks gearbeitet, die versprachen, das Setup von Hadoop und verwandten Werkzeugen zu vereinfachen. Ähnliche Werkzeuge gibt es, um Kubernetes «einfacher» handhabbar zu machen.
Das Problem ist nur: Während Vereinfachung versprochen wird, verbringt man in der Praxis oft erhebliche Zeit damit, die Abstraktion selbst zu erlernen, statt sich mit dem eigentlichen Problem zu beschäftigen – also Daten zu speichern und auszuwerten, oder Anwendungen zu entwickeln und zu betreiben.
Deshalb sollte man sehr genau hinschauen, welche Abstraktionen man in den eigenen Workflow hineinholt. Werkzeuge sollten dabei helfen, bei kritischen Infrastrukturentscheidungen das Richtige zu tun. Sie sollten Komplexität nicht bloss verdecken und Verständnis nicht ersetzen.
Ich stelle immer wieder fest, dass Exzellenz oft erstaunlich langweilig aussieht: kleine Werkzeuge, von denen jedes genau eine Sache gut kann; transparente Systeme mit sauber definierten Schnittstellen; wiederholbare Prozeduren, bei denen jede Iteration das Verständnis des Gesamtsystems vertieft.
XWare unterstützt Unternehmen dabei, DevOps-Praktiken systemisch weiterzuentwickeln – mit klaren Prioritäten und umsetzbaren nächsten Schritten.
Kohärente Betriebsmodelle entwickeln
Startups, die neue Software auf Hyperscalern prototypisch entwickeln, wachsen häufig organisch in ein cloud-natives Betriebsmodell hinein. Etablierte Unternehmen, die Monolithen in den eigenen Rechenzentren betreiben, hatten dagegen viele Jahre Zeit, ein On-Premise-Mindset auszubilden. Organisationen, die in hybride Modelle gedrängt werden, geraten immer wieder dann in Schwierigkeiten, wenn ihre Geschäftsprozesse mit dem technischen Status quo nicht mehr Schritt halten. Denn eines ist fast immer sicher:
Den alten Prozess schlicht auf eine neue Umgebung zu übertragen, erzeugt meist mehr Widersprüche, als man zunächst wahrhaben will.
Ein ähnliches Problem zeigt sich bei der Wahl von Softwareentwicklungsmethoden. Eine aus Scrum herausgewachsene Organisation, die zusätzliche Frameworks einführt, um teamübergreifende Kommunikation zu strukturieren, wird andere Probleme haben als eine Organisation, die historisch stark zum Wasserfall neigte und nun plötzlich Scaled Agile Frameworks einführt.
Mit der Zeit wird man einen Weg finden wollen, die mit diesem Wandel verbundenen Spannungen und Widersprüche aufzulösen. Gute Chancen stehen dabei für bewusste Entscheidungen, die tatsächlich zur eigenen Organisation passen – und anschliessend dafür, Prozesse, Architektur und Führungsverhalten konsequent daran auszurichten.
Anreize an der Systemgesundheit ausrichten
— Andrew Ross Sorkin
Organisationen sollten die richtigen Dinge belohnen. Wie bereits angedeutet, wären unter anderem folgende Aspekte sinnvolle Ansatzpunkte für Anreize:
- Einfachheit
- Lesbarkeit
- schnelle und wahrheitsgemässe Feedbackschleifen
- geringe Fragilität
- gute Fähigkeiten zur Fehlerbehebung
- und letztlich auch Uptime
Stattdessen habe ich immer wieder Unternehmen erlebt, die ein regelrechtes Komplexitätstheater aufführen und dabei ein Durcheinander aus Tooling, Software-Stack und Architektur erzeugen, weil genau das am schnellsten persönliche Sichtbarkeit und Anerkennung verspricht. In solchen Umgebungen verliert nachhaltige Wartbarkeit fast immer gegen das nächste glänzende neue Werkzeug.
Es lohnt sich daher, klare Verantwortlichkeiten für die kontinuierliche Verbesserung der Systeminfrastruktur zu definieren – und diese in eine Kultur einzubetten, die echte Verbesserungen zulässt und honoriert, insbesondere dann, wenn sie der Organisation helfen, die zuvor genannten Ziele zu erreichen.
Ein praktischer Test für DevOps Excellence
Ein paar Fragen, die helfen können, den Reifegrad einer Organisation auf dem Weg zu DevOps Excellence einzuschätzen, könnten etwa so lauten:
- Kann das Team deployen, was es baut?
- Trägt das Team die Kosten von Instabilität?
- Werden Reviews genutzt, um kritisch zu reflektieren, oder nur zum Abnicken?
- Beantwortet jede Umgebung eine konkrete Frage des Engineerings?
- Kannst du euer Operating Model in einem Satz beschreiben?
- Überlebt euer Prozess personelle Wechsel, ohne zum Cargo Cult zu verkommen?
- Ist die Verantwortung im Fall von Zwischenfällen eindeutig geregelt?
Die 4x4-Methodologie
Wir bei der XWare GmbH haben es in längerfristigen Engagements als hilfreich empfunden, Kunden bereits im Onboarding mit einer Reihe von Fragen zu qualifizieren, die sich auf die verschiedenen Komponenten des DevOps Infinity Loops beziehen.
Daraus ist unsere eigene 4×4-Methodologie entstanden, in der unsere Teilhaber sich auf unterschiedliche Schwerpunkte vertiefen. Ein kleiner Ausschnitt daraus:
- Über wie viele Stellen hinweg – Anwender, Verkaufsorganisationen, weitere interne Einheiten – müssen Sie zwischen dem Endanwender und Ihrem DevOps-Entwicklungsteam kommunizieren?
- Definieren Sie Themes, Epics oder Grobanforderungen, und sind diese so gebündelt, dass daraus anschliessend ein konkreter, nutzbarer Anwendungsfall entsteht?
- Erarbeiten Sie eine Roadmap, in der Releases, Ziele und Inhalte ersichtlich sind?
- Für welche Artefakte wird Versionskontrolle verwendet? Anforderungen, Code, Konfiguration, Tests, Testdaten?
- Welche Arten von Code Reviews kommen zum Einsatz? Pair Review vor Abschluss einer Story, PR-Policy mit verpflichtendem Reviewer-Approval, Präsentation von Enabler Stories vor dem ganzen Team, sporadisches Pair Programming, statische Code-Analyse?
- Wie verwalten Sie Staging-Umgebungen? Vollautomatische Deployments, teilautomatisierte Deployments oder manuelle Pflege?
- Wie prüfen Sie die Qualität der erstellten Applikationen? Durch automatisierte Tests, Performance-Tests, Penetrationstests, manuelles Testing — oder gar nicht?
- Wie erkennen Sie potenzielle Probleme frühzeitig? Wie reagieren Sie auf Security Incidents?
- Wie messen Sie Benutzerverhalten und sammeln Rückmeldungen?
- Wie prüfen Sie Produkthypothesen aus dem ersten Schritt anhand der gesammelten Daten?
Fazit: DevOps Excellence ist ein organisationales Verhalten
DevOps Excellence ist keine Zertifizierung, kein Maturity Badge und keine Einmalmassnahme. Sie ist das Resultat einer Organisation, die lernt, Verantwortung nahe an der Kontrolle anzusiedeln, zu evaluieren, was funktioniert, und wegzuwerfen, was nicht. Sie verkürzt und verstärkt Feedbackschleifen und bringt die Anreize ihrer Stakeholder in Einklang mit der Fähigkeit, Produktionssysteme sicher, häufig und bewusst zu verändern.
Im Umkehrschluss bedeutet das: DevOps Excellence lässt sich nicht einmalig «ausrollen» und dann als abgeschlossen betrachten. Sie ist eine dauerhafte Gewohnheit, ein organisationales Verhalten, eine Umgebung, in der gute Entscheidungen über die Zeit wahrscheinlicher werden.
Diese Entscheidungen vereinen Verantwortung und Kontrolle. Sie verbessern Geschwindigkeit und Ehrlichkeit des Feedbacks. Sie begünstigen Einfachheit und Lesbarkeit im Tooling. Sie stärken Kohärenz im Betriebsmodell. Und sie richten Anreize an der Gesundheit des Systems aus.
DevOps Excellence in der Praxis umsetzen
Organisationen, die diesen Weg bewusst gestalten wollen, profitieren häufig von einer strukturierten Standortbestimmung und von klaren, umsetzbaren nächsten Schritten. Wir bei XWare begleiten Unternehmen dabei, ihre DevOps-Praktiken entlang dieser Prinzipien weiterzuentwickeln – pragmatisch, systemisch und mit Fokus auf nachhaltige Ergebnisse. Melden Sie sich gerne direkt über die untenstehenden Kontaktdaten.
