23.07.2024 - Tobias Hundt
⏱ Lesedauer: 4 Minuten
Der Zielkonflikt zwischen Dev und Ops
Entwickler und Betreiber haben, auch wenn sie am selben Produkt arbeiten, völlig unterschiedliche Ziele. Die Hauptaufgabe der Entwickler und ihr Selbstverständnis ist das Erschaffen neuen Kundenwertes, indem sie Features oder Verbesserungen für die Software erstellen und möglichst schnell in Produktion bringen. Operations hat das Ziel, die Stabilität und Verfügbarkeit der Software sicherzustellen. Oder kurz: Die Entwicklung will möglichst häufige Änderungen, Operations will möglichst seltene Änderungen. Diese zwei Ziele scheinen im ersten Moment unvereinbar.
Grafik KI-generiert
Auch kann aus diesem Konflikt eine Abwärtsspirale entstehen, die dort beginnt, wo die Menge an technischen Schulden so sehr steigt, dass Änderungen in Produktion zunehmend mehr Probleme verursachen und den Betrieb einschränken. Zu allem Überfluss passiert das am ehesten dort, wo viele Änderungen passieren und der höchste Druck herrscht: An unseren kritischsten Systemen.
Technische Schulden als Katalysator
In der Folge kommt es zu verhäuft notwendigen Notfalleinsätzen der IT-Operations bis tief in die Nacht, um die Auswirkungen der Fehler gering zu halten. Änderungen rückgänig machen, Backups einspielen, etc. Die Menschen sind gestresst, der Kunde unzufrieden. Wenn jetzt dem Kunden Versprechungen für Entschädigungen in Form von neuen, priorisierten Features gemacht werden, beschleunigt es die Abwärtsfahrt noch weiter. Das Entwicklerteam, welches ohnehin unter erhöhtem Stress steht ist nun unter noch höherem Druck, teils utopische Versprechungen einlösen zu müssen und geht weitere technische Schulden ein, um ansatzweise dem Ziel nahe zu kommen. Die Aufgabenliste wird immer länger. Die Arbeit wird abhängiger, da durch mehr Workarounds und unsaubere Trennungen mehr Konflikte im Code auftauchen können. Auch kleine Änderungen führen vermehrt zu Problemen, was die IT-Operations veranlasst immer weniger Änderungen anzunehmen und Releases zu verhindern, da sie der Entwicklung immer weniger vertrauen, fehlerfreie Änderungen einzureichen. Nötige Refactorings und Softwaretests werden verschoben. Die Entwicklung beginnt, IT-Operations ebenfalls weniger zu vertrauen weil sie die Änderungen nicht mehr schnell genug in Produktion bringen. Auf deren Seite wächst ebenfalls die Menge an technischen Schulden, da die Arbeit an Notfällen immer mehr Zeit in Anspruch nimmt. Die neuen technischen Schulden führen zu noch schlechterer Codequalität und die Spirale beginnt von vorn.
Die Menschen der Entwicklung fühlen sich nicht mehr wirksam, weil sie vermehrt Bugs beheben müssen und Operations zu viel blockiert. Operations geht das alles viel zu schnell und sie wollen sich erstmal stabilisieren. Beide Seiten haben geringeres Vertrauen in die jeweils andere. Das schränkt die Entwicklung weiter ein und erhöht den Druck auf die ganze Organisation.
Diese Sequenz kann mal stark und mal leicht ausgeprägt sein. Sie kann mal schneller und mal langsamer ablaufen. Teils unbemerkt und schleichend. Sie kann sich über Jahre ziehen bis sie wahrgenommen wird. Aber dann kann es schon zu spät sein und das Unternehmen leidet unter Unzufriedenheit, Abgängen und Marktverlusten. Und da immer mehr Unternehmen Software entwickeln kann sie fast überall auftauchen.
Die Lösung aus der Sicht von DevOps
Im Werkzeugkoffer von DevOps gibt es genügend Werkzeuge, um dieser Abwärtsspirale zu entkommen oder sie gar nicht erst entstehen zu lassen. Wichtigster Punkt dabei ist, dass Deployments zur reinen routine werden, auf die sich alle verlassen können. Sie müssen so einfach, so geübt und so vertrauenswürdig sein, dass sie auch unter der Woche zu normalen Arbeitszeiten und unter erhöhtem Entwicklungsdruck stattfinden können. Das klingt so simpel, ist aber ein großer Schritt. Um das zu erreichen, braucht es eine umfassende und früh beginnende Test-Strategie und Deployments auf Vorproduktions-Umgebungen, die auf Knopfdruck frisch entstehen und nicht durch jahrelange Benutzung kaputt-konfiguriert sind. Es braucht Automatismen, die manuelle Arbeit umfangreich ersetzt und damit menschliche Fehler oder Unachtsamkeiten verhindern. Es braucht eine nahtlose Einbindung der IT-Security und der QA in die Softwareentwicklung. Es braucht funktionierende und regelmäßig getestete Roll-Back-Methoden. Es braucht viele und möglichst kurze Feedbackschleifen an die Entwickler und Betreiber. Es braucht eine Deployment-Strategie, die es ermöglicht, im laufenden Prozess Änderungen einzuspielen, ohne, dass die Kunden eine Downtime wahrnehmen. Für diese Ziele muss die Software vorbereitet werden: Kleine Entwicklerteams arbeiten an voneinander unabhängigen Features, beispielsweise in Microservice-Umgebungen. Einzelne Komponenten können unabhängig voneinander deployed werden. Kritische Komponenten können skaliert werden und parallel laufen.
Gegenseitiges Vertrauen ist unerlässlich
In einer solchen Umgebung mit schnellem Feedback und ausführlichen Tests kann wieder das nötige Vertrauen entstehen, mit Änderungen keine negativen Folgen zu erzeugen. Lange Not-Debugging-Nächte und Workarounds gehören der Vergangenheit an. Technische Schulden häufen sich weniger schnell an, da die Codequalität ein ohnehin höheres Niveau erreicht. Entwicklerinnen und Entwickler haben wieder Zeit und Vertrauen, zu experimentieren und damit neuen, möglicherweise unverhofften Wert zu schaffen.
Die nötigen Grundlagen zur Umsetzung schaffen
Das alles sind mitunter große Herausforderungen und nicht innerhalb kurzer Zeit zu meistern. Und nur mit Technologie ist es hierbei nicht getan. Es müssen Prozesse zu dieser Arbeitsweise passen und die Menschen müssen den Wert der neuen Praktiken verinnerlichen, um gemeinsam den Weg in diese neue Welt zu gehen. Dabei beginnt man am besten dort, wo die Menschen den höchsten Grad an Innovationslust haben und gern neue Dinge ausprobieren. Von dort verbreitet sich der Gedanke durch Erfolgsgeschichten schnell ins Unternehmen.
Aber ohne technische Hilfsmittel geht es auch nicht. Hier kann es je nach Organisation sinnvoll sein, mit kleinen Schritten anzufangen, die Menschen dort abzuholen wo sie sind und iterativ auf das Ziel hinzuarbeiten. Beispielsweise bei der Erhebung von relevanten Metriken wie die Fehlerrate für Releases und der durchschnittlichen Zeit von FeatureRequest bis zum Ausrollen in Produktion. Oder bei der konsequenten Umsetzung von automatisierten Teststrategien zum früheren Erkennen von Fehlern. So oder so geht es immer um die Automatisierung von Prozessen, die die Arbeit zwischen Devs und Ops vereinfacht, manuelle Tätigkeiten möglichst vermeidet und dafür sorgt, dass Menschen wieder Vertrauen in ihre Arbeit und in das Produkt gewinnen.
Möchten Sie mehr über dieses Thema erfahren oder mir Feedback geben, schreiben Sie mir gern unter:
Blue Atlas Technologies GmbH
Altewiekring 20a
38102 Braunschweig
Telefon: +49 176 637 645 63
E-Mail: kontakt@blue-atlas.de