Was Sie über DevOps wissen müssen

Wenn Sie den Begriff „DevOps“ als Berufsbezeichnung verwendet haben, haben Sie möglicherweise einen großen Fehler gemacht. Es klingt harmlos: Ist DevOps nicht etwas, was Sie tun? Wenn Sie in Ihrem Unternehmen Marketingfachkraft, Personalmanager oder Nicht-Ingenieur sind, könnte es so aussehen.

Aber nichts könnte ferner von der Wahrheit sein. Es handelt sich tatsächlich um eine Philosophie und eine Reihe von Praktiken, die die Arbeitsweise Ihrer Engineering- und IT-Teams bestimmen. Und die falsche Verwendung des Begriffs kommt bei technischen Teams nicht immer gut an, selbst wenn in ihrem LinkedIn-Profil „DevOps Engineer“ steht.

Die falsche Verwendung des Begriffs kann viele Probleme verursachen. Sie kann in Ihrem Unternehmen zusätzliche Silos schaffen oder sich negativ auf die Zusammenarbeit und Erledigung von Aufgaben in Teams auswirken – und so die Effektivität und Verantwortlichkeit der DevOps-Arbeit einschränken.

Um Fehlinterpretationen darüber, was DevOps ist und was es bedeutet, vorzubeugen, ist es hilfreich zu wissen, warum es wichtig ist und woher die Idee stammt.

Warum DevOps kein Berufstitel ist

DevOps ist eine Arbeitsweise, die Zusammenarbeit, offene Kommunikation und den reibungslosen Austausch von Ideen und Code betont. Für viele Organisationen, die zu einem DevOps-Modell wechseln, stellt dies einen Kulturwandel dar, und die damit verbundene Kommunikation ist wichtig.

Gute DevOps-Arbeit erfordert Tests, Iterationen und sogar das Zerstören von Dingen. Das muss schnell, reibungslos und – ganz wichtig – ohne Schuldzuweisungen geschehen. Jemanden als DevOps-Leiter oder -Team zu definieren, könnte bedeuten, dass nur diese Personen für DevOps verantwortlich sind und dass es bei einem Scheitern individuelle und keine systemischen Fehler sind.

Wie Chip Locke schreibt, sind Softwareentwickler und Betriebsingenieure möglicherweise unterschiedliche Menschentypen, und der Versuch, sie in einer einzigen Rolle zu vereinen, ist möglicherweise nicht effektiv. Wenn Entwickler und Betriebsingenieure in eine einzige Rolle oder ein einziges Team gedrängt werden, anstatt ermutigt zu werden, teamübergreifend zusammenzuarbeiten, sind konkurrierende Werte und (manchmal) suboptimale Ergebnisse die Folge. Darüber hinaus ist die Implementierung von DevOps als drittes Team, das zwischen den Entwicklungs- und Betriebsteams sitzt, ein Rezept für eine Katastrophe. Der Versuch, das Problem durch die Kombination dieser Silos zu beheben, macht die Dinge nur noch schlimmer.

Also, was ist DevOps?

Es gibt keine Standarddefinition von DevOps. Laut The Agile Admin ist DevOps eine „Methodik der Zusammenarbeit“. Anders ausgedrückt ist es laut der Website „agile Systemadministration“. Das bedeutet, dass es bei DevOps darum geht, dass Softwareentwickler und Betriebsingenieure mit gemeinsamen Werten, Prinzipien, Methoden, Praktiken und Tools zusammenarbeiten, um Systeme zu erstellen, zu warten und zu verbessern – über den gesamten Lebenszyklus der Dienste hinweg.

Diese Definition passt nicht auf eine Visitenkarte. Aber eine richtige Definition ist für Ihr Unternehmen wichtig. Denn bei DevOps geht es nicht darum, dass Softwareentwickler die Arbeit von Ops übernehmen oder Ops die Arbeit von Entwicklern. Und es geht nicht nur um gemeinsam genutzte Tools (obwohl das ein Teil davon ist). Es geht darum, Veränderungen in ganzen Systemen und Kulturen umzusetzen, um die Art und Weise zu verbessern, wie Kunden Produkte und Dienstleistungen erhalten, Barrieren abzubauen und die Zusammenarbeit und Kommunikation zwischen zwei Teams zu fördern, die manchmal nicht miteinander auskommen.

Woher kommt DevOps?

Wie wurde DevOps für viele Softwareunternehmen zur bevorzugten Option? Daten zeigen, dass DevOps Unternehmen dabei hilft, bessere Softwareprodukte zu liefern und sich schneller an schnelllebige Marktrealitäten anzupassen, indem es schnellere Codebereitstellungen unterstützt.

Der Aufstieg von DevOps in Agile Admin wurzelt in den Bewegungen Agile Systems Admin und Enterprise Systems Management. Beide entstanden aus der Notwendigkeit, Geschäftsprozesse durch die Nutzung schnellerer, kleinerer und Open-Source-Unternehmensframeworks „großer Anbieter“ zu verbessern. Gleichzeitig wurde Agile Systems Admin in Europa immer üblicher, da Unternehmen die Erkenntnisse aus Lean und Agile Manufacturing auf die IT-Abteilungen auf dem gesamten Kontinent übertrugen.

Doch trotz dieser Fortschritte gab es in den Unternehmen noch immer gravierende Silos und eine gefährliche Unflexibilität.

Bessere Tools – kombiniert mit dem Scheitern großer oder schwerer Implementierungen – führten zu dem, was The Agile Admin als „den perfekten Sturm“ bezeichnet. Wir hatten die Mittel, Dinge besser zu machen. DevOps war geboren.

Der Begriff wurde erstmals 2009 von Patrick Debois und Andrew „Clay“ Shafer geprägt. Die Philosophie kam in Schwung, als Debois die ersten DevOps Days im belgischen Gent veranstaltete. Der Rest ist, wie man so schön sagt, Geschichte.

Und wenn Sie diese Geschichte verstehen, ist es einfacher zu verstehen, warum Ingenieure sich über die Idee von DevOps als Berufsbezeichnung oder Unternehmensrolle ärgern. Wenn Sie DevOps richtig ansprechen und darüber nachdenken, machen Sie nicht nur die technischen Talente in Ihrem Unternehmen glücklicher. Sie tragen auch dazu bei, die DevOps-Prinzipien in Ihrer Organisation zu verinnerlichen.