Agil und ITIL - geht das?

«DevOps» nennt sich ein relativ junger Ansatz, der Anwendungsentwicklung (Development) und IT-Betrieb (Operations) enger zusammenbringen will – speziell bei Webanwendungen und agil geführten Projekten mit hohen Änderungsraten. Dieser Beitrag zeigt, wie das neue Konzept den bisherigen Standard für IT-Betriebe ergänzen und integrieren kann.

Quelle: Computerworld 3/2014, www.computerworld.ch

Eine der grossen Herausforderungen jeder IT-Organisation ist die (durch die komplexen Technologien fast zwangsläufige) Aufstellung in sogenannten funktionalen Silos. Die Datenbankadministratoren haben alle Hände damit voll, die Performance-Anforderungen der Kunden zu erfüllen – und wissen nicht, dass die Netzwerker eben eine neues Zonenkonzept eingeführt, die Security-Leute die Firewall neu aufgesetzt und die Systemadministratoren einen dringenden Patch eingespielt haben. Am Schluss läuft die Anwendung nicht richtig und das grosse Fingerzeigen beginnt.

Es war eines der Hauptziele von ITIL, diese Silos durch einheitliche Prozesse und Regeln aufzubrechen und so eine stabilere Betriebsumgebung zu erreichen. Nach mehr als 10 Jahren ITIL V2 und V3 steht fest, dass dies gelungen ist. Gerade die hier relevanten Prozesse Incident-, Problem-, Change- und Release-Management wurden inzwischen in sehr vielen IT-Betriebsorganisationen erfolgreich eingeführt. Allerdings gibt es in jeder IT-Abteilung immer noch zwei grosse Silos: Anwendungsentwicklung und IT-Betrieb. ITIL stellt nur Schnittstellen zur Anwendungsentwicklung zur Verfügung und verweist für den eigentlichen Entwicklungsprozess auf bestehende Best Practices wie CMMI, PRINCE2, TOGAF etc. Interessanterweise gibt es im ITIL-Lifecycle-Modul «Service Design» auch keinen Prozess für das Design von Services.

So geschieht es auch heute noch häufig, dass Software-Entwicklungsabteilungen am Freitagabend ein neues Release an den Betrieb übergeben mit der Bitte, diesen am Montag in Produktion zu nehmen. Vielerorts trennt ein tiefer Graben die Entwickler, die sich eher als Künstler verstehen und die Stabilität und Leistung der Infrastruktur einfach als Selbstverständlichkeit ansehen, und die «Schrauber», die sich täglich mit Abstürzen, Leistungsschwankungen und Security-Problemen herumschlagen müssen. Beide Seiten wissen wenig über die Arbeit der anderen Seite. Eine andere Ursache für die Spannungen sind auch die unterschiedlichen Zielsetzungen: Die Anwendungsentwicklung muss neue Funktionalitäten rasch liefern, während der IT-Betrieb vor allem für Stabilität, Leistung und Sicherheit zu sorgen hat.

Diese Situation verschärft sich mit neuen Methoden und Technologien noch. Agile Entwicklungsmethoden mit ihren kleinen, aber häufigeren Entwicklungsschritten («Sprints») stellen sehr hohe Anforderungen an Test-, Release- und Deployment-Management-Prozesse. In solchen Umgebungen reichen die üblichen zwei bis vier Releases pro Jahr bei Weitem nicht mehr. Neue Technologien wie Virtualisierung, Clustering, Loadbalancing oder Cloud (Infrastructure as a Service, Platform as a Service) erlauben hochflexibles Provisioning von Kapazitäten und ganzen Serverumgebungen auf Knopfdruck. Dies kann zu Inkompatibilitäten und Falschkonfigurationen führen. Es müssen also eine ganze Menge mehr Changes in einer potenziell labileren mgebung ausgeführt werden. Genau dies möchte das DevOps-Konzept adressieren.

Was ist DevOps?

DevOps ist mehr eine Bewegung als eine definierte Methode. Die Idee wurde von IT-Operations-Praktikern im Umfeld grosser Webanwendungen und unter dem Einfluss der agilen Entwicklungsmethode entwickelt. Das Konzept basiert auf folgenden fünf Grundideen:

