DevOps, das was und warum

Jeder Ingenieur ist von Natur aus bestrebt, eine Lösung für seine spezifischen Aufgabenstellungen zu finden – und das effizient und zielgerichtet. Dieses Bestreben kann dazu führen, dass Scheuklappen aufgesetzt werden. Abhängigkeiten zu anderen Teams werden übersehen, neuere und vielleicht bessere geeignete Tools werden nicht verwendet und zu guter Letzt wird der experimentelle Einsatz von Technologie und Prozessen abgelehnt – der Effizienz willen. Um jedoch schnell und effizient ein hochwertiges – und vor allem kommerziell erfolgreiches - Produkt zu entwickeln, müssen die aus oben genannten Reservierungen resultierenden Probleme und die zugrunde liegenden Vorurteile erkannt und dann überwunden werden. Dies kann weder durch jedwede Technologie noch durch Prozesse und „Team-Efforts“ allein passieren – alle drei Bereiche müssen gleichermaßen adressiert werden. DevOps ist jetzt ein Ansatz, bei dem Entwicklungs, Test- und Operationsingenieure während des gesamten Lebenszyklus eines Softwareprodukts zusammenarbeiten, vom Design über die Entwicklung bis hin zur Produktunterstützung. Auf diese Weise wird erreicht, dass alle für ein Produkt zuständigen, technischen Teams zusammenarbeiten – beginnend bei Spezifikation, über Technologieauswahl bis hin zu Tests und Betrieb – Silodenken (und damit Scheuklappen) wird somit aktiv adressiert und beseitigt. Als zweiten wichtigen Eckpfeiler stellt DevOps dabei moderne und sich stetig weiterentwickelnde Tools in den Mittelpunkt. Technische Probleme werden mittels herausragenden technischen Hilfsmitteln gelöst und wiederkehrende Aufgaben werden soweit wie möglich automatisiert.

Was ist DevOps?

DevOps ist eine Kombination aus Denkweisen, Praktiken und Tools, mit denen Unternehmen Anwendungen und Services für Endkunden schneller und einfacher bereitstellen können. Die weitere Produktentwicklung und -verbesserung kann in kürzerer Zeit erreicht werden als in Unternehmen, die auf herkömmliche Softwareentwicklungs- und Infrastrukturmanagementprozesse angewiesen sind. Mit diesem Geschwindigkeitsvorteil können Unternehmen ihre Kunden besser bedienen und sich effektiver vermarkten.

Fig.: Schematische Darstellung der DevOps Idee

Wie DevOps die Teamzusammenarbeit in den Mittelpunkt stellt

DevOps beeinflusst den Lebenszyklus eines Softwareprodukts in allen Phasen seiner Planung, Entwicklung, Lieferung und seines Betriebs. Jede Phase ist von anderen abhängig und alle Phasen sind unabhängig von Rollen. In einer echten DevOps-Kultur ist jede Rolle in jeder Phase beteiligt:

