About Dogs and Cats - über DevOps in großen Konzernen

über DevOps in großen Konzernen

http://www.flickr.com/photos/ifl/3926784260/ 16.07.2015

Stefan Bauer Bild: Peretz Partensky

Heute ist Release-Day.

Meine Rolle dabei nennt sich DevOps. Gestern hatte ich die letzten Infos, Pakete und Freigaben von den Entwicklern bekommen

und alles vorbereitet. Der zuständige Administrator braucht nur noch die Werte vom Ticket in die Variablen des Puppetmaster

einzutragen. Das ist gut, alles am Tag davor fertig zu haben.

Naja, so gut war es auch nicht…

Ich habe gestern den ganzen Tag gebraucht und bin erst um 21 Uhr fertig geworden. Ein bereits fertiges Packet wurde

neugebaut. Es musste händisch auf der Testumgebung ausgetauscht werden, da die Versionsnummer nicht erhöht wurde. In der

Beschreibung zu einer anderen Komponente tauchte auf einmal eine neue Konfigurationsdatei auf. Diese war bei der

Implementierung des automatisierten Deployments noch nicht berücksichtigt worden. Also mussten die bereits abgeschlossenen

Änderungen nochmal überarbeitet werden und dann alles sorgsam auf Staging getestet werden. Dabei funktionierte dann auch

das gelieferte Startskript nicht mehr korrekt. DAS macht Spaß: Abends wenn keiner mehr da ist, anderer Leute Skripte zu

verstehen.

Als alles fertig war und ich die Änderung für Produktion eingecheckt hatte, schlug der Testjob für das Puppet-Deployment fehl.

Eine Kollision von Variablennamen unbekannter Herkunft. Gottseidank war die Fehlermeldung gut genug, um das Problem

schnell zu verstehen. Das ist selten, aber es muss ja auch mal etwas Gutes passieren.

Heute ist Release-Day.

Ich habe einen Arzttermin und werde aus der Ferne zuschauen, wie alles passiert.

Es passiert nichts.

Dann kommt eine E-Mail: Wir dürfen nicht releasen. Heute morgen hat das Administrationsteam erfahren, dass es einen

konzernweiten Change Freeze gibt. Nee ne ?

Außerdem wird betont, dass die Struktur einer Komponente nicht akzeptabel sei und das ist jetzt ein Showstopper. Hatten wir die

Probleme nicht schon mal abgeklärt und einen Kompromiss gefunden der vom Administrationsteam akzeptiert wurde?

Tja, das scheint Schnee von gestern zu sein. Genauso wie der gestrige Abend den ich dafür verpulvert habe…

About Dogs and Cats - DevOps in Konzernen

2

14:00

Wir haben eine Erlaubnis für einen Teil des Deployments bekommen. Das Release ist noch nicht gestartet.

Ich bin gerade im Bahnhof und in 20 Minuten muss ich beim Zahnarzt auf dem Stuhl sitzen. Ein Entwickler meldet sich per Chat.

Ich möchte doch noch dieses eine Paket für das Release nachschieben. Ich erkläre ihm, dass es jetzt etwas spät dafür ist. Er soll

ein Ticket dafür machen. Irgendwie versteht er das nicht. Egal, ich muss los.

"Egal, ich muss los" … das muss ich mir unbedingt für den Feierabend vor dem nächsten Release einprägen.


3

Bei Triplesense Reply GmbH für DevOps und interne IT verantwortlich

seit 1996 Softwareentwickler

2000-2007 Unternehmer, Entwickler für 3D-Grafiksoftware

2007-2014 Entwickler, Toolsexperte, Admin & DevOps bei HERE

Tweets @bitbauer https://www.xing.com/profile/Stefan_Bauer240

Entwickler von Herzen und Atlassian Fan


4

https://www.xing.com/profile/Stefan_Bauer240

KLARSTELLUNG

Zu der Zeit der Geschichte hatten wir …

• Wöchentliche Releases

• Automatisierte Deployments

• Versionierte Konfiguration

• Entwickler beteiligten sich an Puppet-Implementierung


5

DANN IST DOCH ALLES

RICHTIG, ODER ?

Technische Umsetzung:

• Reproduzierbarkeit durch Automatisierung und Maschinenimages

• Gute CI Abläufe

• Automatisierte Deployments

• Versionierte Konfiguration

… Wow


6

