DevOps · 16. April 2016 0

DevOps Part II – DevOps in der Praxis

DevOps Area Matrix
Die DevOps Area Matrix (Abbildung 1) nach Patrick Debois, Gene Kim, John Willis und Mike Orzen dient der Veranschaulichung von DevOps und besteht im Kern aus vier verschiedenen Bereichen:

Bereich 1: Extend development to operations
Hier arbeiten Entwicklung und Betrieb bezüglich der Bereitstellung zusammen.

Bereich 2: Extend operations to development
Dieser Bereich konzentriert sich darauf, dass Informationen vom Betrieb an die Entwicklung weitergegeben werden.

Bereich 3: Embed development into operations
In diesem Bereich wird die Entwicklung in Aufgaben einbezogen, die normalerweise der Betrieb erledigt.

Bereich 4: Embed operations into development
Dieser Bereich befasst sich mit der Einbindung des Betriebs in den ganzheitlichen Entwicklungsprozess.

Abbildung 1: DevOps Area Matrix.

(Quelle: Eigene Abbildung nach: http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices)

Um einen Wissensaustausch und schnelles Feedback zu fördern, benötigt jeder Bereich die Interaktion in beide Richtungen, d.h. von der Entwicklung zum Betrieb und umgekehrt. Dabei überschneiden sich die Bereiche in der Praxis. Jedoch hilft es bei der Einführung von DevOps, in Bereiche zu unterscheiden, um so ein besseres Verständnis zu bekommen. Alle vier Bereiche umfassen die grundlegenden Ansichten aus DevOps Part I – Kern von DevOps, wobei die Prozesse sehr dominieren und im Mittelpunkt stehen. Der Ansatz der DevOps Area Matrix begründet die Tatsache, dass sowohl Entwicklung als auch Betrieb ihre eigenen internen Prozesse und Lösungen verwenden. Die Entwicklung wird häufig als Teil eines Projektes organisiert, dessen Ziel es ist, einen definierten Inhalt in einer bestimmten Qualität zu einer bestimmten Frist anhand von festgesetzten Meilensteinen zu liefern. Sowohl die Projekte als auch die Aktivitäten des Betriebs sollten daher aufeinander ausgerichtet sein. Während der Einführung von DevOps müssen nicht alle Bereiche gleichzeitigt abgedeckt werden. Maßnahmen in jedem einzelnen Bereich sind hilfreich, die Zusammenarbeit von Entwicklung und Betrieb zu verbessern. Nachfolgend werden die vier Bereiche detaillierter dargestellt.

Bereich 1: Extend development to operations
Die Erweiterung der Entwicklung hin zum Betrieb umfasst Maßnahmen, welche die Softwareentwicklung als einen ganzheitlichen Ansatz interpretieren, indem relevante Elemente für den Betrieb frühzeitig und häufig als Teil der Entwicklung einbezogen werden. Ziel dieses Ansatzes ist es, die manuelle Bereitstellung von Umgebungen zu verhindern. Stattdessen kann unter der Zuhilfenahme von DevOps und der Verwendung von Tools, welche für die Bereitstellung und Konfiguration (Infrastructure as Code) geeignet sind, die Bereitstellung entsprechend automatisiert werden. Infrastruktur Artefakte gibt es in beiden Abteilungen und gehören somit zu den Ausgangspunkten. Ebenso ist es sinnvoll, diese Tools in ein Versionsverwaltungssystem (SVC) einzubinden. Das fördert nicht nur eine schnellere Rückmeldung durch die Automatisierung und die Wiederverwendung von Codes und Tools, sondern verbessert auch die Zuverlässigkeit des Lieferprozesses. Eine weitere Möglichkeit zur Verbesserung wäre die Integration des Betriebs in den Entwicklungsprozess. Ein Beispiel hierfür wäre die Verwendung von Kanban, um die Arbeit von Entwicklung und Betrieb zu verfolgen.

Praxis: Verwendung von Tools, wie Chef, Salt oder Vagrant, unter der Zuhilfenahme von Versionsverwaltungssystemen für Codes.
Ziel: Schnellere Rückmeldung durch Automation, Wiederverwendung von Codes und Tools sowie Zuverlässigkeit der Lieferkette und Bereitstellung.

Bereich 2: Extend operations to development
Der zweite Bereich umfasst Maßnahmen, um den Betrieb hin zur Entwicklung zu erweitern. Dieser Bereich ist ähnlich, wie Bereich 1, jedoch geht hier die Konvergenz vom Betrieb aus. Grund hierfür ist, dass die Entwicklung oft keinen Einblick in das Verhalten einer Anwendung auf einem Produktivsystem hat, der Betrieb hingegen schon. Die Informationen dazu werden in einem Überwachungssystem gesammelt. Erfolgt jedoch keine Rückmeldung an die Entwicklung, fehlen dieser somit bestimmte Informationen, die bei der Verbesserung der Anwendung förderlich sind. Mit DevOps werden diese Informationen, welche meistens aus Protokolldateien und Metriken bestehen, für beide Abteilungen ersichtlich. Das ist besonders dann Relevant, wenn die Entwicklung Fehler beheben soll, die auf einem Produktivsystem auftreten. In der Regel ist der Entwicklung nicht gestattet, auf Produktivsysteme zuzugreifen.

