Seit 2009 ist DevOps ein wichtiges Thema auf den IT-Konferenzen, und inzwischen empfehlen auch die großen Beratungshäuser eine DevOps-Strategie. Doch während sich die Tools hoher Popularität erfreuen und Quasistandard wurden, sind Kultur und Organisationsdesign auf der Strecke geblieben. Die Tools alleine realisieren nur einen kleinen Teil des Benefits von DevOps, der große Vorteil entsteht erst mit der Integration von DevOps-Struktur, Organisation und Kultur im Unternehmen zu bekommen. Wie breche ich Silos jenseits von Dev und Ops auf? Wie schaffe ich gemeinsame Ziele über die Abteilungsgrenzen hinaus? Wie mache ich eine verlässliche Testphase bei einem Deploy am Tag? Welche Strukturen von heute stehen DevOps im Weg?

1. DevOps jenseits der Tools
Hallo Zusammen! Ich möchte nämlich etwas persönliches erzählen.

2. 27.10.2010
Mein erstes Mal.
Mein erstes Mal ist ziemlich genau 5 Jahre her. am 27.10 habe ich in Frankfurt meinen ersten Vortrag über DevOps gehalten, nachdem unser damaliger Admin Rene
praktisch seit der ersten DevOps-Konferenz nonstop erzählt hat, dass das was gutes wäre.

3. Wer von Euch kennt noch die Tools links und rechts? Genau, das war die Zeit.
Da haben wir etwa mit DevOps angefangen.

4. DevOps @ Mayflower:
5 Jahre voller Fehlern
In den fünf Jahren haben wir sehr viele Dinge falsch gemacht. Wir haben unsere zentralen Puppet-Stack zb in zwischen zum vierten Mal refaktorisiert.

5. … und in vielen
Kundenprojekten
Und wir haben DevOps in vielen Kundenprojekten mit eingeführt - sowohl als Technik wie auch als Kultur. Auch da haben wir viele Fehler gemacht.

6. Wir haben sogar Kollegen,
die alleine DevOps gemacht
haben.
Wir haben sogar Kollegen gehabt, die alleine DevOps gemacht haben.

7. Deshalb gibt es diesen Talk.
Damit wir bessere Fehler
machen.
Und genau deshalb gibt es diesen Talk, damit sowas nicht so leicht wieder passiert, und wir statt dessen lieber alle bessere, höhenwertige und herausfordernde Fehler
machen.

8. Wouha DevOps!
Aber zurück zu DevOps. DevOps hat sich von einer Sache „die man mal angucken muss“ zu einer fest etablierten Größe entwickelt.

9. Accenture, 2014
No longer can applications be
‚built‘ as one distinctive activity
and ‚maintained‘ as another.
Engineering Innovations such as
Agile and DevOps enable software
to be continuously delivered and
evolve as business needs change.
Inzwischen haben es auch die grossen Unternehmensberatungen spitz bekommen. Tatsächlich kann man offensichtlich mit solchen Innovationen wie dem 14jährigem
Teenager Agile und dem Grundschüler DevOps Continuous Delivery machen.

10. Cap Gemini, 2014
Development to Operations
(DevOps) implementations will
increase significantly during
2015-2016.
Auch Cap Gemini geht davon aus, dass DevOps genau jetzt immer wichtiger wird. Interessanterweise nennen sie DevOps hier „Development to Operations“.

11. Zur Erinnerung: als 2009 das Thema im Talk „10+ Deploys a day“ von Flickr zum ersten mal aufkam war es noch nicht „Development to Ops“, sondern „Dev and Ops“ :-)

12. Gartner Group, 2011
Die Gartner Group hatte DevOps schon zwei Jahre nach dem Flickr-Talk auf dem Radar, schon 2011 wurde es als Trigger-Technologie mit einer Mainstream-Adoption in
5-10 Jahren bewertet.

13. Gartner Group, 2015
Gartner Says By 2016, DevOps
Will Evolve From a Niche to a
Mainstream Strategy Employed
by 25 Percent of Global 2000
Organizations.
Und tatsächlich stehen zu der alten Einschätzung - genau 5 Jahre später gehen sie davon aus, dass es Mainstream wird. Also 500 der Top 200 Unternehmen.

14. Puppet Labs, Hersteller der dicken Infrastructure as Code-Lösung Puppet, fragt einmal jährlich den State of DevOps ab.

