DevOps, (k)ein Widerspruch

Ansatz für einen IT-Betrieb basierten Entwicklungszyklus

Ein Versuch das Thema Best Practice bei „DevOps Konzepten“ und deren Gefahren zu beschreiben.

Ausgangssituation

Aktuell sehen wir immerwieder weitgefächerte strukturelle Herausforderungen beim Umbau einzelner IT-Infrastrukturen für einen Zoo von Webanwendungen, die im Laufe der Zeit in einer Organisation entwickelt werden. Unstimmigkeiten zwischen den Sysadmin Teams und den Entwickler Teams können enorme Konflikte entfachen, bei denen auf der Berechtigungsebene, durch doppelte Zuständigkeiten im administrativen Wirkbetrieb, Änderungen ohne Change Requests zu erwarten sind. Entweder aus Trotz oder „weil man das halt immer so gemacht hat“.

Sollten Teammitglieder in der Rolle eines Softwareentwicklers sein und unkontrolliert Zugriff auf die Produktionsebene haben, läuft der reguläre IT-Betrieb Gefahr sich durch verkürzte und intransparente Änderungsprozesse in die 2005er Jahre „zurückkatapultieren“. Ärger ist dann vorprogrammiert.

Die Ausläufer dieser Katastrophe sind kleine unauffällige Spannungsfelder, die nicht mehr wirklich zur Lösung einer technischen Störungen (Incidents) beitragen. Es entstehen Durchlaufzeiten von mehreren Wochen oder gar Monaten. Wenn solche „geheimen“ Änderungen an produktiven Systemen von Softwareentwicklern durchgeführt werden, die ungetestet Störungen verursachen, obwohl eine Testing Infrastruktur bereitgestellt wurde, könnte es bereits zu spät sein. Es existiert somit keine logische oder sonstig geartete Barriere oder Policy, die den Softwareentwickler daran hindert, manuelle Änderungen sofort in die Produktion ungetestet zu übertragen. Will man das ?

Risiken sind kaum sichtbar, weil permanent versucht wird, sichtbaren Schaden von der Produktion fernzuhalten. Wenn dann doch etwas passiert, so tendiert es, kritisch für die Anwendung zu werden, weil der Fehler wie eine Nadel im Heuhaufen irrttümlicherweise im letzten großen Release gesucht wird. Wenn dann Überschneidungen der Rollen und Berechtigungen beim Deployment durch sowohl Softwareentwickler als auch Sysadmins verursacht werden, ist die Intransparenz und Doppelarbeit perfekt. (Ironie off)

Aber wie beurteilen wir solche Situationen ?

Wir sollten konsequenter auf bereits bestehende Standards aus dem IT-Betrieb setzen. Damit unnötige Abhängigkeiten aufgelöst und zusammen mit den Entwicklern auf einer Art „IT-Betriebs-Prozess-Ebene“ die Softwareentwicklung inklusive das Testing neu gedacht werden.

Wer als Sysadmin im IT-Betrieb gearbeitet hat, sollte nur Störungen und Aufträge wie z.B. das Deployment im Blick haben. Voraussetzung bleiben die entsprechenden Testings in den dafür bereitgestellten Test-Infrastrukturen.

• Kein Zugang für Devs auf die Produktion
• Kein Zugang für Sysadmins auf die Entwicklung

Ok – aber wie messen wir die Durchlaufzeit einer Umsetzung ?

Die Handlungsfähigkeit durch die etablierte Stabilität eines IT-Betriebes liefert uns die Grundlage für einen effizienten Testprozess-Zyklus. Anhand der definierten KPIs beginnend von der Beauftragung im CRM-System, über die Entwicklungsabteilung, der Freigabe und bis zum Deployment durch die Sysadmins, kristallieren sich die Durchlaufzeiten nach und nach mehr oder weniger schnell heraus. Nach etwas 4 Wochen sollten ersten Tendenzen erkennbar sein. Feinjustieren kann dann jeder Teamleiter mit seinem Team selbst. Ein entscheidender Maßstab ist stets die getrennte Betrachtung der operativen von den Entwicklungs Rollen und Berechtigungen, um den Erfolg einer DevOps Teams zu garantieren. Das Team wird sicher noch etwas Kosmetik betreiben wollen, um den neuen DevOps Deployment Prozess zu verfeinern. Das ist die Chance für alle Transparenz im IT-Betrieb und Teilhabe am Entwicklungszyklus mitzugestalten.