ITIL vs. DevOps: Konkurrenz oder Ergänzung?

Es scheint den Menschen schwer zu fallen, zu entscheiden, was DevOps überhaupt ist, geschweige denn, wie (oder ob) es im Vergleich zu einer stark strukturierten Methodik wie ITIL abschneidet. Um die großen Fragen vorab zu beantworten: Nein, Sie müssen sich nicht zwischen DevOps und ITIL entscheiden; Nein, DevOps ersetzt ITIL nicht oder umgekehrt; nein, DevOps wird nicht alle Probleme einer ITIL-Umgebung lösen, und nein, DevOps wird nicht durch die Implementierung von ITIL perfektioniert. Der Aufbau guter IT-Prozesse ist jedoch der Schlüssel zur Ausfallsicherheit, und UpGuard kann dabei helfen.

Während DevOps im Wesentlichen eine Philosophie ist, eine Perspektive darauf, wie die Probleme angegangen werden können, mit denen Entwicklungs- und Betriebsteams konfrontiert sind, die (nicht) zusammenarbeiten, ist ITIL ein kodifiziertes System des Information Technology Service Management (ITSM), das entwickelt wurde, um die IT besser in die Geschäftsanforderungen und -strategien zu integrieren. Obwohl es also einige Überschneidungen gibt, adressieren diese beiden Systeme unterschiedliche Kernprobleme. Der beste Weg, sich ihnen zu nähern, ist über das Problem, das Sie zu lösen versuchen. Bevor Sie eines der beiden implementieren können, müssen Sie eine Bestandsaufnahme dessen machen, was Sie haben, und einige Zeit damit verbringen, darüber nachzudenken, was Sie brauchen. Wir werden uns einige gängige Szenarien ansehen, die Menschen zu ITIL und/oder DevOps führen, und wie jedes System helfen kann. Bevor wir sie vergleichen, lassen Sie uns zunächst DevOps und ITIL an und für sich definieren.

DevOps (Englisch)

DevOps begann in einer Softwareentwicklungsumgebung, und als solche konzentrieren sich viele seiner Methoden und Tools auf die Verbesserung der Softwarebereitstellung. Continuous Integration (CI) und Continuous Delivery (CD) transformierten den Bereitstellungsprozess, während Continuous Monitoring nahezu in Echtzeit Einblick in die gesamte Infrastruktur bietet. Aber bei DevOps geht es um mehr als agile Softwareentwicklung.

Es schadet nie, ein wenig Struktur in die eigenen Angelegenheiten zu bringen, insbesondere wenn es um IT-Geschäftsprozesse und -Assets geht.

Die Hybridisierung von Entwickler- und Betreiberaufgaben hat sich auf alle Aspekte der IT ausgewirkt, einfach weil der Austausch von Informationen und die Zusammenarbeit im Hinblick auf Geschäftsziele produktiver sind und ein besseres Arbeitsumfeld schaffen als die traditionelle Wissensabgrenzung. Ein Grund, warum DevOps gemeinhin als Philosophie beschrieben wird, ist, dass die Transformation eines Unternehmens mit seinen Ideen einen Schritt zurücktreten und einige der grundlegendsten Annahmen der IT-Arbeit neu bewerten erfordert.

Anstatt spezialisierte Personen zu haben, die sich um einen einzelnen Teil des Gesamtsystems kümmern und davon ausgehen (oder sich keine Gedanken darüber machen, ob) alles zusammenarbeitet, versuchen DevOps-Teams, den IT-Prozess ganzheitlich zu betrachten und ihre individuelle Arbeit so zu modifizieren, dass sie den Geschäftsanforderungen am besten entsprechen. Das bedeutet, dass Programmierer Systeme lernen, Betriebsmitarbeiter, die das Programmieren lernen, jeder Sicherheit und Projektmanagement/Zusammenarbeit lernt. Aber das ist mehr als traditionelles Cross-Training, denn bei DevOps geht es darum, Kernpraktiken mit interdisziplinären Ideen zu ändern, wie z. B. Infrastructure-as-Code, bei dem fragile Snowflake-Server durch wiederholbare, skalierbare Bereitstellungsprozesse ersetzt werden, die auf Entwicklungs-, Test-, QA- und Produktionsumgebungen abgestimmt werden können.

