DevOps jenseits der Tools

14.644 Aufrufe

Veröffentlicht am

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?

Veröffentlicht in: Software
0 Kommentare
6 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
14.644
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
11.020
Aktionen
Geteilt
0
Downloads
19
Kommentare
0
Gefällt mir
6
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

DevOps jenseits der Tools

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

×