© reddz, 123RF

Führt ein Unternehmen eine Devops-Kultur ein, baut es meist kurzentschlossen Teams um, verschiebt Verantwortlichkeiten und vergibt Adminrechte neu. Doch kalkuliert es auch die Risiken und Nebenwirkungen mit ein? Ein Bericht aus der Praxis.

Ein typischer Effekt beim Wechsel hin zur Devops-Kultur: Auf den Servern im Rechenzentrum wächst der Nutzerkreis mit administrativen Berechtigungen. Nach der anfänglichen Euphorie stellen sich bei Ausfällen im Alltag jedoch wieder die altbekannten Fragen: Wer war es, wie konnte das passieren und warum haben wir es nicht bemerkt?

Zwar ändert sich der Weg zum Ziel in einer agilen Welt dramatisch, doch kann auch diese kaum auf einen stabilen Betrieb und Nachhaltigkeit verzichten. War es früher nur wenigen Admins erlaubt, Änderungen auf Servern auszurollen, darf nun dank Devops fast jeder Kollege ran. Die IT soll nicht mehr von Spezialwissen und einem jahrelang antrainierten Bauchgefühl abhängen, an ihre Stelle tritt mehr und mehr die Testautomation. Von Spezialisten entwickelt, setzt sie dann jedermann ein.

Testautomation ist nicht neu und kommt in der Software-Entwicklung schon lange zum Einsatz. Dass Admins dieses Vorgehen auf den Betrieb von Servern und Rechenzentren übertragen, ist allerdings eine recht junge Entwicklung.

Die im Artikel vorgestellten Methoden eignen sich womöglich weniger für kleinere IT-Umgebung. Doch Firmen mit vielen Mitarbeitern sowie solche, die Nachhaltigkeit anstreben, dürften davon profitieren. Sie zielen vor allem darauf ab, die Kosten für das Beseitigen von Fehlern zu senken. Im Entwicklungsprozess, der aus Planen, Entwickeln, Testen und Betreiben besteht, wird die Lösung meist umso teurer, je später der Fehler auffällt (Abbildung 1). In der Planungsphase kann ein Entwickler einen Designfehler günstig und einfach beseitigen. Geht ein Softwareprodukt erst in Produktion, lässt sich der gleiche Fehler nur mit größtem Aufwand entfernen.

Abbildung 1: Fehlerfolgekosten während des Produkt-Lebenszyklus.

An genau diesem Punkt gehen Entwickler und Admins sehr unterschiedlich vor. Die Software-Entwickler investieren typischerweise viel mehr Zeit in die Planung, um dann relativ zügig zu entwickeln, zu testen und die Software in Betrieb zu nehmen. Im Operations-Bereich (auf Deutsch “Betrieb”) entstehen dagegen viele Ideen spontan oder werden in kurzen Workshops erarbeitet.

Eine entwickelte Software schicken die Admins vor dem Produktiveinsatz in eine längere Testphase. Das fertige Programm testen sie dann meist nur über Ausprobieren und stellen so fest, ob “etwas Schlimmes passiert”. Abbildung 2 vergleicht symbolhaft die beiden Welten, die Devops vereinen möchte.

Abbildung 2: Die Testphase verläuft bei Entwicklern (Devs) und Admins (Ops) nicht selten unterschiedlich.

Planen Betriebler umfangreiche Änderungen, treffen sie im Operations-Bereich nicht selten auf großen Widerstand. Dahinter steht meist die Angst, eine funktionierende Infrastruktur zu zerstören. In der Entwicklung passiert es hingegen häufiger, dass eine gut getestete Software auch größere Umbauten mit überschaubarem Risiko übersteht.

Aus Fehlern lernen

In der Praxis braucht Devops vor allem zwei Dinge: gegenseitigen Respekt und die Bereitschaft, voneinander zu lernen. Viele Devops-Projekte beginnen damit, dass die Entwickler das Rechenzentrum und den Serverbetrieb besser kennenlernen und die Herausforderungen im Operations-Bereich in ihrer Planung berücksichtigen. Entwickler lernen nervige Probleme zu vermeiden, indem sie dafür sorgen, dass Logfiles nicht die Festplatten überschwemmen, keine störrischen und trägen Dienste laufen, Monitoring und Alarming funktionieren und sie keine Systeme mit völlig überzogenen Ressourcen-Anforderungen bestellen.