ITIL

Im Gegensatz zu DevOps handelt es sich bei ITIL um eine hochstrukturierte Methodik, die darauf ausgelegt ist, die Effizienz zu steigern und Statistiken für den IT-Betrieb bereitzustellen. ITIL ist eine Art von ITSM und konzentriert sich als solche in erster Linie auf Protokolle zur Implementierung, Verwaltung und Verbesserung von IT-Services für das Unternehmen und/oder die Kunden.

Da ITIL so stark strukturiert ist, gibt es viele spezifische Begriffe und Konzepte, die gelernt werden müssen, um es effektiv nutzen zu können. Seit 2013 ist ITIL geistiges Eigentum von AXELOS, das ITIL-Materialien lizenziert, Zertifizierungen anbietet und das ITIL-Framework aktualisiert. Das bedeutet, dass ITIL ein proprietäres System ist, das von einem privaten, gewinnorientierten Unternehmen verwaltet wird, und nicht von der amorphen, besitzerlosen Philosophie von DevOps.

Die Komplexität und Strenge von ITIL führt zu einem gewissen Overhead für IT-Abteilungen, da ITIL nur so gut funktioniert, wie es implementiert ist. Dies bedeutet eine erhebliche Investition von Zeit und Geld in den Aufbau eines ITIL-Teams. ITIL ging DevOps voraus, daher gibt es offensichtlich einige Bereiche, in denen ITIL die Anforderungen einiger Unternehmen noch nicht erfüllte. Schauen wir uns einige gängige Szenarien an und wie DevOps und ITIL dabei helfen können.

Der Softwarebereitstellungsprozess muss überarbeitet werden

Problem: Die hohen Anforderungen an Software erfordern eine deutlich schnellere Bearbeitung von Fixes und Updates sowie die Integration von Tests und Qualitätssicherung in den Entwicklungsprozess. Mit den traditionellen Methoden der Bereitstellung können wir nicht mit dem Markt Schritt halten.

DevOps: Die Softwarebereitstellung ist das Brot und die Butter von DevOps. Von der Toolchain bis zur Philosophie konzentriert sich DevOps speziell auf diesen Prozess, obwohl es sich darüber hinaus auf die allgemeine IT ausgeweitet hat. Die leistungsstarke Automatisierung eines Tools wie Puppet oder Chef zusammen mit einem Konfigurationsüberwachungs- und Testtool wie UpGuard hilft dabei, standardisierte Umgebungen zwischen Entwicklung und Produktion zu erstellen und zu pflegen.

ITIL: ITIL hat ein sehr spezifisches Framework für die Bereitstellung von Software und konzentriert sich mehr auf die Integration des Bereitstellungsprozesses in andere Geschäftsprozesse, indem Stakeholder definiert und Protokolle festgelegt werden. Dies ergänzt die DevOps-Seite gut, denn während DevOps allgemeine Prinzipien hat, hat ITIL detaillierte Richtlinien, die zu befolgen sind.

Lösung: DevOps ist für diesen Prozess von entscheidender Bedeutung, während ITIL geeignet ist, aber nicht erforderlich ist. ITIL allein würde jedoch viele der Innovationen verpassen, die DevOps mit sich bringt.

Wissenssilos in der IT führen zu Engpässen bei Projekten und senken die Moral

Problem: Systemadministratoren kennen die Systeme, Entwickler kennen die Software, Netzwerkadministratoren kennen Netzwerke, aber dieses Wissen ist innerhalb eines Abschnitts (oder einer Einzelperson) isoliert und Informationen werden selten geteilt, wobei immer dann mit dem Finger auf andere gezeigt wird, wenn es ein Problem gibt.