15. Puppet Labs, 2015
…high-performing IT teams
deploy code 30 times more
frequently than their peers, and
200 times faster (from commit to
production).
Bei den Umfragen geht es ihnen nicht nur um den State, sondern auch wie sich die Highperformer von den Lobperformern unterscheiden.
Das sind die Unterschiede: es wird 30 mal häufiger deployed, und der Weg von Commit in die Produktion ist 200 mal schneller als bei den Low Performern.

16. Puppet Labs, 2015
… with 60 percent fewer failed
deployments and a mean time to
recover (MTTR) that’s 168 times
faster.
Und nicht nur das - die Deployments schlagen häufiger fehl, und wenn ein Fehler passiert, dann wird er viel schneller korrigiert.

17. Puppet Labs, 2015
It’s their use of DevOps
practices that sets these top
performers apart from the pack.
Und wenn man nach der Ursache schaut, warum die das können - dann wird man genau bei den DevOps-Praktiken fündig.

18. Wer macht DevOps?
Wer von Euch macht DevOps?

19. Wer von Euch ist der DevOps
in einem Team oder
in der Firma?
Ist jemand von Euch der DevOps in einem Team oder in der Firma?

20. Wer hat in der Firma
schon ein DevOps-Team?
Und wer hat ein DevOps-Team in der Firma, das sich um die Automatisierung von Aufgaben kümmert?

21. (Ok, das waren jetzt zwei
Fangfragen nach
Antipattern.)
Das war gerade gemein von mir - sowohl die DevOps-Rolle als auch das spezialisierte DevOps-Team gelten als Antipattern - und ich komme auch noch darauf, warum
das so ist.

22. Puppet oder Chef?
Bitte mitrechnen: Jeweils 1 Hipsterpunkt
Aber klären wir mal die Fronten. Wer hier ist Puppet Anhänger? Wer setzt Chef ein?
Wer von den Chefs macht auch sonst Dinge in Ruby?

23. Ansible, Salt, Fabric?
Bitte mitrechnen: Jeweils 3 Hipsterpunkte
Wer setzt Anbisse, Salt, Fabric ein? Bitte 3 Hipsterpunkte addieren.

24. Vagrant, Otto?
Vagrant: 1 Punkt Otto: 5 Punkte.
Wer setzt Vagrant ein? Wer setzt Otto ein?

25. Docker?
Bitte mitrechnen: 1 Hipsterpunkt

26. Docker in Produktion?
Bitte mitrechnen: 3 Hipsterpunkte

27. Docker in Produktion mit
Kubernetes?
Bitte mitrechnen: 5 Hipsterpunkte

28. Docker in Produktion mit
Kubernetes für
MicroServices?
Bitte mitrechnen: 8 Hipsterpunkte

29. Jenkins, Travis, TeamCity?
Bitte mitrechnen: Jeweils 1 Hipsterpunkt

30. Continous Deployment?
Bitte mitrechnen: Jeweils 1 Hipsterpunkt

31. 0 Punkte?
1-5 Punkte?
6-10 Punkte?
15-n Punkte?
Wer von Euch hat gar keinen Punkt?
Wer hat zwischen 1 und 5?
Wer hat zwischen 6 und 10?
Wer hat mehr als 15?

32. Wie oft macht Ihr es so?
1
2
3
4
5
>= 1 mal täglich
mehrfach / Woche
Scrum-Style per Sprint
monatlich?
Enterprise-Style
Wie oft deployed ihr?

33. Neue Features?
1
2
3
4
5
>= 1 mal täglich
mehrfach / Woche
Scrum-Style per Sprint
monatlich?
Enterprise-Style
Und wie oft werden dabei wirklich neue Features live genommen?

34. We’ll deploy anyway.
Da ist nichts dagegen zu sagen - wer die Kosten für einen Deploy soweit unten hat, dass er auch mal ohne Grund deployed - der hat auf jeden Fall seine Automatisierung
im Griff.

35. Enterprise-Style Deployment
Es ist jedes mal spannend zu sehen, ob noch jemand mit Quartalsweisen Deployments da ist.

36. Monitoring? Reporting?
Wer von Euch macht übergreifendes Monitoring?
Genau, das sind schon weniger. ELK? Nagios, Zabbix & Sensu?

37. DevOps:
Check, Tools are there.

38. CAMS
Aber DevOps ist …
Kennt noch jemand Dieses Akronym?

39. CAMS
Culture
Automation
Measurement
Sharing
Genau, das war eine der frühen Definitionen von DevOps - Culture, Automation, Measurement, Sharing.

40. CAMS
Culture
Automation
Measurement
Sharing
Und meist ist nur die Automatisierung übrig geblieben, und ein bisschen vom Measurement.

