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

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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (11)

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

Ähnlich wie About Dogs and Cats - über DevOps in großen Konzernen (20)

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