DANN IST DOCH ALLES

RICHTIG, ODER ?

Organisatorische Aufstellung:

• Beteiligte sind verstreut über die Organisation

Produktmanagement

Entwicklung

Operations

Infrastructure

Security

• Kommunikation nur kontrolliert und ungenügend

… Ja, das ist halt so


7

DANN IST DOCH ALLES

RICHTIG, ODER ?

Strategische Ausrichtung:

• Technikgetrieben

• Methodiken und Regeln sind unklar

• Transparenz unwichtig

• Command & Control

… Das geht bestimmt besser


8

STRATEGIE IST WICHTIG

Rahmen und die Ziele müssen definiert werden

Gesamte Organisation berücksichtigen

Gute Strategien sind einfach verständlich

Strategie ist für einige Jahre gültig


9

ORGANISATION

Transparenz für gegenseitiges Vertrauen

Regeln und Methoden für reguläre Zusammenarbeit

Organigramm ist sekundär

Kultur muss erkämpft und verteidigt werden


10

TECHNIK

Umsetzung mit Tools und Automatisierung

Funktionale Anforderungen

z.B. an Versionierbarkeit, Auswertbarkeit

Nicht-Funktionale Anforderungen

z.B. an Einfachheit, Geschwindigkeit


11

SO UND JETZT ?

Ist das ausreichend für große Veränderungen …

• in Organisationen

• im Verständnis über Software

• in unseren Köpfen

???


12

Conway‘s Law

Teams & Prozesse


13

CONWAYS LAW

Organisationen, die Systeme modellieren, […] sind auf

Modelle festgelegt, welche die Kommunikationsstrukturen

dieser Organisationen abbilden.

(Melvin E. Conway - 1968)

https://de.wikipedia.org/wiki/Gesetz_von_Conway


14



CONWAYS LAW

UND PROZESSE

Prozesse und Abläufe in Organisationen bilden den

Informationsfluss und Informationsbarrieren derselben ab.

Die prägenden Informationsflüsse in klassischen

Organisationen sind …

• der Bottom-Up Report

• die Top-Down Planung


15

CONWAYS LAW

UND PROZESSE

Prozesse und Abläufe in Organisationen bilden den

Informationsfluss und Informationsbarrieren derselben ab.

Informationsbarrieren werden durch Übergabepunkte

gehandhabt. An diesen wird …

• Arbeit eingefroren und Information gesammelt

• danach als Arbeitspaket weitergegeben


16

FACHLICHE TEAMS

Eine Entwicklungsabteilung besteht oft aus:

• Architekturteam

• mehreren Entwicklerteams

• QA-Team

Administrationsabteilung besteht oft ebenfalls aus mehreren

fachlichen Teams


17

GLEICHARTIGE RUDEL

Lücken in der Fachlichkeit während der Arbeitsphase

Fachliche Konflikte werden zu Rudelkämpfen

Informationsbeschaffung über Barrieren

Kreative Einflüsse kommen oft von „außen“


18

GEMISCHTE RUDEL


19

GEMISCHTE RUDEL

• interne Skills in Kundenkommunikation und Prozessen

• Diversität in den Fachlichkeiten

• Fachliche Konflikte und Lösungen sind Teil der täglichen Projektarbeit

• Kreative Einflüsse kommen von „innen“

http://dustinrcollins.com/devops-a-house-divided


20










INTERDISZIPLINÄRE TEAMS

Projekterfolg steht im Zentrum

Wenige externe Abhängigkeiten

Aufgaben in kleinen Schritten abgeschlossen werden

Abteilungen werden zu autarken Mini-Unternehmen


21

Ziele, Ziele, Ziele

… der eigene Weg


22

HERAUSFORDERUNGEN

Ziele definieren!

Für strategische Transformation

Für organisatorische Transformation

Für Technische Transformation


23

STRATEGIEZIELE

Das eigene Business verstehen…

• Welchen Mehrwert liefert das Unternehmen ?

• Änderungen des Marktes berücksichtigen !

• Was sind die Stärken gegenüber Mitbewerbern ?


24

ORGANIZATIONSZIELE

z.B. mehr Effizienz durch:

• weniger Handovers und Automatisierung

• weniger sequenziellem Arbeiten

• weniger Reworkaufwand durch CI

z.B. mehr Effektivität durch:

• Verteilung von Entscheidungen

