DevOps – Digitale Transformation bis zum Betrieb

Als Ziele digitaler Transformation gelten folgende, scheinbar im Widerspruch befindliche Ziele:

• erhöhte Geschwindigkeit, um Software schneller an den Kunden zu bringen oder geänderte Anforderungen und Kunden-Feedback schneller umzusetzen
• Realisierung von Kostensenkungen
• und erhöhte Qualität.

Schnelle Entwicklungszyklen bei hoher Qualität und sicherem Betrieb.
Software, die Business- und Qualitätsziele erfüllt und Compliance-Anforderungen genügt, wird automatisiert ausgerollt – und der Betrieb läuft. Idealerweise gilt: Jedes Inkrement an Änderungen am Code ist potentiell sofort auslieferbar (potentially shippable increment), ohne Qualiätsverluste.

Agile Software-Entwicklungs-Modelle sollen das doch ermöglichen. Wozu dann noch DevOps?
Bleibt Agilität beschränkt auf das Software-Entwicklungsprojekt, dem üblicherweise kein Systemadministrator angehört, ist es zu kurz gegriffen.
Die Softwarelebenszeit ist ja auch immer um ein Vielfaches länger, als die Entwicklungsprojektdauer.

Ein paar gängige Klischees zu Entwicklern und System Administratoren, überspitzt formuliert:

• Änderung ist der Feind des laufenden Betriebs. Ein Systemadministrator scheut die Änderung, denn die Betriebsunterbrechung ist quasi vorprogrammiert.
• Entwickler sind nur daran interessiert Änderungen schnell in Code zu gießen, und dann über den Zaun zu werfen. Deployment Skripte langweilen schon. Betriebsthemen werden zu spät angepack. Der Betrieb brennt? Problem der Systemadministratoren.
• Die Infrastruktur war mal wieder schuld.
• Wenn ein Entwickler automatisiert bis in die Produktion ausrollen kann, bricht das große Chaos aus.

Die Barrieren der Trennung von Entwicklung und Betrieb sind über Jahre gewachsen und gefestigt – es gibt sicher genug Beispiele aus dem Arbeitsalltag, um jede der oben genannten Behauptungen zu stützen.
Die viel gestellte Schuldfrage (wer hat das Problem verursacht?) über die Gräben zwischen Entwicklern und Operatoren ist eine typische Folge.

"Entwicklung und Betrieb spielen oft Katz’ und Maus während des Deployments. Um die Streitereien zu beenden, müssen wir sie näher zusammenbringen, damit sie wieder beginnen, zusammenzuarbeiten."¹ Devops: A Software Revolution in the Making? (Übersetzung durch die Autorin).

Geschwindigkeit erhöhen kann man nicht nur, indem man schneller wird, auch das Abbauen von Barrieren lässt uns schneller vorwärtskommen. Gemeinsam Probleme lösen, indem jeder sein Wissen einbringt, anstelle von Ticket-Ping Pong, Eskalationen und Schuldzuweisungen.
Und genau hier setzt auch DevOps an. Abbauen von Vorurteilen, organisatorische Neu-Ausrichtungen, um Abteilungssilos aufzulösen, Wissen breiter streuen.

DevOps – Automatisierung, Werkzeug, Methode, Konzept?

Oft wird das Thema DevOps auf Automatisierung und dabei verwendete Werkzeuge verkürzt. Das behebt einige fehlerbehaftete und zeitraubende Themen wie etwa das manuelle Installieren und Konfigurieren von Software, und manuelles Testen. Für die Konstruktion von hoher Software-Qualität ist das Aufsetzen einer passenden Continuous Integration und Delivery Pipeline mit automatisierten Tests von hoher Bedeutung. Fokus auf konstruktive Qualiätssicherung bedeutet, dass Qualität in das System eingebaut wird, anstelle sich stark auf nachgelagerte Code Inspections und Teststufen (analytische Qualitätssicherung) zu stützen.

In einem weiteren Blog-Beitrag werden wir uns dem Thema DevOps Pipelines aus technischer Sicht widmen. Wie es organisiert werden kann, dass diese Pipelines wirklich aufgesetzt werden, ist wieder eine Frage, wie DevOps in einem Unternehmen umgesetzt wird.

Kooperation, Zusammenarbeit zwischen Entwicklern und Betrieb/Infrastruktur sind ein elementarer Bestandteil für die erfolgreiche Einführung des DevOps Gedankens:

"Für 80 Prozent der Organisationen ist es daher enorm wichtig, die Barrieren zwischen den Entwicklungs- und Operations-Teams zu verkleinern oder ganz aufzuheben. Doch nur eine Minderheit von 20 Prozent hat bereits alle Hürden dieses kulturellen Wandels überwunden – es braucht Zeit und Geduld, um die traditionellen Grenzen, etablierten Denkweisen und lang andauernden Revierkämpfe hinter sich zu lassen."¹ DevOps: Ziemlich beliebt, ziemlich falsch umgesetzt (Computerwoche)

Gemeinsam die Ziele der Business Kunden im Blick haben.
Verständnis entwickeln für die Arbeit (und Nöte) der anderen Kollegen.
Dabei ist es auch sinnvoll, noch weiter gefasst zu denken, und das Business und IT Alignment (BITA) dahingehend zu denken, dass auch an dieser Grenze ein weiteres Kennenlernen stattfindet.
Existierende Vorurteile abbauen, Vertrauen gewinnen: Um einzelne Inkremente schnell ausrollen zu können, wird es gerade bei großen Teams so sein, dass auch noch nicht produktive Funktionalität quasi "verborgen" ausgerollt wird. Oder eine bestimmte Änderung vorerst nur für eine bestimmte Pilotnutzergruppe bereitgestellt wird, gesteuert über rollen-basierten Zugriff und im Fehlerfall auch deaktivierbar ist (Stichwort "Feature flags").
Das braucht ein Mehr an Vertrauen und Verständnis seitens der Fachabteilungen gegenüber der IT-Abteilung. Auch das will entwickelt werden.

Es gilt also nicht nur die Software, die Infrastruktur, die Werkzeuge geeignet zu wählen, so dass sich durch Automatisierung Geschwindigkeits- und Qualitätsvorteile, sowie auf längere Sicht gesehen auch Kosteneinsparungen ergeben (der Erstaufwand für die Automatisierung muss sich amortisieren).
Sondern auch die kollaborative Seite und den Kulturwandel innerhalb der IT-Abteilung und über die IT-Abteilung hinaus zu sehen. (Vergleiche auch die Erkenntnisse aus dem Puppet State of DevOps Report 2016).
Hier zeichnet sich auch schon ab, dass eine DevOps Einführung immer auf den gegebenen Unternehmenskontext bezogen sein muss, um erfolgreich zu sein.
Und, dass es bisweilen langen Atem brauchen wird, bis sich Konvergenzen ergeben. Könnte man einfach kopieren, was Amazon, Etsy, Facebook, Uber oder andere Unternehmen für die DevOps-Einführung gemacht haben, wäre es vermutlich bedeutend einfacher. Externe DevOps-Consultants, DevOps-Ingenieure, DevOps-Architekten und welche Bezeichnungen es noch am Markt geben mag, können eine Unterstützung sein, jedoch auch keine one-size-fits-all Lösung mitbringen.
Denn, es braucht eine unternehmens-kontextsensitive Implementierung von DevOps, eine Art iDevOps.

iDevOps – unternehmensspezifische Betrachtung

Wie findet man die unternehmenspezifische Implementierung von DevOps Prinzipien?
Fangen wir doch an beim Status Quo: Wie arbeiten die Teams im Unternehmen bisher? Wie kann man dort Barrieren abbauen? Was bleibt zentral verwaltet und was wird dezentral in den IT Projekten gelöst? Wichtig ist ein begleitendes Change Management. Und, eine Perspektive für alle. Auf hoher Ebene kann man ausloten, wohin es geht. Die Details besser gemeinsam in gemischten Arbeitsgruppen erarbeiten. Hierbei sind externe DevOps-Consultants sicher hilfreich und auch ein guter Katalysator für auftretende Spannungen.

Es gilt möglichst viele Fragen zu stellen und gemeinsam die Antworten zu finden. Hier eine kurze Liste:

• Was brauchen wir an Dokumentation und Prozessen, um eine gute Zusammenarbeit zu ermöglichen, und Governance Regeln einzuhalten, damit es am Ende keine Probleme mit der IT-Revision gibt? Stichwort ITIL (oder auch SIAM) und entsprechende Software wie ServiceNow. Je nach bestehender Prozesslage kennen bspw. Entwickler die mit ITIL verbundenen Prozesse nur wenig bis gar nicht. Administratoren sind dagegen oft sehr vertraut damit.
• Wie profitieren die konkreten IT-Projekte davon? Welche Freiräume werden geöffnet und welche zusätzliche Verantwortung tragen die Projekte?
• Wie kann der Grad der Automatisierung gerade auch in bestehenden Projekten erhöht werden? Für die Ankurbelung der Automatisierung und das Aufbauen der DevOps Pipelines für die Haupttechnologien ist es sicher wert darüber nachzudenken, externe Spezialisten zu holen und einen geeigneten Ansatz zu haben, um das Wissen zu multiplizieren.
• Welche zentralen Vorgaben setzen den Rahmen für alle Projekte? Wie wird das in die Projekte transportiert, welche Anforderungen bspw. seitens Security und Compliance einzuhalten sind?
• Was ist mit den Anwendungen, die schon lange laufen, und wo die Änderungsrate sehr gering ist?
• Welche Skills braucht man dafür in den IT-Projekten, die die bisherige Zusammensetzung eventuell nicht abdeckt? Gibt es den mythischen Full-Stack-Developer, und wie viele davon finden sich am Markt?
• Ändert sich die Rollendefinition und welche Rollen gibt es zusätzlich?

