DevOps Teil 3: Der traditionelle Konflikt zwischen Entwicklung und Betrieb

Bewerten Sie diesen Beitrag!

Etwas vereinfacht besteht die Aufgabe von Softwareentwicklern darin, die vom Auftraggeber gewünschten Funktionen möglichst schnell umzusetzen. Wird eine neue Funktion verfügbar, ergibt sich ein potenzieller Mehrwert für die Endnutzer. Oft wird dieser Mehrwert schon bei der ersten Abnahme durch den Auftraggeber anerkannt. Je häufiger neue Features komplettiert werden, desto positiver werden die Entwickler wahrgenommen. Es ist für die Entwickler dabei weitestgehend irrelevant, ob die neuen Features tatsächlich auf dem Produktionssystem verfügbar sind.

Ebenfalls vereinfacht gesagt, besteht die Aufgabe des IT-Betriebs darin, die von der Entwicklung gelieferte Software auf der Produktivumgebung für die Endnutzer verfügbar zu machen. Dazu zählen das Deployment neuer Softwarereleases und die Sicherstellung des laufenden Betriebs unter bestimmten Qualitätsanforderungen. Der Betrieb trägt also die unmittelbare Verantwortung für die Verfügbarkeit der Anwendung, und sein Erfolg wird daran gemessen, inwieweit die gegebenen Qualitätsanforderungen erreicht werden. Die Erwartungshaltung der Nutzer ist in der Regel die volle Verfügbarkeit und Sicherheit der Anwendung. Ist nun zum Beispiel die Verfügbarkeit einmal beeinträchtigt, fällt das direkt auf den Betrieb zurück. Die Folge ist eine stark negative Wahrnehmung durch die Auftraggeber, besonders wenn die Nutzer der Anwendung ein Problem melden, noch bevor die verwendeten Monitoring-Systeme Alarm schlagen. Um die Wahrscheinlichkeit für unerwartete Ausfälle zu minimieren, setzt der Betrieb deshalb oft alles daran, den Zustand einer stabil laufenden Anwendung vor Änderungen zu schützen.

Dieser Vergleich der Aufgaben von Entwicklung und Betrieb zeigt, dass beide Abteilungen entgegengesetzte Anreize haben. Die Entwicklung ist an schnellen und häufigen Releases interessiert, der Betrieb hingegen würde Releases am liebsten vermeiden. Beide Seiten verfolgen damit das gleiche Ziel, nämlich ihren eigenen Wert für das Unternehmen zu beweisen. Genau das führt aber regelmäßig zu Konflikten, Anfeindungen und schlechter Laune.

Dies ist ein Teil des Artikels „Die DevOps-Bewegung – Was ist das eigentlich und was bedeutet es für uns?“ von Dr. Patrick Peschlow.

Die Einleitung zum Artikel finden Sie hier. Das vorige Kapitel erreichen Sie hier, und hier geht es weiter zum nächsten Kapitel.

Stichworte:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close