Die Betonung des Dev in DevOps

Der Begriff "DevOps" sollte eine Methode sein, um die Kluft zwischen Entwicklern und Betrieb zu überbrücken und selbständige, autonome Teams zu schaffen. Aber in der Praxis wird er meist mit dem Betrieb in Verbindung gebracht. Wenn ein Unternehmen "DevOps" betreibt und "DevOps Engineers" beschäftigt, bedeutet das oft, dass sie Bereitstellungen und CI/CD-Pipelines automatisieren und darüber hinaus die Rolle dessen übernehmen, was wir früher "Systemadministratoren" nannten. Ein zynischer Mensch könnte sogar sagen, dass der Begriff DevOps nur ein weiterer vermarktbarer Begriff geworden ist, um Produkte und Dienstleistungen zu verkaufen, während er die Probleme, die er eigentlich lösen sollte, aus den Augen verliert.

Welche Probleme?

Es dreht sich alles um Rückkopplungsschleifen. Wenn ein Entwickler Software entwickelt, möchte er verschiedene Dinge wissen, zum Beispiel:

• Funktioniert es so, wie es soll? Und tut es nicht, was es nicht tun soll?
• Ist es leistungsfähig?
• Ist es skalierbar?
• Ist es sicher?
• Was passiert, wenn etwas schief geht?

Die rechtzeitige Beantwortung dieser Fragen führt zu einer kontinuierlichen Verbesserung, die wiederum zu einer höheren Qualität der Software und zufriedeneren Endbenutzern führt.

Fällt Ihnen noch etwas an diesen Fragen auf? Die meisten davon können Sie nicht beantworten, wenn Sie keine Kenntnisse über den "Betrieb" haben. Wenn die Personen mit Betriebskenntnissen nicht Teil des Entwicklungsteams sind, führt dies zu einem Engpass oder sogar zu Interessenkonflikten. Fragen, Anfragen und Probleme müssen möglicherweise über den Zaun geworfen werden, damit das "DevOps-Team" sie lösen kann, während der Entwickler, der die Software entwickelt hat, warten muss. Das DevOps-Team könnte bereits mit der Bearbeitung von Problemen anderer Teams überfordert sein, während es selbst nicht genug über die Software weiß, die es betreibt. Gleichzeitig hat ein Entwickler vielleicht nicht einmal ausreichende Rechte in den jeweiligen Umgebungen, um die Probleme zu untersuchen, mit denen er konfrontiert ist.

Die Antwort auf diese Probleme wird oft in der Automatisierung und Abstraktion von vermeintlichen Wissenslücken gesehen. Vorgefertigte CI/CD-Pipelines und Bereitstellungsbausteine, die heutzutage vielleicht sogar von der KI generiert werden, werden als Mittel zur Lösung dieser Engpässe eingesetzt.

Aber ein organisatorisches Problem wird nicht durch eine technische Lösung gelöst. Wenn eine Pipeline versagt, ist dann sofort klar, warum sie versagt? Liegt es an einem Problem in der Software oder an der Infrastruktur oder an der Pipeline selbst? Hat ein Entwickler die Möglichkeit, diese Frage zu beantworten? Wenn auf der anderen Seite ein Problem in der Produktion auftaucht, kann dann derjenige, der das Produkt betreibt, dieselben Fragen beantworten? Und wird es dann nicht zu etwas anderem, das über den Zaun geworfen wird?

Was haben wir also falsch gemacht und wie können wir das Problem lösen?

Teams auszubilden und zu reorganisieren ist schwierig. Im Gegensatz dazu ist es einfach, einer bestehenden Organisationsstruktur ein neues Etikett aufzudrücken. Das haben wir bei den agilen Übergängen gesehen und das sehen wir jetzt bei DevOps. Aber um die oben genannten Engpässe zu beseitigen, die Feedbackschleifen und den Entwicklungslebenszyklus zu verbessern und wirklich eine kontinuierliche Verbesserung zu erreichen, ist eine organisatorische Veränderung erforderlich.

Diese organisatorische Veränderung lässt sich wie folgt zusammenfassen:

