Hand in Hand: Devops und iITSM

Zuerst kamen mit SCRUM agile Methoden für die Software-Entwicklung auf. Dann etablierten sich mit DevOps neue Prinzipien zur besseren Verzahnung von Entwicklung und Betrieb. Nun geht die IT-Welt mit Begriffen wie bimodal endgültig in eine neue Ära. [...]

Bei agilen Methoden handelt es sich 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-Servicemanagement-Prozesse (ITSM) haben.
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.

Zwiespalt

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 DevOps 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 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 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 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.

Zweifel an der Kompatibilität

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 (zum Beispiel 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.

Integration der Tools in das IT-Service-Management

Wichtig für diese enge Verzahnung des Entwicklungsprozesses mit den ITIL-Prozessen ist die Integration der DevOp-Tools mit dem IT-Servicemanagement-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 zum Beispiel USU Valuemation unterstützen diese Szenarien durch eine hohe Integrationsfähigkeit und umfangreiche Automatisierungsbausteine.

Von der Entwicklung in den Betrieb

In seinem ursprünglichen Sinne beschreibt 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 wie etwa den Zusammenschluss von Entwicklern und Betriebsverantwortlichen in DevOp-Teams im Blick, kommt man heute dem Ziel durch den Einsatz moderner Tools zur automatisierten Produktivsetzung (Continuous Integration & Delivery) sehr viel näher. Einen weiteren 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. Martin Landis|USU

Dieser Artikel ist ein Auszug aus einem Whitepaper der USU GmbH, das hier heruntergeladen werden kann: http://bit.ly/wp-devops-itsm-cw