DevOps für Dummies
DevOps für Dummies
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
© 2020 WILEY-VCH Verlag GmbH & Co. KGaA, Weinheim
Original English language edition DevOps For Dummies © 2019 by Wiley Publishing, Inc. All rights reserved including the right of reproduction in whole or in part in any form. This translation published by arrangement with John Wiley and Sons, Inc.
Copyright der englischsprachigen Originalausgabe DevOps For Dummies © 2019 by Wiley Publishing, Inc. Alle Rechte vorbehalten inklusive des Rechtes auf Reproduktion im Ganzen oder in Teilen und in jeglicher Form. Diese Übersetzung wird mit Genehmigung von John Wiley and Sons, Inc. publiziert.
Wiley, the Wiley logo, Für Dummies, the Dummies Man logo, and related trademarks and trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries. Used by permission.
Wiley, die Bezeichnung »Für Dummies«, das Dummies-Mann-Logo und darauf bezogene Gestaltungen sind Marken oder eingetragene Marken von John Wiley & Sons, Inc., USA, Deutschland und in anderen Ländern.
Das vorliegende Werk wurde sorgfältig erarbeitet. Dennoch übernehmen Autoren und Verlag für die Richtigkeit von Angaben, Hinweisen und Ratschlägen sowie eventuelle Druckfehler keine Haftung.
Coverfoto: © vchalup – stock.adobe.com
Korrektur: Matthias Delbrück, Dossenheim/Bergstraße
Print ISBN: 978-3-527-71624-1
ePub ISBN: 978-3-527-82319-2
Technologie-Expertin und Geschichtenerzählerin Emily Freeman hilft Entwicklungsteams, ihre Arbeitsgeschwindigkeit zu erhöhen. In ihren Augen sind die größten Herausforderungen für Entwickler nicht technischer, sondern menschlicher Natur. Es ist ihre Berufung, Technologieunternehmen zu transformieren. Das Mittel dazu ist eine Unternehmenskultur, in der sich vielfältige, kollaborative Teams entfalten können.
Emily ist Senior Cloud Advocate bei Microsoft, und ihre Erfahrung reicht von wegweisenden Startups bis hin zu den weltgrößten Tech-Unternehmen. Ihre Arbeit wurde in Medienkanälen wie Bloomberg vorgestellt und sie ist weithin gesucht als fähige, unterhaltsame und professionelle Keynote-Speakerin. Besonders bekannt ist Emily für ihren kreativen Ansatz, die menschlichen Herausforderungen im Software-Engineering zu identifizieren und zu lösen. In der Technologiebranche findet man nur selten Menschen, die mit Code und Wörtern gleichermaßen vertraut sind, aber ihre Laufbahn ist durch genau diese Kombination geprägt.
Emily lebt mit ihrer Tochter in Denver, Colorado.
Für Clara, meinen Nordstern, und für all jene, die vor mir da waren, deren scheinbar belanglose Entscheidungen zu diesem Moment der Freude und Erfüllung führten.
Dieses Buch war alles andere als ein Alleingang. Ich kann unmöglich allen danken, die mich ermutigten oder an mich glaubten, wenn mir dies selbst nicht gelang. Von ganzem Herzen: Danke.
Zuallererst danke ich meinen Lesern. Vielen Dank, dass Sie Ihre kostbare Zeit damit verbringen, meine Gedanken über die Grundlagen und die Implementierung von DevOps zu lesen. Ich hoffe, dass Sie sich nach der Lektüre dieses Buchs befähigt fühlen, Veränderungen für sich und Ihre Kollegen vorzunehmen.
Vielen Dank an Steven Hayes, der es auf einen Versuch mit einer Erstautorin ankommen ließ. Diese Chance bedeutete mir sehr viel. Dank seiner Arbeit ist dieses Buch besser geworden. Vielen Dank auch an Nicole Forsgren für ihr großartiges Vorwort (und ihren weisen Rat) und an Jason Hand für sein Fachlektorat.
Ein besonderer Dank gilt meinen Eltern, Barry und Pamela Freeman, die mich immer wieder aufgebaut haben, als ich schon aufgeben wollte. Danke für eure Liebe, dafür, dass ihr mir die Bedeutung schöpferischer Arbeit vermittelt und mir das Geschenk des Mitgefühls gegeben habt. Ich liebe euch.
Große Teile meines Erfolgs verdanke ich den Autoren, die mich auf diesem Weg ermutigt haben. Vielen Dank an John Allspaw, David Blank-Edelman, Sarah Drasner, Chad Fowler, Stephen O’Grady, Mike Julian, Gene Kim, Niall Murphy, Erik St. Martin, Mary Thengvall und James Turnbull.
Ich möchte all jenen von Ihnen in der Community danken, die schon lange vor den Tausenden von Twitter-Anhängern an mich geglaubt haben. Ich war eine Backend-Entwicklerin, die gerade erst die Programmierschule abgeschlossen hatte, und Ihr Vertrauen in mein Potenzial hat mich weiter gebracht, als Sie es sich jemals vorstellen können. Ich verdanke Menschen wie Aaron Aldrich, Kent Dodds, James Governor, Nathen Harvey, Christian Herro, Bridget Kromhout, Ken Mugrage, Corey Quinn, J. Paul Reed, Matt Rogers, Michael Stahnke, Matty Stratton und Joshua Zimmerman so viel.
Ich bin überzeugt, dass ich einige der besten Freunde auf der Erde habe. Ich müsste den ganzen Tag tippen, um alle aufzuzählen, aber ich möchte ein paar besondere Personen hervorheben, die für dieses Buch eine wichtige Rolle gespielt haben. Vielen Dank an Jessica West, meine beste Freundin und Vertraute. (Ich weiß nicht, was ich ohne dich machen würde.) Scott Church, danke, dass du mich ohne Beurteilung so sein lässt, wie ich bin. Melanie Parish, du bist meine vernünftige Beraterin. Rachel Stephens, deine ansteckende Freude ist ein Geschenk. Heidi Waterhouse, danke, dass du dich um mich gekümmert und mich geerdet hast. Chris Short, danke für deinen schrägen Humor und deine Offenheit. Lovisa Svallingson, danke, dass du mir bedingungslose Liebe schenkst, wenn ich mich leer fühle. Kristin Jones, Amber Rivera und Mary MacCarthy, ihr inspiriert mich und haltet mich über Wasser.
Dies ist eine der häufigsten Fragen, die ich in meiner Arbeit gestellt bekomme – und zwar gleichermaßen von Fachleuten wie von Einsteigern. Ich arbeite seit fast zwei Jahrzehnten in der IT-Branche und habe als DevOps-Forscherin, Strategin und Expertin Hunderte von führenden Technologieunternehmen und Entwicklern bei der Verbesserung ihrer Software unterstützt, damit sie ihren Kunden schneller und sicherer Mehrwert liefern können. Aber viele von uns in diesem Bereich hören diese Frage immer noch.
Leider gibt es keine einzige, allgemeingültige Definition von DevOps – sehr zum Leidwesen aller. Aber wenn wir ehrlich sind, ist es wahrscheinlich egal; schließlich hat die klare Definition, die im Agilen Manifest hinterlegt wurde, der Agile-Community auch nicht viel weitergeholfen.
Mit DevOps für Dummies hat Emily Freeman ein Buch über DevOps geschrieben, das Sie von Anfang bis Ende durchlesen oder als Nachschlagewerk verwenden können, oder Sie machen sich auf Ihre eigene Erkundungstour durch die DevOps-Konzepte. Es ist eine brillante Weise, Inhalte zu strukturieren, denn DevOps umfasst die Bereiche Entwicklung, Operations sowie eine ganze Menge Unternehmenskultur – und noch einiges mehr. In diesem Buch vertieft Emily wichtige Konzepte für Teams, die diese neue Arbeitsweise implementieren – egal, ob Sie sich mit Greenfield- oder Brownfield-Projekten beschäftigen oder gar keine Ahnung haben, was diese beiden Begriffe eigentlich bedeuten.
Emily nimmt sich des Themas mit klarem Blick und frischer Stimme an und liefert aufschlussreiche Analysen in klar verständlicher Sprache. Als Quereinsteigerin in die Tech-Branche bringt sie ein Gespür und ein Verständnis für solche Sachverhalte mit, die andere, die in die Technik »hineingeboren« wurden, oft für selbstverständlich halten. Ihre Texte vermitteln diese (manchmal auch verborgenen) Details mühelos und führen den Leser mit Leichtigkeit und Witz durch das Feld.
Zu meinen Favoriten gehören die Abschnitte über die Entwicklung von gut les- und wartbarem Code (Kapitel 9, insbesondere der Teil über Peer-Reviews) und über die Befähigung von Teams, an der Unternehmensskalierung mitzuwirken, und … – ich müsste zu viele Lieblingskapitel und -abschnitte auflisten, also bitte ich Sie, Ihre eigenen Favoriten zu finden und darauf zu achten, dass Ihnen die Haftnotizen und Textmarker nicht ausgehen!
Ich wünsche Ihnen viel Glück auf Ihrer DevOps-Reise. Es ist egal, wo Sie anfangen; was zählt, ist, dass Sie weitermachen und sich ständig verbessern.
— Nicole Forsgren, Research & Strategy bei Google Cloud und Mitbegründerin und CEO von DevOps Research and Assessment (DORA)
Ich glaube, dass die größten Herausforderungen für die Technologiebranche nicht technischer, sondern menschlicher Natur sind. Überlegen Sie nur: Hardware und Computer sind leistungsfähiger als je zuvor. Automatisierte Tools machen mühevolle Routinearbeiten überflüssig. Robuste Frameworks und Bibliotheken ermöglichen Abkürzungen und Funktionen in Anwendungen. Sie können schneller mehr erreichen als jemals zuvor.
Das Problem, mit dem Unternehmen heute konfrontiert sind, ist die soziale Dynamik in Entwicklerteams. Konkret ist das vor allem die natürliche Reibung, die durch falsch ausgerichtete Leistungsanreize und schlecht kommunizierte Ziele entsteht; der frustrierende Versuch, jemandem mit einem anderen technischen Hintergrund ein Konzept oder einen Ansatz zu erklären, und die Angst, die man empfindet, wenn man sich vorstellt, vor seinen Kollegen dumm auszusehen oder aus seinem Job wegautomatisiert zu werden.
DevOps greift all diese Probleme auf, und dieses Buch erklärt, wie.
Ich habe dieses Buch als Ressource konzipiert, die jemand, der noch nie von DevOps gehört hat – oder nicht weiß, was es eigentlich bedeutet – durcharbeiten kann, um ein umfassendes Verständnis von DevOps zu erlangen und zu verstehen, wie es in den Software Development Life Cycle (SDLC) passt – also in den gesamten Prozess der Entwicklung und Veröffentlichung von Software. Obwohl SDLC traditionell das Wort Development verwendet, bevorzuge ich Delivery, weil damit eine mögliche Überhöhung der Entwickler gegenüber anderen Disziplinen vermieden wird.
Ich habe die Informationen in diesem Buch so angeordnet, dass sie sowohl chronologisch als auch selektiv zugänglich sind. Sie können es direkt durchlesen und jeden Abschnitt auf dem vorigen aufbauen lassen, oder Sie können nach Herzenslust darin herumspringen.
Ich verwende im gesamten Buch die folgenden Konventionen:
nichtproportionaler Schrift angezeigt. Wenn Sie eine digitale Version dieses Buches auf einem mit dem Internet verbundenen Gerät lesen, können Sie auf die Webadresse klicken oder tippen, um diese Website zu besuchen, so wie hier: www.wiley-vch.de/de/dummies.Als ich anfing, dieses Buch zu schreiben, hatte ich Mühe, meine Hauptzielgruppe zu identifizieren. Entwickler? Operations-Leute? Führungskräfte? Es war mir wichtig, DevOps zugänglich und greifbar zu machen. Zu oft wird über DevOps nur im Rahmen von Greenfield-Projekten und Unternehmen mit fast endlosen Ressourcen gesprochen. Ich wollte lieber zum Kern von DevOps als Disziplin vordringen – einer Disziplin, die Entwicklern hilft, ihre Arbeit besser und schneller zu erledigen. Ich wollte die Leser außerdem dort abholen, wo sie sich befinden, und mit Leuten sprechen, die noch nie von DevOps gehört haben, ebenso wie mit jenen Entwicklern, die sich auf dem besten Weg zu fortgeschrittenen DevOps-Praktiken befinden. Am Ende konzentrierte ich mich auf alle, die sowohl geschäftliche Prioritäten einhalten als auch technische Talente halten müssen. Sie brauchen realistische Lösungen für reale Probleme. Sie erkennen die Vorteile der Automatisierung, müssen aber auch auf die Sicherheit und die Einhaltung von Vorschriften achten.
Egal, ob Sie genau zu diesem Profil passen, ich hoffe, dass Sie aus diesem Buch herausziehen können, was Sie brauchen, und dass es einen kleinen Beitrag zu Ihrem Erfolg leisten kann, wenn Sie Ihre Entwicklungspraxis weiterentwickeln und verbessern.
Die Glühbirne kennzeichnet Tipps (ah!) und Tricks, die Ihnen die Implementierung von DevOps-Praktiken erleichtern.
Der Finger mit dem Faden markiert Informationen, die besonders wichtig sind. Um die wichtigsten Informationen aus jedem Kapitel abzuschöpfen, gehen Sie einfach diese Symbole durch.
Dieses Symbol kennzeichnet besonders technische Informationen, die Sie normalerweise überspringen können.
Das Warnsymbol weist Sie darauf hin, dass Sie vorsichtig sein müssen! Es kennzeichnet wichtige Informationen, die Ihnen Kopfschmerzen und unnötige Konflikte ersparen können.
Ich habe dieses Buch so geschrieben, dass Sie es querlesen können, wenn Sie das möchten. Als Entwickler sind sie mit den meisten Informationen in Teil II vielleicht bereits vertraut (obwohl ich vorschlage, sie noch einmal zu überfliegen, um ein paar neue Ideen zu erhalten!). Als Betriebsingenieur fühlen Sie sich vielleicht eher in einigen der eher infrastrukturorientierten Kapitel aufgehoben.
Eine DevOps-Transformation ist keine Kleinigkeit, und sie wird auch nicht von heute auf morgen stattfinden. Dazu braucht es Stunden der Planung, ehrliche Gespräche, Brainstorming, Reflexion und technische Veränderungen. Hetzen Sie sich nicht durch den Prozess. Einfach nur zu lernen und aus einer anderen Perspektive über Ihre tägliche Arbeit nachzudenken, ist eine gesunde Art, Ihren Verstand zu wecken. Der Weg ist genauso wertvoll wie das Ergebnis.
Teil I
Kapitel 1
IN DIESEM KAPITEL
DevOps verändert die Zusammenarbeit von Entwicklungsteams bei der Erstellung und Bereitstellung von Software. Diese breit angelegte, umfassende Philosophie wirkt branchenübergreifend und in den verschiedensten Anwendungsgebieten inspirierend.
Ich definiere DevOps als Entwicklungskultur der Zusammenarbeit, Eigenverantwortung und des Lernens, alles mit dem Ziel, den Lebenszyklus der Softwareentwicklung von der Idee zum fertigen Produkt zu beschleunigen. DevOps kann zwischenmenschliche Reibungsverluste reduzieren, Engpässe beseitigen, die Zusammenarbeit optimieren, die Arbeitsmoral der Entwickler durch selbstbestimmte Tätigkeit erhöhen und die Produktivität der Teams steigern. DevOps ist kein Wundermittel, kann sich aber massiv auf Ihre Organisation und Ihre Produkte auswirken.
In diesem Kapitel betone ich die wichtige Rolle der Unternehmenskultur gegenüber Abläufen und Werkzeugen, diskutiere die Grundsätze und Werte von DevOps und führe aus, inwiefern Ihre Organisation von einem DevOps-Ansatz profitieren wird.
Dieses Buch liefert Ihnen kein genaues DevOps-Rezept – denn es gibt keins. DevOps ist eine Philosophie, die Menschen über den Prozess stellt und Prozesse über Werkzeuge. DevOps schafft eine Kultur des Vertrauens, der Zusammenarbeit und kontinuierlichen Verbesserung. Der Entwicklungsprozess wird ganzheitlich betrachtet, dabei werden alle Beteiligten berücksichtigt: Entwickler, Tester, ITler, Sicherheitsleute und Infrastrukturentwickler. DevOps stellt keine dieser Gruppen über die andere, noch wertet es die Bedeutung ihrer Arbeit. Stattdessen ist für ein DevOps-Unternehmen das gesamte Entwicklerteam entscheidend, um dem Kunden die bestmögliche Erfahrung zu bieten. (In Kapitel 2 erfahren Sie mehr über Unternehmenskultur.)
Im Jahr 2001 trafen sich 17 Softwareentwickler und veröffentlichten das »Manifest für agile Softwareentwicklung«, in dem die 12 Grundsätze des agilen Projektmanagements dargelegt wurden. (Im Kasten »Die Ursprünge von Agile« in Kapitel 7 erfahren Sie weitere Details darüber.) Dieser neue Workflow war eine Reaktion auf die Frustration und Inflexibilität von Teams, die in einem (linearen) Wasserfallprozess arbeiten. Bei der Arbeit nach agilen Prinzipien müssen sich Entwickler nicht an die ursprünglichen Anforderungen halten oder einem linearen Entwicklungsworkflow folgen, bei dem jedes Team Arbeit an das nächste abgibt. Stattdessen können sie sich an die sich ständig ändernden Erfordernisse des Unternehmens oder des Markts und manchmal sogar an neue Technologien und Tools anpassen.
Obwohl Agile die Softwareentwicklung in vielerlei Hinsicht revolutionierte, konnte es den Konflikt zwischen Entwicklern und Ops-Team nicht lösen. Um technische Fähigkeiten und Spezialitäten bildeten sich immer noch Silos, und die Entwickler gaben den Code weiterhin an den IT-Betrieb weiter, der ihn bereitstellt und betreut.
Im Jahr 2008 machte Andrew Clay Shafer in einem Gespräch mit Patrick Debois seinen Ärger über den ständigen Konflikt zwischen Entwicklern und operativen Mitarbeitern deutlich. Gemeinsam organisierten sie die ersten DevOpsDays in Belgien, um eine bessere und flexiblere Vorgehensweise bei der Softwareentwicklung zu etablieren. Diese Weiterentwicklung von Agile konnte sich durchsetzen und DevOps ermöglicht es mittlerweile Unternehmen auf der ganzen Welt, schneller (und meist auch kostengünstiger) bessere Software zu produzieren. DevOps ist kein kurzlebiger Trend, sondern eine weithin akzeptierte Entwicklungsphilosophie.
Wer sagt, dass es bei DevOps nur um Werkzeuge geht, will Ihnen etwas verkaufen. DevOps ist vor allem eine Philosophie, die sich auf Entwickler und die Verbesserung der Zusammenarbeit zwischen ihnen konzentriert – mit dem Ziel, großartige Software zu entwickeln. Sie könnten Millionen in alle DevOps-Tools der Welt investieren und wären trotzdem keinen Schritt weiter in Richtung DevOps-Nirvana. Konzentrieren Sie sich stattdessen auf Ihr wichtigstes Entwicklungsinstrument: die Entwickler. Glückliche Entwickler produzieren großartige Software. Wie bekommen Sie glückliche Entwickler? Nun, Sie schaffen eine kollaborative Arbeitsumgebung, in der gegenseitiger Respekt, gemeinsames Wissen und die Anerkennung harter Arbeit gedeihen können. In den Kapiteln 2 und 15 erfahren Sie mehr darüber, wie Sie Teams aus glücklichen, eigenverantwortlichen Entwicklern bilden können, die stolz auf ihre Arbeit sind und wachstumsorientiert denken.
Ihr Unternehmen verfügt über eine Kultur, selbst wenn sich diese durch Trägheit entwickeln musste. Diese Kultur hat mehr Einfluss auf die Arbeitszufriedenheit, Produktivität und Teamgeschwindigkeit, als Sie es wahrscheinlich für möglich halten.
Unternehmenskultur lässt sich am besten als die unausgesprochenen Erwartungen, das Verhalten und die Werte eines Unternehmens beschreiben. Sie signalisiert Ihren Mitarbeitern auch, ob die Unternehmensführung offen für neue Ideen ist, und beeinflusst die Entscheidung des Einzelnen, ob er ein Problem ansprechen oder doch lieber unter den Teppich kehren soll.
Kultur möchte gestaltet und verfeinert werden und sollte nicht dem Zufall überlassen werden. Auch wenn die tatsächliche Definition von Unternehmen zu Unternehmen und von Person zu Person variiert, ist DevOps im Grunde eine kulturelle Herangehensweise an die Produktentwicklung.
Eine vergiftete Unternehmenskultur wird Ihre DevOps-Reise ruinieren, bevor sie überhaupt beginnt. Selbst wenn Ihr Entwicklungsteam sich eine DevOps-Mentalität zu eigen macht, werden die Haltungen und Schwierigkeiten der übergeordneten Organisation in Ihre Arbeitsumgebung einfließen.
Mit DevOps vermeiden Sie Schuldzuweisungen, Sie schaffen Vertrauen und konzentrieren sich auf den Kunden. Sie lassen Ihren Entwicklern freie Hand, das zu tun, was sie am besten können: Lösungen ausarbeiten. Wenn Sie mit der Umsetzung von DevOps beginnen, geben Sie Ihren Entwicklern Zeit und Raum, sich darauf einzustellen. Lassen Sie ihnen die Möglichkeit, sich gegenseitig besser kennenzulernen und Kontakte zu Leuten mit unterschiedlichen Fachkenntnissen aufzubauen. Zudem messen Sie den Fortschritt und belohnen Leistungen. Geben Sie niemals Einzelpersonen die Schuld an Misserfolgen. Stattdessen sollte sich das Team gemeinsam kontinuierlich verbessern, und Erfolge sollten gefeiert und belohnt werden.
Die unvoreingenommene Beobachtung des Arbeitsablaufs ist eine leistungsstarke Technik, mit der Sie die Erfolge und Herausforderungen Ihres Workflows realistisch einschätzen können. Dies ist die einzige Möglichkeit, die richtige Lösung für Problembereiche zu finden, die Engpässe in Ihren Abläufen verursachen. Genau wie bei Software besteht die Lösung nicht immer darin, einfach Kubernetes (oder ein anderes neues Tool) einzusetzen. Sie müssen erkennen, wo die Probleme liegen, bevor Sie sie beheben. Währenddessen sammeln Sie Daten – nicht, um Erfolg oder Misserfolg zu messen, sondern um die Leistung des Teams zu verfolgen. Sie ermitteln, was funktioniert und was nicht und was Sie beim nächsten Mal versuchen sollten. In Kapitel 3 erfahren Sie, wie Sie Engpässe in Ihrem Entwicklungsprozess identifizieren können.
Es ist nicht einfach, DevOps an Ihre Führungskräfte, Kollegen und Mitarbeiter zu verkaufen. Auch für Entwickler ist der Ablauf nicht immer intuitiv. Sollte sich eine gute Idee nicht von selbst verkaufen? Wenn es doch nur so einfach wäre! Als Schlüsselkonzept bei der Umsetzung von DevOps sollten Sie jedoch immer daran denken, dass es die Menschen in den Vordergrund stellt. Die sogenannten »Soft Skills«, also Kommunikation und Zusammenarbeit, sind für die Einführung von DevOps von zentraler Bedeutung. Andere Leute in Ihrem Team und in Ihrem Unternehmen vom Einsatz von DevOps zu überzeugen, erfordert gute Kommunikationsfähigkeiten. Frühe Gespräche mit Kollegen über DevOps können Wegbereiter für den späteren Erfolg sein – besonders wenn Sie auf unerwartete Hindernisse stoßen.
Der Aspekt von DevOps, der darauf abzielt, immer nur kleine, graduelle Änderungen durchzuführen, hat seine Wurzeln in der schlanken Fertigung, die auf schnelles Feedback, kontinuierliche Verbesserung und kürzere Time-to-Market setzt. Wenn ich über die Einführung von DevOps spreche, verwende ich als Metapher gerne das Wasser. Wasser ist eines der mächtigsten Elemente der Welt. Wenn es nicht gerade eine Hochwasserkatastrophe gibt, halten wir es für relativ harmlos. Der Colorado River hat den Grand Canyon geformt. Langsam, über Millionen von Jahren, schnitt sich das Wasser durch den Stein, um fast zwei Milliarden Jahre alte Bodenschichten und Felsen freizulegen.
Sie können wie Wasser sein, der langsame, unerbittliche Wandel in Ihrem Unternehmen. Hier zu Ihrer Inspiration das berühmte Zitat aus einem Bruce-Lee-Interview (https://www.youtube.com/watch?v=cJMwBwFj5nQ):
Inkrementelle Änderungen anzuwenden, bedeutet beispielsweise, dass Sie ein Problem finden und dieses beheben. Dann beheben Sie das nächste. Sie gehen nicht zu schnell zu viel an und Sie stellen sich auch nicht unmittelbar jedem Kampf. Sie begreifen, dass einige Kämpfe nicht die Energie oder das soziale Kapital wert sind, die sie Sie kosten können.
Das gesamte Buch befasst sich damit, wie Sie und Ihr Team vom Einsatz von DevOps in Ihrem Unternehmen profitieren können. Neben der menschlichen Komponente, die schnellere Auslieferung, verbesserte Funktionalität und furchtlose Innovation ermöglicht, bietet DevOps auch technische Vorteile.
Kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) sind eng mit DevOps verknüpft. Durch die kontinuierliche Softwarebereitstellung werden viele der Engpässe beseitigt, die häufig in Teams auftreten, die nur selten liefern. Wenn Sie automatisierte Pipelines erstellen, um neuen Code durch eine robuste Testsuite zu leiten, können Sie sich mit Ihren Implementierungen sicherer fühlen. (Mehr zu CI/CD erfahren Sie Kapitel 11.)
DevOps ermöglicht auch eine schnellere Regeneration nach Zwischenfällen. Sie werden irgendwann unweigerlich eine Ihre Kunden beeinträchtigende Unterbrechung Ihres Dienstes erleben, egal wie gut Ihr Code getestet ist. Aber Teams, die nach der DevOps-Methode arbeiten, finden durch bessere Koordination und Zugänglichkeit, gemeinsames Lernen und bessere Leistungsüberwachung schnellere Lösungen.
Nicht nur die Entwicklungsabteilung Ihrer Organisation profitiert von DevOps. Die geschäftliche Seite wird weniger Kundenreklamationen, schnellere Bereitstellung neuer Funktionen und eine höhere Zuverlässigkeit der bestehenden Dienste verzeichnen.
Mit Hilfe von DevOps können Sie mit den bereits vorhandenen Ressourcen mehr erreichen. Die Methode akzeptiert die realen Einschränkungen und zeigt Ihnen, wie Sie in Ihrer speziellen Umgebung erfolgreich sein können.
Während Sie sich mit DevOps vertraut machen, stoßen Sie wahrscheinlich auch auf das CALMS-Modell. Es steht für Kultur, Automatisierung, Schlankheit, Messung und Austausch und bietet einen hilfreichen Rahmen, um die DevOps-Prinzipien zu verstehen und Ihren DevOps-Erfolg bei der Anwendung dieser Prinzipien in Ihrem Unternehmen zu bewerten.
Ihre Kultur muss auf Zusammenarbeit und Kundenorientierung ausgerichtet sein. Ihre Entwickler sollten begreifen, dass die Technologie dafür da ist, den Kunden das Leben zu erleichtern. Wenn die Kunden im Produkt keinen Wert erkennen, wird es versagen. Die Technologie ist diesem Ziel untergeordnet. Die besten DevOps-Kulturen sind extrem kollaborativ und funktionsübergreifend; Menschen aus verschiedenen Teams und mit unterschiedlichen Fähigkeiten arbeiten zusammen an einem besseren Produkt. Zuhören ist ein wichtiger Aspekt der Kommunikation, und wenn Sie sich Gespräche anhören, bekommen Sie einen einfachen Lackmustest der Kultur. Fallen sich die Leute ständig gegenseitig ins Wort? Wenn ja, dann können Sie die Kultur mit Sicherheit noch wesentlich verbessern.
Routinetätigkeiten sind der schlimmste Albtraum eines Entwicklers, denn sie sind nicht nur, na ja, langweilig, sondern auch ineffizient. Entwickler sprechen Computersprache, damit sie Computern beibringen können, die Aufgaben zu erledigen, die die Menschen nicht übernehmen wollen. Normalerweise sind Code Builds, Testroutinen, Implementierungen und Infrastrukturbereitstellungen am einfachsten zu automatisieren. In Kapitel 3 werde ich noch genauer darauf eingehen, welche Änderungen sich besonders niederschwellig umsetzen lassen.
Schlank bezieht sich nicht nur auf die schlanke Fertigung. Das Prinzip lässt sich auch auf die Natur von DevOps-Teams übertragen, die agil und schlagkräftig sind. Lean-Teams vermeiden Aktivitäten mit geringen Auswirkungen, da sie für den Kunden keinen Mehrwert bieten. Ein weiterer Aspekt von Schlankheit ist die konsequente kontinuierliche Verbesserung. Jeder arbeitet wachstumsorientiert und will sich ernsthaft verbessern.
Daten sind für DevOps von entscheidender Bedeutung. Messdaten zum Fortschritt beeinflussen nahezu jeden Aspekt der Umgestaltung Ihres Unternehmens. Denken Sie aber daran, dass Fortschritte niemals an individuelle Leistung gebunden sein sollten. Betrachten Sie sie eher als die Beobachtung Ihrer Fortschritte bei einem endlosen Marathon denn als eine Möglichkeit zu wissen, wann Sie »fertig« sind. Sie sind niemals fertig. Niemand ist das jemals.
Statt aus den gesammelten Daten herauszulesen, wie schlecht Sie es machen, sehen Sie darin lieber eine Messung Ihrer Fortschritte. Feiern Sie die Siege. Dieser Ansatz stärkt das gesamte Team und Ihre Entwickler bleiben glücklich, motiviert und produktiv. Ich garantiere Ihnen, dass Sie einiges gut machen, und es ist wichtig, das Gute herauszustellen. In Kapitel 5 spreche ich darüber, was Sie messen können.
DevOps wurde ins Leben gerufen, weil Geschäftstätigkeit und Entwicklung in einem Konflikt standen. Es fehlte an Gemeinsamkeiten und beide Bereiche erhielten Anreize auf unterschiedlichen Grundlagen. Das operative Geschäft wird typischerweise an der Zuverlässigkeit und Verfügbarkeit einer Anwendung gemessen, während Entwickler meist dazu motiviert werden, neue Funktionen für die Anwendung zu entwickeln. (Ich spreche im nächsten Abschnitt ausführlicher darüber, wie betriebliche Abläufe und die Entwicklung gemessen werden.) Wissen Sie, was die größte Bedrohung für die Systemverfügbarkeit ist? Deployments. Entwickler initiieren Deployments mit neuen Code-Versionen. Demzufolge hassen die Leute aus dem Geschäftsbetrieb die Entwickler. Ganz so schlimm ist es meistens zwar nicht, aber es steckt ein Fünkchen Wahrheit drin. Diese Reibung macht die Problemlösung fast unmöglich und am Ende stehen nur noch Schuldzuweisungen. DevOps möchte diese Atmosphäre grundlegend verändern und eine Umgebung schaffen, in der sich beide Teams gegenseitig unterrichten und sich bestärkt fühlen – und so letztlich ein einziges Team bilden, zu dem alle etwas beitragen.
In traditionellen Teams stehen sich Entwickler (die den Code schreiben) und IT-Verantwortliche (die die Systeme einsetzen und die Infrastruktur warten) als Gegner eines endlosen Krieges gegenüber. Okay, das stimmt nicht ganz. Aber sie kommen nicht miteinander klar, und das liegt daran, dass sie nach unterschiedlichen Kriterien beurteilt werden.
Entwickler werden typischerweise an der Anzahl der Features gemessen, die sie veröffentlichen oder an der Anzahl der von ihnen behobenen Fehler. (Die Bewertung von Entwicklern nach geschriebenen Codezeilen ist eine schreckliche Idee. Die besten Entwickler löschen häufig mehr Codezeilen, als sie hinzufügen.)
Leider werden Qualität und Zuverlässigkeit des Codes meist nicht gemessen. Daher priorisieren Entwickler natürlich die Arbeit, die sie produktiv wirken lässt. Sie verbringen keine Zeit mit der Überarbeitung des Codes, um ihn lesbarer zu machen, oder der Tilgung der technischen Schuld, die durch die letzte große Produktoffensive entstanden ist.
Im Gegensatz zur Bewertung von Entwicklern werden Ops-Teams typischerweise an der Zuverlässigkeit und Verfügbarkeit der Website gemessen. Wahrscheinlich kennen Sie die fünf Neuner: 99,999 Prozent Verfügbarkeit. Das läuft darauf hinaus, dass Ihre Website nur fünf Minuten pro Jahr offline sein darf. Fünf Minuten … pro Jahr. Das ist ziemlich viel verlangt. Es verursacht auch enorme Betriebskosten aufgrund der großen Speicher- und Computerressourcen, die Ihnen zur Verfügung stehen müssen, ganz zu schweigen vom Personalaufwand, um die Verfügbarkeit auf diesem Niveau zu halten. Den Verantwortlichen werden oft heroische Anstrengungen abverlangt, um auf Probleme zu reagieren, unabhängig von Tag, Zeit, vorhandener Arbeitsbelastung oder persönlichen Verpflichtungen.
Um den Konflikt zu verdeutlichen: In traditionellen Softwareunternehmen müssen Entwickler neuen Code ausrollen, um neue Funktionen freizugeben. Aber Deployments sind die häufigste Ursache für Dienstunterbrechungen und Website-Ausfälle.
Aus dieser Situation ergeben sich zwei Probleme:
Verstehen Sie, warum Sie hörbare Seufzer vernehmen, wenn Entwickler und Betriebspersonal zusammenarbeiten? Mit DevOps versucht man, die Herausforderungen, die durch siloisierte Verantwortung und widersprüchliche Ziele entstehen, zu eliminieren. Durch Anpassung von Anreizen, Wissensaustausch, Beseitigung von Barrieren und Berücksichtigung verschiedener Rollen kann DevOps die zwischenmenschliche Kommunikation und Zusammenarbeit in Ihrem Team erheblich verbessern.