In meinem vorherigen Blog-Artikel habe ich mich mit der Notwendigkeit eines Zusammenwirkens von DevOps und ITSM im Bereich Change, Release und Deployment Management insbesondere aus der Perspektive der Compliance befasst. Wie bei vielen anderen Artikel im Internet zum Thema DevOps und ITSM liegt hier der Fokus der Auseinandersetzung auf die Prozesse aus dem Service Design und Service Transition nahe, weil dies der Kernbereich des agilen Entwickelns ist. Doch wenn DevOps das Motto „You build it, you run it“ vertritt, dann muss am Ende des Tages jede agil entwickelte Software auch betrieben werden: also hat man sich dringend auch mit Service Operation zu beschäftigen. In meinem derzeitigen Projekt bei einem großen deutschen Konzern musste ich für genau dieses Problem eine Lösung finden, da das Projektteam ihre entwickelte Software auch selbst betreibt. Egal, ob die hier vorgestellten Rollen und Prozesse im DevOps-Team selbst oder in einer anderen Organisation dargestellt werden, die Aufgaben, Aktivitäten und die daraus hier abgeleiteten Empfehlungen sind dieselben.
Service Operation, kein Thema für agil – oder doch?
Zum Thema DevOps und ITSM gibt es ja wenig Material im Internet zu finden, aber insbesondere die fundierten Blogbeiträge von Alex Lichtenberger stechen heraus. In seinem Artikel zu Integrating Agile and ITSM stellt Alex mit dieser sehr hilfreichen Grafik die beiden Prozesswelten gegenüber:
Es gibt also Interaktionen zwischen Service Operations und der agilen Entwicklung, hier dargestellt als Anforderungen aus dem nicht-funktionalen Bereich, die in die Entwicklungen einfliessen müssen. Aber Service Operation beschränkt sich ja nicht nur auf die grundsätzliche Verbesserung der Betriebsfähigkeit von Software, sondern muss sich mit ganz konkreten Ereignissen im Betrieb von Services befassen, die zudem oftmals nicht mit der Taktung einer agilen Entwicklung vereinbar sind.
Aber sehen wir uns die wichtigsten ITIL-Prozesse in diesem Bereich und ihren Einfluß auf DevOps doch einmal einzeln an.
Event Management
Um die vereinbarte Qualität eines Service aufrecht zu erhalten, muss man seinen Zustand zuerst einmal überwachen und sich bei Abweichungen darüber informieren (lassen). Wir haben uns also um Folgendes zu kümmmern:
- Wir brauchen Festlegungen (oder SLAs), die bestimmen, was ein normales, akzeptiertes Verhalten und was eine Abweichung davon ist
- Es müssen kritische Stellen in der (Cloud-)Infrastruktur und in der Software (heutzutage üblicherweise Microservices) überwacht werden
- Und wir müssen daraus resultierende Alarme oder auch nur Informationen über negative Entwicklungen an die richtige Stelle bringen, damit sie auch bemerkt werden
Fangen wir mit dem letzten Punkt an: Die richtige Stelle für „echte“ Störungen im Sinne einer SLA-Verletzung ist das Incident Management. Der einfachste Fall für Operations ist immer, wenn ein Service überhaupt nicht oder mit merkbaren Einschränkungen läuft, dann melden sich in der Regel die Benutzer von selbst. Mit der Verbindung zwischen dem Incident Management und dem DevOps-Team beschäftigen wir uns später, nehmen wir uns zunächst den allgemeinen Zustand des Service und die negativen Entwicklungen vor. Es sind die schleichenden Fehler und Behinderungen die uns Sorgen machen müssen. Fehler, die gerne einmal von den Developern durch einen Retry übertüncht werden, weil man es ja mit einem stateless service zu tun hat und es beim zweiten oder dritten Mal dann schon klappen wird. Am Ende kann man dann immer noch eine Exception schmeissen, wenn es gar nicht geklappt hat. Was das unter Umständen für die Performance eines solchen Systems bedeutet, brauche ich hier nicht zu erläutern.
An einem agil entwickelten Service werden laufend Änderungen vorgenommen, die sich unter Umständen negativ auf die Performance und Stabilität auswirken können, was leider oftmals erst im Betrieb sichtbar wird. Es hat sich bewährt, im DevOps-Team die Rolle eines „Health Ministers“ zu etablieren, dessen Aufgabe es ist, den Service im laufenden Betrieb regelmäßig zu beobachten, Fehlern nachzugehen, diese zu analysieren und gegebenenfalls Maßnahmen zu Beseitigung zu veranlassen. Mit dieser besonderen Rolle wird den Developern auch der Rücken freigehalten, damit sie sich auf die Entwicklung der Anwendung konzentrieren können. In gewisser Weise ist es eine Art permanentes, operatives Problem Management. Die Werkzeuge die dem Health Minister dazu zur Verfügung stehen, sind in modernen Cloud-Umgebungen vielfältig, es gibt dort sehr effiziente Tools zur Erzeugung und Auswertung von Logs, die dann z.B. in Form von Dashboards einen Gesamtüberblick über den Zustand des Service geben können.
Hier kommen wir zum zweiten Punkt der Liste: Damit der Health Minister seinen Aufgaben optimal nachkommen kann, muss er viel über die Architektur der Infrastruktur und der Anwendung sowie über die inneren Abläufe des Service wissen. Es genügt nicht, wie früher bei den klassischen Anwendungen, CPU-Verbrauch, Hauptspeicher und Plattenplatz zu überwachen, zumal diese Ressourcen in einer Cloud-Umgebung ohnehin meist automatisch skalieren und in den seltestens Fällen jemals an ihre Grenzen stoßen. Sicher müssen diese Parameter auch überwacht werden, schon um zu vermeiden, dass die Kosten für die Cloud-Infrastruktur durch Fehler aus dem Ruder laufen.
Vielmehr muss der Health Minister die Abläufe zwischen den komplexen Microservices verstehen, um z.B. Engpässe identifizieren zu können. Deshalb ist es unabdingbar, dass er ein tiefes Verständnis für die Anwendung entwickelt, was er am besten als integriertes Mitglied des DevOps-Teams kann. Andererseits ist er angehalten, andere Interessen als das Developer-Team zu verfolgen – nämlich insbesondere Servicequalität -, dem es in erster Linie um die Funktionalität des Service gehen muss.