Trifft ein traditioneller Servicedesk auf DevOps, ergeben sich Herausforderungen für den Support, die nicht zuletzt auf der massiv erhöhten Geschwindigkeit von Entwicklung und Deployment im IT-Betrieb begründet sind. Will sich ein Servicedesk auf die rasante Entwicklung von Services und Produkten einstellen und dennoch nach ITIL arbeiten, sind neue Ansätze und Organisationsformen gefragt. Dazu zählen nicht zuletzt Automatisierung und künstliche Intelligenz.Der klassische, personenbesetzte Servicedesk ist in der Idealvorstellung so aufgestellt, dass ein empathischer Personenkreis – der einen guten Überblick über die Organisation hat – kundenorientiert die Anfragen für Incidents und Service-Request entgegennimmt. Diese bewertet, analysiert, koordiniert der Support und löst sie idealerweise auch gleich. Um dieses Ziel schrittweise zu erreichen, gibt es notwendige Voraussetzungen. Eine davon ist ein Servicekatalog, der einen Überblick über alle Standardservices liefert. Diesen aktualisieren die Verantwortlichen regelmäßig mit den neuen Entwicklungen und Portfoliobewertungen. Die Services und Produkte benötigen eine eindeutige Kategorisierung beziehungsweise Klassifizierung sowie eine Zuordnung zu Servicegruppen, bevor sie live gehen.
Das funktioniert jedoch nur, wenn die Zusammenarbeit mit allen beteiligten Stakeholdern und Servicegruppen, Entwicklern, dem Betrieb, dem Servicedesk und auch den Kunden mit einem gelebten Continual-Improvement-Konzept (CIP) unterstützt wird. Gleichzeitig hat sich die Entwicklung beschleunigt, weshalb ein automatisiertes Servicedesk-Handling durch Tools für Standardabläufe eine unabdingbare Voraussetzung für ein weiterhin koordiniertes, kontrolliertes, effektives und effizientes IT-Servicemanagement ist. ITIL gibt dazu reichlich Anregungen hinsichtlich der sinnvollerweise zu beachtenden Aspekte.
Servicedesk neu aufstellen
Das Umsetzen dieses integrativen Ansatzes macht die frühzeitige Einbindung der Stakeholder in die Portfoliostrategie und die Entwicklung der Services notwendig. Durch das Etablieren einer ITIL-Steuerungsgruppe ist der CIP-Gedanke umsetzbar. So entsteht ein Adressat und eine koordinierte Dokumentations-, Bewertungs- und Supporteinheit, die Ideen, Anträge, Reklamationen im Kontext mit nötigen Anpassungen an sich ändernde Geschäftsanforderungen steuert, bei der Umsetzung begleitet und auch einen Nutzenrevisionsansatz für Verbesserungen einrichten kann.
Die breichsübergreifende Koordination ist fast immer mit der Neuorientierung der organisatorischen Struktur verknüpft. Nicht jeder Mitarbeiter heißt dies sofort willkommen. Der Aufbau einer ETC (Enterprise Transition Community nach Scrum) für die organisatorischen Änderungen kann zusammen mit der eher technisch ausgerichteten ITIL-Steuerungsgruppe die nötigen Transformationsprozesse begleiten. Die klassische Silostruktur müssen Unternehmen aufbrechen – nicht als Big Bang, sondern als ein zielorientiertes Kooperationsmodell. Ein hybrides Organisationsmodell erleichtert diese Übergänge in eine wertorientierte Ablauforganisation, ohne den Ansatz der Aufbauorganisation auszuhebeln. Dies würde idealerweise beim DevOps-Ansatz zu sogenannten Systemteams führen, die diese Aufgaben übernehmen.
Das funktioniert jedoch nur, wenn die Zusammenarbeit mit allen beteiligten Stakeholdern und Servicegruppen, Entwicklern, dem Betrieb, dem Servicedesk und auch den Kunden mit einem gelebten Continual-Improvement-Konzept (CIP) unterstützt wird. Gleichzeitig hat sich die Entwicklung beschleunigt, weshalb ein automatisiertes Servicedesk-Handling durch Tools für Standardabläufe eine unabdingbare Voraussetzung für ein weiterhin koordiniertes, kontrolliertes, effektives und effizientes IT-Servicemanagement ist. ITIL gibt dazu reichlich Anregungen hinsichtlich der sinnvollerweise zu beachtenden Aspekte.
Servicedesk neu aufstellen
Das Umsetzen dieses integrativen Ansatzes macht die frühzeitige Einbindung der Stakeholder in die Portfoliostrategie und die Entwicklung der Services notwendig. Durch das Etablieren einer ITIL-Steuerungsgruppe ist der CIP-Gedanke umsetzbar. So entsteht ein Adressat und eine koordinierte Dokumentations-, Bewertungs- und Supporteinheit, die Ideen, Anträge, Reklamationen im Kontext mit nötigen Anpassungen an sich ändernde Geschäftsanforderungen steuert, bei der Umsetzung begleitet und auch einen Nutzenrevisionsansatz für Verbesserungen einrichten kann.
Die breichsübergreifende Koordination ist fast immer mit der Neuorientierung der organisatorischen Struktur verknüpft. Nicht jeder Mitarbeiter heißt dies sofort willkommen. Der Aufbau einer ETC (Enterprise Transition Community nach Scrum) für die organisatorischen Änderungen kann zusammen mit der eher technisch ausgerichteten ITIL-Steuerungsgruppe die nötigen Transformationsprozesse begleiten. Die klassische Silostruktur müssen Unternehmen aufbrechen – nicht als Big Bang, sondern als ein zielorientiertes Kooperationsmodell. Ein hybrides Organisationsmodell erleichtert diese Übergänge in eine wertorientierte Ablauforganisation, ohne den Ansatz der Aufbauorganisation auszuhebeln. Dies würde idealerweise beim DevOps-Ansatz zu sogenannten Systemteams führen, die diese Aufgaben übernehmen.
Aus der technischen Betrachtung setzt ein erfolgreiches DevOps auf intelligente Workflows, die durch effektive, optimierte und automatisierte Prozessabläufe bestimmt sind. Lean Thinking kann dabei helfen, nicht benötigte Schritte zu eliminieren. Das Toyota-3M-Modell wäre auch ein möglicher Weg, um nach Muda (Verschwendung), Muri (Unausgeglichenheit) und Mura (Überbeanspruchung) die Optimierung der benötigten Arbeiten zu erreichen.
Die standardisierten Anfragen und Aufgaben des Servicedesks lassen sich gezielt durch Incident- und Problemmanagement-Prozesse so unterstützen, dass Standards und Workarounds in den ITSM-Tools und Knowledge-Tools zur Verfü- gung stehen und gepflegt werden. So wird der Support auch gezielt entlastet und dessen Mitarbeiter haben mehr Zeit, konkret auf die Wünsche der Anwender einzugehen, Anforderungen besser zu verstehen und so wertvolle Inputs zur Wertschöpfungskette beizutragen. Sie können so sicherstellen, dass Sie Probleme effektiv und effizient im Sinne des Anwenders lösen.
AIOps unterstützt Supporter
Die Prognosefähigkeit und Qualität von Artificial Intelligence for IT Operations (AIOps) als Kombination von Erkennen, Auswerten, Prognosen, Trends und Analysen verringert erheblich den Zeitaufwand des Helpdesks für das Erkennen, Priorisieren, Kategorisieren, Diagnostizieren und Lösen von Incidents. Die gewonnene Zeit steht dann für wertschöpfende Aufgaben zur Verfügung.
Für AIOps sollten IT-Verantwortliche auf einer skalierbaren Datenplattform Daten aus diversen Repositories zusammenführen. Dazu zählen beispielsweise Events, Alarme, Incidents, Infrastruktur und Logs. So sind mithilfe des konsolidierten Monitorings und Unterstützung von KI und Statistik frühzeitig Abweichungen und Prognosen erkennbar, was erlaubt, proaktiv gegen diese anzusteuern. Diese Tools sind heute notwendig, um große komplexe Datenmengen zu managen, die oft auch noch sehr verteilt sind.
Kein Administrator ist zeitlich und toolmäßig in der Lage, diese unendlichen Daten ständig zu sichten und zu interpretieren. Dies ist in derzeitigen Arbeitszeitmodellen und hinsichtlich der Ansprüche der Anwender nicht darstellbar. Eine KI kann dieses komplexe Verhalten und Abweichungen erlernen, analysieren und auf dieser Basis alle relevanten Datenströme erkennen, nach vorgegebenen Kriterienkatalogen (Next-Level-of-Knowledgebase) interpretieren und so den IT-Verantwortlichen sinnvoll in der Arbeit unterstützen.
Eine weitere Voraussetzung für ein erfolgreiches KI-Training und somit eine effiziente und effektive Unterstützung der Servicegruppen sind qualifizierte Textvorlagen, denn das sichere Erkennen von Mustern und Zuordnungen gehört zu den Aufgaben guter Tools und muss zuverlässig funktionieren. Die Arbeit des Administrators verlagert sich von den vielen fließbandartigen Routineaufgaben hin zu den wichtigen wertschöpfenden Tätigkeiten. Diese Interpretation nimmt auch den DevOps-Gedanken "automate everything you can" auf, sodass das Hauptaugenmerk auf dem Core und dem Context liegt. Core steht für das, was der Kunde braucht – wofür er zahlt – , und Context beschreibt, was den Anwender nicht direkt interessiert, aber nötig ist, um Services beziehungsweise Produkte zu erhalten.
Supportkonzept für DevOps
Wie der Name DevOps bereits impliziert, ist für eine erfolgreiche Implementierung eines Produkt-Lifecycles auch das Zusammenspiel zwischen Entwicklung, allen dazwischen beteiligten Stellen bis hin zur Produktion essentiell. Hierzu gehört nicht nur eine übliche Kommunikation von Dev zu Ops, sondern auch das stetige Feedback zu den vorausgehenden Bereichen eines Deployments. Früher hat der Entwickler nur bedingt erfahren, wie es um die nachfolgenden Bereiche und das Ausrollen steht, sodass sich dieses Wissens oft nur sehr langsam und meist über Release-Zyklen und Incidents verbreitete. DevOps setzt hier auf hohe Transparenz und Kommunikationsebenen, die unter anderem auch den Servicedesk betreffen.
Grundsätzlich ist ein sanfter Paradigmenwechsel durch Zusammenschluss in der Ablauforganisation sinnvoll – das zuvor beschriebene hybride Organisationsmodell. Die daraus resultierenden Systemteams (in der DevOps-Welt existieren hierfür sehr viele Namen mit einer ähnlichen Bezeichnung, zum Beispiel auch SRE-Team oder Produktteam) sind in der Ablauforganisation produktbezogen aufgestellt. Je nach Produkt (idealerweise Microservice) werden von Entwicklung, Qualitätssicherung, Automatisierung, Monitoring, Security, Administration und so weiter unter Einbeziehung von Plattformteams passende Rollen zusammengeschlossen, die den Lifecycle innerhalb der vom Management definierten Toleranzen gemeinsam verantworten. Ein Entwickler sollte sich auf das Entwickeln konzentrieren können, aber auch den Administrator zur Seite haben, sodass er ein auch zur Produktion passendes Produkt erzeugt. Umgekehrt hat der Administrator beim Deployment den Entwickler beim Go-Live dabei, sodass sich zusammen sofort etwaige Anforderungen identifizieren und eventuell gleich lösen lassen.
Hierfür sind geeignete Standards in Form von Services erforderlich, damit sich auch alle Systemteam-Rollen gleichartig über das ihnen zugeordnete Produkt/Service informieren und passend reagieren können. Die Entscheidung, ob im Feature-Modus (Entwicklung einer neuen Funktionalität) oder im Incident-Modus (Optimierung der bestehenden Funktionen oder Fehlerbehebung) gearbeitet wird, trifft das Systemteam innerhalb des eigenen Verantwortungsbereichs basierend auf den vorliegenden Informationen. Diese Informationen sollten idealerweise auch für den Servicedesk und andere Servicegruppen in geeigneten Wissensdatenbanken oder in Tools integriert verfügbar sein. Das jeweilige Systemteam sollte als Ablauforganisationseinheit auch direkt über den Servicedesk adressiert werden können.
Da ein Systemteam aus diversen Rollen besteht, die einer definierten Anzahl von Mitarbeitern zugeordnet werden, ist eine Mehrfachzuordnung eines Mitarbeiters zu mehreren Produkten notwendig. In einer hybriden Organisation sollte das jeweilige Team hierfür auf eine gleichmäßige Auslastung achten. Dadurch kann sich jede Rolle auf ihre eigentliche Aufgaben und die notwendige Produktsicht beschränken, was dann auch vollständig die Lücken kompensiert, die sich in einer reinen Aufbauorganisation finden, in der jeder Entwickler selbst das Automatisieren, die Datenbereitstellung, die Qualitätssicherung und Weiteres verantworten muss.
Mit GitOps zur Automatisierung
Diese Services sind für die verschiedenen Umgebungen und Dienste stetig weiterzuentwickeln und auch so weit als möglich zu automatisieren, was dann auch in passgenauen Self-Services mündet. Dabei ist bei der Übergabe in die Produktion die Compliance zu beachten, was wiederum ein Einbinden des Release-Managements erfordert. Dabei ist der GitOps-Ansatz sehr dienlich, denn er definiert einen "Single Point of Truth" (meist im Git – daher der Name), wohin die Entwicklung neuen Code liefert und diesen mit der Produktion nach der Freigabe synchronisiert. Die Synchronisation erfolgt hierbei bidirektional, das heißt, sowohl neue freigegebene Lieferungen aus der CI-Pipeline wie auch Änderungen in der Test-/Referenz- oder Produktionsumgebung (etwa Erweiterung oder Ausfälle) holen sich den IST-Zustand automatisch aus diesem Single Point of Truth.
Letztendlich basieren Informationen für die erfolgreiche Implementierung einer weitestgehend automatischen CI/CD-Pipeline und GitOps auch auf einem passgenauen Monitoring und der Überwachung von SLAs. Auch diese Informationen lassen sich automatisiert über ein Logmanagement mit Alerting versehen und über den Servicedesk an die Systemteams kommunizieren. Idealerweise erzeugen geeignete Tools eine eigenständige Problemlösung in Form eines Alerts und dokumentieren diese im Servicedesk. Hierbei ist wie bei jeder Automatisierung ein Vorsichtsprinzip einzuführen, das nicht autorisierte Maßnahmen vermeidet.
Fazit
Im ersten Teil haben wir wertschöpfende Tätigkeiten und die Zusammenarbeit der gesamten Ressourcen im IT-Servicemanagement betrachtet. Der zweite Teil aus der DevOps-Perspektive lieferte Ihnen Erfahrungen und Empfehlungen zum Transformationsprozess hin zur neuen Arbeitsweise, die einen kulturellen Wandel mit tiefgreifender Auswirkungen auf Teams und das ganze Unternehmen mit sich bringt. Dabei sollten Sie sich unbedingt mit GitOps beschäftigen, das wir aus Platzmangel nur im Ansatz betrachtet haben.
Der Mensch steht im Mittelpunkt des kulturellen Wandels und Tools helfen dabei immer besser, Aufgaben zu kontrollieren. Die Automation über GitOps unterstützt diese Arbeitsaufteilung mit dem ständig aktiven Abgleichmechanismus, der den Sollzustand der Produktionsumgebung definiert.