41. Automation klappt doch super.
Warum dann den Rest machen?
Culture
Automation
Measurement
Sharing

42. „Even with the best tools,
DevOps is just another buzzword
if you don’t have the right culture.“
Der Herr rechts oben - wer von Euch kennt ihn?
Er sagt in seinem Blog folgendes: Auch mit den besten Werkzeugen ist DevOps nur ein Buzzword, wenn die Kultur das ganze nicht unterstützt.

43. Was ist denn die richtige Kultur?
Ok, wir brauchen also die richtige Kultur - aber was ist denn Bitte die richtige Kultur?

44. Worum es bei
DevOps geht …
Schauen wir uns doch einmal an, worum es bei DevOps eigentlich geht …

45. Features schneller von
der Idee zum Kunden
DevOps sollte Features schneller zum Kunden bringen, und damit das ganze Unternehmen beschleunigen.

46. Performance- und Userfeedback
schneller an Ops, Dev & Biz
Und nicht nur da soll es schneller werden - auch der Weg der Information zurück soll beschleunigt werden.

47. Weniger Wartezeiten auf
Dev, QA, Ops, andere Teams,
Requirements
Ein sicherer Weg zu mehr Geschwindigkeit ist natürlich auch weniger Warten.

48. Die Verlässlichkeit der
Applikation erhöhen.
Gleichzeitig soll es die Verlässlichkeit erhöhen. Weniger Ausfälle, weniger seltsames Verhalten, besseres Skalieren etc.

49. weniger:
Fehler im Betrieb
Single-Environment-Fehler
Das beinhaltet natürlich die Reduktion der Fehler, die im Betrieb noch passieren, also frühere Erkennung von Fehlern. Um das zu Erreichen brauche ich Environments, die
sich ähnlich sehen - oder, anders formuliert, weniger Snowflake-Server. Weiss jemand, was ein Snowflake Server ist?
Das sind Server, die komplett und on demand per Hand konfiguriert werden. Es gibt sie nur einmal, sie sind unique, und keiner kennt alle Elemente, die sie enthalten.
Meist gibt es nur wenige Leute, die sie administrieren wollen. Wer kennt solche Server?

50. Qualität erhöhen
Und natürlich - Überraschung, Überraschung - durch eine höhere Qualität der Software. Folgerichtig spielt Qualität bei DevOps eine wichtige Rolle - sonst gäbe es nur
Continuous Deployment, nicht auch Continuous Integration.

51. „Menschliches Versagen“
und Blamestorming
Resultat von der höhere Verlässlichkeit ist eine Reduktion von „menschlichen“ Fehlerzuweisungen.

52. Deployment:
Aufwand & Kosten minimieren

53. Konkret verspricht DevOps also, das Magic Triangle / Iron Triangle des Projektmanagements zu brechen - und gleichzeitig die Qualität zu erhöhen, die Geschwindigkeit
zu verbessern und dabei den Preis zu senken. Klingt ja erst mal attraktiv.

54. DevOps Kultur
Was bedeuten diese Ziele für die DevOps-Kultur?

55. „DevOps is just short for
DevProductSupportNetSecBizOps.
Damit ich all das genannte optimieren kann, reicht es nicht, wenn ich DevOps nur zwischen Dev und Ops mache - denn damit könnte ich nur einen kleinen Teil
verbessern. DevOps bedeutet in Wahrheit DevProductSuportNetSecBizOps. Es geht über alle Bereiche.

56. Product Development Quality Ass. Maintenance
Silo-Effekt
Wer kennt den Silo-Effekt? Der tritt, wie auch seine kleine Schwester Silo-Denke, vor allem in grossen Unternehmen auf. Dort wird wenig über Abteilungsgrenzen hinweg
kommuniziert, aber das gibt es auch in kleineren Unternehmen - bei uns gibt es zB Team-Silos, die wenig mit der Aussenwelt kommunizieren, oder Abteilungsilos wie
Sales.

57. Vice President
Product
Vice President
Development
Vice President
Quality
Vice President
Maintenance
Product
Developer
Software
Developer
Quality
Assurance
Operator
Product Owner
Frontend
Developer
Tester
NetSec
Consultant
Product
Designer
Backend
Developer
Test
Infrastructure
Performance
Consultant
CEO
Und es ist Absicht, dass diese Silos entstanden sind. Dahinter steht die Idee der Funktionalen Organisation. Ich trenne die Spezialisten nach Abteilungen, und die haben
jeweils auch einen Chef, der sich damit auskennt.

