DevOps beyond the Tools

Editor's Notes

• #2: Hello and welcome to the talk about devops beyond the tools. This is a bit of a revival talk, about a topic that somehow got lost in the devops world.
• #3: Actually it’s not ten years old yet. DevOps is in the third grade now. It was born as „Agile Operations“ in 2009. Patrick Debois coined the word „devops“ for it.
• #4: Do you remember when it all started ten years ago? Who was there right from the beginning?
• #5: Actually it’s not ten years old yet. DevOps is in the third grade now. It was born as „Agile Operations“ in 2009. Patrick Debois coined the word „devops“ for it.
• #6: That was one slide from the talk „10+ deploys a day“ by flickr at velocity 2009. While there was dev and ops involved, there was still an „and“ in the middle.
• #7: That was the tool world back in the days. We actually met the inventor of the term devops - patrick debois - in the augustinergarten biergarten in 2010, and he was talking about how great cfengine was. Hey, jenkins is on hold in the thought works technology radar today.
• #8: Just one year later gartner group figure it out and said that devops will come.
• #9: Who does devops today?
• #10: and it did. if even the big consultancies talk about it you know that you are there.
• #11: Even cap gemini! (ok, it’s dev to ops for them)
• #12: And in 2015 gartner group finally predicted that it will be early majority by 2016
• #13: .. for a reason, since everything gets better with devops. a lot faster …
• #14: And puppet labs figured, as a devops company, that it is exactly devops that makes companies successful.
• #15: Who does devops today?
• #16: Ist jemand von Euch der DevOps in einem Team oder in der Firma?
• #17: Und wer hat ein DevOps-Team in der Firma, das sich um die Automatisierung von Aufgaben kümmert?
• #18: 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.
• #19: 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?
• #20: 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?
• #21: Wer setzt Anbisse, Salt, Fabric ein? Bitte 3 Hipsterpunkte addieren.
• #26: Wer von Euch hat gar keinen Punkt? Wer hat zwischen 1 und 5? Wer hat zwischen 6 und 10? Wer hat mehr als 15?
• #27: Wie oft deployed ihr?
• #28: Und wie oft werden dabei wirklich neue Features live genommen?
• #29: 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.
• #30: Es ist jedes mal spannend zu sehen, ob noch jemand mit Quartalsweisen Deployments da ist.
• #31: Wer von Euch macht übergreifendes Monitoring? Genau, das sind schon weniger. ELK? Nagios, Zabbix & Sensu?
• #33: Does anyone remember this acronym?
• #34: Genau, das war eine der frühen Definitionen von DevOps - Culture, Automation, Measurement, Sharing.
• #35: Und meist ist nur die Automatisierung übrig geblieben, und ein bisschen vom Measurement.
• #37: And we all know - if even martin fowler says it, it’s true. It’s great. it’s true.
• #38: Ok, wir brauchen also die richtige Kultur - aber was ist denn Bitte die richtige Kultur?
• #39: DevOps sollte Features schneller zum Kunden bringen, und damit das ganze Unternehmen beschleunigen.
• #40: Ein sicherer Weg zu mehr Geschwindigkeit ist natürlich auch weniger Warten.
• #41: 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.
• #42: 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.
• #43: 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.
• #44: Who has got this kind of organigram somewhere in his company? That’s a functional organization, and it’s the prototype for every second company out there. It’s one of the major inventions of scientific management.
• #45: This kind of organization does a few things pretty good. Specialization helps to divide the work so nobody needs to know everything. It’s easy to control, since mental functions are separated from manual functions. It’s efficient, since you only need to know what you need to know. It’s cheap, because you can work with standardized processes, components and people. And it scales, you can just create a tree for each node.
• #46: Even better - this kind of company is easy to command & control using cascading objectives and key performance indicators.
• #47: Und wie so oft waren die Militärs uns agilen Leuten einen Schrittweit voraus. Schon in den 90ern wussten sie, wie sich solche Welten anfühlen. Und nannten das VUCA - Volatil, dh. schneller und häufiger Wechsel. Uncertainty, weil es nicht mehr möglich ist, gute Vorhersagen zu machen. Komplex, weil viele Faktoren ineinander greifen und interagieren, und damit klare Ursachen und Wirkungen wegfallen - und Ambiguität, weil ich zwar viel Information bekomme, es aber auch eine Vielzahl von Schlüssen gibt, die ich daraus ziehen kann.
• #48: So richtig wissenschaftlich hat das Herr Ashby 1956 in seiner Introduction to Cybernetics - die auch dieses Wort erst mal so richtig unter die Leute brachte - formuliert. Varietät absorbiert Varietät, und deshalb brauche ich für ein System, dass mit einem anderen umgehen soll, mindestens die gleiche Anzahl von Status.
• #49: Does anyone remember this diagram? That’s the wall of confusion.
• #50: Das kann natürlich nicht klappen, und im Resultat erzeugt man Fingerpointing - die Administration wird als Diktator gesehen, das Development als unfähige Bugschleudern.
• #51: 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.
• #52: Agil hat schon Silo-Brecher-Effekte gehabt - Requirements, Development und Qualität greifen bei agilen Methoden hart ineinander.
• #53: DevOps spannt diesen Bogen noch deutlich weiter - und nimmt Deployment, Maintenance und Operations ebenfalls mit dazu.
• #54: That makes a lot of sense in the real world - since product development in online companies affects all areas of the organization.
• #55: Ok, who do you remove silos? Obviously you have to get rid of the walls between the departments.
• #56: That means - direct cooperation instead of departmental boundaries. If you want something from the other department, you don’t talk to the head of, you talk to the people. Direct cooperation means that you discuss stuff with the people in the other department, and
• #57: 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.
• #58: DevOps-Kultur zielt mit der Verantwortung nicht auf lokale Verantwortung - sondern auf shared accountability für das Gesamtsystem.
• #59: 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.
• #61: 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.
• #62: 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.
• #63: 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.
• #64: Das sind die Pfeiler der DevOps-Kultur: direkte Kooperation, Autonome Teams, gemeinsame Verantwortung und Ziele, Automatisierung und Vertrauen & Respekt.
• #65: 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.
• #66: Und genau diese Widersprüche führen zu Antipattern.
• #67: If my organization looks like this …
• #68: … und ich von DevOps nur die Tools verstehe, dann passiert folgendes: Ich baue eine neue Abteilung, die sich um DevOps kümmert.
• #69: 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.
• #70: 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.
• #71: Diese Grafik kennen vermutlich die meisten - DevOps als Schnittmenge zwischen QA, Dev und Ops.
• #72: 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.
• #73: 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.
• #74: Aber es ist trotzdem schön, wenn es ihn gibt - dann vereint wenigstens einer im Team die Kompetenzen, die eigentlich alle haben sollten.
• #75: 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.
• #76: That was another anti pattern we encountered. The Development department
• #77: Das Management ist eine arme Sau bei DevOps, und das Verschweigen die Unternehmensberatungen meistens. Die müssen gleich mehrfach in den sauren Apfel beissen.
• #78: 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.
• #79: Es ist sogar noch schlimmer - aus „never change a running system“ wird „always improve a running system.“
• #80: 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.
• #81: 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.
• #83: Und wie komme ich jetzt zu einer DevOps Kultur?
• #84: Und wie komme ich jetzt zu einer DevOps Kultur?
• #85: Und wie komme ich jetzt zu einer DevOps Kultur?
• #86: Und wie komme ich jetzt zu einer DevOps Kultur?
• #87: Netterweise gibt es da inzwischen gute Ansätze. Der bekannteste sind die 3 Ways of DevOps, die auch demnächst im DevOps cookbook herauskommen.
• #88: 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
• #89: … 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.
• #90: 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.
• #91: 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.
• #93: 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?
• #94: Der letzte Schritt ist die „Culture of Continual Experimentation & Failure“.
• #95: 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.
• #96: 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.
• #97: 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.
• #98: 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.
• #99: Das sind die Pfeiler der DevOps-Kultur: direkte Kooperation, Autonome Teams, gemeinsame Verantwortung und Ziele, Automatisierung und Vertrauen & Respekt.
• #100: Also: DevOps wirkt, ist Mainstream, und man kann es in der Praxis machen. Und man kann damit das magische Dreieck des Projektmanagements brechen. Manchmal ist es schon cool, was wir ITler so alles für Dinge können.