Standardisierte ITIL-Prozesse

Viel agiler dank IT-Service-Management

Wie sich die Release-Zyklen agiler Entwicklungsteams mithilfe von ITIL-Prozesse ­unterstützen und überwachen lassen

Viel agiler dank ITSM

Unterstützung erhielt die DevOps-Bewegung vor allem durch technologische Entwicklungen.

Vor einiger Zeit 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 schließlich wurde die Trennung der alten, statischen 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. Dabei gilt es bei der Bereitstellung von Software-Lösungen, 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 potentielles 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.

Unterstützung erhielt die DevOps-Bewegung vor allem durch technologische Entwicklungen. Virtualisierungs- und Cloud-Lösungen ermöglichen heute das vollautomatische Bereitstellen von Infrastrukturumgebungen. Mithilfe von Continuous-Integration- und Continuous-Delivery-Tools (CI/CD) wie beispielsweise 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 mithilfe 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 Plattformservices 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 Plattformservices 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.

Keine schwerfälligen Change-Prozesse


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. Er beschreibt diese Entwicklung und erläutert, welche Auswirkungen die neuen, agilen Methoden auf die etablierten IT-Service-Management-Prozesse haben. Der Change-Prozess wird nur dann langsam, wenn der Wechsel manuell bewertet und genehmigt werden muss.

Änderungen an kritischen Services wurden bisher wegen des potentiellen Ausfallschadens meist mit einem hohen Risiko bewertet, der Wechsel 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 Wechsel 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 Ent­wicklungsprozesses mit den ITIL-Prozessen ist die ­Integration der DevOps-Tools mit dem IT-Service-­Management-Tool. Dabei werden Releases und Standard-Changes laut dem IT-Anbieter Usu Software ­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 können diese Szenarien dank einer hohen Integrationsfähigkeit und umfangreicher Automatisierungsbausteine unterstützen.

Dies ist ein Artikel aus unserer Print-Ausgabe 4/2019. Bestellen Sie ein kostenfreies Probe-Abo.

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 ans 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 mithilfe der ITIL-Prozesse unterstützt und überwacht werden.

Bildquelle: Getty Images / iStock

©2019Alle Rechte bei MEDIENHAUS Verlag GmbH

Unsere Website verwendet Cookies, um Ihnen den bestmöglichen Service zu bieten. Durch die weitere Nutzung der Seite stimmen Sie der Verwendung zu. Weitere Infos finden Sie in unserer Datenschutzerklärung.

ok