DevOps: Praktische Auswirkungen auf ITSM – Agiles IT Service Management

DevOps wird durch den Einsatz moderner Tools zur automatisierten Produktivsetzung (Continuous Integration & Delivery) immer effektiver. Werden diese Tools mit dem IT-Service-Management-Tool integriert, können auch die kurzen Release-Zyklen agiler Entwicklungsteams mit Hilfe der ITIL-Prozesse kontrolliert werden.

Zuerst kamen mit SCRUM agile Methoden für die Softwareentwicklung auf. Dann etablierten sich mit DevOps neue Prinzipien zur besseren Verzahnung von Softwareentwicklung und Betrieb. Und schließlich wurde die Trennung der alten, stabilen IT-Welt von der neuen, dynamischen IT-Welt mit Bezeichnungen wie »Bimodale IT« oder »IT der unterschiedlichen Geschwindigkeiten« verdeutlicht. Dabei handelt es sich bei den agilen Methoden keineswegs um revolutionäre, neue Ideen, sondern lediglich um eine evolutionäre Weiterentwicklung – ermöglicht durch den technischen Fortschritt. Dieser Artikel beschreibt diese Entwicklung und erläutert, welche Auswirkungen die neuen, agilen Methoden auf die etablierten IT-Service-Management-Prozesse haben.

DevOps thematisiert die Zusammenarbeit zwischen Entwicklung und Betrieb. Bei der Bereitstellung von Softwarelösungen gilt es, zwei grundlegend gegensätzliche Zielsetzungen durch einen Kompromiss zu optimieren:

  • Die Softwareentwicklung möchte möglichst schnell innovative Funktionen entwickeln und dem Kunden zeitnah zur Verfügung stellen. Mit den heute üblichen agilen Entwicklungsmethoden werden neue Software-Releases in kurzen Entwicklungszyklen bereitgestellt. Dies resultiert in häufigen Änderungen (Changes) für die laufenden Applikationen.
  • Der Softwarebetrieb dagegen möchte dem Kunden möglichst fehlerfreie, stabile Applikationen zur Verfügung stellen. Jede Änderung stellt hier
    ein potenzielles Risiko für Fehler, Sicherheitslücken oder Ausfälle dar. Außerdem ist die Bereitstellung von Applikationen in traditionellen Infrastrukturumgebungen noch mit viel manueller Arbeit für beispielsweise Beschaffung, Installation und Wartung verbunden. Unter diesen Bedingungen kann die Betriebsorganisation die von der Entwicklung geforderten kurzen Release-Zyklen häufig nicht unterstützen.

In diesem Spannungsfeld entstanden ab 2009 Überlegungen zur Verbesserung der Zusammenarbeit zwischen Entwicklung (Development) und Betrieb (Operations), die unter dem Begriff DevOps zusammengefasst wurden [1]. Die grundlegende Idee dabei war, die Kommunikationshürden zwischen den traditionell getrennten Entwicklungs- und Betriebsorganisationen abzubauen. Anforderungen aus dem Betrieb sollten bereits bei der Entwicklung berücksichtigt werden, um den späteren Übergang einer Applikation in den Betrieb möglichst reibungslos zu gestalten (Abbildung 1).

 

Abbildung 1: Entwicklungs- und Betriebsorganisation nach dem DevOps-Prinzip.

 

Technologie ist der Treiber der DevOps-Bewegung. Unterstützung hat die DevOps-Bewegung vor allem durch die technologische Entwicklung erhalten. Virtualisierungs- und Cloud-Lösungen ermöglichen heute das vollautomatische Bereitstellen von Infrastrukturumgebungen. Mit Hilfe von Continuous Integration und Continuous-Delivery-Tools (CI/CD) wie etwa Jenkins, Chef, Puppet oder Ansible kann auch der Übergang einer Applikation von der Entwicklungsumgebung in den Test oder die Produktion weitestgehend ohne manuelle Eingriff erfolgen. Und mit Hilfe von Containertechnologien wie beispielsweise Docker oder Kubernetes werden Anwendungen automatisiert skaliert und verwaltet.

Da nun viele der klassischen Betriebsaufgaben automatisiert werden können, ändert sich das Tätigkeitsfeld der Betriebsorganisation. Statt manuell Infrastruktur bereitzustellen und zu betreiben, stellt sie jetzt automatisierte Plattform-Services zur Verfügung, die von der Entwicklung flexibel je nach Bedarf abgerufen werden können. Dieser automatisierte Betrieb verkürzt dann nicht nur die Bereitstellungszeiten für neue Releases dramatisch. Er verringert auch das Risiko von Fehlern, die bei manuellen Eingriffen entstehen können, und erhöht den Grad der Standardisierung.