Praxis: Der Entwicklung Zugriff auf Protokolldateien und Überwachung ermöglichen.
Ziel: Austausch von Informationen über den Zustand von Produktivsystemen. Verbesserungsmöglichkeiten der Anwendung durch die Entwicklung ermöglichen. Der Entwicklung Einblick in Probleme mit Produktivsystemen ermöglichen.

Bereich 3: Embed development into operations
Der dritte Bereich umfasst Maßnahmen, die Entwicklung in den Betrieb mit einzubinden und prägt hierdurch Prozesse in beiden Abteilungen. Dabei soll nicht nur das Team als solches betrachtet werden, sondern auch dessen Aktivitäten und Ziele. Es ist nicht hilfreich, dass sich die Entwicklung nur auf das Ziel, neue Funktionen zu liefern, fokussiert und nicht funktionale Anforderungen vernachlässigt. Daher sollten auch nicht funktionale Anforderungen, wie bspw. Stabilität, Geschwindigkeit oder Kapazität, als eines der Ziele für die Entwicklung gesetzt werden, um die Lücke zwischen beiden Abteilungen zu überwinden.

Praxis: Stabilität, Geschwindigkeit und Kapazität als Entwicklungsziele festlegen.
Ziel: Ziele angleichen, gemeinsame Anreize schaffen.

Bereich 4: Embed operations into development
Der vierte und letzte Bereich umfasst Maßnahmen, den Betrieb in die Entwicklung einzubinden. Beide Abteilungen arbeiten eng zusammen, um den besten Lösungsansatz zu erreichen. Dazu berät der Betrieb die Entwicklung und gibt Rückmeldung über die Lösung. Ziel ist es, der Entwicklung eine schnelle Rückmeldung über die Machbarkeit zu geben sowie recht- und frühzeitig Wissen zu teilen. Dies betrifft vor allem nicht funktionale Anforderungen, da diese nachträglich schwieriger zu implementieren sind bzw. nur mit viel Aufwand.

Praxis: Betrieb gibt früh- und rechtzeitig Rückmeldung über das Design der Anwendung, welche noch entwickelt wird.
Ziel: Rückmeldung über die Machbarkeit sowie Wissen teilen.

Darüber hinaus besteht die DevOps Area Matrix aus noch weiteren Bereichen wie bspw. Human Resources, Management, Marketing oder Vertrieb und kann um weitere Abteilungen ergänzt werden. Je nachdem, welche Bereiche DevOps über die Kernbereiche Entwicklung und Betrieb noch zusätzlichen vereinen soll. Einen Ausblick erfolgt im übernächsten Abschnitt.

Vor- und Nachteile von DevOps
Wie bei den meisten Strategien gibt es auch bei DevOps einige Vor- und Nachteile. In der folgenden Auflistung werden einige von ihnen aufgezeigt.

Vorteile

  • Performance: Mit den Kernbereichen (Zusammenarbeit, Prozesse und Tools) von DevOps lässt sich die Produktivität erhöhen, Zeit beim Rollout eines neuen Releases einsparen, die Anzahl der Releases erhöhen und letztendlich die Kosten reduzieren.
  • Qualität und Stabilität: Durch die Verwendung von Tools und der Automatisierung von Vorgängen werden Fehler vermieden, was wiederum die Qualität verbessert und die Stabilität erhöht.
  • Zentrales Management: Die Implementierung eines zentralen Managements übernimmt bspw. Priorisierung und Kategorisierung von Ad-hoc Aufgaben und Störungen, um so Durchlaufzeiten zu verbessern. Zudem lassen sich Bereitstellungen besser planen, Engpässe früher erkennen und Prozesse sowie Abläufe bspw. durch eine Wertstromanalyse optimieren.
  • Lernkurve durch Erfahrungsaustausch: Indem Entwicklung und Betrieb gegenseitig Erfahrungen austauschen oder gemeinsam an Lösungen arbeiten, steigt das Know-how auf beiden Seiten.

Nachteile

  • Umsetzung: Nicht alle Mitarbeiter sind aufgeschlossen gegenüber Veränderungen. Zudem müssen Strukturen erst geschaffen, Tools entsprechend ausgewählt, erlernt und implementiert sowie das Management überzeugt werden.
  • Burnout: Bei der Umsetzung von DevOps kann es zu Personalengpässen kommen und Mitarbeiter verstärkt unter Zeitdruck stehen. Daneben führt die Erlernung und Implementierung neuer Tools oder die Definition und Einführung neuer Prozesse zu einer zeitlichen sowie physischen Mehrbelastung.
  • Ständige Paradigmenwechsel: Mit der Veränderung der Aufgaben auf beiden Seiten steigt auch der Paradigmenwechsel. Wird gerade noch ein Problem mit der Produktivumgebung gelöst, steht als nächstes die Lösungserarbeitung eines neuen Produktfeatures an.

