Johann-Peter Hartmann, profile picture
Hochgeladen vonJohann-Peter Hartmann
PDF, PPTX17,106 aufrufe

DevOps jenseits der Tools

Das Dokument reflektiert über fünf Jahre DevOps-Erfahrung und betont die Entwicklung von DevOps von einer Neuheit zu einer etablierten Praxis in Unternehmen. Es wird die Bedeutung einer geeigneten Unternehmenskultur hervorgehoben, um DevOps erfolgreich umzusetzen, sowie die Notwendigkeit, Silos zwischen Abteilungen abzubauen und gemeinsame Verantwortungen zu fördern. Der Fokus liegt auf der Automatisierung von Prozessen, um die Effizienz und Zuverlässigkeit bei der Softwareentwicklung zu steigern.

Präsentation einbetten

Als PDF, PPTX herunterladen
1 / 109
2 / 109
3 / 109
4 / 109
5 / 109
6 / 109
7 / 109
8 / 109
9 / 109
10 / 109
11 / 109
12 / 109
13 / 109
14 / 109
15 / 109
16 / 109
17 / 109
18 / 109
19 / 109
20 / 109
21 / 109
22 / 109
23 / 109
24 / 109
25 / 109
26 / 109
27 / 109
28 / 109
29 / 109
30 / 109
31 / 109
32 / 109
33 / 109
34 / 109
35 / 109
36 / 109
37 / 109
38 / 109
39 / 109
40 / 109
41 / 109
42 / 109
43 / 109
44 / 109
45 / 109
46 / 109
47 / 109
48 / 109
49 / 109
50 / 109
51 / 109
52 / 109
53 / 109
54 / 109
55 / 109
56 / 109
57 / 109
58 / 109
59 / 109
60 / 109
61 / 109
62 / 109
63 / 109
64 / 109
65 / 109
66 / 109
67 / 109
68 / 109
69 / 109
70 / 109
71 / 109
72 / 109
73 / 109
74 / 109
75 / 109
76 / 109
77 / 109
78 / 109
79 / 109
80 / 109
81 / 109
82 / 109
83 / 109
84 / 109
85 / 109
86 / 109
87 / 109
88 / 109
89 / 109
90 / 109
91 / 109
92 / 109
93 / 109
94 / 109
95 / 109
96 / 109
97 / 109
98 / 109
99 / 109
100 / 109
101 / 109
102 / 109
103 / 109
104 / 109
105 / 109
106 / 109
107 / 109
108 / 109
109 / 109
DevOps jenseits der Tools Hallo Zusammen! Ich möchte nämlich etwas persönliches erzählen.
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.
Wer von Euch kennt noch die Tools links und rechts? Genau, das war die Zeit. Da haben wir etwa mit DevOps angefangen.
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.
… 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.
Wir haben sogar Kollegen, die alleine DevOps gemacht 
 haben. Wir haben sogar Kollegen gehabt, die alleine DevOps gemacht haben.
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.
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.
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.
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“.
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“ :-)
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.
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.
Puppet Labs, Hersteller der dicken Infrastructure as Code-Lösung Puppet, fragt einmal jährlich den State of DevOps ab.
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.
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.
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.
Wer macht DevOps? Wer von Euch macht DevOps?
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?
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?
(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.
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?
Ansible, Salt, Fabric? Bitte mitrechnen: Jeweils 3 Hipsterpunkte Wer setzt Anbisse, Salt, Fabric ein? Bitte 3 Hipsterpunkte addieren.
Vagrant, Otto? Vagrant: 1 Punkt Otto: 5 Punkte. Wer setzt Vagrant ein? Wer setzt Otto ein?
Docker? Bitte mitrechnen: 1 Hipsterpunkt
Docker in Produktion? Bitte mitrechnen: 3 Hipsterpunkte
Docker in Produktion mit Kubernetes? Bitte mitrechnen: 5 Hipsterpunkte
Docker in Produktion mit Kubernetes für 
 MicroServices? Bitte mitrechnen: 8 Hipsterpunkte
Jenkins, Travis, TeamCity? Bitte mitrechnen: Jeweils 1 Hipsterpunkt
Continous Deployment? Bitte mitrechnen: Jeweils 1 Hipsterpunkt
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?
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?
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?
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.
Enterprise-Style Deployment Es ist jedes mal spannend zu sehen, ob noch jemand mit Quartalsweisen Deployments da ist.
Monitoring? Reporting? Wer von Euch macht übergreifendes Monitoring? Genau, das sind schon weniger. ELK? Nagios, Zabbix & Sensu?
DevOps: Check, Tools are there.
CAMS Aber DevOps ist … Kennt noch jemand Dieses Akronym?
CAMS Culture Automation Measurement Sharing Genau, das war eine der frühen Definitionen von DevOps - Culture, Automation, Measurement, Sharing.
CAMS Culture Automation Measurement Sharing Und meist ist nur die Automatisierung übrig geblieben, und ein bisschen vom Measurement.
Automation klappt doch super. Warum dann den Rest machen? Culture Automation Measurement Sharing
„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.
Was ist denn die richtige Kultur? Ok, wir brauchen also die richtige Kultur - aber was ist denn Bitte die richtige Kultur?
Worum es bei DevOps geht … Schauen wir uns doch einmal an, worum es bei DevOps eigentlich geht …
Features schneller von der Idee zum Kunden DevOps sollte Features schneller zum Kunden bringen, und damit das ganze Unternehmen beschleunigen.
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.
Weniger Wartezeiten auf 
 Dev, QA, Ops, andere Teams, Requirements Ein sicherer Weg zu mehr Geschwindigkeit ist natürlich auch weniger Warten.
Die Verlässlichkeit der Applikation erhöhen. Gleichzeitig soll es die Verlässlichkeit erhöhen. Weniger Ausfälle, weniger seltsames Verhalten, besseres Skalieren etc.
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?
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.
„Menschliches Versagen“ und Blamestorming Resultat von der höhere Verlässlichkeit ist eine Reduktion von „menschlichen“ Fehlerzuweisungen.
Deployment: 
 Aufwand & Kosten minimieren
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.
DevOps Kultur Was bedeuten diese Ziele für die DevOps-Kultur?
„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.
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.
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.
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.
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.
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.
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.
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.
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.
Silos abbauen Wie reisse ich ein Silo ab?
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.
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.
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.
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.“
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.
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.
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.
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.
„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.
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.
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.
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.
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.
Diese Widersprüche führen zu Anti-Pattern Und genau diese Widersprüche führen zu Antipattern.
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 …
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.
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.
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.
Dev Ops QA DevOps Diese Grafik kennen vermutlich die meisten - DevOps als Schnittmenge zwischen QA, Dev und Ops.
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.
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.
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.
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.
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.
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.
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.
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.“
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.
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.
Uh, und wie mache ich das jetzt? Und wie komme ich jetzt zu einer DevOps Kultur?
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.
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.
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
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.
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.
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.
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.
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?
3Culture of Continual Experimentation & Failure Der letzte Schritt ist die „Culture of Continual Experimentation & Failure“.
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.
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.
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.
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.
„All three, please.“ Indem ich von Good, Cheap and Fast einfach alle 3 mache.
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.

Weitere ähnliche Inhalte

PDF
About Dogs and Cats - über DevOps in großen Konzernen
vonStefan Bauer
 
PDF
DevOps - Programmierst Du noch oder betreibst Du schon?
vonJean-Pierre König
 
PDF
RoofTop Brains & BBQ: Ein Gästbuch für China
vonJohann-Peter Hartmann
 
PDF
Scrum als agiles Vorgehensmodell für Programmierer
vonTobias Schlüter
 
PDF
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
vonMayflower GmbH
 
PDF
Einfangen eines technisch kaputten projektes
vonJohann-Peter Hartmann
 
PDF
Erfolgreiche rewrites
vonJohann-Peter Hartmann
 
PPTX
DevOps: Revolution im IT Betrieb?
vonDigicomp Academy AG
 
About Dogs and Cats - über DevOps in großen Konzernen
vonStefan Bauer
 
DevOps - Programmierst Du noch oder betreibst Du schon?
vonJean-Pierre König
 
RoofTop Brains & BBQ: Ein Gästbuch für China
vonJohann-Peter Hartmann
 
Scrum als agiles Vorgehensmodell für Programmierer
vonTobias Schlüter
 
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
vonMayflower GmbH
 
Einfangen eines technisch kaputten projektes
vonJohann-Peter Hartmann
 
Erfolgreiche rewrites
vonJohann-Peter Hartmann
 
DevOps: Revolution im IT Betrieb?
vonDigicomp Academy AG
 

Was ist angesagt?

PDF
E-Commerce vs Architektur CodeTalks.Commerce_2018
vonJohann-Peter Hartmann
 
PDF
Performancemessung, jetzt in echt
vonJohann-Peter Hartmann
 
PDF
DevOps in der Praxis
voninovex GmbH
 
KEY
OOP 2012 - Udo Pracht - DevOps Einführung und Überblick
vonUdo Pracht
 
PDF
Quo vadis DevOps
voncusy GmbH
 
PDF
Legacy php - Sanieren oder Ablösen?
vonJohann-Peter Hartmann
 
PPTX
Advanced Continuous Integration
vonOPITZ CONSULTING Deutschland
 
PDF
Anforderungen haben immer Schuld
vonFrank Düsterbeck
 
PDF
Meine! Deine! Keine! Verantwortung in agilen Teams
vonFrank Düsterbeck
 
PDF
DevOps - ab auf die Reise
vonAlex Lichtenberger
 
PDF
23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
vonStephan Schmidt
 
PDF
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten
vonStephan Schmidt
 
PDF
Agile Anti-Patterns
vonMayflower GmbH
 
PDF
E-Commerce Organisationsstrukturen
vonBjörn Schotte
 
PDF
NewWork in der Praxis
vonJohann-Peter Hartmann
 
PDF
DevOps day - feature teams
vonWalter Strametz
 
PDF
Bessere Software schneller liefern
vonMayflower GmbH
 
PDF
Arbeitsorganisation
vonBenJannedy
 
PDF
Day CQ 5.3 WCM - Was ist neu
vonCédric Hüsler
 
PDF
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
vonMayflower GmbH
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
vonJohann-Peter Hartmann
 
Performancemessung, jetzt in echt
vonJohann-Peter Hartmann
 
DevOps in der Praxis
voninovex GmbH
 
OOP 2012 - Udo Pracht - DevOps Einführung und Überblick
vonUdo Pracht
 
Quo vadis DevOps
voncusy GmbH
 
Legacy php - Sanieren oder Ablösen?
vonJohann-Peter Hartmann
 
Advanced Continuous Integration
vonOPITZ CONSULTING Deutschland
 
Anforderungen haben immer Schuld
vonFrank Düsterbeck
 
Meine! Deine! Keine! Verantwortung in agilen Teams
vonFrank Düsterbeck
 
DevOps - ab auf die Reise
vonAlex Lichtenberger
 
23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
vonStephan Schmidt
 
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten
vonStephan Schmidt
 
Agile Anti-Patterns
vonMayflower GmbH
 
E-Commerce Organisationsstrukturen
vonBjörn Schotte
 
NewWork in der Praxis
vonJohann-Peter Hartmann
 
DevOps day - feature teams
vonWalter Strametz
 
Bessere Software schneller liefern
vonMayflower GmbH
 
Arbeitsorganisation
vonBenJannedy
 
Day CQ 5.3 WCM - Was ist neu
vonCédric Hüsler
 
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
vonMayflower GmbH
 

Andere mochten auch

PDF
Java script security for java developers
vonJohann-Peter Hartmann
 
PDF
How not to screw the operating system of your startup
vonJohann-Peter Hartmann
 
PDF
Von Kutschern, Managern und Systemadministratoren
vonJohann-Peter Hartmann
 
PDF
JavaScript Security
vonJohann-Peter Hartmann
 
PDF
Warum die it nicht um new work herumkommt
vonJohann-Peter Hartmann
 
PDF
Wetware Bugs and Refactoring
vonJohann-Peter Hartmann
 
PDF
Leadership in der IT
vonJohann-Peter Hartmann
 
PDF
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
vonJohann-Peter Hartmann
 
PDF
DevOps beyond the Tools
vonJohann-Peter Hartmann
 
PDF
Rewrites überleben
vonJohann-Peter Hartmann
 
PDF
Management brainfucks
vonJohann-Peter Hartmann
 
PDF
Agile versus Management WJAX 2014
vonJohann-Peter Hartmann
 
PDF
Das Ende der Karriere
vonJohann-Peter Hartmann
 
PPTX
Javascript Security
vonjgrahamc
 
PDF
Die Architektur, die man kann
vonJohann-Peter Hartmann
 
PDF
Lügen, schlimme Lügen und IT-Verträge
vonJohann-Peter Hartmann
 
PDF
Reparier Deine Unternehmenskultur!
vonJohann-Peter Hartmann
 
Java script security for java developers
vonJohann-Peter Hartmann
 
How not to screw the operating system of your startup
vonJohann-Peter Hartmann
 
Von Kutschern, Managern und Systemadministratoren
vonJohann-Peter Hartmann
 
JavaScript Security
vonJohann-Peter Hartmann
 
Warum die it nicht um new work herumkommt
vonJohann-Peter Hartmann
 
Wetware Bugs and Refactoring
vonJohann-Peter Hartmann
 
Leadership in der IT
vonJohann-Peter Hartmann
 
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
vonJohann-Peter Hartmann
 
DevOps beyond the Tools
vonJohann-Peter Hartmann
 
Rewrites überleben
vonJohann-Peter Hartmann
 
Management brainfucks
vonJohann-Peter Hartmann
 
Agile versus Management WJAX 2014
vonJohann-Peter Hartmann
 
Das Ende der Karriere
vonJohann-Peter Hartmann
 
Javascript Security
vonjgrahamc
 
Die Architektur, die man kann
vonJohann-Peter Hartmann
 
Lügen, schlimme Lügen und IT-Verträge
vonJohann-Peter Hartmann
 
Reparier Deine Unternehmenskultur!
vonJohann-Peter Hartmann
 

Ähnlich wie DevOps jenseits der Tools

PDF
VSHN DevOps Workshop at topsoft 2019
vonMarkus Speth
 
PDF
DevOps Prinzipien im Zusammenspiel mit Kubernetes
vonQAware GmbH
 
PDF
Das Mindset von DevOps
vonChristinaLerch1
 
PDF
DevOps + Continuous Delivery + Cloud: The Three Drivers of Enterprise Agility...
vonSchlomo Schapiro
 
PPTX
Agents of D.E.V.O.P.S
vonConSol Consulting & Solutions Software GmbH
 
PDF
Quo vadis-devops-nuernberg
voncusy GmbH
 
PDF
DevOps Sepc15
vonFlorian Thiévent
 
PDF
Devops
voninovex GmbH
 
PPTX
DevOps: Change Mindset before Toolset
vonOPITZ CONSULTING Deutschland
 
PDF
Architektur und Automation als Enabler für DevOps
vonmatfsw
 
PDF
DevOps und ITIL: Waffenbrüder oder Feinde?
vonOPITZ CONSULTING Deutschland
 
PDF
Xidra 2016 DevOps
vonEduard van den Bongard
 
PDF
BizDevOps - Die prozessorientierte IT-Organisation
vonUwe Weng
 
PDF
Migration von Applikationen in die Cloud
vonAarno Aukia
 
PDF
Agile, DevOps, Continuous Delivery: Was ist das und wie betrifft es mich als ...
vonNico Meisenzahl
 
PDF
DEVOPS
vontechdev Solutions
 
PPTX
Evolution der Softwareentwicklung: Von Wasserfall über Agile zu DevOps
vonDieter Ziegler
 
PPTX
Lean development 04
vonSuperB2
 
PDF
OC|Weekly Talk The Power of DevOps…
vonOPITZ CONSULTING Deutschland
 
PDF
Liebe Mobiliar, wie macht Ihr eigentlich DevOps?
vonPhilipp Grossenbacher
 
VSHN DevOps Workshop at topsoft 2019
vonMarkus Speth
 
DevOps Prinzipien im Zusammenspiel mit Kubernetes
vonQAware GmbH
 
Das Mindset von DevOps
vonChristinaLerch1
 
DevOps + Continuous Delivery + Cloud: The Three Drivers of Enterprise Agility...
vonSchlomo Schapiro
 
Agents of D.E.V.O.P.S
vonConSol Consulting & Solutions Software GmbH
 
Quo vadis-devops-nuernberg
voncusy GmbH
 
DevOps Sepc15
vonFlorian Thiévent
 
Devops
voninovex GmbH
 
DevOps: Change Mindset before Toolset
vonOPITZ CONSULTING Deutschland
 
Architektur und Automation als Enabler für DevOps
vonmatfsw
 
DevOps und ITIL: Waffenbrüder oder Feinde?
vonOPITZ CONSULTING Deutschland
 
Xidra 2016 DevOps
vonEduard van den Bongard
 
BizDevOps - Die prozessorientierte IT-Organisation
vonUwe Weng
 
Migration von Applikationen in die Cloud
vonAarno Aukia
 
Agile, DevOps, Continuous Delivery: Was ist das und wie betrifft es mich als ...
vonNico Meisenzahl
 
DEVOPS
vontechdev Solutions
 
Evolution der Softwareentwicklung: Von Wasserfall über Agile zu DevOps
vonDieter Ziegler
 
Lean development 04
vonSuperB2
 
OC|Weekly Talk The Power of DevOps…
vonOPITZ CONSULTING Deutschland
 
Liebe Mobiliar, wie macht Ihr eigentlich DevOps?
vonPhilipp Grossenbacher
 

Mehr von Johann-Peter Hartmann

PPTX
The End of my Career
vonJohann-Peter Hartmann
 
PDF
Vom Entwickler zur Führungskraft
vonJohann-Peter Hartmann
 
PDF
Surviving Complexity
vonJohann-Peter Hartmann
 
PDF
Serverside Cryptoparty
vonJohann-Peter Hartmann
 
PDF
JavaScript und Security - JavaScript Days 2013 Berlin
vonJohann-Peter Hartmann
 
PDF
Profiling for Grown-Ups
vonJohann-Peter Hartmann
 
KEY
Paradigmenwechsel bei webapplikationen
vonJohann-Peter Hartmann
 
The End of my Career
vonJohann-Peter Hartmann
 
Vom Entwickler zur Führungskraft
vonJohann-Peter Hartmann
 
Surviving Complexity
vonJohann-Peter Hartmann
 
Serverside Cryptoparty
vonJohann-Peter Hartmann
 
JavaScript und Security - JavaScript Days 2013 Berlin
vonJohann-Peter Hartmann
 
Profiling for Grown-Ups
vonJohann-Peter Hartmann
 
Paradigmenwechsel bei webapplikationen
vonJohann-Peter Hartmann
 

DevOps jenseits der Tools

  • 1.
    DevOps jenseits derTools Hallo Zusammen! Ich möchte nämlich etwas persönliches erzählen.
  • 2.
    27.10.2010 Mein erstes Mal. Meinerstes 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 Euchkennt noch die Tools links und rechts? Genau, das war die Zeit. Da haben wir etwa mit DevOps angefangen.
  • 4.
    DevOps @ Mayflower: 5Jahre 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 invielen 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 sogarKollegen, die alleine DevOps gemacht 
 haben. Wir haben sogar Kollegen gehabt, die alleine DevOps gemacht haben.
  • 7.
    Deshalb gibt esdiesen 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ückzu DevOps. DevOps hat sich von einer Sache „die man mal angucken muss“ zu einer fest etablierten Größe entwickelt.
  • 9.
    Accenture, 2014 No longercan 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 Developmentto 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: als2009 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 DieGartner 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 GartnerSays 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, Herstellerder dicken Infrastructure as Code-Lösung Puppet, fragt einmal jährlich den State of DevOps ab.
  • 15.
    Puppet Labs, 2015 …high-performingIT 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’stheir 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? Wervon Euch macht DevOps?
  • 19.
    Wer von Euchist 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 inder 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 warenjetzt 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? Bittemitrechnen: 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? Bittemitrechnen: Jeweils 3 Hipsterpunkte Wer setzt Anbisse, Salt, Fabric ein? Bitte 3 Hipsterpunkte addieren.
  • 24.
    Vagrant, Otto? Vagrant: 1Punkt Otto: 5 Punkte. Wer setzt Vagrant ein? Wer setzt Otto ein?
  • 25.
  • 26.
    Docker in Produktion? Bittemitrechnen: 3 Hipsterpunkte
  • 27.
    Docker in Produktionmit Kubernetes? Bitte mitrechnen: 5 Hipsterpunkte
  • 28.
    Docker in Produktionmit Kubernetes für 
 MicroServices? Bitte mitrechnen: 8 Hipsterpunkte
  • 29.
    Jenkins, Travis, TeamCity? Bittemitrechnen: Jeweils 1 Hipsterpunkt
  • 30.
  • 31.
    0 Punkte? 1-5 Punkte? 6-10Punkte? 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 machtIhr 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 >= 1mal 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. Daist 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 istjedes mal spannend zu sehen, ob noch jemand mit Quartalsweisen Deployments da ist.
  • 36.
    Monitoring? Reporting? Wer vonEuch macht übergreifendes Monitoring? Genau, das sind schon weniger. ELK? Nagios, Zabbix & Sensu?
  • 37.
  • 38.
    CAMS Aber DevOps ist… Kennt noch jemand Dieses Akronym?
  • 39.
    CAMS Culture Automation Measurement Sharing Genau, das wareine der frühen Definitionen von DevOps - Culture, Automation, Measurement, Sharing.
  • 40.
    CAMS Culture Automation Measurement Sharing Und meist istnur die Automatisierung übrig geblieben, und ein bisschen vom Measurement.
  • 41.
    Automation klappt dochsuper. Warum dann den Rest machen? Culture Automation Measurement Sharing
  • 42.
    „Even with thebest 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 denndie richtige Kultur? Ok, wir brauchen also die richtige Kultur - aber was ist denn Bitte die richtige Kultur?
  • 44.
    Worum es bei DevOpsgeht … Schauen wir uns doch einmal an, worum es bei DevOps eigentlich geht …
  • 45.
    Features schneller von derIdee zum Kunden DevOps sollte Features schneller zum Kunden bringen, und damit das ganze Unternehmen beschleunigen.
  • 46.
    Performance- und Userfeedback schnelleran 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 Applikationerhö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 Dasbeinhaltet 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 Resultatvon der höhere Verlässlichkeit ist eine Reduktion von „menschlichen“ Fehlerzuweisungen.
  • 52.
    Deployment: 
 Aufwand &Kosten minimieren
  • 53.
    Konkret verspricht DevOpsalso, 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 bedeutendiese Ziele für die DevOps-Kultur?
  • 55.
    „DevOps is justshort 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 QualityAss. 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 VicePresident 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 VicePresident 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 VicePresident 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ürlichnicht 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-Effektezwischen • 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-Effektezwischen • 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 VicePresident 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 reisseich 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 VicePresident 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 • Verantwortungfü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 • Fokusauf • 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 GoalGoal 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ßenam 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 bautdas 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ürAutomatisierung: • 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 esdem 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 GemeinsameVerantwortung 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 zuAnti-Pattern Und genau diese Widersprüche führen zu Antipattern.
  • 79.
    Vice President Product Vice President Development VicePresident 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 QualityAss. 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 Funktionist. 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 Grafikkennen vermutlich die meisten - DevOps als Schnittmenge zwischen QA, Dev und Ops.
  • 84.
    Developer Role Operation Role QualityAssurance 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, aberbesser 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 ProductDevelopment 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 DasManagement 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 Automatisierungkostet
 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 arunning 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 Nomore 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 wiemache ich das jetzt? Und wie komme ich jetzt zu einer DevOps Kultur?
  • 95.
    3Ways of DevOps Netterweisegibt 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 Dererste Ansatz ist Systems Thinking, also der gemeinsame Blick auf das Gesamtsystem, um es zu verstehen und verbessern zu können.
  • 97.
    1 Systems Thinking Eineprofessionelle 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 Drawhow 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 Derzweite 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 SystemsThinking 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 GemeinsameVerantwortung 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.“ Indemich von Good, Cheap and Fast einfach alle 3 mache.
  • 109.
    Danke! 
 Fragen: @johannhartmann hartmann@mayflower.de https://hashtagagile.slack.com/ 
 Slides mitTonspur: 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.