Um einen möglichst hohen Automatisierungsgrad im Betrieb zu erreichen, ist natürlich eine enge Abstimmung zwischen Entwicklung und Betrieb bezüglich der Plattform-Services notwendig. Nachdem beide Seiten ein hohes Interesse an einer funktionierenden Automatisierung haben, ist die Motivation grundsätzlich gegeben. Ob man die enge Abstimmung zusätzlich noch fördert, indem man produkt- oder servicespezifische DevOps-Teams auch in der Aufbauorganisation abbildet, muss im Einzelfall abgewogen werden. Denn auch in interdisziplinären DevOps-Teams wird es Spezialisten einerseits für die Entwicklung und andererseits für die Betriebsaufgaben geben. 

DevOps und ITIL ergänzen sich zum agilen IT Service Management. Häufig wird bezweifelt, dass die agile Arbeitsweise von DevOps-Teams mit den standardisierten ITIL-Prozessen ausgereifter IT-Organisationen kompatibel ist. Vor allem der Change-Prozess wäre viel zu langsam und schwerfällig, um mit den schnellen Release-Zyklen von DevOps-Teams Schritt halten zu können.

Das muss aber nicht so sein. Der Change-Prozess wird nur dann langsam, wenn der Change manuell bewertet und genehmigt werden muss. Änderungen an kritischen Services wurden bisher wegen des potenziellen Ausfallschadens meist mit einem hohen Risiko bewertet, der Change musste genehmigt werden. Durch die heute mögliche Automatisierung im Test-, Release- und Deployment-Prozess wird allerdings die Wahrscheinlichkeit für die durch Change-Prozesse verursachten Störfälle drastisch reduziert. Wenn also der Release- und Deployment-Prozess einmal grundsätzlich genehmigt wurde (etwa für Minor Releases auf dem Hauptentwicklungspfad), können alle weiteren Changes entlang dieses Prozesses als Standard-Change betrachtet und ohne Genehmigung automatisiert durchgeführt werden. Und sollte doch einmal ein Fehler auftreten, wird mit den automatisierten Rollback-Verfahren der ursprüngliche Zustand schnell wiederhergestellt.

Wichtig für diese enge Verzahnung des Entwicklungsprozesses mit den ITIL-Prozessen ist die Integration der DevOps-Tools mit dem IT-Service-Management-Tool (Abbildung 2). 

 

Abbildung 2: Integration der DevOps-Tools mit dem ITSM-Tool.

 

Releases und Standard-Changes werden automatisch im ITSM-Tool angelegt und mitsamt der Change-Historie dokumentiert. Infrastrukturkomponenten werden auf Anfrage automatisch über die Cloud Automation Engine des ITSM-Tools bereitgestellt und in der CMDB aktualisiert. Und letztlich überträgt das ITSM-Tool automatisch die Störfälle, die auf der Entwicklungsseite beseitigt werden müssen, in das SCRUM-Tool der Entwickler.

Moderne ITSM-Tools wie USU Valuemation unterstützen diese Szenarien durch eine hohe Integrationsfähigkeit und umfangreiche Automatisierungsbausteine.

Fazit. In seinem ursprünglichen Sinne beschreibt der Begriff DevOps das Ziel, den Übergang einer Applikation von der Entwicklung in den Betrieb möglichst effizient zu gestalten. Hatte man anfangs vor allem organisatorische Maßnahmen im Blick wie den Zusammenschluss von Entwicklern und Betriebsverantwortlichen in sogenannten DevOps-Teams, kommt man heute dem Ziel durch den Einsatz moderner Tools zur automatisierten Produktivsetzung (Continuous Integration & Delivery) sehr viel näher. Ein weiterer Schritt stellt die Integration dieser Tools mit dem IT-Service-Management-Tool dar. Auf diese Weise können auch die kurzen Release-Zyklen agiler Entwicklungsteams mit Hilfe der ITIL-Prozesse unterstützt und überwacht werden.

 

Whitepaper Download

Dieser Artikel ist ein Auszug aus einem Whitepaper, das hier heruntergeladen werden kann: 

http://bit.do/wp-devops-itsm-mit

 


Martin Landis ist bei der USU GmbH im Produktbereich Valuemation
als Experte für das IT- und Enterprise Service -Management tätig.
Er hat über 15 Jahre Erfahrung in der Entwicklung und dem erfolgreichen
Einsatz entsprechender Tools innerhalb der IT, aber auch in weiteren
Servicebereichen wie Personalwesen, Facility Management und
Field Service.
www.usu.de

 

[1] Siehe https://legacy.devopsdays.org/events/2009-ghent/

 

Illustration: © Dark ink /shutterstock.com

 


 

Bessere Zusammenarbeit von NetOps und DevOps – Höhere Effizienz durch Netzwerk-Automatisierung

Risikofreie Implementierung von DevOps unterstützen: Gemeinsam stark

Zunehmende Akzeptanz von agilen Methoden und DevOps – Management sieht automatisiertes Testen noch kritisch

BizDevOps rückt in den Mittelpunkt der Applikationsentwicklung

Sicherung vertraulicher Zugangsdaten in DevOps-Umgebungen kommt zu kurz

DevOps gegen IT-Operations

 

Weitere Artikel zu