DevOps und YaSM

 

Vergleich: YaSM und DevOps

Teil von: YaSM und andere Service-Management-Frameworks und -Standards

 

DevOps beschreibt einen Ansatz, mit dem die Software-Entwicklung ("Dev" - Development) und der Software-Betrieb ("Ops" - Operations) zusammengebracht werden sollen. Es handelt sich bei DevOps nicht um ein genau definiertes Framework oder einen festgelegten Prozess, sondern um eine Reihe von Praktiken und Philosophien. Gelegentlich wird DevOps auch als "Bewegung" bezeichnet.

Abb. 1: Einsatz von DevOps im Service-Management

 

 

Traditionell herrschte in Organisationen, die sich mit der Entwicklung von Software beschäftigen, oft eine Aufteilung in "Silos" vor, also getrennte organisatorische Einheiten. Entwickler, Tester, Administratoren und Betriebs-Personal waren jeweils eigenständige Teams, und Arbeitsergebnisse wurden in größeren Blöcken von einem Team an das andere übergeben.

Eine solche lineare Struktur führt zu Problemen, wenn jedes Team auf seine eigenen Interessen achtet und weniger auf den gesamtheitlichen Erfolg.

Ein typisches Beispiel sind die sich oft widersprechenden Interessen zwischen Software-Entwicklung und Betrieb: Während die Entwickler neue Releases von Anwendungen zügig bereitstellen möchten, legt der Betrieb viel mehr Wert auf Software-Qualität und gründliches Testen, damit die Produktionsumgebung stabil bleibt.

Bei DevOps geht es darum, diese Silos aufzubrechen und funktionsübergreifende Teams einzurichten, damit Entwickler, Tester und Administratoren von Anfang an zusammenarbeiten. Jedes Team ist insgesamt dafür verantwortlich, dass die Software die Anforderungen der Anwender erfüllt. Das Ziel ist dabei, Software zeitnäher und zuverlässiger bereitzustellen, in Übereinstimmung mit den sich schnell verändernden Anforderungen der Kunden.

Damit dieser Ansatz funktioniert, befürwortet DevOps den Einsatz anderer, verwandter Praktiken und Methoden, wie z.B. Agile, Lean, Continuous Integration [1], Continuous Delivery [2] usw.

Die Drei Wege von DevOps

Der gesamte DevOps-Ansatz leitet sich aus einigen wenigen Grundprinzipien ab, die als die "Drei Wege von DevOps" ("Three Ways of DevOps") bekannt sind:

Der erste Weg - Systemdenken (Systems thinking)

Organisationen müssen sich auf die Leistungsfähigkeit des ganzen Systems konzentrieren, im Gegensatz zur Leistungsfähigkeit einzelner Silos. Dies bedeutet auch, Engpässe zu beseitigen, um den Arbeitsfluss zu verbessern.

Der zweite Weg - Verstärkung von Rückkopplungen (Amplify feedback loops)

Dieses Prinzip besagt, dass die Wege für Rückmeldungen kurz sein sollten, so dass Verbesserungen kontinuierlich und in kurzen Abständen erfolgen können. Probleme sollten als Rückmeldungen betrachtet werden und schnell zu Korrektur-Maßnahmen führen.

Der dritte Weg - Kultur des kontinuierlichen Experimentierens und Lernens (Culture of continual experimentation and learning)

Der dritte Weg sagt aus, dass Experimentieren, Risikofreude sowie das Lernen aus Erfolgen und Misserfolgen entscheidend sind, damit sich Organisationen weiterentwickeln und ihre Abläufe optimal gestalten können.

Warum ist DevOps so populär?

ITSM-Frameworks wie ITIL^® haben über die Jahre den Ruf erworben, übermäßig komplex und schwerfällig zu sein. DevOps wird hier oft als ein Weg gesehen, aus dieser Welt starrer Prozesse auszubrechen und schneller voranzukommen.

Und tatsächlich helfen die DevOps-Prinzipien vielen Organisationen, besser auf sich ändernde Marktbedingungen und Kundenanforderungen reagieren zu können:

• Die Arbeit wird in kleinere Schritte aufgeteilt, was zu kürzeren Entwicklungs- und Release-Zyklen führt.
• Funktionsübergreifende Teams, die sich über Entwicklung und Betrieb erstrecken, stellen sicher, dass betriebliche Belange bei der Software-Entwicklung von Beginn an berücksichtigt werden.

Ein weiterer Grund, warum DevOps so beliebt ist, ist die Verfügbarkeit moderner Konzepte und Technologien, die den DevOps-Ansatz unterstützen, wie z.B.Cloud-Services, Virtualisierung, Containerization, Microservices usw.

Ersetzt DevOps ITSM und Service-Management Best Practice?

