DevOps-Discovery

DevOps nachhaltig einführen: Fragen und Antworten aus der Praxis

Brian Dawson

(c) Shutterstock / anathomy

Als IT-Consultant mit Schwerpunkt DevOps berät man verschiedenste Unternehmen und deren Teams bei der Optimierung von Software-Development und -Delivery in Bezug auf Prozessfragen, Werkzeuge und Technologien. Bei der Evaluierung des gegenwärtigen Stands der jeweiligen Software Delivery-Pipeline werden klare Ziele formuliert und man begleitet die Einführung von DevOps-Praktiken. Diese Arbeit beginnt immer mit einer grundlegenden Voruntersuchung oder Bestandsaufnahme (Discovery). Im Verlauf des Prozesses kehren dann häufig dieselben Fragen bzw. daraus resultierende Erkenntnisse wieder.

Der Ansatz bleibt dabei grundsätzlich gleich, unabhängig davon, ob es sich um die Analyse und Optimierung von Grafik-Pipelines bei Spiele-Entwicklern, um die Open Source-inspirierte Kollaboration zwischen unabhängigen Teams, oder um spezialisierte Continuous-Integration (CI) / Continuous-Delivery (CD)-Pipelines mittels Jenkins, Git, und ALM Tools für große Finanzunternehmen handelt. Es geht darum, mit Entwickler-, Qualitätssicherungs- oder IT-Betrieb-Teams eine Verbesserung der Software-Development- und -Delivery-Prozesse herbeizuführen, um gemeinsame agile Release-Methoden zu definieren und DevOps-Praktiken implementieren zu können.

Bei vielen Unternehmen lassen sich bei der Discovery spezifische „Anti“-Pattern im Betrieb feststellen, die eine Optimierung der Software-Delivery Pipeline und damit eine nachhaltige DevOps-Transformation bisher verhindert haben. Die gezeigten Beispiele dienen dabei als Anleitung, wie weitere Erkenntnisse für DevOps-Konzepte im Rahmen eines vollen Discovery-Prozesses gewonnen werden können.

Die ersten Schritte

Oft tauchen diese Muster oder Widerstände in den Unternehmen bereits am Beginn einer DevOps-Transformation auf, weil voreilig gehandelt wird. Häufig sind Prozesse wie CI oder CD bereits im Betrieb, agile Methoden wie Scrum sowie Service- und Management-Systeme wie ITIL oder Six Sigma schon im Einsatz. Aus Sicht des Unternehmens bedarf es daher keines Discovery-Prozesses oder einer Evaluierung ihrer Unternehmensprozesse und Kultur – sie möchten nur so schnell wie möglich wissen, welche Tools sie künftig einsetzen sollen.

Dennoch ist es wichtig, bei einer generellen Analyse, die als ersten essentiellen Schritt die Definition von Begriffen wie Agile, CI, CD und auch DevOps voraussetzt, bei „Null“ anzufangen. Wenngleich weit verbreitet, gibt es im IT-Sektor verschiedene Auslegungen dieser Methoden, und so können Missverständnisse bei der Einführung in einer schlechten Implementierung enden. Daher sollte mit grundlegenden Fragen über den Ist-Zustand und das zu erreichende Ziel begonnen werden, nach Möglichkeit aus der Sicht verschiedener Stakeholder wie dem Geschäftsbereich, Entwicklung, QA oder Change Management.

Diese ersten Schritte können langwierig und mühsam sein, aber sie liefern die nötigen Einblicke in die Unterschiede der jeweiligen Perspektive, mit deren Hilfe sich eine Übereinstimmung unter den Stakeholdern erzielen lässt. Aus den gemeinsamen Zielen und Prioritäten kann dann eine Roadmap für den Weg zur Einführung von DevOps geschaffen werden.

Die Zielsetzungen können vielfältig ausfallen und reichen von der Steigerung der Wettbewerbsfähigkeit durch höhere Release-Stabilität, Team-Produktivität und damit steigende Mitarbeiterzufriedenheit, bis zur Einführung von Testautomatisierungs- und CI-/CD-Praktiken für bestehende und neue Produkte. Ebenso kann die Zusammenführung von Development-, QA- und Operations-Teams in ein Team oder die Messung von Key-Performance-Indikatoren (KPI) wie Time-To-Deploy, Severity 1-Issues und Cycle-Time das erklärte Hauptziel sein.