Ausblick – Wohin die Reise geht
Mit DevOps steht die Kollaboration klar im Vordergrund und ermöglicht so eine bessere Zusammenarbeit zwischen Teams mit unterschiedlichen Aufgabenbereichen. Damit bezieht DevOps nur die IT mit ein, doch gibt es in Unternehmen noch mehr als nur die IT. Daher liegt es nahe, diese Teams insgesamt noch breiter aufzustellen (englisch: Cross Functional) und bspw. Marketing und Vertrieb mit einzubinden. So ist das Team nicht nur fachlich für die Serviceerbringung verantwortlich, sondern übergreifend für einen bestimmten Geschäftsbereich. Diesen Ansatz verfolgt auch Design Thinking. Anhand einer Problemstellung eines Kunden wird ein neues Produkt entworfen, welches durch die Zusammenarbeit der verschiedenen Teams, bestehend aus Softwareentwicklung, Betrieb, Marketing, Vertrieb und weitere, umgesetzt wird. Design Thinking setzt hierbei auf einen Lernprozess, der neben der teamübergreifenden Zusammenarbeit auch auf das Verstehen und Beobachten setzt. So lassen sich Rückmeldungen über das Kundenverhalten bei neu implementierten Funktionen besser auswerten. Eine weitere Ergänzung ist bspw. Lean Startup, welcher sich nicht nur für Start-ups eignet, sondern für jede Art von Unternehmen. Dabei geht es darum, Hypothesen durch iterative Produktneuerungen am Markt zu verifizieren. Durch die Befragung von Kunden über eine zukünftige Funktion lässt sich schon erkennen, wie erfolgsversprechend die Funktion ist. Das spart Zeit, da die neue Funktion nicht erst implementiert werden muss. Genauso lassen sich auch die Möglichkeiten, vorhandene Funktionen zu erweitern, messen. Zentraler Bestandteil von Lean Startup ist somit die Rückmeldung.

Fazit
Die Neuausrichtung von Entwicklung und Betrieb in ihrer Zusammenarbeit verbessert neben dem Bereitstellungsprozess ebenso die Entwicklung und den laufenden Betrieb von IT-Services. Voraussetzung hierfür ist jedoch die Umsetzung der drei Kernbereiche Zusammenarbeit, Prozesse und Automatisierung. Während es ausreichend Prozessmodelle und Tools für die erfolgreiche Umsetzung von DevOps in Unternehmen gibt, stellt die organisatorische Veränderung die größte Hürde dar, ebenso wie regional oder global verteilt arbeitende Teams zusammenzubringen. Ein weiterer Punkt ist die Veränderung in der Führung und Motivation von Mitarbeitern, die auf das Management zukommt. Vor der Einführung von DevOps ist es daher wichtig, einen detaillierten Plan zu erstellen, wie die Veränderungen im Einzelnen aussehen sollen. Dabei gilt es zu vermeiden, nach dem Motto „Learning by Doing“ zu verfahren. Ein Workflow kann bei der Visualisierung der DevOps-Methoden helfen. So weiß jedes Teammitglied, welcher Prozess wie abläuft und wann die eigene Expertise benötigt wird. Unterstützend hierzu bietet die DevOps Area Matrix einen Blick über den Tellerrand, um so einen Überblick über die Arbeit, Prozesse und Herausforderungen des jeweils anderen zu bekommen sowie die Möglichkeiten der Zusammenarbeit zu fördern. Eine weitere Überlegung DevOps auf andere Bereiche im Unternehmen, wie Human Resources, Vertrieb oder Marketing auszudehnen, welche zusammen für einen Geschäftsbereich verantwortlich sind, könnte sich als durchaus sinnvoll erachten. Hierbei ist es nicht erforderlich, ein neues Team mit neuen Mitarbeitern zu etablieren, sondern vielmehr bestehende Teams zusammenzuführen. Dabei wird DevOps die klassischen Teamstrukturen teilweise aufbrechen.
Dennoch ist DevOps kein Allheilmittel und gibt bspw. noch keine Antwort auf die Frage, wie es sich mit einem IT-Service-Management kombinieren lässt. Es ist vielmehr eine Bottom-Up-Entwicklung. Zudem ist es Unternehmensindividuell und u.a. abhängig, worauf der Fokus liegt. Stehen eher neue Funktionen und häufige Releases im Vordergrund oder ist es wichtig, einen sicheren und stabilen IT-Service zu gewährleisten.

Hilfreich
DevOps Tools
DevOps Links