58. Vice President
Product
Vice President
Development
Vice President
Quality
Vice President
Maintenance
Product
Developer
Software
Developer
Quality
Assurance
Operator
Product Owner
Frontend
Developer
Tester
NetSec
Consultant
Product
Designer
Backend
Developer
Test
Infrastructure
Performance
Consultant
Eigene Kompetenz
Eigene Ziele
Klare Verantwortung
Eigene Prozesse
Eigene Planung
CEO
Diese Abteilungen haben an der Spitze jemanden, der sich gut mit dem Thema auskennt, und darunter auch Spezialisten - die sich gut mit Ihrer Materie auskennen.
Sie übernehmen die Aufgabe Product Development für das ganze Unternehmen, und sind dafür auch Accountable. Dafür haben sie vom CEO Ziele bekommen, die sie zu
erfüllen haben, und definieren ihre eigenen Prozesse und planen das auch selbst. Die sind pfiffig, also sind die Prozesse reif und die Arbeit ist gut.

59. Vice President
Product
Vice President
Development
Vice President
Quality
Vice President
Maintenance
Dummerweise gibt es an den Aussenkanten immer Ärger. Und da kommt die DevOps-Kultur her.
Development will, vom Business damit beauftragt, schnelle neue Features in kurzer Zeit. Dafür bekommt sowohl der Vice President Product als auch der Vice President
Development Ihren Jahresbonus.
Auf der anderen Seite spielt Stabilität die entscheidende Rolle - es soll wenig Bugs geben, wenig Reklamationen, wenig Ausfälle und eigentlichen einen 100% stabilen &
kontinuierlichen Regelbetrieb.

60. Fingerpointing
Das kann natürlich nicht klappen, und im Resultat erzeugt man Fingerpointing - die Administration wird als Diktator gesehen, das Development als unfähige
Bugschleudern.

61. Agile
löst die Silo-Effekte zwischen
• Requirements und
• Development und
• Qualität
Agil hat schon Silo-Brecher-Effekte gehabt - Requirements, Development und Qualität greifen bei agilen Methoden hart ineinander.

62. DevOps
löst die Silo-Effekte zwischen
• Requirements und
• Development und
• Qualität und
• Deployment und
• Maintenance und
• Operations
DevOps spannt diesen Bogen noch deutlich weiter - und nimmt Deployment, Maintenance und Operations ebenfalls mit dazu.

63. Vice President
Product
CEO
Vice President
Development
Vice President
Quality
Vice President
Maintenance
Product
Developer
Software
Developer
Quality
Assurance
Operator
Product Owner
Frontend
Developer
Tester
NetSec
Consultant
Product
Designer
Backend
Developer
Test
Infrastructure
Performance
Consultant
Product Development
In der Praxis ergibt das natürlich deutlich Sinn - denn die Produktentwicklung betrifft im Regelfall alle diese Bereiche.

64. Silos abbauen
Wie reisse ich ein Silo ab?

65. Direkte Kooperation
statt Abteilungsgrenzen
Diskussionen & Debatten
statt Handovers & Prozessen
Die einfaches Variante ein Silo zu sprengen ist es zu ignorieren. Ich arbeite nicht in den Grenzen meiner Abteilung, sondern kooperiere direkt. Alle Diskussionen und
Debatten werden direkt mit den anderen Ansprechpartnern geführt, und nicht nur innerhalb meines Development-Departments. Wer war gestern in Judiths Talk? Genau,
diese Art von direkter Kommunikation ist gefragt.

66. Gemeinsame Themen
• Requirements
• Businessmetriken
• Zeitplan / Releaseplanung
• technische Ressourcen
• Architektur
Und dort werden alle Themen diskutiert, die bereichsübergreifende Effekte haben. Das bedeutet nicht nur Requirements, sondern auch die Metriken um sie zu messen.
Das bedeutet Release-Planung, Architekturplanung, die technischen Ressourcen, die eingesetzten werden sollen.

67. Autonomous Cross-
Functional Teams
• enthalten Dev, QA&Ops-Kompetenz
• treffen Dev, QA+Ops-Entscheidungen
selbst
• sind in einer OrgEinheit(!)
• Hand in Hand vs. HandOver
Nukleus dieser Zusammenarbeit ist das autonome Crossfunktionale Team, das minimal alle Development, QA- und Ops-Aspekte als Kompetenz und
Entscheidungsfähigkeit enthält. Sie können selbstständig agieren, und brauche nicht externe Rückfragen zu stellen.