Warum Definitionen so wichtig sind

Wenn man Begriffe wie Agile, CD oder DevOps unterschiedlich definiert, werden sie mitunter auch von den einzelnen Stakeholdern auch verschieden interpretiert. Dies kann zu Missverständnissen über den gegenwärtigen Stand der Implementierung solcher Praktiken führen und darüber, wie hoch der Arbeitsaufwand für das Erreichen gesetzter Ziele ausfallen wird. Ohne gemeinsame Basis und Übereinstimmung zwischen allen Parteien wird es damit unmöglich, eine gemeinsame Roadmap für die DevOps-Einführung zu schaffen.

Zur Veranschaulichung zwei Definitionen von Continuous Delivery:

  • Definition 1: Ein Software-Engineering-Ansatz, bei dem Teams die Software in kurzen Zyklen entwickeln, um sicherzustellen, dass die Software zuverlässig jederzeit als Release verfügbar gemacht werden kann. Ziel ist es, das Erstellen, Testen und das Release von Software schneller und häufiger zu ermöglichen. Der Ansatz reduziert Kosten, Zeit und das Risiko bei einem geänderten Release durch inkrementelle Updates für Anwendungen im Produktions-Prozess. Ein einfacher und reproduzierbarer Deployment-Prozess ist wichtig für Continuous Delivery. (Wikipedia)

Auf den ersten Blick unterscheiden sich beide Definitionen kaum. Allerdings besteht bei dieser Auslegung die Gefahr einer Verwechslung von Continuous Delivery und Continuous Deployment, also dass jede Änderung im Software-Build automatisch verteilt wird. Ein solches Missverständnis kann bei einer DevOps-Einführung bei verschiedenen Stakeholdern zu Widerstand führen, sei es weil die Geschäftsebene Continuous Deployment als zu aufwändig erachtet, der IT-Betrieb den Support für Delivery, Sicherheit und Workloads nicht leisten kann, oder die Compliance für die neuen Versionen dies im Rahmen eines regulären Review-Prozesses zeitlich undurchführbar macht.

Gleiche Definitionen am Beginn einer DevOps-Einführung sind daher extrem wichtig, will man potenzielle Hindernisse und organisatorische Widerstände vermeiden. Auch im Hinblick auf die Bedürfnisse des Unternehmens ist ein pragmatischer Ansatz, der entsprechend zugeschnitten wird, von großem Wert: Ein Unternehmen wie Netflix kann Continuous Deployment sinnvoll im Betrieb einsetzen, ein systemrelevanter Finanzdienstleister wird hingegen eher selten darauf zurückgreifen.

Die Problematik der Begrifflichkeit findet sich auch bei DevOps wieder. Erneut lesen sich die Definitionen auf Webopedia und Wikipedia sehr ähnlich, und erst die genaue Betrachtung zeigt den Unterschied: Der Schwerpunkt in der ersten Definition liegt auf den Beziehungen der Abteilungen (also Unternehmenskultur und Kollaboration) zueinander, während die zweite die „Automatisierung des Software-Delivery-Prozesses und Infrastrukturwandels“ mit einschließt.

Dieser Unterschied ist erfahrungsgemäß wichtig. Konzentrieren sich Unternehmen allein auf die Abteilungsstrukturen, besteht die Gefahr absolut unrealistischer Vorgaben bei Timeline, Budget und Ergebnisse. Dies gilt genauso umgekehrt, wenn sich die Stakeholder nur auf eine reine Umstellung der Tools und Praktiken verständigen. Eine gelungene DevOps-Transformation muss daher Mitarbeiter, Betriebsprozesse und Tools gleichermaßen umfassen. Hierbei hilft es, sich die Aufgaben der verschiedenen Komponenten und deren Beziehungen zueinander deutlich zu machen.

devops1

DevOps ist das angestrebte Ziel, definiert nach festgelegten Leitkriterien (What). Agile Development, Continuous Integration und Continuous Delivery hingegen sind die Prozesse, Methoden und Tools, die als Fundament zu einer nachhaltigen DevOps-Implementierung führen (How).

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

DevOps-Discovery aus verschiedenen Perspektiven