DevOps: Neben der Softwarebereitstellung war das Aufbrechen von IT-Silos einer der Hauptpunkte der DevOps-Bewegung. Jeder, der schon einmal in der IT gearbeitet hat, weiß, wie schwierig ein Wissenssilo sein kann. DevOps-Praktiker verwenden oft das Wort Empathie, denn sich in die Lage einer Person zu versetzen und zu versuchen, die getroffenen Entscheidungen zu verstehen, ist der Schlüssel zur Zusammenarbeit. Tools wie Slack oder ein Kanban-Board können dabei helfen, Teams in Verbindung zu halten und laufende Arbeiten zu visualisieren.

ITIL: Technisch gesehen kann ITIL bei der Wissenssilobildung helfen, denn wenn sich jeder an die strenge Methodik hält, sollte alles dokumentiert werden. Aber in der Praxis hilft ITIL möglicherweise überhaupt nicht bei der Wissenssilobildung und kann sogar zusätzliche Silos schaffen, wie z. B. "die Person, die über ITIL Bescheid weiß. ”

Lösung: Bei DevOps geht es schon beim Namen darum, ehemals ungleiche Teams zusammenzubringen. Wenn Wissenssilos Ihr Problem sind, ist ein DevOps-Ansatz möglicherweise die beste Wahl, um sie aufzubrechen, da er sich auf den menschlichen Aspekt konzentriert, der eine große Rolle spielt, warum Wissen geteilt wird und warum nicht. Das ITIL-Framework, insbesondere wenn es sich um etwas handelt, das Sie bereits im Einsatz haben, kann bei der Regulierung von Protokollen helfen, sollte aber nicht als Ersatz für die Ideen und Tools angesehen werden, die DevOps auf den Tisch bringt.

Ich weiß nicht, welches Problem ich zu lösen versuche, aber ich höre immer wieder von DevOps/ITIL

Problem: Sie haben viel über DevOps, ITIL und andere Systeme gehört, die IT-Abteilungen neu beleben oder zumindest in der Tech-Welt für viel Aufsehen sorgen, und Sie möchten wissen, ob und wie es Ihrer Umgebung helfen könnte.

Lösung: Seien Sie vorsichtig, wenn Sie Schlagworten und Himmelsversprechungen zum Opfer fallen. Ein CTO nimmt vielleicht an einer Konferenz teil, auf der jemand DevOps erwähnt, und geht zurück zu seinem Team und sagt: "Lass uns DevOps machen", ohne wirklich zu wissen, was das bedeutet. Eine unachtsame Implementierung einer Methodik schafft mehr Probleme, als sie löst, und mehr Arbeit, als sie reduziert. Auf der anderen Seite bedeutet das Wissen genug, um die Frage zu stellen, dass das Bewusstsein für einen neuen Weg existiert. Aber die Vielfalt der Informationen kann überwältigend sein, besonders für jemanden, der neu in das Thema einsteigt. Anstatt zu versuchen, sich mit ganzen Systemen auseinanderzusetzen, beginnen Sie mit den Problemen, die Sie haben, und den Zielen, die Sie erreichen möchten. Finden Sie dann heraus, wie DevOps und/oder ITIL helfen können.

Nachbereitung

Es macht nicht viel Sinn, zu versuchen, ITIL und DevOps in einem Vakuum zu vergleichen. Vergleichen Sie sie stattdessen auf der Grundlage des Problems, das Sie zu lösen versuchen, und konzentrieren Sie sich auf die greifbaren Vorteile, die Sie und Ihr Team aus jedem einzelnen ziehen würden. ITIL konzentriert sich auf Prozesse, Standardisierung und Metriken. DevOps fügt das menschliche Element hinzu und untersucht, wie Teams zusammenarbeiten können, um mehr als nur ihre individuellen Bemühungen zu erreichen. Die Chancen stehen gut, dass beide Methoden etwas zu bieten haben und Ihnen zumindest einen Ausgangspunkt geben, wie Sie Ihren Betrieb verbessern können. UpGuard validiert IT-Prozesse in der von Ihnen verwendeten Methodik. Fragen Sie sich nicht, ob Ihre Prozesse funktionieren. Visualisieren Sie sie.