68. Vice President
Product
Vice President
Development
Vice President
Quality
Vice President
Maintenance
Product
Developer
Software
Developer
Quality
Assurance
Operator
Product Owner
Frontend
Developer
Tester
NetSec
Consultant
Product
Designer
Backend
Developer
Test
Infrastructure
Performance
Consultant
CEO
Team
You built it, you run it.
Die Idee dazu kommt - natürlich - aus der agilen Softwareentwicklung, dahinter stehen grossfunktionale Teams. Bei DevOps wird das aber noch erweitert - in „You built it,
you run it.“

69. Geteilte Verantwortung
• Verantwortung für das Produkt statt für
die Abteilung
• Dokumentation & Ticketing ist ein
Werkzeug, kein Vertrag
• Handover ist implizit, nicht explizit
DevOps-Kultur zielt mit der Verantwortung nicht auf lokale Verantwortung - sondern auf shared accountability für das Gesamtsystem.

70. Geteilte Ziele
• Fokus auf
• Produkt
• Gesamtprozess
• Gemeinsame Metriken
• Produktivdaten
• Nutzungsdaten
• Build- & Qualitätsdaten
Damit das funktioniert brauche ich gemeinsame Ziele - mit dem Fokus auf das Produkt und auf den Gesamtprozess. Und ich brauche gemeinsame Metriken, um die
Bewegung in Richtung dieser Ziele zu verstehen.

71. Vice President
Product
Product
Developer
Product Owner
Product
Designer
Goal Goal
Abteilungsziele stehen DevOps unmittelbar im Weg - denn sie erlauben nicht, dass man das Gesamtsystem optimiert.
Der Fokus bei DevOps ist das Gesamtsystem, sprich: das Produkt selbst und alle Prozesse im Unternehmen.

72. Respekt & Vertrauen
(erwiesenermaßen am schwersten)
• Jeder vertraut jedem
• leicht: für die anderen bei mir
• schwer: ich den anderen
• (sogar Product Development!)
Damit die Kooperation funktioniert braucht es Vertrauen, und das ist an dieser Stelle noch eins schwerer. Bei meinen Kollegen brauch ich gar nicht Vertrauen, weil ich es
beurteilen kann. Über die Kompetenzgrenzen hinweg ist dies jedoch nicht möglich.
Das ist sehr leicht für die anderen, weil ich genau weiß was ich tue und es gut mache. Umgekehrt ist das nicht so einfach, denn ich weiß ja gar nicht, was sie tun.

73. „Product Design baut das richtige Produkt“
„Dev baut das Produkt auf die richtige Art.“
„Ops liefert echte, relevante Metriken.“
Respekt & Vertrauen
(erwiesenermaßen am schwersten)
Da ist insbesondere die Grenze in andere, nicht-technische Domains schwierig, denn ich verstehe zu wenig, um Anlass zu vertrauen zu haben. Wie man das trotzdem
macht zeige ich später.

74. Automatisierung
• Gründe für Automatisierung:
• es ist „State of the Art „
• ich las einen Blogartikel
• ich hörte einen Konferenzvortrag
• ich will es auch ausprobieren
• weil ich es kann!
• was mit Cloud drin
Und natürlich ist Automatisierung ein wichtiger Teil auch der DevOps-Kultur.
Wichtig ist hier aber das Ziel. Wenn man mit anderen Entwicklern redet, dann hört man heimlich oft diese Gründe.

75. Automatisierung
• weil es dem Kunden nutzt!
• höhere äussere Qualität
• weniger Fehler
• hohe Verlässlichkeit
• hohe Stabilität
• schnelles Feedback
• schnelle Featureentwicklung
• schnelle Anpassung
Das eigentlich Ziel ist aber ein ganz anderes. Automatisierung soll das Produkt selbst, das Verhalten, den Gesamtprozess und das Feedback verbessern.

76. DevOps-Kultur
Direkte Kooperation
Autonome Teams
Gemeinsame Verantwortung
Gemeinsame Ziele
Automatisierung
Vertrauen & Respekt
Das sind die Pfeiler der DevOps-Kultur: direkte Kooperation, Autonome Teams, gemeinsame Verantwortung und Ziele, Automatisierung und Vertrauen & Respekt.