• Planen: Während der Planungsphase entwerfen, definieren und beschreiben die DevOps-Teams die Funktionen und Fähigkeiten der von ihnen erstellten Anwendungen und Systeme. Sie verfolgen den Fortschritt bei niedrigen und hohen Detaillierungsgraden, von Einzelproduktaufgaben bis hin zu Mehrproduktportfolios. Die Backlog-Erstellung, das Verfolgen von Fehlern, das Verwalten der agilen Softwareentwicklung mit beispielsweise Scrum, das Verwenden von Kanban-Boards und das Visualisieren des Fortschritts mit Dashboards sind einige der Methoden, mit denen DevOps-Teams agil und visuell planen. Dabei jederzweit wichtig: Alle technischen Domänen – von Entwicklung bis Operations – sind direkt an Board.
• Entwickeln: Die Entwicklungsphase umfasst alle Aspekte: Codierung, Codetests, Überprüfung des Codes und Code-Integration durch Teammitglieder sowie das Einbauen dieses Codes in Build-Artefakte, die in verschiedenen Umgebungen bereitgestellt werden können. DevOps-Teams sind bestrebt, schnell Innovationen zu entwickeln, ohne dabei an Qualität, Stabilität und Leistung zu verlieren. Zu diesem Zweck verwenden sie leistungsstarke Tools, automatisieren Routine- und manuelle Schritte und iterieren in kleinen Schritten durch automatisierte Tests und kontinuierliche Integration. CI/CD ist somit Integraler Bestandteil einer DevOps-Umgebung.
• Deployment: Bei der Auslieferung werden Anwendungen konsistent und zuverlässig in Produktionsumgebungen bereitgestellt. Die Lieferungsphase umfasst auch die Bereitstellung und Konfiguration der vollständig verwalteten zugrunde liegenden Infrastruktur, aus der diese Umgebungen bestehen. Während der Lieferphase definieren die Teams einen Release-Management-Prozess mit klaren Genehmigungsschritten. Sie installieren automatische Gateways, die Anwendungen zwischen Phasen verschieben, bis sie den Kunden zur Verfügung stehen. Es ist hier nochmal herauszustellen, dass die Deployment-Phase in einem idealen DevOps-Team keine manuellen Schritte benötigt. Jegliche Handlung sollte automatisiert sein – automatisierte Tests stellen notwendige Qualitäts-Gateways dar, das Deployment sowie Konfigurationsmanagement ist automatisiert und Quellcode-Verwaltet, Monitoring und selbst Rollbacks sind ebenfalls automatisch zu erledigen. Durch diese konsequente Automatisierung dieser Prozesse sind sie skalierbar, wiederholbar und verwaltbar. Daher ist es nicht verwunderlich, dass DevOps-Teams ihre Artefakte deutlich häufiger, mit besserer Qualität und weniger Production-Incidents ausrollen als ihre klassischen Pendants.
• Betreiben: Die Betriebsphase umfasst die Wartung, Überwachung/Monitoring und Fehlerbehebung von Anwendungen in einer Produktionsumgebung. Durch DevOps arbeitet das gesamte Team daran, die Systemzuverlässigkeit und Hochverfügbarkeit sicherzustellen, Ausfallzeiten zu vermeiden und gleichzeitig Sicherheit und Steuerung zu stärken. Die Last liegt somit nicht auf einem zentralen Operations-Team – das häufig nur wenig direkten Einblick in den betriebenen Code hat. Experten aus allen Domänen von Entwicklung über Operations bis Testing sind am Betrieb der Lösungen beteiligt. DevOps-Teams bemühen sich, Probleme zu identifizieren, bevor sie sich auf das Kundenerlebnis auswirken, und sie schnell zu lösen, wenn sie auftreten. Die Aufrechterhaltung dieser Wachsamkeit erfordert umfangreiche Telemetrie, umsetzbare Warnungen und vollständige Sichtbarkeit und Transparenz für Anwendungen und das zugrunde liegende System
• Feedback: Getreu dem Motto „Nach dem Spiel ist vor dem Spiel“ führt die tiefgreifende Zusammenarbeit aller involvierter Disziplinen zu detailierten Feedbackschleifen in alle Bereiche. Entwicklungsingeneure bekommen direktes Feedback darüber, wie ihr Code zu betreiben ist, Operations-Experten bekommen Feedback darüber, wie der Betrieb der Plattform weiter automatisiert werden können, die Produkt-Owner wiederum liefern direktes Kundenfeedback an alle Mitglieder des DevOps-Teams darüber, wie neue Features aufgenommen werden, wie das aktuelle Performanceempfinden der User ist, in welchem Maße Kunden vom letzten Production-Incident betroffen waren.

Agile und DevOps: Wie sie zusammenarbeiten

Häufig wird die Meinung vertreten, DevOps löst agile Software-Entwicklungsmethoden wie Scrum ab, oder ist deren „Nachfolger“. Nichts könnte jedoch weiter von der Wahrheit entfernt sein. DevOps ist ein Prozess- und Werkzeuge-Template das den gesamten Software-Lebenszyklus aus technischer Sicht abdeckt. Scrum hingegen ist ein Entwicklungsframework zur hochqualitativen Entwicklung von Software – und DevOps-Teams sind gefordert hochqualitative Software zu entwickeln.

