DevOps als Treiber für agiles und schlankes IT-Servicemanagement
Wieder so ein Hype aus der Marketingagentur eines großen Beratungsunternehmens könnte man meinen: DevOps als Retter der IT oder gar als wichtigster Bestandteil einer digitalen Information. Demgegenüber steht eine Skepsis über Inhalte und Notwendigkeit, häufig angesiedelt im klassischen IT-Betrieb. Dieser Beitrag möchte DevOps aus Sicht des IT-Servicemanagements (als Synonym für einen prozessorientierten IT-Betrieb) beschreiben, Einsatzmöglichkeiten darstellen sowie erste praktische Tipps geben.
Die Notwendigkeit für Veränderungen im IT-Servicemanagement liegt auf der Hand. Die Anforderungen des Marktes bzw. der internen Kunden steigen. Die Ursachen dieses erhöhten Drucks auf die IT kann man drei Bereichen zuordnen, die als Treiber von DevOps anzusehen sind [1]:
- Externes Umfeld
- Interne Organisation
- Technische Entwicklung
Das externe Umfeld wandelt sich in einem steigenden Tempo und verändert die Anforderungen an Applikationen und Servicebereitstellung sowie an die Formen der Zusammenarbeit innerhalb der liefernden Unternehmen. Die Digitalisierung der Angebote und in der Folge auch die der Geschäftsmodelle am Markt erfordert eine engere Zusammenarbeit zwischen Business und IT, die augenscheinlich nicht zufriedenstellend durch klassische Ansätze zu leisten ist. Während aus traditioneller Sicht die Anforderungen von den Fachbereichen formuliert und dann zeitversetzt von der IT umgesetzt wurden, müssen heute sehr viel schneller bewertbare Ergebnisse erzielt werden und Marktveränderungen viel schneller in den Applikationen berücksichtigt werden. Auch die Web- und App-Entwicklung für mobilen Zugriff auf die Unternehmensdienste und -angebote verlangt eine schnellere Produktivsetzung von Funktionen und kann häufig nicht auf wochenlange Change-Management-Prozesse warten. Der Zeitraum zwischen Anforderung aus Sicht des Business und der Verfügbarkeit für den Benutzer muss verkürzt werden, teilweise ist er schon ein wichtiger Wettbewerbsfaktor. Das beinhaltet auch, neue Ideen am Markt schnell testen zu können (Experiment und Lernen).
Auch die interne Organisation in der IT-Abteilung wandelt sich. Die verstärkte Organisationsform einer agilen Softwareentwicklung stellt schneller fertige Lösungen bereit. Die geforderte Verkürzung des Umsetzungszeitraums wird hier schon bis zum Betrieb einer Lösung erreicht. Jedoch bleiben dann häufig noch die erstellten Teilfunktionalitäten wochen- oder monatelang auf Halde liegen und warten auf den nächsten Releasetermin. Aus Sicht des Betriebs der Applikationen steigen die Ansprüche an Governance, Verfügbarkeit und Stabilität. Nach Fertigstellung durch die Softwareentwicklung müssen umfangreiche Tests durchgeführt und absichernde, umständliche Prozesse zur Produktivsetzung absolviert werden. Dabei entstehen erhöhte Aufwendungen und die erzielten Zeitgewinne werden durch umständliche Rückmeldeprozeduren aus dem Betrieb an die Entwicklung verspielt.
Hinzu kommt die technische Entwicklung unterstützender Tools am Markt. Aktuell besteht durch leistungsfähige Open Source-Systeme wie beispielsweise Docker, Jenkins, Nagios, Ansible, OpenStack oder auch Git eine enorm verbesserte Möglichkeit der Automatisierung im Bereich DevOps. Diese Tools ermöglichen u. a. durch vereinfachtes Monitoring bessere Auswertungen zum Applikationsverhalten. Die Virtualisierung und stark wachsende Cloud-Angebote steigern die vereinfachte Nutzung und Verfügbarkeit technischer Umgebungen für Entwicklungs- und Testarbeiten sowie für die Produktivsetzung.
Was ist DevOps?
DevOps als Kunstwort aus Development und Operations ist kein neues Framework [2]. Es beschreibt eine Philosophie, die die beiden "Namensgeber" (Entwicklung und Betrieb) zusammenbringt. Im Unterschied zu bestehenden Frameworks wie ITIL, COBIT oder Scrum gibt es keinen Rechteinhaber und auch keine Institution, die sich andersartig als inhaltlicher Eigentümer sehen kann. Insofern existieren weder allgemeingültige Definitionen noch Vorgaben, was eine IT-Organisation tun sollte, um DevOps anzuwenden. Eine breite Community hat sich etabliert, die eigenen Erfahrungen, praktische Überlegungen und Sichtweisen austauscht und so diese Philosophie in aller Öffentlichkeit und als Open Source weiterentwickelt.
Die Prinzipien geben einen Rahmen zur Entwicklung in Richtung DevOps.
Die DevOps Agile Skills Association (DASA) unterstützt diese Bewegung mit einem Ausbildungskonzept und hat 6 Prinzipien aufgestellt [3]. Diese Prinzipien sollen eine erste Richtung und einen Rahmen geben, wie eine IT-Organisation sich und vor allem seine Mitarbeiter in Richtung DevOps entwickeln sollte. Was hat das mit IT-Servicemanagement (ITSM) zu tun und was kann ITSM daraus lernen? Diese Frage soll zunächst geklärt werden, um dann die Fragestellung dieses Beitrages aufzugreifen.
Prinzip 1: Customer-Centric Action
Kundenzentrierte Aktionen im DevOps bedeutet, dass die Feedbackzyklen mit Kunden und Anwendern immer kürzer und direkter werden. Alle Aktivitäten der Serviceerbringung müssen sich an den Kunden orientieren. IT-Organisationen müssen dazu die Fähigkeit erlangen, sich ähnlich wie junge Start-Ups kontinuierlich neu zu erfinden und schnell auf veränderte Einflüsse zu reagieren.
Aus Sicht des ITSM ist das eine Veränderung. Auch wenn Frameworks wie ITIL den Kunden/Anwender mit der Serviceorientierung in den Mittelpunkt stellen, ist der DevOps-Gedanke weitergehender. Die Verantwortung für einen Service wird einem Team vollumfänglich übertragen und die Organisation so gestaltet, dass das Feedback des Kunden viel intensiver eingeholt und verarbeitet wird. Während in IT-Servicemanagement-Organisationen ein Service Owner bzw. Manager selten ausreichend Mittel und Befugnisse hat, Kundenbedürfnisse umzusetzen, ist das durch ein Business-Service-Team rund um einen Service bzw. ein Produkt in DevOps zielgerichteter gestaltet.
Prinzip 2: Create with the End in Mind
Mit dem Prinzip "Schon zu Beginn an das Ergebnis denken" versucht DevOps, die "klassische" prozessorientierte Vorgehensweise mit individuellen Rollen und Funktionen in eine produktorientierte Organisation zu verwandeln. Diese agiert mit dem Ziel, funktionierende Produkte an Kunden zu liefern und mit einer entsprechenden Denkweise zu agieren. Diese Zielsetzung manifestiert sich in der passenden Organisation.
Die im ITSM anzutreffende Prozessorganisation mit Arbeitsteilung und einer Fokussierung auf Aktivitäten ist einer hohen Kundenzufriedenheit nicht zuträglich. Die einzelnen Prozessteilnehmer verfolgen eigene Ziele und sind häufig nur daran interessiert, ihre beschriebenen Prozessschritte auszuführen. In einer an DevOps-Ideen ausgerichteten IT-Organisation wandelt sich die Orientierung vom Spezialistentum (in komplexen Prozessen eingegliedert) hin zu einer Ausrichtung an der Arbeit und dem Ergebnis. Die Organisation entwickelt sich dabei von der Funktionsorientierung (in Prozessabläufen verbunden) zu einem teambasierten Aufbau. Der Fokus verschiebt sich von Projekten auf Produkte ("You build it, you run it.") und die Arbeit bezieht sich zukünftig nicht mehr auf Einzelne, sondern auf Teams.
Prinzip 3: End-To-End Responsibility
Eine Ende-zu-Ende-Verantwortung bedeutet aus Sicht von DevOps, dass die traditionelle Trennung von Entwicklung und Betrieb zugunsten von voll verantwortlichen Teams ("Von der Wiege bis zur Bahre") verändert wird. Diese Teams entwickeln und betreiben die Services, ebenso wie sie Support leisten und damit eine viel weitreichendere Verantwortung übernehmen.
Aus Sicht von IT-Servicemanagement ergänzt dieses Prinzip die beiden vorherigen. Die herkömmlich in Prozessen und Abteilungen aufgeteilten Aktivitäten und aufgesplittete Verantwortung werden in ein Service-Team zusammengeführt. Dieses Business-Service-Team führt alle Tätigkeiten für die Entwicklung und den Betrieb eines Service aus und hat die komplette Verantwortung dafür.
Prinzip 4: Cross-Functional Autonomous Teams
Die Forderung nach crossfunktionalen, autonomen Teams aus Sicht von DevOps ist eine Weiterentwicklung agiler Ansätze. Scrum als bekanntestes agiles Framework setzt ebenfalls auf diese Teamorganisation. Um eine hochwertige Serviceerbringung sicherzustellen, ist ein fein ausbalanciertes Set an Wissen und Fähigkeiten notwendig. Es ist also ein sehr gutes T-Shape-Profil notwendig anstelle des klassischen IT-Spezialisten.
Dieses Prinzip kämpft in der praktischen Umsetzung mit ähnlichen Schwierigkeiten wie sie das IT-Servicemanagement kennt. Die Anforderungen an die Mitarbeiter wandeln sich noch stärker und es bedarf einer intensiven und umfangreichen Personal- und Organisationsentwicklung, um die "altgedienten" Menschen zu befähigen. Die Erfahrungen aus einer Neuausrichtung der Mitarbeiter an Prozess- und Serviceorientierung können nun auf Team- und Kundenorientierung angewendet werden.
Prinzip 5: Continuous Improvement
Das Prinzip von kontinuierlicher Verbesserung beschreibt aus Sicht von DevOps die Tatsache, dass sich moderne IT-Organisationen permanent an verändernde Bedingungen (Kundenanforderungen, technologische Rahmenbedingungen, Gesetze und Verordnungen, usw.) anpassen können müssen. DevOps setzt dabei auf Prinzipien von Lean Management um Verschwendung zu vermeiden sowie Kosten zu senken und die Liefergeschwindigkeit zu erhöhen. Experimente werden gefördert und eine neue Fehlerkultur ("Fail fast, fail offen") etabliert, die darauf abzielt, aus Fehlern zu lernen.
ITIL hat eine eigene Lebenszyklusphase und damit auch eine eigene Publikation, die sich mit der kontinuierlichen Verbesserung beschäftigt. Hier bietet sich nun die Möglichkeit, die agilen Prinzipen und Erfahrungen zu integrieren. Kontinuierliche Verbesserung ist in agilen Ansätzen noch stärker etabliert und in die tägliche Arbeit integriert. Die eher statische Behandlung in klassischen Ansätzen kann bspw. durch Daily Stand-Ups und Retrospektiven erweitert werden.
Prinzip 6: Automate Everything You Can
"Automatisiere alles was du kannst!" ist eine im Prinzip unmissverständliche Forderung. Sie setzt unter anderem auf der kontinuierlichen Verbesserung auf bzw. unterstützt diese, um schnelle Lieferzyklen zu realisieren, die dann zu sofortigem Feedback durch die Kunden führen. Die Automation umfasst dabei nicht nur den Entwicklungsprozess sondern auch die darunterliegende Infrastruktur. Unter dem Begriff "Infrastructure as code" wird damit eine neue Art der Servicelieferung beschrieben.
Aus Sicht des IT-Servicemanagement ist die Automation positiv zu bewerten. Die Lebenszyklusphase Service Transition wird dabei aktiv unterstützt und einbezogen. Von einer einfacheren und sicheren Aktualisierung des CMS über eine bessere Unterstützung des Release-Management bis zu einer stärkeren Fehlervermeidung im Change-Management sind nützliche Impulse vorhanden. Überall dort, wo menschliche Arbeiten ersetzt werden, steigt die Verlässlichkeit von Prozessen und deren Ergebnissen.
Handlungsfelder bei der Etablierung von DevOps
Die oben beschriebenen Prinzipien zeigen deutlich, dass die vielerorts anzutreffende Sichtweise nicht ausreicht, DevOps allein mit einer Automatisierung bzw. dem Aufbau einer Continuous Delivery-Pipeline gleichzusetzen. Automation ist zwar ein wichtiger Bestandteil, der jedoch um weitere Aspekte ergänzt werden muss. Durch die aufgeführten und in der Praxis im Einsatz befindlichen Frameworks ergeben sich verschiedene Handlungsfelder (s.Abb.1). Diese müssen vollständig betrachtet und bei einer Umsetzung in der Praxis bearbeitet werden. Neben der Automatisierung muss eine Kultur für DevOps geschaffen werden, die unter anderem die beiden unterschiedlichen Sichtweisen von Betrieb und Entwicklung aus traditioneller Sicht zusammenführt. Dazu sind Prozesse abzustimmen und eine passende Organisation aufzubauen. Weiterhin muss eine kontinuierliche Verbesserung als passende Mischung etabliert werden.
DevOps als Unterstützung für agiles und schlankes IT-Servicemanagement
DevOps ist eine Möglichkeit, das IT-Servicemanagement um agile und schlanke Prinzipien zu bereichern. Damit wird die ITSM-Organisation reaktionsfähiger und kann die eigene Erfahrung im Betrieb von Applikation einbringen. Klassische Ziele und Aktivitäten aus dem IT-Servicemanagement werden in DevOps mit zeitgemäßen Ansätzen modernisiert. IT Operations sowie die Prozesse Change, Configuration und Release-Management können bspw. durch die Automatisierung eine kontinuierliche Lieferung und Erhöhung des Releasezyklus erreichen und die erfolgreiche Produktivsetzung stärker absichern. Eine automatisierte und damit verbesserte (weil fehlerfreiere) Überführung der Services in den operativen Betrieb hilft auch den Prozessen Incident- und Problemmanagement.
DevOps sollte dabei wie schon erwähnt nicht als Framework und Vorgabe verstanden werden. Auch wenn es schwieriger und aufwändiger in der Umsetzung ist: DevOps liefert keine Blaupause für die erfolgreiche Bewältigung, sondern muss als Vorschlag für eine individuelle Anwendung verstanden werden. Die im agilen Umfeld häufig anzutreffenden Communities of Practice (CoP) können auch für einen Brückenschlag zwischen Entwicklung und Betrieb genutzt werden. Die Orientierung an DevOps-Prinzipien kann mit der Kommunikation in solchen Gruppen starten. Der nächste Schritt ist dann eine gesteigerte Verbindlichkeit der Berücksichtigung der Betriebsinteressen. In der Definition of Done der agilen Entwicklungsteams müssen die Anforderungen des Betriebs berücksichtigt werden. Damit wird sichergestellt, dass die agile Softwareentwicklung schon von Beginn an eine reibungslose Produktivsetzung und einen ordnungsgemäßen Betrieb im Fokus hat, auch wenn noch keine Business-Service-Teams rund um den Service etabliert sind. Gleiches gilt für die Akzeptanzkriterien, die die konkreten Kundenanforderungen formulieren und eine Erfüllung der Kundenwünsche auch im Betrieb gewährleisten müssen.
Auch bei definierten Rollen können beide Seiten voneinander lernen und aufeinander zugehen. Der Service Owner aus ITIL ist eine Rolle für DevOps-orientierte Organisationen als äquivalent zum Product Owner aus Scrum. Die durch DevOps gesteigerte Verantwortung für einen Service findet sich im Service Owner wieder, agile Ergänzungen aus der Arbeit des Product Owners helfen dabei, auch die agile Sichtweise in dieser Rolle abzubilden. Der Service Owner ist verantwortlich für definierte Services und dient dem Kunden als verantwortlicher Ansprechpartner für alle servicebezogenen Belange. Die Verantwortung des Service Owner erstreckt sich über den gesamten Lifecycle des jeweiligen Service, reicht also von der Initiierung, Planung und Überführung in den Betrieb (Transition) über die Pflege der Serviceinhalte bis zum Support für die Anwender. Der Product Owner hingegen hat die konkrete fachliche Steuerung des Teams im Auge und fokussiert somit unter anderem auch auf einen optimalen ROI für die Produktentwicklung.
Mit einer Ausrichtung an DevOps-Prinzipien kann das IT-Servicemanagement nicht zuletzt die eigene Arbeit als interner Cloud Service Provider etablieren. Den Business-Service-Teams mit der Produktverantwortung in Richtung Kunde und Anwender steht ein Plattform-Team zur Seite, das die Technologie für die Services liefert. Damit sieht das IT-Servicemanagement DevOps als Unterstützung und kann der Gefahr entgegenwirken, dass sich die Problematik "Schatten-IT" weiterentwickelt und auch Entwicklungsteams ohne interne IT einen Betrieb anbieten [4].
Aus Sicht von DevOps ist die bimodale IT die falsche Lösung
Die bis hier beschriebene DevOps-Philosophie führt bei konsequenter Anwendung dazu, dass der Ansatz einer bimodalen IT nicht sinnvoll erscheint. Wie die Geschichte vom Hase und dem Igel zeigt, ist es nicht zielführend, einfach nur schneller zu sein. Wer mit Köpfchen und im Team arbeitet, erreicht sein Ziel und eine gute Work-Life-Balance langfristig besser. Es geht darum, besser zu werden, die "Schnelligkeit" (d. h. die richtige Geschwindigkeit) kommt dann von selbst! Hochperformante IT-Organisationen erreichen die Codelieferung 200x regelmäßiger, erzielen eine 24x schnellere Wiederherstellung bei Fehlern und eine 2.555x kürzere Durchlaufzeit. Das Ergebnis des DevOps-Reports lautet: Stabilität und Geschwindigkeit lassen sich verbinden [5].
Fazit
Mit einer DevOps-Philosophie als Freund kann das IT-Servicemanagement seine Arbeit zeitgemäßer und erfolgreicher gestalten. Die Ziele und Erfahrungen aus bewährtem IT-Servicemanagement sollten dabei im Rahmen einer agilen Organisationsentwicklung mit erfahrenen Coaches in eine DevOps-Organisation überführt werden.
- D. Söllner: DevOps in der Praxis – Handlungsfelder für eine erfolgreiche Zusammenarbeit von Entwicklung und Betrieb, in: HMD Praxis der Wirtschaftsinformatik, Volume 54, Issue 2, April 2017
- Podcast bei Spotify: DevOps auf die Ohren und ins Hirn
- DASA DevOps Principles
- P. Schaefer, D. Söllner: DevOps by Scrumban, in: HMD Praxis der Wirtschaftsinformatik, Volume 54, Issue 2, April 2017
- Puppet.com: 2016 State of DevOps Report
Publikationen
- IT-Service Management mit FitSM
- Perspektivwechsel im IT Service Management: Erfolgsgeschichten oder - Dierk Söllner, Peter Bergmann, itSMF