77. Widersprüche
Klassisch DevOps
Klare
Accountability
Globale
Verantwortung
Abteilungsziele Gemeinsame Ziele
Persönliche Ziele Gemeinsame Ziele
Eigenen Prozess
optimieren
Globalen Prozess
optimieren
Der Haken an der Sache ist: das ganze steht oft im Widerspruch zur bisherigen Unternehmenskultur. Klare Accountability „jemand hat den Hut auf“ widerspricht einer
gemeinsamen Verantwortung. Wenn der mit dem Hut auf einen Fehler macht, ist das in DevOps auch mein Fehler - denn hier geht es um geteilte Verantwortung.
Abteilungsziele und persönliche Ziele - jemand mit Jahreszielen anwesend? - stehen in Widerspruch zu gemeinsamen Zielen. Welche soll ich erfüllen wenn ich die Wahl
habe? Die Verbesserung des eigenen Prozesses steht im Widerspruch zum gemeinsamen Prozess.

78. Diese Widersprüche
führen zu Anti-Pattern
Und genau diese Widersprüche führen zu Antipattern.

79. Vice President
Product
Vice President
Development
Vice President
Quality
Vice President
Maintenance
Product
Developer
Software
Developer
Quality
Assurance
Operator
Product Owner
Frontend
Developer
Tester
NetSec
Consultant
Product
Designer
Backend
Developer
Test
Infrastructure
Performance
Consultant
CEO
Wenn ich aus so einer funtionalen Organisation komme, und ich will DevOps einführen …

80. Vice President
DevOps
Database
DevOps
Enterprise
DevOps
Junior DevOps
Wenn man Automatisierung
mit DevOps verwechselt…
… wird DevOps als
funktionale Abteilung
eingeführt.
CEO
Devops
… und ich von DevOps nur die Tools verstehe, dann passiert folgendes: Ich baue eine neue Abteilung, die sich um DevOps kümmert.

81. Product Development Quality Ass. Maintenance
Antipattern: Neu!
Jetzt auch mit DevOps-Silo!
DevOps
Neu!
Der Effekt ist natürlich ein ganz anderer: statt dem eigentlichen Ziel, der Vermeidung von Schranken und dem durchbrechen von Silos habe ich ein zusätzliches Silo
geschaffen.

82. DevOps nicht Funktion ist.
DevOps sein Form von
Kooperation, die Tools nutzt.
DevOps ist keine Funktion, sondern eine Form der Kooperation, die Tools als unterstützendes Werkzeug einsetzt. DevOps sorgt für gemeinsame Verantwortung und Ziele
von Developern und Operations-Leuten, nicht für eine neue Funktion.

83. Dev Ops
QA
DevOps
Diese Grafik kennen vermutlich die meisten - DevOps als Schnittmenge zwischen QA, Dev und Ops.

84. Developer Role
Operation Role
Quality Assurance Role
+ DevOps Role?
Viele Firmen schliessen daraus, dass es sich in der Mitte offensichtlich um eine neue Rolle handelt, die man jetzt auch bestücken kann. Deshalb gibt es in vielen Firmen
DevOps-Rollen, DevOps-Engineers.

85. DevOps-Engineer
Devs mit QA & Ops-Knowhow
Ops mit QA & Dev-Knowhow
QA mit Dev & Ops-Knowhow
Eigentlich war aber gemeint, dass man gemeinsame Ziele, Metriken und Verantwortung hat - und in dem Zug auch Verständnis für die anderen Domänen.
Ein DevOps-Engineer ist also nicht das, was DevOps meinte, sondern es geht um das gemeinsame Knowhow.

86. DevOps-Engineer -
ein Antipattern,
aber besser als nichts.
Aber es ist trotzdem schön, wenn es ihn gibt - dann vereint wenigstens einer im Team die Kompetenzen, die eigentlich alle haben sollten.

87. Vice President
Development
Software
Developer
Frontend
Developer
DevOps
Engineer
CEO
Development-
only DevOps
Puppet
Vagrant
Jenkins
Test-Stage
! Beta
! Produktion
Antipattern:
Ein weiteres Antipattern, das man häufig sieht: eine DevOps-Rolle, die sich ausschliesslich um Development kümmert. Dort gibt es zwar alles in Puppet, es gibt auch eine
Vagrant-Development-Box, es gibt einen Jenkins, der von ihm administriert wird, und vielleicht sogar einen Test-Stage auf Basis seiner Konfiguration - aber Produktion
und Beta-Environment sehen ganz anders aus.