Der Begriff "DevOps" wurde zuerst im Jahre 2009 von Patrick Debois [3] geprägt. Das Interesse an DevOps hat schnell zugenommen und sich bisweilen zum Hype entwickelt. In diesem Zuge wurde an mancher Stelle auch der Eindruck erweckt, DevOps sei die bessere Alternative zu ITSM und Service-Management-Frameworks wie ITIL^®.

DevOps bietet zwar neue Ansätze, von denen Organisationen profitieren können; doch wurde im Lauf der Zeit klar, dass Organisationen kaum funktionieren können, wenn man ausschließlich auf frei agierende, funktionsübergreifende Teams setzt. Klar definierte Prozesse werden immer noch benötigt, um die Richtung vorzugeben und die Organisation zu steuern. Wie sonst könnten Unternehmen z.B. sicherstellen, dass die angebotenen Services mit den Anforderungen der Kunden übereinstimmen, und wie vertraglich zugesagt geliefert werden?

Heute ist die gängige Meinung, dass DevOps und ITSM nicht dasselbe sind. Vielmehr ergänzen sich beide Konzepte gegenseitig und sollten in Kombination verwendet werden.

Warum Service-Management Best Practice weiterhin relevant ist

Service-Management-Frameworks enthalten viele bewährte Empfehlungen, um als Anbieter von Services erfolgreich zu sein. Sie beschreiben z.B., wie Service-Provider

• eine Service-Strategie formulieren und umsetzen
• Services auf Basis von Kundenbedürfnissen definieren
• Änderungen ('Changes') und die damit verbundenen Risiken managen
• Service-Incidents beheben und Serviceaufträge erfüllen
• die Service-Qualität messen
• ihre Services kontinuierlich verbessern
• Kundenbeziehungen pflegen
• Lieferanten und Dienstleister managen
• Compliance sicherstellen.

Dies alles sind essenzielle Kompetenzen für jede Organisation, die Services erbringt. DevOps jedoch hat zu diesen Themen nichts oder sehr wenig zu sagen. Deshalb wäre es falsch, die traditionellen Service-Management-Rahmenwerke als alten Hut abzutun. Sie sind so relevant wie bisher!

Was allerdings abgelegt werden sollte, ist die Vorstellung, das Service-Management als Disziplin schwierig und bürokratisch ist. Die Service-Management-Frameworks können sehr komplex wirken, aber es war schon immer falsch, alles mit dogmatischem Eifer "implementieren" zu wollen. Es kommt darauf an, die Prinzipien hinter den Frameworks zu verstehen, die zur Organisation passenden Empfehlungen auszuwählen und klare, maßgeschneiderte Prozesse zu definieren.

Ein besonderer Fall: Der gefürchtete Change-Management-Prozess

Eine ITIL^®-Disziplin, die besonders oft als schwerfällig und übermäßig bürokratisch wahrgenommen wird, ist das Change Management, wobei das CAB-Meeting ganz besonders in der Kritik steht. Sein schlechter Ruf kommt daher, dass manche Organisationen jede Änderung gleichbehandeln. Damit sind sehr viele Changes zu diskutieren, was zu schier endlosen CAB-Meetings führt.

Sicherlich kann dies nicht für Organisationen funktionieren, die DevOps verwenden, wo Änderungen praktisch an der Tagesordnung sind und schnell umgesetzt werden müssen.

Trotzdem besteht ganz klar die Notwendigkeit, Changes zu kontrollieren, egal, ob Organisationen sich an DevOps orientieren oder nicht. Vor allem gilt es, schlecht koordinierte oder getestete Changes zu verhindern, die nach manchen Schätzungen mehr als die Hälfte aller Service-Incidents verursachen. Die Lösung kann also nicht die Abschaffung des Change-Managements sein, sondern es geht darum, die Grundidee hinter dem Prozess zu verstehen und ihn zu verbessern.

In ITIL^® hat das Change-Management die Aufgabe, die mit Änderungen verbundenen Risiken zu kontrollieren. ITIL^® schreibt aber in keiner Weise vor, dass jeder Change im CAB diskutiert werden muss, sondern bietet mehrere Möglichkeiten an, mit Changes umzugehen: Changes mit hohem Risiko müssen vom CAB freigegeben werden, doch dieser Fall sollte eher die Ausnahme sein. Für die meisten Änderungen sind die Risiken gut bekannt, und für solche Changes empfiehlt ITIL^® die Definition von (vorab autorisierten) Standard-Changes mit entsprechenden Change-Modellen.

In einer DevOps-Umgebung sind das Testen und Ausrollen häufig automatisiert und standardisiert, so dass die Risiken aufgrund fehlerhafter Changes wesentlich geringer sind. Mit DevOps sind Organisationen daher in der Lage, sehr viel mehr Standard-Changes zu definieren und den Arbeitsaufwand für das CAB weiter zu senken.