1. Kommunikation: IT-Betrieb und IT-Entwicklung müssen mehr miteinander sprechen. Einerseits muss die Operations-Abteilung in allen Phasen eines Entwicklungsprojekts mitarbeiten, andererseits müssen die Entwickler die betrieblichen Aspekte ihrer Applikation verstehen und sich mit den Problemen auseinandersetzen.
2. Lean-IT-Konzepte als Grundlage: Wie die Schwestermethodik «Agile» bezieht DevOps Ideen aus der Lean-Management-Schule: Alle Dimensionen sollen berücksichtigt werden; es gilt der Grundsatz: «People over Process over Tools».
3. Continuous Delivery: In Anpassung an die agile Entwicklungsmethode werden die Einzelschritte der Service Transition so aufgetrennt, dass sich diese – nur lose gekoppelt – stetig ausführen lassen. Builds werden laufend erstellt, die Erfolg versprechenden ins Testing weitergegeben und, was dort besteht, unmittelbar ins Staging weitergereicht. Die Qualitätssicherung bestimmt, welche Release Packages in Produktion gehen. Das Monitoring sorgt für Feedback (vgl. Grafik).
4. Automation: Continuous Delivery ist ohne Automation nicht möglich. Tools für Versionskontrolle und Software-Konfiguration müssen integriert werden. Neue Lösungen (z.B. Chef oder Puppet) wurden eigens zu diesem Zweck entwickelt. Auch neue, einfache Scripting-Sprachen (wie Ruby) werden hier oft eingesetzt.
5. Infrastructure as Code: Techniken wie Virtualisierung und Cloud Computing abstrahieren die Anwendung immer mehr von der Hardware. Infrastruktur-Management wird zum reinen Software-Management, das durch Tools und Scripts «programmiert» werden kann. Um die Kontrolle darüber zu behalten, müssen auch diese Programme und Scripts unter die Versionskontrolle der Anwendungsentwicklung gestellt werden.

Was kann DevOps leisten?

Der neue Ansatz eignet sich vor allem für die Zusammenarbeit des IT-Betriebs mit agilen Projekten. Auch muss die Zahl der zu verarbeitenden Builds, Tests und Deployments relativ gross sein, damit sich der Automatisierungsaufwand lohnt. Beim Einsatz von Cloud-Diensten ist diese Herangehensweise sicherlich sinnvoll. Für kleinere Umgebungen, Legacy-Anwendungen und klassische COTS-Lösungen (Commercial off the shelf) lohnt sich der Einsatz kaum. DevOps wird heute vor allem in grossen Webumgebungen wie Google, Facebook oder Amazon angewendet. Allerdings muss sich jede Firma, die agile Methoden, Virtualisierung oder Cloud-Services einzusetzen gedenkt, über die neuen Anforderungen an die Service Transition Gedanken machen.

Was kann ITIL beitragen?

ITIL ist und bleibt der Standard für einen stabilen und ziel- d.h. serviceorientierten, kostenoptimierten Betrieb einer IT-Umgebung. Definierte Prozesse mit Regeln, Verantwortlichkeiten und Kennzahlen bilden eine hervorragende Grundlage für die Einführung von Lean-Konzepten, sei es für agiles Projekt-Management, DevOps-Transition-Management oder kontinuierliche Verbesserung. Unter dem Aspekt von sehr häufigen, aber kleinen Änderungen sind zwei Prozesse der Schlüssel für das erfolgreiche Zusammenspiel von DevOps und ITIL: Change-Management und Configuration-Management. Der Change-Management-Prozess ist dahingehend anzupassen, dass sehr viel mehr Change-Modelle erstellt und automatisiert werden. Ähnlich wie sich Standard Changes für Endanwender (z.B. die Installation von Visio auf einem Arbeitsplatzrechner) in einem Portal als «Selfhelp» automatisieren lassen, sollten normale Changes mit wenig Risiko und starker Automatisierung vom Administrator durchgeführt werden können. Via Runbook-Automation können auch Events aus dem Monitoring automatisch interpretiert und automatisierte Massnahmen eingeleitet werden.

Damit einhergehend muss das Configuration Management System (CMS), das in ITIL eher als passives Informations-Tool beschrieben wird, zu einem aktiven Konfigurationssystem ausgebaut werden, in dem sich für bestimmte Configuration Items oder -Klassen neue Sollzustände definieren lassen. Durch integrierte Software-Konfigurations- und -Verteilungs-Tools kann man diese vom Ist- zum Sollzustand führen.

DevOps ist ein vielversprechender, aber auch ehrgeiziger Ansatz, der im Kern aber sehr pragmatisch ist: Man darf die Arbeit nicht einfach bürokratischen Prozessen und Tools überlassen – am Anfang sollte immer die zwischenmenschliche Kommunikation stehen.