88. Product
Developer
Software
Developer
Quality
Assurance
Operator
Product Owner
Frontend
Developer
Tester
NetSec
Consultant
Product
Designer
Backend
Developer
Test
Infrastructure
Performance
Consultant
Production-
Environment
SLES
Kopie
Production-
Environment
SLES
Eigene
Plattform
Ubuntu
Product Development
WTF WTF
Aber es geht noch schlimmer als Development-Only-DevOps.
In einem echten Projekt für ein grosses Unternehmen hatten wir folgende Situation:
Die Entwicklungsabteilung hat auf einer Kopie der Standardisierten Produktionsumgebung entwickelt, um möglichst wenig Probleme mit Produktion zu habe. Die
Qualitätsicherungsabteilung hat selbst Ubuntu ausgewählt - es mussten also aus den Produktions-RPMs Debian-Packages gebaut werden, und aus denen dann wieder
RPMs - inklusive diverser Versionsunterschiede.
Die meisten Fehler, die die QA auf die Weise gefunden hat waren inkompatibilitäten zwischen ihrem und dem Produktionsenvironment.

89. DevOps vs Management
Das Management ist eine arme Sau bei DevOps, und das Verschweigen die Unternehmensberatungen meistens. Die müssen gleich mehrfach in den sauren Apfel
beissen.

90. DevOps vs Management
Automatisierung kostet
Strukturen aufweichen
Team - Colocation
Learn & Fail statt Plan & Run
Automatisierung selbst kostet erst mal Geld.
Zunächst müssen die Abteilungsgrenzen aufgeweicht werden - oder direkt neue Teams gebildet werden, die cross-functional arbeiten und die Software, die sie gebaut
haben, auch selbst betreiben.
Die Leute müssen miteinander arbeiten. Das braucht zB einen gemeinsamen Ort. Das ist problematisch, wenn man den Betrieb gerade nach Indien outgesourced hat,
weil das jemand im Controlling mal durchgerechnet hat.
Es braucht Zeit gemeinsam zu lernen, es braucht auch die Möglichkeit gemeinsam Fehler zu machen. DevOps optimiert das Gesamtsystem kontinuierlich, deshalb gib es
keinen Plan & run mehr.

91. Never change a running system.
Always improve a running system.
Es ist sogar noch schlimmer - aus „never change a running system“ wird „always improve a running system.“

92. DevOps vs Firmenkultur
No more lonely heroes
Die Firmenkultur hat es aber auch nicht besser. Die Kooperation in DevOps mit gemeinsamer Verantwortung, gemeinsamen Zielen und gemeinsamen Knowhow zwingt
einem dazu, gemeinsam zu gewinnen oder gemeinsam zu verlieren.

93. Firmenerfolg > Teamerfolg > Einzelerfolg
Keine „SalesDroids“mehr
Keine „dummen FrontEndler“ mehr
Keine „idiotischen Kunden“ mehr
Kein „inkompetentes Management“ mehr
Keine „beknackten Features“ mehr
Kein „mein Team ist grossartig, die
anderen aber nicht“ mehr.
Wir Developer mögen Erfolge, und wir mögen es, wenn wir Dinge gut können und mit unserer Leistung glänzen. Meritokratie ist hervorragend, da können wir zeigen, was
wir alle zustande bringen. Eine DevOps-Kultur fokussiert aber nicht auf mich, sondern auf das grosse ganze - und deshalb kann ich nicht länger in der Rolle Held
zwischen Idioten überleben, sondern muss meine ganze Energie daran setzen, das Gesamtsystem zu verbessern.

94. Uh, und wie mache ich das jetzt?
Und wie komme ich jetzt zu einer DevOps Kultur?

95. 3Ways of DevOps
Netterweise gibt es da inzwischen gute Ansätze. Der bekannteste sind die 3 Ways of DevOps, die auch demnächst im DevOps cookbook herauskommen.

96. 1 Systems Thinking
Der erste Ansatz ist Systems Thinking, also der gemeinsame Blick auf das Gesamtsystem, um es zu verstehen und verbessern zu können.

97. 1 Systems Thinking
Eine professionelle Variante dazu ist Value Stream Mapping, bei dem die Prozesse eines Unternehmens in Folge betrachtet werden. Das ist eher nontrivial, deshalb
empfehlen wir

98. 1 Systems Thinking
Draw how to make
Toast
http://www.drawtoast.com/
… eine andere Methode - „Draw how to make toast“. Da gibt es einen hervorragenden 10 Minute-TedTalk dazu, und eine Website auf der alles notwendige erklärt wird -
es gibt sogar diverse Templates. Ich hätte den Film gerne heute gezeigt, aber die 10 Minuten bekommt ihr auch anders hin.

99. 2 Amplify Feedback
Loops
Der zweite Weg ist die Verstärkung von Feedback Loops. Dazu muss ich erst mal welche haben, und zwar über die gesamte Strecke von Rechts nach links.