• Transparenz in Projekt und Entscheidungen

• Anforderungen stetig pflegen


25

TECHNISCHE ZIELE

Zum Beispiel:

bessere Versionierbarkeit

automatische Auswertbarkeit für Controlling

weniger Komplexität

höhere Geschwindigkeit der Tests


26

DER EIGENE WEG

Es gibt keinen generellen Plan,

aber …

es gibt viele gute Ideen und Praxiserfahrungen!


27

Varianten in der Praxis

Transformation


28

DEVOPS ALS EIGENES TEAM ?

sehr verbreitet z.B. bei HERE

• muss Erfahrung vielen Bereichen des Unternehmens mitbringen

• Teammitglieder brauchen starkes Standing in den Unternehmensbereichen

• problematisch, da breite Veränderung von „aussen“ kommt

https://puppetlabs.com/blog/team-structure-for-devops-success

http://continuousdelivery.com/2012/10/theres-no-such-thing-as-a-devops-team/


29




























DEVOPS ALS JOBROTATION

Als erster Schritt in klassischen Unternehmen

• jeder darf sich für einige Wochen einen anderen Bereich aussuchen

• Nicht nur Tausch zwischen Entwicklern und Administratoren

• Erfahrungsaustausch, Verständnis, Vertrauen


30

DEVOPS ALS LERNTEAM

Beispiel GiantSwarm

• Mixed Team aus temporären Mitgliedern

• Mitglieder kommen aus den vorhandenen Team

• Erfahrungen werden wieder zurück in das Ursprungsteam getragen

https://jaxenter.de/interview-loew-luebken-devops-team-kultur-18903


31















DEVOPS ALS NORMALZUSTAND

Beispiele Facebook, Google, Amazon …

• Stetige gemischte Teams

• Diversität als Stärke verstehen

• Nicht nur Techies im Team !


32

ORGANISATORISCHE

TRANSFORMATION

• kleine Iterationen bei der Transformation

• Praktisches Training

• Organisatorische Freiheit -> das Team ist Zentrum

• Involvierung und Gespräche

• Transparenz und gegenseitiges Vertrauen bei allen

Problemen

• kultivieren von positiven Erfahrungen


33

TECHNISCHE TRANSFORMATION

• alle Vorschläge zu Lösungen ernst nehmen

• einfache Lösungen bevorzugen

• automatisierte Testbarkeit gewährleisten

• Abhängigkeiten bei einzelnen Lösungen bewerten

... es gibt i.A. keine eierlegende Wollmilchsau.


34


35

KERN VON DEVOPS

Technologie war Auslöser, Agile Bewegung der Treiber

Viele Administrationstasks inzwischen automatisierbar

Volles Potential durch Veränderung der Organisation

Prozesse sollen helfen nicht stören

Veränderung der Organisation steckt im Kern von DevOps


36

MENSCH & TECHNIK

• Veränderung der Technologie ist rasant

• Kulturtransformation, menschlich langsam

erst recht in großen hierarchischen Organisationen


37

MENSCH

Veränderung gelebter Kultur durch:

• Transparenz und Kommunikation

• Wissenstransfer und Anwendung

Konflikte der Anforderungen ist normal,

Vertrauen und Respekt notwendig.


38

VERÄNDERUNG MESSEN

• Frustrationpegel

• Genauigkeit in Aufwandschätzungen

• Kurze/Keine Wartezeiten zwischen Implementierung und Livegang

• Weniger Stau in der Arbeit

• Bessere Anwendung von Standards

• Schnelle Korrektur von Konfigurationsprobleme

• Weniger Deploymentfehler mit stabiler Deployment Prozedur

…


39

DEVOPS, CHATOPS AND NOOPS

Tausend Namen, ein Gedanke …

Verbesserung von Organisation und Prozessen,

basierend auf den Möglichkeiten der Technik.


40


41

PERSÖNLICHER AUFRUF

viel Potential zur Testbarkeit bleibt ungenutzt

bitte kein pre-TDD bei der Automatisierung

Test-Driven zu Arbeiten zahlt sich aus

ohne Tests altert der Code


42

FAZIT

DevOps braucht:

• Kontinuität und Hartnäckigkeit

• Gegenseitiges Vertrauen und Respekt

• Konflikte und Freiraum zur Lösung

DevOps braucht alle


43

Technology

About Dogs and Cats - über DevOps in großen Konzernen