Stellt man den Stakeholdern zusammen in der Gruppe im Vorfeld die elementaren Fragen, können bereits frühzeitig wichtige Erkenntnisse und erste Annäherungsschritte für eine gemeinsame Umsetzung von DevOps gefunden werden.

Was ist das Ziel für die Einführung von DevOps?

  • CIO: Skalierbarkeit der Delivery erhöhen, weil das Unternehmen zu einem Software-as-a-Service (SaaS)-Modell übergeht. Deshalb müssen die Entwicklungsproduktivität gesteigert und die Kundenwünsche schneller beantwortet werden sowie gleichzeitig weniger Fehler auftreten.
  • IT-Betrieb: Technische Schuld durch schlecht umgesetzte Software reduzieren und weniger Ressourcen bei unvorhergesehenen Notfällen aufwenden, um moderne Best Practices wie Infrastructure-as-Code einführen zu können und kosteneffektiv zu arbeiten.
  • Entwickler: Kundenspezifische und ineffiziente einmalige Arbeiten minimieren, die bei Entwicklung, QA und Deployment die Komplexität erhöhen. Dafür soll mehr Zeit zur Verbesserung der Benutzerfreundlichkeit, Performance und genereller Mehrwert investiert werden, anstatt mit Bugfixes und falsch verstandenen Anforderungen ausgelastet zu sein.

Der Fokus der Antworten wird dabei sehr stark durch die Perspektive geprägt. Für leitende Angestellte stehen geschäftsorientierte Ziele im Vordergrund, für den IT-Betrieb zählen Stabilität und Notfallbewältigung (auch „Firefighting“ genannt), die Entwickler dagegen sehen fortgesetzte Innovation als elementar an.

Bei allen Unterschieden zeigen sich aber Gemeinsamkeiten bei den Themen „Produktivität“ und „Qualität“, dadurch lassen sich bereichsübergreifende Ziele für alle Beteiligten ableiten:

  • Steigerung der Produktivität und Minimierung von Überstunden und Firefighting
  • Steigerung der Anwendungsqualität und hohe Uptime

Es lassen sich zwar noch keine weiterführenden Entscheidungen für die Prozess- oder Tool-Wahl ableiten, wohl aber können KPI erstellt werden – etwa die Defekte pro Build/Release, die Zahl der Arbeitsstunden oder eine Verringerung der Cycle-Time – und machen den langfristigen Erfolg der Transformation messbar.

Wird bereits agil gearbeitet? Wie wird „Done“ bei Story und Sprint definiert?

CD und Lean Product Development sind fundamental für eine erfolgreiche Einführung von DevOps (auch wenn einige Definitionen dies nicht zwingend verlangen). Sie bilden eine Pipeline, durch die Arbeit in Form von kontinuierlicher Veränderung dargestellt und verwaltet werden muss. Wie diese Arbeit initiiert und Änderungen verwaltet werden, hängt stark von der angewandten Methodik bei der Entwicklung und anderer Praktiken ab.

Auch wenn Unternehmen bereits vom sequentiellen Waterfall-Modell auf agile Softwareentwicklung umsteigen, besteht noch Verbesserungspotenzial:

  • Agile und/oder Scrum werden verwendet, die Teams arbeiten in 2-Wochen-Iterationen und planen Sprint-Phasen nach Ende des vorangegangenen Sprints.
  • „Done” ist erreicht, wenn der Code erfolgreich zu einem Build im Team-Branch hinzugefügt wurde. Ein Sprint gilt als beendet, wenn alle Stories für diesen Sprint abgeschlossen sind.
  • Teams integrieren alle drei Monate von einer Verzweigung (Branch) zum Hauptstrang (Trunk) und beginnen mit der QA-Testphase, nach deren Bestehen manuell die Deployment-to-Production erfolgt.

Diese Antworten sind typisch für eine Adaptierung von Agile im Development-Prozess, ohne dass andere Teams wie QA oder IT-Betrieb einbezogen wurden. Oft sind Hindernisse in der Unternehmensstruktur oder –kultur der Grund, weshalb eine komplette Umstellung auf Agile ausblieb.

Das Ergebnis ist eine Mischform, die laut Studien 33 Prozent der Unternehmen praktizieren: Nach oben wird agil gearbeitet (Agile Upstream), nach unten weiterhin sequentiell agiert. Erst 13 Prozent der Unternehmen nutzen iterative Entwicklungsmethoden für Planung oder Coding in einem „Agile Downstream” unter Verwendung von CI/CD, automatisiertem Testen und Deployment.