100. Loops
2 Amplify Feedback
Product
Development
Software
Development
Deployment
Business
Analytics
Management
Das ist ein typischer Feedback-Loop in einem IT-Unternehmen. Das Management entscheidet, wie das Produkt sich weiterentwickeln soll, das Product Development
entwickelt und konzipiert es, das Development baut es, die Admins deployen es und der Business-Analytics-Mensch misst, ob das schlau war - und sagt dann dem
Manager Bescheid.

101. 2 Amplify Feedback
Product
Development
Software
Development
Deployment
Business
Analytics
Management 1 Monate
3 Monate
1 Woche
1 Sprint
1 Tag
143 Tage!
Loops
Der Nachteil an so einem Feedback-Loop ist das Tempo. Nach der Vorstandssitzung dauert es eine Woche, bis das Product Development was davon erfährt, das kann
beim Entwickler immer nur pro Sprint einmal neue Dinge einkippen, der Deploy geht schnell - denn wir machen DevOps - dann braucht der Business-Analytics-Guy aber
wieder einen Monat, um relevante Daten zu sammeln, und sein Bericht muss dann auch wieder bis zur nächsten Vorstandssitzung warten, damit das Produkt angepasst
werden kann. Die beste Reaktionsgeschwindigkeit so eines Loops liegt in diesem Fall bei 143 Tagen - offensichtlich kann man so nicht schnell arbeiten und lernen oder
den Prozess verbessern.

102. 2 Amplify Feedback
Product
Development
Software
Development
Deployment
Business
Analytics
1 Woche
1 Tag
1 Sprint
1 Tag
23 Tage Loop
Loops
Management
Der nächste Schritt das kürzen & beschleunigen dieses Loops. Wenn das Management zB nicht mehr im Detail mitmischt, das Business-Analytics-Feedback schneller
kommt - dann wird der Feedback-Loop um mehr als Faktor 6 beschleunigt, und sowohl Produkt als auch Prozessverbesserungen finden schnell statt. Aber
Prozessverbesserung ist nur die eine Hälfte - die andere hälfte zu guten Prozessen und guten Produkten ist Innovation. Und wie bekomme ich Innovation?

103. 3Culture of Continual
Experimentation & Failure
Der letzte Schritt ist die „Culture of Continual Experimentation & Failure“.

104. 3Culture of Continual
Experimentation & Failure
Fail cheap
Fail often
Dahinter steht eine alte Idee von uns Webleuten: fail cheap & fail often.
Wenn ich die Feedback-schleife kurz habe, und einen schnellen Prozess habe. dann kann ich auch preiswerte Fehler machen. Und ich lege es nicht mehr darauf an, das
beste theoretische Produkt zu erzeugen - sondern das beste am Kunden selbst getestete & validierte.

105. 3Culture of Continual
Sichtbarkeit
Resilienz
Experimentation & Failure
Damit ich das bekommen kann brauche ich hohe Transparenz und Sichtbarkeit - und das muss meine Firmenkultur ertragen können. Und netterweise passiert das auch,
aber über Zeit. Um so mehr ich transparent aus Fehlern lernen kann, um so resilienter wird mein Unternehmen. Und um so besser verstehe ich die Kollegen.

106. 3Ways of DevOps
Systems Thinking
Amplify Feedback Loops
Culture of Continual Experientation
DevOps-Culture
ist das Outcome
Eine DevOps-Kultur kann man - wie jede Kultur - nicht einfach machen - aber ich kann mit diesen drei Wegen dafür sorgen, dass sie eine gute Chance hat zu entstehen.
Sie ist das Outcome aus dem gemeinsamen Verständnis, der Kooperation und dem Reflektieren.

107. DevOps-Kultur
Direkte Kooperation
Autonome Teams
Gemeinsame Verantwortung
Gemeinsame Ziele
Automatisierung
Vertrauen & Respekt
Und damit komme ich in der Folge nicht nur zu einer DevOps-Kultur, sondern ich kann es auch den Projektmanagern zeigen.

108. „All three, please.“
Indem ich von Good, Cheap and Fast einfach alle 3 mache.

109. Danke!
Fragen: @johannhartmann
hartmann@mayflower.de
https://hashtagagile.slack.com/
Slides mit Tonspur:
http://slideshare.net/johannhartmann
Wer Fragen hat, kann sich gerne an mich wenden. Wer Beratung dazu will - einfach Judith Andresen fragen, die kann so Dinge.