Das og. „Missverständis“ lässt sich aus einer falschen Interpretation von Scrum ableiten. Scrum definiert ein oder mehrwöchige Zeitperioden als Sprint – ein Sprint hat dabei ein definiertes Ziel, das dem Team Fokus geben soll. Häufig erlebe ich, dass Teams zu Beginn ihres Sprints eine umfangreiche Planungs-Session durchführen, in der die Arbeitspakete für den nächsten Sprint (und somit beispielsweise die nächsten 3 Wochen) geplant werden. Der Scrum-Master verlangt dann von den Teams ein „committment“ zu diesen Arbeitspaketen und das Team arbeitet konsequent an diesen Paketen und schützt sich während des Sprints gegen zusätzliche Arbeit von außen. Was geschieht nun, wenn ein Production-Incident auftritt? Laut der vorhin genannten Interpretation von Scrum wäre keine Zeit dafür vorgesehen – und da liegt der Hund begraben. Diese häufig zu findende Umsetzung von Scrum entspricht in keinster Weise der ursprünglichen Idee. Ein Sprint soll ein Sprint-Goal haben, das mit maximaler Priorität bearbeitet wird – darauf sollte sich das Team dann committen. Nicht jedoch auf jedes einzelne geplante Arbeitspaket. Auch der häufig streng gelebte Satz, der Sprint-Backlog dürfe sich im Laufe des Sprintes nicht ändern, ist ein kompletter Widerspruch zu den Scrum-Prinzipien. Solange das eigentliche Sprint-Ziel erreicht wird, dürfen Arbeitspakete aus dem Sprint-Backlog entfernt und andere hinzugefügt werden – wobei nur das Team dazu berechtigt ist. Mit diesen beiden Richtigstellungen lässt sich einfach erkennen, dass die Kombination aus Scrum und DevOps kein Widerspruch sondern ein ziemlich guter Match ist. Das DevOps-Team bestehend aus diversen Disziplinen kann ohne Weiteres die Vorteile von Scrum – unter anderem Fokus, Transparenz, Offenheit, Experimentierfreude – nutzen, um die eigene Arbeit zu planen und zu koordinieren.

Fig.: Typisches Scrum Bild :-)

Die Vorteile von DevOps

Ums gleich vorweg zu nehmen, DevOps wird nicht alle Probleme moderner IT/Software-Entwicklung lösen – kommt jedoch näher an den ideal Prozess bzw. das ideale Prinzip als alles was ich bis dato sehen durfte:

• DevOps ermöglicht es, Entwicklung, Softwaretest und Betrieb in einem einzigen Prozess zu verknüpfen, was letztendlich dazu führt, dass die Software ohne Reibungsverluste häufiger aktualisiert wird. Daher der erste und wichtigste Pluspunkt - DevOps erhöht die Effizienz und Wettbewerbsfähigkeit des Unternehmens. Denn je schneller die Anwendung den Endbenutzer erreicht, desto schneller beginnt das Unternehmen, Gewinne und auch neue Kunden zu erzielen.
• Durch die Automatisierung des Entwicklungs-, Test- und Betriebszyklus können Sie das Treffen und Implementieren von Entscheidungen im Zusammenhang mit der Softwareentwicklung beschleunigen.
• Mithilfe der DevOps-Tools können Sie schnell auf Marktsituationen reagieren und erforderliche Änderungen am Produkt vornehmen. DevOps ist somit in der Tat eine Erweiterung zur klassisch agilen Entwicklungsmethoden, die sich häufig eher auf die Entwicklung und Verteilung der Software konzentriert hatten. DevOps weitet dies nun auch auf den Betrieb und somit den gesamten Lebenszyklus aus.
• Darüber hinaus tragen Automatisierung und Standardisierung dazu bei, dass Mitarbeiter in deutlich geringerem Maße Routinearbeiten ausführen. Menschliche Fehler werden minimiert und die Teams können sich auf die Weiterentwicklung der Produkte und auch der Betriebsinfrastruktur konzentrieren. Gerade letzterer Punkt ist in klassischen Prozessen schwierig und kostenintensiv, aufgrund vieler manueller, hochriskanter Schritte die beim Eingriff in die Infrastruktur notwendig waren.
• DevOps-Techniken und -Tools helfen dabei, das System stabil zu halten, einen klaren und transparenten Überblick über den aktuellen Betriebszustand zu erhalten und im Fehlerfall die Wiederherstellungszeit zu verkürzen.

Wie setzen Sie DevOps in Ihren Unternehmen um?

Die schlechte Nachricht vorweg, es gibt keinen goldenen Weg zur Umsetzung von DevOps in einem Unternehmen. Die gute Nachricht: Ähnlich verhält es sich seit den 2000er-Jahren mit der Umstellung klassischer Software-Entwicklung hin zu agilen Methoden. Es ist somit viel Erfahrung im Umgang mit diesen doch gravierenden Änderungen in IT-Teams vorhanden.

Meine Methode der DevOps-Einführung lässt sich wie folgt gliedern:

