DevOps beyond the Tools
•
8 j'aime•2,703 vues
DevOps is mainstream - at least the tools, the automation and the metrics. But what happened to DevOps Culture? Does it still matter? If yes - how do we achieve it?
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à DevOps beyond the Tools
Similaire à DevOps beyond the Tools (20)
Plus de Johann-Peter Hartmann
Plus de Johann-Peter Hartmann (11)
Dernier
Dernier (20)
DevOps beyond the Tools
- 2. Johann, Mayflower We do agile stuff, too. (a lot, like no budgets, open books, no job titles, team selected roles, reverse accountability, peer feedback, slacktime, (mostly) open salaries, peer salaries, sociocracy, stuff)
- 3. 10 Years of DevOps! Who else was there, back in the days?
- 4. DevOps Born as „Agile Operations“ in 2009 (3rd grade today)
- 8. 2017: DevOps still growing early majority
- 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.
- 10. Cap Gemini, 2014 Development to Operations (DevOps) implementations will increase significantly during 2015-2016.
- 11. 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.
- 13. Puppet Labs, 2015 It’s their use of DevOps practices that sets these top performers apart from the pack.
- 14. Do you even DevOps?
- 15. Who is „the Devops“ in a team / company
- 16. Is there a „DevOps Team“ in Your Company?
- 17. (Ok, that’s two anti patterns for a start.)
- 18. Let’s figure out Your actual DevOps Hipster Score
- 19. Puppet, CF-Engine or Chef? Please add 1 Hipster Point
- 20. Ansible, SaltStack, Fabric? Please add 3 DevOps Hipster Points
- 21. Docker Just 1 DevOps Hipster Point - it’s 2017
- 22. Kubernetes / DC/OS-Mesos / Swarm Please add 5 DevOps Hipster Points
- 23. drone.io GoCD Spinnaker Please add 5 DevOps Hipster Points
- 24. ChatOps? NixOS? Please add 5 DevOps Hipster Points
- 25. 0 Points? 1-5 Points? 6-10 Points? >10 Points?
- 26. How often do you deploy? 1 2 3 4 5 >= 1 time daily multiple times a week at the end of each sprint once a month? every 3/6 months
- 27. New features into production 1 2 3 4 5 > 1 per day >2 per week 7-12 each sprint 1-5 per month some each year
- 29. State of DevOps: - Automation: check - CI: check - CD: check - Metrics: check
- 30. When DevOps started, it was about …
- 33. Hey, it works for me. Why bother about culture & sharing? Culture Automation Measurement Sharing
- 34. „Even with the best tools, DevOps is just another buzzword if you don’t have the right culture.“
- 35. Ok, but what is the right culture?
- 36. „DevOps is just short for DevProductSupportNetSecBizOps.
- 37. 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
- 38. 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 Specialization Effective Control Efficiency Economy Expansion CEO
- 39. 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 Strategy Company Goals Department Goals Individual Goals & KPIs CEO
- 40. Vice President Product Vice President Development Vice President Quality Vice President Maintenance
- 41. Fingerpointing
- 42. Product Development Quality Maintenance Silo effect
- 43. Agile …deals with the silo effects between • Requirements and • Development and • Quality Assurance
- 44. DevOps … deals with silo effects between • Requirements engineering • Development • Quality • Deployment • Maintenance • Operations
- 45. 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
- 46. Remove Silos
- 47. Direct Cooperation vs departmental boundaries Discussions vs handovers & processes
- 48. Shared Topics • requirements • business metrics • release pipeline • technical resources • architecture
- 49. Shared Responsibility • Responsibility for the product, not department objectives • documentation & ticketing is a tool, not a contract • no handovers
- 50. Shared Goals • focus on • product • overall process • shared metrics • user metrics • platform metrics • quality metrics
- 51. 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.
- 52. Autonomous Cross- Functional Teams • all skills needed are part of the team • no external dependencies • authority for decisions • no handover needed Inverse Conway Maneuver
- 53. „Product Design builds the right product“ „Dev builds the product the right way.“ „Ops delivers the right support.“ Respect & Trust (a.k.a. the hard part)
- 54. DevOpsCulture Direct cooperation Autonomous Teams Shared Responsability Shared Goals Automation Trust & Respect
- 55. Contradictions Organisation DevOps individual accountability shared accountability department goals & objectives shared objectives individual objectives & bonuses shared objectives local efficiency global efficiency
- 56. Ignoring these contradictions between DevOps and functional Orgs will result in anti patterns
- 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
- 58. Vice President DevOps Database DevOps Enterprise DevOps Junior DevOps „DevOps is a new department focussing on infrastructure & deployment automation“ CEO Devops
- 59. Product Development Quality Ass. Maintenance Look, we added another silo! DevOps Dev Ops
- 60. DevOps is not a function. DevOps is a form of cooperation
- 62. Developer Role Operation Role Quality Assurance Role + DevOps Role?
- 63. DevOps-Engineer Devs with QA & Ops knowhow SysEng with QA & Dev Knowhow QA with Dev & Ops Knowhow
- 64. DevOps-Engineer - an anti-pattern that is a starting point, too.
- 65. Vice President Development Software Developer Frontend Developer DevOps Engineer CEO Development- only DevOps Puppet Vagrant SaltStack Testing & CI … but not in Production
- 66. Product Developer Software Development Quality Assurance Operations Product Owner Frontend Developer Tester NetSec Consultant Product Designer Backend Developer Test Infrastructure Performance Consultant SLES based SLES based Vagrant Boxes QA uses Ubuntu Product Development WTF WTF
- 68. DevOps vs Management Automation is expensive Incompatible with functional orgs Incompatible with MbO Incompatible with command & control
- 69. Never change a running system. Always improve your running system.
- 70. DevOps vs Company Culture No more lonely heroes
- 71. Cooperation is harder than it seems No more „stupid sales droids“ No more „stupid frontend devs“ No more „stupid customers“ No more „stupid management“ No more „stupid features“ No more „my department is great, but (other department) is not“
- 72. 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 MicroService-Team Inverse Conway Maneuver FTW?!
- 73. Inverse Conway Maneuver FTW?! Corporate Culture does not change fast.
- 74. Inverse Conway Maneuver FTW?! Corporate Culture does not change fast. Functional Org DevOps
- 75. Inverse Conway Maneuver FTW?! Corporate Culture does not change fast. Functional Org DevOps True for 20 years True for 6 months
- 76. How to create a DevOps Culture
- 77. 3Ways of DevOps
- 79. 1 Systems Thinking Draw how to make Toast http://www.drawtoast.com/
- 81. Loops 2 Amplify Feedback Product Development Software Development Deployment Business Analytics Management
- 82. 2 Amplify Feedback Product Development Software Development Deployment Business Analytics Management 1 months 3 months 1 week 1 Sprint 1 day 143 days!
- 83. 2 Amplify Feedback Product Development Software Development Deployment Business Analytics 1 week 1 day 1 sprint 1 day 23 days Management
- 84. 3Culture of Continual Experimentation & Failure
- 85. 3Culture of Continual Experimentation & Failure Fail cheap Fail often
- 87. 3Ways of DevOps Systems Thinking Amplify Feedback Loops Culture of Continual Experientation DevOps culture is the delayed outcome
- 88. 3Ways of DevOps Enable Your teams to understand the business , cooperate and learn together. It’s not about change management
- 89. DevOpsCulture Direct cooperation Autonomous Teams Shared Responsability Shared Goals Automation Trust & Respect
- 90. Have fun breaking the iron triangle using DevOps!
Notes de l'éditeur
- 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.
- 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.
- Do you remember when it all started ten years ago? Who was there right from the beginning?
- 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.
- 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.
- 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.
- Just one year later gartner group figure it out and said that devops will come.
- Who does devops today?
- and it did. if even the big consultancies talk about it you know that you are there.
- Even cap gemini! (ok, it’s dev to ops for them)
- And in 2015 gartner group finally predicted that it will be early majority by 2016
- .. for a reason, since everything gets better with devops. a lot faster …
- And puppet labs figured, as a devops company, that it is exactly devops that makes companies successful.
- Who does devops today?
- Ist jemand von Euch der DevOps in einem Team oder in der Firma?
- Und wer hat ein DevOps-Team in der Firma, das sich um die Automatisierung von Aufgaben kümmert?
- 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.
- 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?
- 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?
- Wer setzt Anbisse, Salt, Fabric ein? Bitte 3 Hipsterpunkte addieren.
- 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 deployed ihr?
- Und wie oft werden dabei wirklich neue Features live genommen?
- 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.
- Es ist jedes mal spannend zu sehen, ob noch jemand mit Quartalsweisen Deployments da ist.
- Wer von Euch macht übergreifendes Monitoring? Genau, das sind schon weniger. ELK? Nagios, Zabbix & Sensu?
- Does anyone remember this acronym?
- Genau, das war eine der frühen Definitionen von DevOps - Culture, Automation, Measurement, Sharing.
- Und meist ist nur die Automatisierung übrig geblieben, und ein bisschen vom Measurement.
- And we all know - if even martin fowler says it, it’s true. It’s great. it’s true.
- Ok, wir brauchen also die richtige Kultur - aber was ist denn Bitte die richtige Kultur?
- DevOps sollte Features schneller zum Kunden bringen, und damit das ganze Unternehmen beschleunigen.
- Ein sicherer Weg zu mehr Geschwindigkeit ist natürlich auch weniger Warten.
- 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.
- 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.
- 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.
- 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.
- 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.
- Even better - this kind of company is easy to command & control using cascading objectives and key performance indicators.
- 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.
- 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.
- Does anyone remember this diagram? That’s the wall of confusion.
- Das kann natürlich nicht klappen, und im Resultat erzeugt man Fingerpointing - die Administration wird als Diktator gesehen, das Development als unfähige Bugschleudern.
- 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.
- Agil hat schon Silo-Brecher-Effekte gehabt - Requirements, Development und Qualität greifen bei agilen Methoden hart ineinander.
- DevOps spannt diesen Bogen noch deutlich weiter - und nimmt Deployment, Maintenance und Operations ebenfalls mit dazu.
- That makes a lot of sense in the real world - since product development in online companies affects all areas of the organization.
- Ok, who do you remove silos? Obviously you have to get rid of the walls between the departments.
- 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
- 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.
- DevOps-Kultur zielt mit der Verantwortung nicht auf lokale Verantwortung - sondern auf shared accountability für das Gesamtsystem.
- 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.
- 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.
- 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.
- 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.
- Das sind die Pfeiler der DevOps-Kultur: direkte Kooperation, Autonome Teams, gemeinsame Verantwortung und Ziele, Automatisierung und Vertrauen & Respekt.
- 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.
- Und genau diese Widersprüche führen zu Antipattern.
- If my organization looks like this …
- … und ich von DevOps nur die Tools verstehe, dann passiert folgendes: Ich baue eine neue Abteilung, die sich um DevOps kümmert.
- 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 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.
- Diese Grafik kennen vermutlich die meisten - DevOps als Schnittmenge zwischen QA, Dev und Ops.
- 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.
- 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.
- Aber es ist trotzdem schön, wenn es ihn gibt - dann vereint wenigstens einer im Team die Kompetenzen, die eigentlich alle haben sollten.
- 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.
- That was another anti pattern we encountered. The Development department
- Das Management ist eine arme Sau bei DevOps, und das Verschweigen die Unternehmensberatungen meistens. Die müssen gleich mehrfach in den sauren Apfel beissen.
- 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.
- Es ist sogar noch schlimmer - aus „never change a running system“ wird „always improve a running system.“
- 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.
- 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.
- Und wie komme ich jetzt zu einer DevOps Kultur?
- Und wie komme ich jetzt zu einer DevOps Kultur?
- Und wie komme ich jetzt zu einer DevOps Kultur?
- Und wie komme ich jetzt zu einer DevOps Kultur?
- Netterweise gibt es da inzwischen gute Ansätze. Der bekannteste sind die 3 Ways of DevOps, die auch demnächst im DevOps cookbook herauskommen.
- 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
- … 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.
- 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.
- 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.
- 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?
- Der letzte Schritt ist die „Culture of Continual Experimentation & Failure“.
- 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.
- 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.
- 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.
- 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.
- Das sind die Pfeiler der DevOps-Kultur: direkte Kooperation, Autonome Teams, gemeinsame Verantwortung und Ziele, Automatisierung und Vertrauen & Respekt.
- 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.