DevOps hat also den Change-Management-Prozess mitnichten bedeutungslos gemacht. Vielmehr bietet DevOps die Chance, mit Änderungen effizienter umzugehen.

Ist DevOps für alle Service-Provider geeignet?

DevOps hat seine Wurzeln im Software-Engineering, und ist damit besonders für softwaregestützte Services geeignet. Für andere Arten von Services ist das Bild weniger klar, obwohl DevOps sehr wahrscheinlich nützliche Empfehlungen für die meisten Service-Provider enthält.

Z.B. nutzt ein Logistik-Dienstleister in großem Umfang Anlagegüter wie Transportfahrzeuge, Warenlager, Sortieranlagen usw. Es ist offensichtlich, dass diese Art von Ausrüstung nicht in so kurzen Zyklen erweitert oder angepasst werden kann, wie dies bei Software der Fall ist.

Aber selbst in Situationen, in denen die Service-Komponenten nicht 'virtualisiert' und kurzfristig geändert werden können, kann sich die Anwendung einiger DevOps-Ideen als nützlich erweisen. Dies gilt zum Beispiel für funktionsübergreifende Teams, die sich um die Services über ihren ganzen Lebenszyklus hinweg kümmern, angefangen vom Service-Design über Implementierung und Betrieb bis hin zur Service-Verbesserung.

Allen Service-Providern wird deshalb empfohlen, sich mit dem DevOps-Ansatz zu befassen.

Kann YaSM zusammen mit DevOps eingesetzt werden?

Das YaSM-Prozessmodell bildet die langjährig etablierte Service-Management 'Best Practice' ab. Es kann auf IT-Services und alle anderen Arten von Services angewendet werden.

Das Modell umfasst Aktivitäten für das Designen, Erstellen, Testen, Ausrollen, Betreiben und Verbessern von Services. Dabei hat das YaSM-Modell keinen Vorschrifts-Charakter und die Anwender können die Prozesse ohne weiteres auf ihre Bedürfnisse zuschneiden und so effizient wie möglich ausführen.

Zum Beispiel geht es bei Test-Aktivitäten darum, Test-Skripte zu erstellen, Testläufe auszuführen, Test-Ergebnisse zu protokollieren usw. Wie die Tests genau durchgeführt werden, muss im Einzelfall entschieden werden und hängt von der Art der zu testenden Service-Komponenten ab. Organisationen, die den DevOps-Empfehlungen folgen, werden sicherlich versuchen, das Testen soweit wie möglich zu automatisieren.

Ähnliches gilt für das Deployment. Das YaSM-Modell beschreibt die typischen Aktivitäten für das Ausrollen der Service-Komponenten. Organisationen, die auf DevOps setzen, werden diesen Prozess möglichst automatisch ablaufen zu lassen.

Das YaSM-Modell ist also nicht speziell an DevOps ausgerichtet. Mit seinen schlanken, geradlinigen Prozessen und Prozess-Templates bietet es Organisationen jedoch einen Rahmen für ihre Service-Management-Prozesse und die Flexibilität, DevOps-Prinzipien in diese Prozesse zu integrieren.

Wo kann ich mehr über DevOps erfahren?

Die meisten Service-Management-Publikationen enthalten heutzutage Abschnitte über DevOps, Diese erläutern die grundlegenden Konzepte und zeigen auf, wie das Service-Management vom DevOps-Ansatz profitieren kann.

Vielfach wird auch das Buch 'The Phoenix Project' [4] als erste Einführung in DevOps empfohlen. Es handelt sich um einen Roman, in dem die Geschichte eines IT-Managers erzählt wird. Dieser findet sich plötzlich im oberen Management wieder, und mit Hilfe von DevOps sorgt er dafür, dass die IT-Projekte schneller Ergebnisse liefern.

Natürlich gibt es auch viele Informationen über DevOps im Internet. Eine der besten Quellen für DevOps ist die Site devops.com [5] mit einer reichen Auswahl zum Thema, wie z.B. Blogartikel von Fachexperten, Artikel zu Fachthemen, Webinare und Podcasts.

Referenzen und Anmerkungen

[1] Kontinuierliche Integration (Continuous Integration). -- Wikipedia. Abgerufen am 22. September 2018.
[2] Continuous Delivery. -- Wikipedia. Abgerufen am 22. September 2018.
[3] Patrick Debois auf LinkedIn
[4] Gene Kim, Kevin Behr, and George Spafford, 2013. The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. IT Revolution Press, Portland, Oregon; USA.
[5] Devops.com (2018). Where the world meets DevOps. Abgerufen von https://devops.com/

Von:  Stefan Kempter   und  Andrea Kempter , IT Process Maps.

 

Was ist DevOps?  › Drei Wege von DevOps  › Ersetzt DevOps ITSM und Service-Management?  › Das YaSM-Modell und DevOps