Best Practices für das Erarbeiten von Methoden, Konzepten und Rollenmodellen:

1. Erst kennen lernen und verstehen, was der andere macht, und im nächsten Schritt
   gemeinsam Prozesse erarbeiten. Dabei auch einfach mal gemeinsam Mittagessen gehen, um Kollegen kennen zu lernen, die wir bisher nur von Ferne gesehen haben.
2. Mindset: Einander mit Offenheit begegnen, andere in ihrer Arbeit bestmöglich unterstützen und eine gute Diskussionskultur ermöglichen.
   Mit dazu gehört auf allen Seiten die Bereitschaft, die eigene Arbeitsweise zu ändern. Es sind sicher oft viele Abteilungen betroffen – zum Teil wusste man vielleicht noch nicht mal um deren Existenz. Barrieren abbauen heißt auch, dass Prozesse nicht "wie bekannt" belassen werden, sondern schrittweise umgebaut – transformiert werden.
3. Transparenz: Wer braucht welche Informationen wofür und warum? Wo werden sie hinterlegt.
4. Lean-Prinzipien anwenden: Geschwindigkeit erhöhen, durch die Reduktion von ‘Waste’ – auch mehrfach an verschiedenen Stellen zu pflegende Informationen sind eine Art von ‘Waste’, wenn es keinen zusätzlichen Nutzen bringt, der auch für alle erkennbar ist. Möglichst wenig Duplikate – das Problem der Aktualisierungs-Anomalien kennt die Informatik schon lange genug.
5. Intersektionalität: Welche anderen Transformationen gibt es, die im Unternehmen durchlaufen werden? Welche neuen Prozesse und Tools gibt es? Wie werden Anforderungen gemeinsam koordinert? Wie ist der Informationsaustausch sichergestellt?

In Puppets State of DevOps Report wird das Westrum Modell erwähnt – mit den oben skizzierten Fragestellungen und Best Practices kann eine generative und auf Performance ausgerichteten Unternehmenskultur erreicht werden:

"Die Markenzeichen einer generativen Organisation sind gute Informationsflüsse, Kooperation und Vertrauen, Brücken bauen zwischen Teams, und bewusstes Nachfragen."¹

(Übersetzung durch die Autorin).

Abschließend noch ein weiterer Aspekt: In größeren Unternehmen, die mit mehreren Dienstleistern auf Seiten von Entwicklung, Infrastruktur und Betrieb arbeiten, wird es schnell auch zu den Fragen kommen: wie arbeitet man dienstleister-übergreifend zusammen? Welche Dienstleistungsvereinbarungen (SLAs) zieht man heran? Ein weiteres breitgefächertes Thema liefert hier Bausteine: SIAM – "Serviceintegration und Management (engl.: Service integration and management, SIAM) ist eine Vorgehensweise, um verschiedene Lieferanten von IT-Dienstleistungen zu managen und eine einheitliche geschäftsorientierte IT-Organisation für die Anwender abzubilden. Sie besteht in der nahtlosen Integration einander abhängiger Dienstleistungen interner und externer Dienstleister mit dem Ziel, durchgängige Dienste zur Bewältigung der Geschäftsvorgänge zu ermöglichen."¹

Es gibt einiges an Neuland kennen zu lernen, und genug Grenzen zu überbrücken, um ein Ziel zu verfolgen: die Businessziele gemeinsam erreichen.
Lassen Sie uns anfangen – wir begleiten Sie gerne und geduldig als DevOps Consultants.

Noch mehr Informationen

• Die DevOpsDays mit denen alles begann werden an vielen Orten der Welt organisiert: www.devopsdays.org – Teilnehmen, mitdiskutieren, austauschen.
• Kontaktieren Sie Branchenpartner für ein Benchmark.
• Die Anbieter von Automatisierungswerkzeugen (Hashicorp, Chef, Puppett und viele andere) haben alle DevOps Themen auf ihren Websites, z.B. Chef: Solutions – DevOps oder Hashicorp: DevOps Defined.
• Seth Vargo (bei Hashicorp): The ten myths of DevOps

Referenzen