DevOps vs. ITIL: Welcher Ansatz ist für dein Team geeignet?

1. DevOps kann ITIL ersetzen

"Wir setzen ITIL nicht mehr ein – wir sind jetzt ein DevOps-Laden!" Wenn du schon länger im IT-Bereich arbeitest, hast du diese Aussage vermutlich schon einmal gehört.

Das Problem ist, dass das einfach nicht stimmt. Denn auch wenn IT-Abteilungen vielleicht weniger ITIL-Schulungen durchführen und Prozesssilos auflösen, müssen sie immer noch gewisse Aspekte des Servicemanagements ausführen: Betrieb, Support, Governance, Kostenrechnung. Dies sind wesentliche Geschäftsfunktionen. DevOps bietet keine Prozessrichtlinien, wie es ITIL tut. Mit großer Wahrscheinlichkeit befolgen also selbst Unternehmen, die lautstark verkünden, dass sie jetzt nur noch DevOps betreiben, immer noch einige ITIL-Prozesse oder -Prinzipien.

2. DevOps = kontinuierliche Entwicklung, Integration und automatisierte Bereitstellung

DevOps beinhaltet kontinuierliche Entwicklung, Integration und automatisierte Bereitstellung, doch das ist bei Weitem nicht alles, was das Konzept zu bieten hat – und stellt nicht unbedingt den Kern des Verfahrens dar. In erster Linie geht es bei DevOps einfach darum, alte Trennlinien zu überwinden und mit gegenseitigem Respekt und ohne Schuldzuweisungen zusammenzuarbeiten.

Im Mittelpunkt stehen also Zusammenarbeit, gemeinsame Ziele, gegenseitiger Respekt und das Ende gegenseitiger Schuldzuweisungen.

Dieser kollaborative Ansatz kann zur Verbesserung verschiedenster Geschäftskennzahlen führen, selbst wenn dein Team noch nicht vollständig auf eine automatisierte Bereitstellung oder kontinuierliche Entwicklung umgestellt hat.

3. ITIL/ITSM ist immer dokumentationslastig und umfasst schwerfällige Prozesse, die Teams verlangsamen

ITIL wird viel zu oft fälschlicherweise als Regelwerk und nicht als Anleitung aufgefasst, die Raum für Interpretationen lässt.

In Wahrheit hat dein Team großen Gestaltungsspielraum mit ITIL. Wenn ein Eindruck von Starrheit entsteht, liegt das an einer Entscheidung, die einmal getroffen wurde. Und diese Entscheidung kann geändert werden.

ITIL sollte am besten als Ausgangspunkt für das Verständnis komplexer IT-Prozesse gesehen werden, die in den meisten Unternehmen abzuwickeln sind. Es ist eine Art Fahrplan, ein Leitfaden. Es sollte nicht als einziger Lösungweg verstanden werden, sondern den erforderlichen Kontext liefern, um Entscheidungen zu treffen und unsere IT-Teams so effektiv und effizient wie möglich zu managen.

Wenn ITIL als Regelwerk angesehen wird, folgt normalerweise ein Stapel von Dokumenten und Bürokratie. Wenn ITIL jedoch als Richtlinie verwendet wird, können Abläufe damit rationalisiert anstatt verlangsamt werden.

4. ITIL/ITSM ist nur für große Unternehmen geeignet

Es stimmt, dass große Unternehmen bei ITIL die Führung übernommen haben. Das bedeutet aber nicht, dass kleine Unternehmen nicht von den Leitlinien profitieren können. Unternehmen jeder Größe müssen wissen, wie sie mit Änderungsmanagement, größeren Vorfällen und Wissensmanagement umgehen können. Dies sind nur einige der grundlegenden Unternehmensaufgaben, für die ITIL eine Grundlage schafft.

Hippe Start-ups müssen irgendwann ihre IT-Teams organisieren, um skalieren zu können. Dasselbe gilt für mittelgroße Unternehmen. Sogar ein selbstfinanziertes App-Projekt, das zwei Personen umfasst, braucht einen Bereitschaftsplan und eine Strategie für das Vorfallmanagement. Andernfalls könnte ein einziger Ausfall das Ende bedeuten.

Beschleunigen neuer Releases mit DevOps

Der agile Ansatz von DevOps bietet Vorteile sowohl hinsichtlich Geschwindigkeit als auch beim Risikomanagement: Kleine, reguläre Releases durchlaufen die Entwicklung nicht nur schneller, sondern können bei Vorfällen auch leichter zurückgesetzt oder korrigiert werden.

Weniger IT-Servicedesk-Anrufe durch ITSM

Die ITSM-Best Practice für das Wissensmanagement beinhaltet, dass das IT-Team bereits während der Lösung von Problemen Dokumentation erstellt. Sowohl für interne als auch für externe Kunden werden dann Self-Service-Optionen angeboten, wodurch die Arbeitsbelastung des Servicedesks erheblich reduziert werden kann.

Vorbeugen von Incidents mit ITIL und DevOps

Durch die Kombination der bewährten Prozesse des Vorfallmanagements aus ITIL mit dem Fokus, den DevOps auf die Automatisierung von Prüfprozessen legt, um Post-Mortem-Analysen ohne Schuldzuweisungen durchzuführen und den You-build-it-you-run-it-Ansatz zu verfolgen, lassen sich Vorfälle reduzieren und verkürzen.

Analysieren von Incidents mit DevOps

Zu den wichtigsten Aspekten von DevOps gehört die Vermeidung von Schuldzuweisungen. Das bedeutet nicht, dass Entwickler keine Verantwortung für Fehler übernehmen. Vielmehr können sie ehrlich über diese Fehler sprechen und offenere Gespräche darüber führen, was schiefgelaufen ist – ohne Angst haben zu müssen, den Job zu verlieren.

Dieser kulturelle Wandel hilft Teams, Vorfällen schneller auf den Grund zu gehen und sich auf echte Lösungen zu konzentrieren, anstatt in einer Kette von Ereignissen, die zu einem Vorfall geführt haben, einen Hauptverantwortlichen ausfindig zu machen.

Mehr Klarheit für Kunden mit ITIL

Zu den ITIL-Best Practices gehören auch SLAs (Service Level Agreements). Diese zeigen auf, was du für ein Produkt oder einem Kunden gegenüber versprochen hast und was nicht. So wird für mehr Klarheit gesorgt und die Anzahl der Beschwerden reduziert.

Optimieren deiner Prozesse mit DevOps und ITIL

ITIL ist der De-Facto-Standard für IT-Prozesse. Das Framework existiert bereits seit geraumer Zeit und wurde an die sich ständig ändernden Anforderungen der Branche angepasst.

Wenn du deine eigenen Prozesse entwickelst, musst du das Rad nicht neu erfinden. ITIL bietet eine bewährte Orientierungshilfe.

Und überall dort, wo DevOps Verbesserungen einbringen kann, etwa mit Post-Mortem-Analysen ohne Schuldzuweisungen, mit Automatisierung, stärkerer Zusammenarbeit usw., können ITIL-Prozesse noch weiter optimiert werden.