1. Trauen Sie den Entwicklern zu, dass sie ihre eigenen Sachen bedienen.

Wie bei vielen organisatorischen Fragen steht auch hier das Vertrauen im Mittelpunkt. Viele Entwickler möchten zwar etwas über den Betrieb lernen oder sind bereits mehr als fähig, ihre Software zu bedienen, haben aber möglicherweise keine ausreichenden Zugriffsrechte, um dies zu tun. Wenn ein Entwickler nicht sehen kann, was in der Produktion vor sich geht und wie die Endbenutzer mit der Software interagieren, behindert dies seine Möglichkeiten, Probleme zu untersuchen und darauf zu reagieren. Und wenn sie nicht über eine Umgebung verfügen, in der sie volle Administratorrechte haben (d.h. eine Sandbox-Umgebung), werden Kreativität und Innovation behindert.

Dieser Mangel an Erlaubnis könnte auf eine zu restriktive Sicherheitsrichtlinie zurückzuführen sein oder darauf, dass die Betriebsabteilung das, was sie als ihre Aufgabe ansieht, "absperrt". In jedem Fall ist dies etwas, das verbessert werden sollte, wenn Sie den Lebenszyklus der Entwicklung verbessern wollen.

2. Setzen Sie Operationen in Entwicklungsteams ein

Ein Punkt, den Sie wahrscheinlich schon einmal gehört haben, der aber in der Praxis nicht oft genug vorkommt: Setzen Sie die Mitarbeiter mit Betriebskenntnissen in Softwareentwicklungsteams ein und nicht in ein separates "DevOps-Team". Außerdem, und das kann ich nicht oft genug betonen: Machen Sie es nicht zu ihrer alleinigen Aufgabe, alles zu betreiben, was das Entwicklungsteam aufgebaut hat! Machen Sie es stattdessen zu ihrer Aufgabe, dem Rest des Teams dabei zu helfen, ihre Software selbst zu bedienen. Das führt direkt zum nächsten Punkt...

3. Förderung des Lernens und des Wissensaustauschs zwischen Entwicklern und Betrieb

Wenn die Entwickler wissen, wie die Software funktioniert, und der Betrieb weiß, wie die Software erstellt wird, führt dies zu einer schnelleren Durchlaufzeit, wenn ein Problem auftaucht oder Verbesserungen vorgenommen werden müssen. Das bedeutet nicht, dass jeder alles wissen muss, und es bedeutet auch nicht, dass Sie bestimmte Rollen abschaffen müssen. Es bedeutet aber, dass ein Umfeld geschaffen werden muss, in dem man lernen und Wissen teilen kann. Das fängt damit an, dass die Leute im selben Team arbeiten, aber das ist noch nicht alles. Fördern Sie Pair Programming, das Schreiben von Testfällen (die eine großartige Form der Dokumentation und Feedbackschleifen sind) und investieren Sie in Schulungen und Tools für die Zusammenarbeit.

Das Wichtigste: haben Sie keine Angst vor dem Scheitern. Die nützlichsten Lernerfahrungen machen Sie, wenn etwas schief geht. Fehler werden passieren, und anstatt mit dem Finger auf sie zu zeigen oder sie gar zu bestrafen, sollten Sie sie als Chance zur Verbesserung begreifen.

Stellen Sie abschließend die Frage: Kann dieses Team eigenständig arbeiten?

Oder noch ausführlicher: Kann dieses Team dieses Softwareprodukt von der Idee bis zur Produktion selbständig entwickeln? Und verfügt es über alles, was es braucht, um aus den Feedback-Schleifen im Entwicklungszyklus zu lernen und das Produkt und sich selbst kontinuierlich zu verbessern? Wenn die Antwort auf diese Fragen "Ja" lautet, dann herzlichen Glückwunsch! Sie praktizieren tatsächlich echtes DevOps. Wenn die Antwort "nein" lautet, sollten Sie sich an den vorhergehenden Punkten orientieren, die Ihnen dabei helfen sollten, in Zukunft ein "ja" daraus zu machen.