devops2

Ein Hauptproblem dieser Mischform, die als „Systems Thinking“ in Gene Kims Buch Projekt Phoenix näher besprochen wird, ist das Fehlen von messbarem Feedback, um den Fortschritt von Projekten abschätzen zu können. Häufig sind Störungen im Entwicklungsprozess, der durch alle Instanzen der Prozesskette innerhalb des Unternehmens läuft, das Ergebnis, wenn Fehler während des Downstream-Teils des Prozesses entdeckt und behoben werden müssen: von missverstandenen Anweisungen und Runtime-Fehlern bei Test oder Deployment-to-Produktion, bis hin zum Worst Case – beim Endanwender.

devops3

Wird CI bereits eingesetzt? Welche Arten von Validierung werden verwendet?

Continuous Integration ist essentiell für Continuous Delivery und damit für DevOps. CI kann als Verbindungspunkt zwischen Agile Upstream und Agile Downstream gesehen werden und ist dabei die Methode, die am meisten angewendet und dabei am häufigsten falsch implementiert wird:

  • Man verwendet Jenkins CI-Server für Teams, und Entwickler spielen ihre Änderungen im Code mehrfach pro Woche mit Jenkins im automatisierten Nightly Build ein.
  • Es wird zwar vereinzelt getestet, es findet aber keine Nachverfolgung der Testabdeckung (code coverage) statt; falls der Nightly Build nicht funktioniert, wird weiter der Code eingespielt und Bugfixes in den kommenden Tagen erledigt.

Diese Antworten zeigen eine inkorrekte Implementierung von CI-Praktiken, die mehr verlangt, als nur Jenkins-Server zu nutzen und darauf Builds zu testen. Martin Fowler definiert CI als „Methode der Softwareentwicklung, bei der Mitglieder eines Teams ihre Arbeit mindestens einmal pro Tag im Code integrieren und durch einen automatisierten Build (einschließlich Test) auf Integrationsfehler überprüfen“.

Die essentiellen Aspekte für korrekt implementierte CI-Praktiken können also wie folgt zusammengefasst werden:

  • Häufige Integration von Änderungen (im Idealfall bei jeder Änderung)
  • Konstante Validierung der Qualität (Tests auf Komponentenebene, Code-Scans etc.)
  • Permanente Verfügbarkeit eines funktionierenden Builds (und Entwicklungsstopp bis zum Beheben aller Probleme, wenn ein Build nicht läuft)

Die Vorteile dieser Methode sind, dass Integrations- und Qualitätsprobleme nahe ihrem Ursprung gefunden und behoben werden können. Dadurch kann qualitativ bessere Software schneller entwickelt werden. Teams, die CI- Praktiken nicht oder nur ungenügend anwenden, können die Vorteile der Methode nicht im vollen Umfang nutzen.

Fazit

Für eine erfolgreiche Einführung von DevOps im Unternehmen müssen der Ist-Zustand klar erkannt und Einigkeit der verschiedenen Stakeholder bei Zielen und bereichsübergreifender Ausrichtung erreicht werden. Dafür ist vorab stets ein Discovery-Prozess mit den Parteien erforderlich, damit ein gemeinsamer Startpunkt für den Weg zu DevOps unter derselben Definition erstellt werden kann.

Die wichtigsten Schritte für diesen Prozess sind:

  • Wichtige Stakeholder bereichsübergreifend einbeziehen
  • Grundlegende Definitionen erstellen
  • Die fundamentalen Fragen häufig ansprechen
  • Gemeinsame Ziele identifizieren und als Orientierung einsetzen
  • Leitprinzipien für die Transformation definieren
  • KPIs erarbeiten und als Werkzeug einsetzen
  • Pragmatisch bei der Implementierung im Rahmen der Bedürfnisse des Unternehmens vorgehen

Aufmacherbild: 3D Illustration: Development & Operations (DevOps) von Shutterstock / Urheberrecht: anathomy

Verwandte Themen:

Geschrieben von
Brian Dawson
Brian Dawson
Brian Dawson ist DevOps-Evangelist bei CloudBees.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: