Ist DevOps mit ITIL kompatibel?

In meiner Karriere war ich sowohl Softwareentwickler als auch ITIL- Praktiker in einer operativen Rolle. Daher war DevOps für mich ein natürlicher Fortschritt.
Ich hatte jedoch immer mit der hochspezialisierten Sprache zu kämpfen, die ITIL einführt, und habe das "Entwicklerfreundlich" genug gemacht, um die Entwickler nicht völlig auszuschalten.

ITIL ist ein international anerkanntes IT-Service-Management-Framework, das über 30 Jahre hinweg als eine Reihe von Verfahren entwickelt wurde, die nachweislich die Betriebsstabilität und -reife eines Unternehmens fördern.

Ist DevOps wirklich mit ITIL kompatibel, oder müssen wir im Wesentlichen den Geist von ITIL aufgreifen und in eine Sprache "übersetzen", die von Entwicklungsteams besser verstanden wird:

• Incident & Problem Management → Produktionsfehler, Bugs oder Probleme
• Change & Release Management → Kontinuierliche Lieferung
• Ereignisverwaltung → Protokollierung, Telemetrie, Instrumentierung und Alarmierung

Meiner Meinung nach geht die DevOps-Kultur mit einer Änderung der Methodik in Richtung agiles Prozessmanagement einher .
ITIL zielt stark auf einen klaren Formalismus des Prozesses und der Ergebnisse ab und ist daher besser an ein Wasserfallmodell angepasst .

Dies bedeutet nicht, dass ITIL nicht mit Devops kompatibel ist. In der Regel handelt es sich hierbei jedoch um zwei separate Prozesse mit unterschiedlichen Zeitplänen. Ich meine, dass die Aufnahme eines neuen Produkts in die ITIL-Referenz in der Regel verzögert wird, bis das Produkt / die Anwendung für eine Weile in der Produktion freigegeben wurde. Frühere Fallstricke und einige für die Integration von ITIL erforderliche Dokumentationen wurden durchgeführt und angepasst, nachdem das Produkt fertiggestellt wurde. " Leben".

Eines der Dinge in ITIL ist das Service-Design, von dem angenommen wird, dass es vor jeder Entwicklungsaufgabe definiert wird. Ein agiler Prozess wird / kann das Design in jeder Iteration überprüfen und den in einem ITIL-Prozess erforderlichen Formalismus brechen.

Das Hauptziel von ITIL besteht, wie Sie sagten, darin, ein Framework bereitzustellen, das sicherstellt, dass zwischen der Entwurfs- / Konzeptions- und Wartungsphase (Build / Run) nichts ausgelassen wird. In einer Devops-Kultur ist das gesamte Team langfristig für alle Phasen verantwortlich, weshalb der Formalismus reduziert wird.

Das heißt nicht, dass wir ITIL vergessen müssen, die Grundprinzipien sind absolut gut und sollten meiner Meinung nach als Checkliste verwendet werden, um den anfänglichen Rückstand eines Produkts aufzubauen. Es ist nur so, dass das Befolgen des ITIL-Prinzips mit all seinen Formalismen gegen das Ziel einer schnellen iterativen Softwareentwicklung verstößt und manchmal nicht anwendbar ist, da weniger Informationen zwischen den Teams übertragen werden müssen, da die Aufgaben von demselben Team ausgeführt werden .

Ich bin ITIL-zertifiziert (obwohl es eine Weile her ist). Ich stimme Tensibai zu: ITIL und DevOps sind nicht inkompatibel , aber das macht sie nicht unbedingt zu guten Freunden.

Es kann argumentiert werden, dass die Prozesse in ITIL auf irgendeine Weise stattfinden müssen, insbesondere für größere Organisationen. Die erfolgreiche Integration von DevOps-Praktiken, in denen ITIL bereits praktiziert wird, erfordert sorgfältige Planung, Kommunikation und Ausführung. Andererseits gilt das für jede DevOps-Transformation.

Für eine "Greenfield" -Transformation, bei der weder ITIL noch DevOps vorhanden sind, würde ich eine Kombination aus beiden erstellen, wobei die von Ihnen beschriebene "zugeordnete" Terminologie verwendet wird. Solange sich jeder in der Organisation auf derselben Seite befindet und dieselbe Sprache verwendet, können ITIL und DevOps zusammen einen Mehrwert schaffen.

Ich mochte die Antworten des IT-Skeptikers auf eine Episode von DevOpsCafe.org. Wenn ich mich richtig erinnere, ist seine Meinung , dass es nur sehr wenige Konflikte gibt, wenn Sie ITIL wirklich verstehen. Dass die meisten ITIL-Richtlinien sehr allgemein sind und dass die Konflikte größtenteils zwischen einigen Implementierungen von ITIL und nicht hinter der eigentlichen Spezifikation liegen.