• Bestandsaufnahme: Identifizieren Sie, welche Teams aktuell unter Zuhilfenahme welcher Prozesse und Mittel an der Entwicklung Ihrer Software- und IT-Landschaft beteiligt sind. Identifizieren Sie ebenfalls, wie viel manuelle Schritte rein in die Verteilung und den Betrieb Ihrer Produkte involviert sind.
• DevOps-Prinzipien betrachten und Ziele definieren: Machen Sie sich mit den theoretischen Hintergründen von DevOps vertraut. Sie sollten zumindest grob über die Prinzipien, Vorteile und Inhalte vertraut sein. Davon ausgehend können Sie für Ihr Unternehmen Ziele definieren, die nach der Implementierung von DevOps erreicht werden sollen. Beispiele dafür können sein, dass die Ausfallszeit Ihrer IT-Systeme auf wenige Stunden pro Jahr reduziert wird oder auch dass die Mitarbeiterzufriedenheit um x% steigt.
• Wirtschaftlichkeit betrachten: Bereits an dritte Stelle setze ich die Betrachtung der Wirtschaftlichkeit. Es dürfte Sie nicht überraschen, dass selbstverständlich jede Prozess-Einführung oder Umstellung auch an verbesserte Wirtschaftlichkeit geknüpft sein sollte. Es gilt jedoch zu beachten, dass dieser Schritt durchaus sehr umfangreich sein kann. So beinhaltet das schlichte Wort „Wirtschaftlichkeit“ eine Vielzahl an Faktoren:
  • Qualtität der gelieferten Produkte
  • Häufigkeit von Updates
  • Kosten des Produkt-Betriebes
  • Kosten von Änderungen und Updates
  • Team-Effizienz
  • Team-Motivation und Mitarbeiterzufriedenheit
  • Viele mehr, je nachdem in welcher Situation Ihr Unternehmen sich vorfinden Allgemein lässt sich sagen, dass kein modernes Unternehmen mit umfangreichen IT-Produkten oder selbst umfangreicher interner IT eine negative Wirtschaftlichkeitsänderung nach Einführung von DevOps zu erwarten hat. Zu groß sind die Vorteile für alle involvierten Breiche, zu langsam und unwirtschaftlich sind herkömmliche Methoden. Ich erwarte somit früher oder später eine sehr große Verbreitung des DevOps-Prinzips – die Priorisierung wann die Umstellung in den Unternehmen stattfindet, hängt natürlich im Wesentlichen von der Unternehmenssituation ab
• Teams involvieren: Aus Erfahrung kann ich berichten, dass DevOps für IT-Teams spannend und aufregend ist. Der Fokus auf moderne Tools und Prozesse erlaubt den Teams, sich zu entfalten und möglicherweise unlieb gewonnene Tätigkeiten und Situationen hinter sich zu lassen. Daher bietet es sich an, alle von einer möglichen DevOps-Umsetzung betroffenen Teams frühzeitig einzubinden, zur Prozessdefinition aufzufordern und – wichtig – Feedback einzuholen. Die natürliche Motivation Ihrer Teams kann dem Projekt Rückenwind geben!
• Kontinuierliche Umsetzung und Verbesserung: Nachdem die Ziele klar, die Wirtschaftlichikeit gegeben und Teams involviert sind, kann DevOps implementiert werden. Das gute an DevOps: Sie müssen nicht von heute auf morgen alle bestehenden Wände niederreißen. Es empfiehlt sich, regulären Entwicklungsprojekten nach und nach ein paar DevOps-Aspekte hinzuzufügen. Das hält die Kosten einer Umstellung in Grenzen, reduziert den Zeit- und Kostendruck auf Seiten der operativen Entwicklung und führt auch zu einem deutlich geringeren Kulturschock, potentiell hervorgerufen durch neue Prozesse und Tools. Im Gegensatz zu anderen Unternehmensprozessen und Prinzipien bietet DevOps eben genau die Flexibilität bzw. propagiert diese sogar: Kontinuierliches Umsetzen und Verbessern!

Schlussbemerkung

DevOps ist ein modernes Prinzip, eine Vereinigung von Prozessen, Tools und Denkweisen zur effizienten und wirtschaftlichen Umsetzung von IT und Softwareprodukten, das den gesamten Lebenszyklen eben dieses Produktes abdeckt. Die DevOps-Methoden sorgen darüber hinaus für einen natürlichen Zuwachs an Teamzufriedenheit und Motivation. Früher oder später wird jedes erfolgreiche Unternehmen das sich mit IT-Produkten befassen muss (und welches Unternehmen muss das nicht?) DevOps (oder Prinzipien die daran angelehnt sind) umsetzen. Die gute Nachricht: Die Umstellung hin zu DevOps erfordert keinen radikalen Schwenk, kontinuierliche Implementierung und Verbesserung sind möglich und sogar propagiert.