DevOps: Praktische Auswirkungen auf das IT Service Management

Lesezeit: 4 Min

Bild: Integration der DevOp-Tools mit dem ITSM-Tool

Ein Wegbereiter für eine dynamische, flexible und anpassungsfähige IT-Welt sind DevOps mit neuen Prinzipien zur besseren Verzahnung von Software-Entwicklung und Betrieb.

Zuerst kamen mit SCRUM agile Methoden für die Software-Entwicklung auf. Dann etablierten sich mit DevOps neue Prinzipien zur besseren Verzahnung von Software-Entwicklung und Betrieb. Und schliesslich 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.

DevOps thematisiert die Zusammenarbeit zwischen Entwicklung und Betrieb

Bei der Bereitstellung von Software-Lösungen gilt es, zwei grundlegend gegensätzliche Zielsetzungen durch einen Kompromiss zu optimieren:

Die Software-Entwicklung 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 Software-Betrieb 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 z. B. 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 DevOps1 zusammengefasst wurden. 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.

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 z. B. 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 Docker und 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 bzgl. 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 DevOp-Teams auch in der Aufbauorganisation abbildet, muss im Einzelfall abgewogen werden. Denn auch in interdisziplinären DevOp-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-Prozesse wäre viel zu langsam und schwerfällig, um mit den schnellen Release-Zyklen von DevOp-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 (z. B. 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 DevOp-Tools mit dem IT-Servicemanagement-Tool (s. Abbildung).

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 z. B. USU Valuemation unterstützen diese Szenarien durch eine hohe Integrationsfähigkeit und umfangreiche Automatisierungsbausteine.

Whitepaper Download
Dieser Artikel ist ein Auszug aus einem umfangreichen Whitepaper, das hier heruntergeladen werden kann: http://bit.do/wp-devops-pc

Autor: Martin Landis, Business Unit Manager, ist bei der USU AG für das Produktmarketing im Bereich IT- und Enterprise Service Management tätig.

13