|
Zu diesem Buch – sowie zu vielen weiteren O’Reilly-Büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei oreilly.plus+: www.oreilly.plus |
Teams, Tools und Infrastrukturen
erfolgreich umgestalten
Gene Kim, Jez Humble,
Patrick Debois & John Willis
Gene Kim, Jez Humble, Patrick Debois & John Willis
Lektorat: Alexandra Follenius
Übersetzung: Thomas Demmig
Korrektorat: Sibylle Feldmann, www.richtiger-text.de
Satz: III-satz, www.drei-satz.de
Herstellung: Susanne Bröckelmann
Umschlaggestaltung: Michael Oréal, www.oreal.de
Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn
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.
ISBN:
Print978-3-96009-047-2
PDF978-3-96010-123-9
ePub978-3-96010-124-6
mobi978-3-96010-125-3
Dieses Buch erscheint in Kooperation mit O’Reilly Media, Inc. unter dem Imprint »O’REILLY«. O’REILLY ist ein Markenzeichen und eine eingetragene Marke von O’Reilly Media, Inc. und wird mit Einwilligung des Eigentümers verwendet.
1. Auflage 2017
Copyright © 2017 dpunkt.verlag GmbH
Wieblinger Weg 17
69123 Heidelberg
Authorized German translation of the English original »The DevOps Handbook« © 2016 by Gene Kim, Jez Humble, Patrick Debois, and John Willis, ISBN 978-1-942788-00-3. This translation is published and sold by permission of IT Revolution Press LLC, which owns or controls all rights to publish and sell the same.
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Die Informationen in diesem Buch wurden mit größter Sorgfalt erarbeitet. Dennoch können Fehler nicht vollständig ausgeschlossen werden. Verlag, Autoren und Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für eventuell verbliebene Fehler und deren Folgen.
5 4 3 2 1 0
Einleitung
Vorwort
Stellen Sie sich eine Welt vor, in der Dev und Ops zu DevOps werden: Eine Einführung in das DevOps-Handbuch
Teil I:Die Drei Wege
1Agile, Continuous Delivery und die Drei Wege
Die Wertkette in der Herstellung
Die Technologie-Wertkette
Die Drei Wege: Die Prinzipien als Basis von DevOps
Zusammenfassung
2Der Erste Weg: Die Prinzipien des Flow
Wir machen unsere Arbeit sichtbar
Die Work in Process (WIP) beschränken
Die Batchgrößen reduzieren
Die Anzahl der Übergaben reduzieren
Unsere Flaschenhälse kontinuierlich identifizieren und reduzieren
Schwierigkeiten und Verschwendung in der Wertkette eliminieren
Zusammenfassung
3Der Zweite Weg: Die Prinzipien des Feedbacks
Mit komplexen Systemen sicher arbeiten
Probleme bei ihrem Auftreten erkennen
Probleme umschwärmen und lösen, um neues Wissen zu schaffen
Die Qualität näher zur Quelle bringen
Für folgende Arbeitsstationen optimieren
Zusammenfassung
4Der Dritte Weg: Die Prinzipien des kontinuierlichen Lernens und Experimentierens
Firmenweites Lernen und eine Sicherheitskultur ermöglichen
Institutionalisieren Sie die Verbesserungen bei der täglichen Arbeit
Lokale Entdeckungen in globale Verbesserungen umwandeln
Resilienzmuster in unsere tägliche Arbeit einbringen
Führungskräfte unterstützen eine Kultur des Lernens
Zusammenfassung
Zusammenfassung Teil I
Teil II:Wie man beginnt
5Die Auswahl der ersten Wertkette
Greenfield- vs. Brownfield-Services
Systems of Record und Systems of Engagement berücksichtigen
Beginnen Sie mit den wohlgesonnensten und innovativsten Gruppen
DevOps in unserer Firma verbreiten
Zusammenfassung
6Die Arbeit in der Wertkette verstehen, sie sichtbar machen und verbreiten
Die Teams identifizieren, die unsere Wertkette unterstützen
Eine Value Stream Map erstellen, um die Arbeit sichtbar zu machen
Ein dediziertes Transformationsteam aufstellen
Tools einsetzen, um das gewünschte Verhalten zu unterstützen
Zusammenfassung
7Organisation und Architektur anhand von Conways Gesetz entwerfen
Organisatorische Archetypen
Probleme, die häufig durch eine zu starke Funktionsorientierung verursacht werden (»Auf Kosten optimiert«)
Marktorientierte Teams anstreben (»Auf Geschwindigkeit optimieren«)
Funktionsorientierung nutzen
Tests, Operations und Sicherheit als Aufgaben für jedermann an jedem Tag
Jedes Teammitglied zu einem Generalisten machen
Nicht Projekte finanzieren, sondern Services und Produkte
Teamgrenzen anhand von Conways Gesetz festlegen
Lose gekoppelte Architektur nutzen, damit Entwickler produktiv und sicher arbeiten können
Zusammenfassung
8Operations in die tägliche Entwicklungsarbeit integrieren
Mit gemeinsam genutzten Services die Produktivität der Entwickler erhöhen
Ops-Techniker in unsere Serviceteams integrieren
Jedem Serviceteam eine Ops-Liaison verschaffen
Ops in die Dev-Rituale integrieren
Zusammenfassung
Zusammenfassung Teil II
Teil III:Der Erste Weg: Die technischen Praktiken des Flow
9Die Grundlagen für unsere Deployment-Pipeline legen
Dev-, Test- und Produktivumgebungen auf Anforderung erstellen können
Ein Single Repository of Truth für das gesamte System schaffen
Infrastruktur einfacher neu bauen, statt zu reparieren
Die Definition des Entwicklungs-»Done« so anpassen, dass der Code in produktivähnlichen Umgebungen läuft
Zusammenfassung
10Schnelles und zuverlässiges automatisiertes Testen ermöglichen
Continuous Build, Test und Integration von Code und Umgebungen
Eine schnelle und zuverlässige automatisierte Validierungstest-Suite aufbauen
Unsere Andon-Cord ziehen, wenn die Deployment-Pipeline unterbrochen wird
Zusammenfassung
11Continuous Integration ermöglichen und umsetzen
Entwicklung in kleinen Batchgrößen und was passiert, wenn wir zu selten Code in den Trunk committen
Trunk-basierte Entwicklungspraktiken übernehmen
Zusammenfassung
12Releases automatisieren und ihr Risiko reduzieren
Unseren Deployment-Prozess automatisieren
Deployments von Releases entkoppeln
Übersicht über Continuous Delivery und Continuous Deployment in der Praxis
Zusammenfassung
13Eine Architektur für risikoarme Releases
Architektonische Prototypen: Monolith vs. Microservices
Mit dem Strangler-Application-Muster die Firmenarchitektur sicher weiterentwickeln
Zusammenfassung
Zusammenfassung Teil III
Teil IV:Der Zweite Weg: Die technischen Praktiken des Feedbacks
14Telemetriedaten erzeugen, um Probleme zu erkennen und zu beheben
Unsere zentrale Telemetrie-Infrastruktur aufbauen
Anwendungs-Logging-Telemetriedaten erzeugen, die in der Produktivumgebung helfen
Mit Telemetriedaten beim Lösen von Problemen helfen
Produktivmetriken als Teil der täglichen Arbeit ermöglichen
Self-Service-Zugriff auf Telemetriedaten und Information Radiators schaffen
Telemetrielücken finden und füllen
Zusammenfassung
15Telemetriedaten analysieren, um Probleme besser vorherzusehen und Ziele zu erreichen
Mit Mittelwert und Standardabweichung potenzielle Probleme erkennen
Unerwünschte Ergebnisse instrumentieren und davor warnen
Probleme, die entstehen, wenn die Telemetriedaten keine Gauß-Verteilung aufweisen
Techniken zur Anomalie-Erkennung einsetzen
Zusammenfassung
16Feedback ermöglichen, sodass Entwicklung und Operations Code sicher deployen können
Deployments mit Telemetriedaten sicherer machen
Dev nimmt am Bereitschaftsdienst von Ops teil
Entwickler ermutigen, ihre Arbeit in der Wertkette zu beobachten
Entwickler ihren Produktivservice initial selbst betreuen lassen
Zusammenfassung
17Hypothesengetriebene Entwicklung und A/B-Tests in die tägliche Arbeit integrieren
Eine kurze Geschichte des A/B-Testens
A/B-Tests in unser Feature-Testing integrieren
A/B-Tests in unser Release einbinden
A/B-Tests in unsere Feature-Planung integrieren
Zusammenfassung
18Review- und Koordinationsprozesse schaffen, um die Qualität der aktuellen Arbeit zu verbessern
Die Gefahren von Change-Approval-Prozessen
Potenzielle Gefahren von »zu sehr kontrollierten Änderungen«
Koordination und Planung von Änderungen ermöglichen
Peer Review für Änderungen einführen
Potenzielle Gefahren durch mehr manuelle Tests und Änderungssperren
Durch Pair Programming all unsere Änderungen verbessern
Bürokratische Prozesse unerschrocken stoppen
Zusammenfassung
Zusammenfassung Teil IV
Teil V:Der Dritte Weg: Die technischen Praktiken des fortlaufenden Lernens und Experimentierens
19Lernen ermöglichen und Erfahrungen in die tägliche Arbeit einbringen
Eine Just Culture und eine Kultur des Lernens umsetzen
Post-Mortem-Meetings ohne Schuldzuweisung nach dem Eintreten von Unfällen
Unsere Post-Mortem-Analysen so weit wie möglich verbreiten
Die Toleranz gegenüber Vorfällen weiter absenken, um immer schwächere Fehlersignale zu erkennen
Fehler neu definieren und das Eingehen kalkulierter Risiken unterstützen
Fehler in die Produktivumgebung einbringen, um Resilienz und Lernen zu ermöglichen
Game Days einführen, um Zwischenfälle zu üben
Zusammenfassung
20Lokale Erkenntnisse in globale Verbesserungen verwandeln
Mit Chatrooms und Chat Bots firmenweites Wissen automatisieren und einfangen
Standardisierte Prozesse zur Wiederverwendung in Software automatisieren
Ein einzelnes, gemeinsam genutztes Quellcode-Repository für die gesamte Firma nutzen
Wissen durch automatisierte Tests als Dokumentation und Community of Practice verbreiten
Durch kodifizierte nicht funktionale Anforderungen für Operations designen
Wiederverwendbare Operations User Stories in die Entwicklung integrieren
Sicherstellen, dass technologische Entscheidungen dabei helfen, die Firmenziele zu erreichen
Zusammenfassung
21Zeit für das firmenweite Lernen und für Verbesserungen reservieren
Rituale institutionalisieren, um technische Schulden zu bezahlen
Lehren und Lernen für jeden ermöglichen
Teilen Sie Ihre auf DevOps-Konferenzen Ihre Erfahrungen
Internes Consulting und Coaches zum Verbreiten von Praktiken aufbauen
Zusammenfassung
Zusammenfassung Teil V
Teil VI:Die technischen Praktiken zum Integrieren von Information Security, Änderungsmanagement und Compliance
22Information Security als Aufgabe für jeden Mitarbeiter an jedem Tag
Infosec in die Präsentationen der Entwicklungsiterationen einbinden
Infosec in das Fehler-Tracking und in Post-Mortem-Analysen einbinden
Präventive Sicherheitsmaßnahmen in die gemeinsam genutzten Quellcode-Repositories und Services integrieren
Infosec in unsere Deployment-Pipeline einbinden
Für die Sicherheit der Anwendung sorgen
Die Sicherheit unserer Software-Lieferkette sicherstellen
Die Sicherheit der Umgebung gewährleisten
Infosec in die Produktiv-Telemetriedaten integrieren
Sicherheits-Telemetriedaten in unseren Anwendungen erstellen
Sicherheits-Telemetriedaten in unserer Umgebung erstellen
Unsere Deployment-Pipeline schützen
Zusammenfassung
23Die Deployment-Pipeline schützen
Sicherheit und Compliance in den Prozess zur Änderungsgenehmigung integrieren
Den Großteil unserer Änderungen mit geringem Risiko als Standardänderungen neu kategorisieren
Was zu tun ist, wenn Änderungen als normale Änderungen eingestuft werden
Das Vertrauen in die Segregation of Duty reduzieren
Für Dokumentation und Belege für Auditoren und Compliance Officer sorgen
Zusammenfassung
Zusammenfassung Teil VI
24Ein Aufruf zum Handeln
Anhänge:Zusatzmaterial
ADie Konvergenz von DevOps
BTheory of Constraints und zentrale chronische Konflikte
CTabellarische Form der Abwärtsspirale
DDie Gefahren von Übergaben und Queues
EMythen der Arbeitssicherheit
FDie Toyota-Andon-Cord
GCOTS-Software
HPost-Mortem-Meetings
IDie Simian Army
JTransparent Uptime
KWeitere Ressourcen
LDanksagungen
Index
Aha!
Das DevOps-Handbuch ist nicht von heute auf morgen entstanden – es begann im Februar 2011 mit wöchentlichen Skype-Telefonaten zwischen den Autoren und der Vision, dem damals noch unvollendeten Buch Projekt Phoenix: Der Roman über IT und DevOps – Neue Erfolgsstrategien für Ihre Firma ein präskriptives Handbuch zur Seite zu stellen.
Über fünf Jahre und mehr als zweitausend Arbeitsstunden später ist das DevOps-Handbuch endlich fertig. Ein außerordentlich langwieriger Prozess, der aber sehr lohnenswert und lehrreich war und den Rahmen viel weiter spannte, als wir uns das ursprünglich vorgestellt hatten. Alle Autoren eint, dass sie an DevOps als außerordentlich wichtiges Konzept glauben, weil sie in ihrem Berufsleben einen »Aha-Moment« hatten, den unsere Leser sicherlich interessiert.
Gene Kim. Ich hatte die Möglichkeit, seit 1999 erfolgreiche Technologiefirmen untersuchen zu können, und eine der ersten Erkenntnisse war, dass die bereichsübergreifende Zusammenarbeit der unterschiedlichen Gruppen – IT Operations, Information Security und Development – für den Erfolg entscheidend ist. Ich erinnere mich vor allem an das erste Mal, als ich die Abwärtsspirale beobachten konnte, die entstand, weil diese Gruppen unterschiedliche Ziele verfolgten.
In 2006 hatte ich die Gelegenheit, für eine Woche eine Gruppe zu begleiten, die die outgesourcten IT Operations eines großen Flugbuchungsdienstleisters betreute. Mir wurden die negativen Folgen der umfangreichen jährlichen Software-Releases beschrieben, die jedes Mal zu großem Chaos und Unterbrechungen für den Outsourcer, aber auch für die Kunden führen würden. Es gäbe wegen der für den Kunden bemerkbaren Ausfälle Strafen aufgrund nicht eingehaltener SLAs (Service Level Agreement), der Gewinn bräche ein, und daher würden die talentiertesten und erfahrensten Mitarbeiter entlassen werden. Es müssten mehr ungeplante Aufgaben erledigt und überall Feuer gelöscht werden. Die verbleibende Crew hätte noch weniger Zeit, den stetig wachsenden Service Request Backlog der Kunden abzuarbeiten. Die Verträge würden überhaupt nur durch den massiven Einsatz des mittleren Managements aufrechterhalten werden, und alle hätten Angst, dass sie in drei Jahren bei einer Neuausschreibung sowieso nicht mehr zum Zuge kämen.
Das Gefühl der Hoffnungslosigkeit und Sinnlosigkeit der Arbeit war für mich der Startschuss für meinen moralischen Kreuzzug. Development schien immer als strategisch wichtig angesehen zu werden, während IT Operations nur taktisch betrachtet wurde – etwas, das man gern wegdelegierte oder gleich ganz auslagerte, nur um es fünf Jahre später in einer noch schlechteren Verfassung wiederzubekommen.
Während all der Jahre war den meisten von uns bewusst, dass es einen besseren Weg geben musste. Ich erinnere mich an die Vorträge der Velocity Conference im Jahr 2009, in denen die erstaunlichen Ergebnisse vorgestellt wurden, die aus der Architektur, den Praktiken und kulturellen Normen entstanden, die wir als DevOps kennen. Ich war total begeistert, weil hier der bessere Weg, nach dem wir alle suchten, deutlich aufgezeigt wurde. Dieses Wissen zu verbreiten, war Teil meiner persönlichen Motivation, am Projekt Phoenix mitzuarbeiten. Sie können sich vorstellen, wie glücklich ich darüber war, dass viele Menschen durch das Buch ihre eigenen Aha-Momente hatten.
Jez Humble. Mein Aha-Moment mit DevOps erlebte ich bei einem Start-up im Jahr 2000 – in meinem ersten Job, den ich nach dem Studium annahm. Eine Zeit lang war ich einer von zwei Technikmitarbeitern. Ich machte alles: Netzwerk, Programmieren, Support, Systemverwaltung. Wir deployten Software in die Produktivumgebung, indem wir sie per FTP direkt von unseren Workstations hochluden.
2004 erhielt ich dann einen Job bei ThoughtWorks – einer Consulting-Firma, in der ich als Erstes in einem Projekt zusammen mit ungefähr 70 Leuten arbeiten sollte. Ich gehörte zu einem Team aus acht Entwicklern, deren einzige Aufgabe das Deployen unserer Software in eine der Produktivumgebung ähnliche Umgebung war. Zu Beginn war das sehr stressig. Aber im Laufe der Zeit schafften wir es, von einem manuellen Deployment, das zwei Wochen brauchte, zu einem automatisierten zu gelangen, das nur eine Stunde dauerte und bei dem der Wechsel zwischen alter und neuer Umgebung in Millisekunden vonstattenging – während der normalen Arbeitszeit und mithilfe des Blue-Green-Deployment-Musters.
Dieses Projekt war Inspirationsquelle für viele der Ideen in Continuous Delivery (Addison-Wesley, 2010) und in diesem Buch. Mich und viele andere, die in diesem Bereich unterwegs sind, treibt das Wissen an, dass es – unabhängig von den gegebenen Randbedingungen – immer besser geht und dass ich den Menschen auf ihrer Reise dorthin helfen möchte.
Patrick Debois. Bei mir waren es mehrere Momente. 2007 arbeitete ich in einem Data-Center-Migration-Projekt mit ein paar Agile-Teams zusammen. Ich war neidisch, dass sie so produktiv waren und in kurzer Zeit so viel erledigen konnten.
In meinem nächsten Projekt begann ich, in Operations mit Kanban zu experimentieren, und ich beobachtete, wie sich die Teamdynamik änderte. Später stellte ich auf der Agile Toronto Conference 2008 mein IEEE-Paper dazu vor, hatte aber das Gefühl, dass es in der Agile-Community nicht groß wahrgenommen wurde. Wir setzten eine Agile-System-Administration-Gruppe auf, aber ich achtete nicht auf die menschliche Seite des Ganzen.
Nachdem ich auf der Velocity Conference 2009 die Präsentation »10 Deploys per Day« von John Allspaw und Paul Hammond gesehen hatte, war ich davon überzeugt, dass auch andere wie ich dachten. Also entschied ich mich dazu, die ersten DevOpsDays zu organisieren, und prägte damit unabsichtlich den Begriff DevOps.
Die Energie auf diesem Event war einmalig und ansteckend. Als die Menschen anfingen, sich bei mir dafür zu bedanken, dass ihr Leben nun besser geworden sei, verstand ich den Einfluss, den das Ganze hatte. Seitdem habe ich nicht mehr damit aufgehört, DevOps anzupreisen.
John Willis. 2008 hatte ich gerade eine Consulting-Firma verkauft, die auf Beratung im Umfeld von großen Legacy-IT-Operations rund um Configuration Management und Monitoring spezialisiert war (Tivoli). Ich traf Luke Kanies (den Begründer von Puppet Labs), der auf einer Open-Source-Konferenz von O’Reilly einen Vortrag über Configuration Management (CM) hielt.
Zuerst lungerte ich nur hinten im Vortragsraum herum, schlug die Zeit tot und dachte: »Was kann mir dieser Zwanzigjährige schon über Configuration Management erzählen?« Schließlich hatte ich schon mein ganzes Leben bei ein paar der größten Unternehmen der Welt gearbeitet und ihnen dabei geholfen, die Architektur für ihr CM und andere Operations-Management-Lösungen aufzubauen. Aber nach fünf Minuten setzte ich mich ganz nach vorne und erkannte, dass alles, was ich in den letzten 20 Jahren gemacht hatte, falsch gewesen war. Luke beschrieb das, was ich heute als CM der zweiten Generation bezeichne.
Nach seiner Session hatte ich die Gelegenheit, mich mit ihm auf einen Kaffee zusammenzusetzen. Von dem, was wir heute als Infrastructure as Code bezeichnen, war ich vollkommen überzeugt. Aber bei unserem Gespräch ging Luke noch weiter und erläuterte mir seine Ideen. Er glaubte, dass sich Operations mehr wie Softwareentwicklung verhalten müsse. Sie müssten ihre Konfigurationen unter Versionsverwaltung stellen und für ihren Workflow CI/CD-Delivery-Muster übernehmen. Ich war damals noch der Oldschool-IT-Operations-Mensch und antwortete wohl mit so etwas wie: »Diese Idee wird so wenig Erfolg haben wie Led Zeppelin mit ihrem Folk-Kram.« (Ich lag so was von falsch!)
Etwa ein Jahr später in2009 besuchte ich auf einer anderen O’Reilly-Konferenz (Velocity) einen Vortrag von Andrew Clay Shafer über Agile Infrastructure. Dabei zeigte Andrew dieses berühmte Bild einer Mauer zwischen Entwicklern und Operations, bei der die Arbeit immer nur hinübergeworfen wird. Dieses Bild bezeichnete er als »Wall of Confusion«. Die Ideen in diesem Vortrag kodifizierten das, was Luke mir ein Jahr zuvor zu erklären versuchte, und mir ging ein Licht auf. Im selben Jahr war ich der einzige Amerikaner, der zu den ersten DevOpsDays in Gent eingeladen wurde. Als dieses Event vorbei war, floss DevOps durch meine Adern.
Alle Autoren dieses Buchs hatten ganz klar die gleiche Erscheinung, auch wenn sie aus verschiedenen Richtungen kamen. Aber es gibt eine unglaubliche Menge an Belegen dafür, dass die beschriebenen Probleme so gut wie überall auftauchen und dass sich die Lösungen, die mit DevOps verbunden sind, nahezu universell einsetzen lassen.
Dieses Buch will beschreiben, wie Sie die Transformationen durch DevOps, an denen wir beteiligt waren oder die wir beobachten konnten, selbst umsetzen können, es will aber auch mit vielen Mythen aufräumen, die vorzugeben versuchen, warum DevOps in bestimmten Situationen nicht funktionieren wird. Ein paar der bekanntesten Mythen, die wir über DevOps gehört haben, sind:
Mythos: DevOps ist nur für Start-ups
DevOps-Praktiken entstanden zwar in Internet-»Unicorn«-Firmen wie Google, Amazon, Netflix und Etsy, aber alle waren an einem das Geschäft gefährdenden Punkt angelangt – aufgrund von Problemen, die eher mit den klassischen »Horses«-Firmen verbunden sind: hochriskante Code-Releases, die zu katastrophalen Fehlschlägen zu werden drohten, fehlende Möglichkeiten, Features schnell genug veröffentlichen zu können, um so der Konkurrenz zuvorzukommen, Compliance-Sorgen, die Unfähigkeit, skalieren zu können, riesiges Misstrauen zwischen Entwicklung und Operations usw.
Aber alle diese Firmen schafften es, ihre Architektur, die technischen Praktiken und ihre Kultur so umzustellen, dass diese erstaunlichen Ergebnisse entstanden, die wir mit DevOps verbinden. Wie der Information Security Executive Dr. Branden Williams gern scherzt: »Reden wir nicht mehr über DevOps-Einhörner oder -Pferde, sondern nur noch über Vollblüter oder Pferde, die zum Abdecker müssen.«
Mythos: DevOps ersetzt Agile
DevOps-Prinzipien und -Praktiken sind kompatibel zu Agile, und viele haben das Gefühl, dass es sich bei DevOps um eine logische Fortsetzung der Agile-Reise handelt, die 2001 ihren Anfang nahm. Agile dient häufig als effektiver Türöffner für DevOps, weil es sich auf kleine Teams fokussiert, die den Kunden kontinuierlich qualitativ hochwertigen Code liefern.
Viele DevOps-Praktiken entwickeln sich daraus, dass wir unsere Arbeit über das Ziel des »potenziell auslieferbaren Codes« am Ende jeder Iteration hinaus fortführen und dafür sorgen, dass er sich stets in einem auslieferbaren Zustand befindet, den Entwickler täglich einchecken und mit dem wir unsere Features in produktivähnlichen Umgebungen präsentieren.
Mythos: DevOps ist nicht kompatibel zu ITIL
Viele sehen DevOps als Rückschritt gegenüber ITIL oder ITSM (IT Service Management), das ursprünglich 1989 veröffentlicht wurde. ITIL hat viele Generationen von Ops-Mitarbeitern beeinflusst, einen der Autoren eingeschlossen, und ist eine stetig weiterentwickelte Praxisbibliothek, mit der die Prozesse und Vorgehensweisen erstklassiger IT Operations kodifiziert werden sollen – einschließlich Servicestrategie, Design und Support.
DevOps-Praktiken können kompatibel zum ITIL-Prozess gestaltet werden. Aber um die mit DevOps in Verbindung gebrachten kürzeren Durchlaufzeiten und höheren Deployment-Frequenzen zu unterstützen, müssen viele Teile der ITIL-Prozesse vollständig automatisiert werden, was eine Reihe von Problemen rund um das Konfigurations- und Release-Management löst (zum Beispiel werden so die Konfigurationsmanagement-Datenbank und die Softwarebibliotheken aktuell gehalten). Und weil zu DevOps auch das schnelle Erkennen von und Reagieren auf Serviceprobleme gehören, bleiben die ITIL-Bereiche Servicedesign sowie Störungs- und Problemmanagement so wichtig wie zuvor.
Mythos: DevOps ist nicht kompatibel zu Information Security und Compliance
Das Fehlen klassischer Steuerelemente (zum Beispiel der Segregation of Duty, eines Änderungsgenehmigungsprozesses oder manueller Security Reviews am Ende des Projekts) mag Experten für Information Security und Compliance in Panik versetzen.
Aber das heißt nicht, dass DevOps-Organisationen keine effektiven Steuerelemente besitzen. Statt Security- und Compliance-Aktivitäten nur am Projektende durchzuführen, lassen sich diese auf jeder Ebene der täglichen Arbeit im Softwareentwicklungs-Lifecycle einbinden, was zu mehr Qualität, Sicherheit und Regelkonformität führt.
Mythos: DevOps eliminiert IT Operations – »NoOps«
Viele missverstehen DevOps als vollständiges Eliminieren der Funktionen von IT Operations. Aber das ist nur sehr selten der Fall. Die Arbeit in IT Operations mag sich ändern, aber sie bleibt so wichtig wie zuvor. IT Operations arbeitet jetzt viel früher im Software-Lifecycle mit der Entwicklung zusammen, während Letztere wiederum auch dann noch mit IT Operations zu tun hat, wenn der Code schon längst produktiv gegangen ist.
Anstatt dass IT Operations manuell Aufgaben erledigt, die aus dem Ticketsystem purzeln, ermöglicht diese Gruppe der Entwicklung, produktiver zu werden, indem sie APIs und Self-Service-Plattformen anbietet, mit denen Umgebungen erstellt werden können. Außerdem kann Code getestet und deployt, die Produktivumgebung überwacht und angezeigt werden und vieles mehr. Dadurch nähert sich IT Operations mehr der Entwicklung an (genauso wie QA und Infosec) und ist an der Produktentwicklung beteiligt, wobei das Produkt hier eine Plattform ist, auf der Entwickler sicher, schnell und zuverlässig ihre IT-Services testen, deployen und in der Produktivumgebung laufen lassen können.
Mythos: DevOps ist nur »Infrastructure as Code« oder Automatisierung
Viele der DevOps-Muster in diesem Buch erfordern durchaus eine Automatisierung, aber DevOps benötigt auch kulturelle Normen und eine Architektur, die es der gesamten IT-Werschöpfungskette erlaubt, die gemeinsamen Ziele zu erreichen. Das geht weit über Automatisierung hinaus. Wie Christopher Little – Technology Executive und einer der ersten Chronisten von DevOps – schrieb: »Bei DevOps geht es nicht um Automatisierung, so wie es in der Astronomie nicht um Teleskope geht.«
Mythos: DevOps geht nur mit Open-Source-Software
Auch wenn viele DevOps-Erfolgsgeschichten in Firmen geschrieben werden, die Software wie den LAMP-Stack nutzen (Linux, Apache, MySQL, PHP), können die Ergebnisse unabhängig von der verwendeten Technologie erreicht werden. Es gibt genauso positive Berichte über Anwendungen, die in Microsoft.NET, COBOL oder Mainframe-Assembler-Code geschrieben wurden, ebenso in der SAP-Welt und sogar in Embedded Systems (zum Beispiel HP LaserJet-Firmware).
Alle Autoren dieses Buchs wurden von den erstaunlichen Innovationen inspiriert, die in der DevOps-Community stattfinden, und von den Ergebnissen, die daraus entstehen: Es bilden sich zuverlässige Arbeitssysteme, und kleine Teams können schnell und unabhängig Code entwickeln und validieren, der sich dann zuverlässig an die Kunden ausliefern lässt. Wir glauben, dass es sich bei DevOps um eine Manifestation dynamischer, lernfähiger Firmen handelt, die fortlaufend ihre auf viel Vertrauen basierenden Normen weiterentwickeln. Und genau solche Organisationen werden weiterhin innovativ und im Markt erfolgreich sein.
Wir hoffen wirklich, dass das DevOps-Handbuch für viele Menschen eine wertvolle Quelle sein wird:
Damit wird es für den Einzelnen nicht nur einfacher, höher gesteckte Ziele zu erreichen, auch die Firma profitiert davon.
In der Vergangenheit gab es in vielen Bereichen des Ingenieurwesens auf die eine oder andere Weise merklichen Fortschritt und ein wachsendes Verständnis der eigenen Arbeit. Es gibt in vielen Ingenieurdisziplinen universitäre Weiterbildung und Organisationen, die Expertenhilfe bieten (Bauwesen, Maschinenbau, Elektrotechnik, Nukleartechnik usw). Tatsächlich braucht die moderne Gesellschaft auch alle Arten von Ingenieuren, um die Vorteile der interdisziplinären Zusammenarbeit zu erkennen und diese umzusetzen.
Denken Sie an die Konstruktion eines modernen Autos. Wo endet die Arbeit eines Maschinenbauers, und wo beginnt die eines Elektrotechnikers? Wo (und wie und wann) sollte jemand mit Aerodynamik-Kenntnissen (der sicherlich eine ziemlich genaue Vorstellung davon hat, wie die Fenster aussehen sollten, wie groß sie zu sein haben und wo sie sitzen sollten) mit einem Experten für die Sitzergonomik zusammenarbeiten? Was ist mit dem chemischen Einfluss des Treibstoffs und des Öls auf die Materialien von Motor und Schläuchen über die gesamte Lebenszeit des Autos? Es gibt zum Design eines Autos noch viel mehr Fragen, die man stellen kann, aber das Ergebnis ist immer das gleiche: Erfolg stellt sich in modernen technischen Projekten nur ein, wenn mehrere Sichtweisen und unterschiedliches Expertenwissen zusammenkommen.
Damit sich ein technischer Bereich weiterentwickelt, muss ein Punkt erreicht werden, an dem man sich Gedanken über den bisherigen Weg macht, diesen von mehreren Seiten beleuchtet und das Ganze so zusammenfasst, dass es für die Vorstellungen der Community zur Zukunft hilfreich ist.
Dieses Buch bietet diese Zusammenfassung und sollte als grundlegende Sammlung von Sichtweisen auf das (zugegebenermaßen sich noch entwickelnde und wachsende) Feld von Softwareentwicklung und Operations gesehen werden.
Egal in welcher Branche Sie arbeiten oder welches Produkt oder welchen Service Ihre Firma bereitstellt – diese Art des Denkens ist für das Überleben jedes Business und Technology Leader außerordentlich wichtig.
John Allspaw, CTO, Etsy
Brooklyn, NY, August 2016
Eine Einführung in das DevOps-Handbuch
Stellen Sie sich eine Welt vor, in der Product Owner, Entwicklung, QA, IT Operations und Infosec zusammenarbeiten – nicht nur, um sich gegenseitig zu helfen, sondern auch, um sicherzustellen, dass die gesamte Firma Erfolg hat. Indem für ein gemeinsames Ziel gearbeitet wird, ermöglicht man den schnellen Fluss geplanter Arbeit in die Produktivumgebung (zum Beispiel durch zehn, Hunderte oder Tausende Code-Deploys pro Tag), während gleichzeitig herausragende Stabilität, Zuverlässigkeit, Verfügbarkeit und Sicherheit gewährleistet werden.
In dieser Welt testen funktionsübergreifende Teams rigoros ihre Hypothesen darüber, welche Features die Benutzer am meisten erfreuen und das Unternehmen voranbringen. Sie kümmern sich nicht nur um das Implementieren von Benutzerfeatures, sondern sie stellen auch aktiv sicher, dass ihre Arbeit geräuschlos und wiederholt die gesamte Wertkette durchläuft, ohne in IT Operations oder bei internen oder externen Kunden Chaos und Unterbrechungen zu verursachen.
QA, IT Operations und Infosec arbeiten parallel daran, Reibungsverluste zwischen den Teams zu verringern und Systeme aufzubauen, die es den Entwicklern ermöglichen, produktiver zu sein und bessere Ergebnisse zu erhalten. Indem das Wissen von QA, IT Operations und Infosec mit dem der Delivery-Teams verbunden und automatisierte Self-Service-Tools und -Plattformen geschaffen werden, können die Teams ihre tägliche Arbeit erledigen, ohne von anderen Teams abhängig zu sein.
Damit können Firmen eine zuverlässige Arbeitsumgebung aufbauen, in der kleine Teams schnell und unabhängig voneinander Code entwickeln, testen und deployen und diesen Wert den Kunden schnell, sicher und zuverlässig bereitstellen. So maximieren Firmen die Produktivität der Entwickler, ermöglichen ein unternehmensweites Lernen, sorgen für eine hohe Mitarbeiterzufriedenheit und sind im Markt erfolgreich.
Das sind Ergebnisse, die durch DevOps zustande kommen können. Die meisten von uns leben aber in einer anderen Welt. Häufig ist das System, nach dem wir arbeiten, kaputt, was zu ausgesprochen schlechten Ergebnissen führt, die unser Potenzial bei Weitem nicht widerspiegeln. In unserer Welt sind Entwicklung und IT Operations Kontrahenten, Tests und Aktivitäten von Infosec geschehen erst am Ende eines Projekts – zu spät, um gefundene Probleme noch zu beheben –, und fast alle kritischen Aufgaben erfordern einen zu großen manuellen Aufwand und zu viele Übergaben, was dazu führt, dass wir ständig warten. So etwas führt nicht nur zu ausgesprochen langen Durchlaufzeiten, wenn wir Aufgaben zu erledigen haben, dazu ist die Qualität unserer Arbeit – insbesondere das Deployen in die Produktion – problematisch und chaotisch, was negative Auswirkungen auf unsere Kunden und unser Geschäft hat.
Letztendlich erreichen wir unsere Ziele nicht, und die gesamte Firma ist mit der Leistung der IT unzufrieden, was zu Budgetkürzungen und frustrierten Mitarbeitern führt, die das Gefühl haben, den Prozess und seine Ergebnisse sowieso nicht ändern zu können.1 Die Lösung? Wir müssen die Art und Weise, wie wir arbeiten, ändern – und DevOps zeigt uns den besten Weg dorthin.
Um das Potenzial der DevOps-Revolution besser zu verstehen, wollen wir uns die Umwälzungen in der Produktfertigung der 1980er-Jahre anschauen. Durch die Übernahmen von Lean-Prinzipien und -Praktiken verbesserten Firmen drastisch die Produktivität ihrer Fabriken, die Verfügbarkeit für den Kunden, die Produktqualität und die Kundenzufriedenheit, wodurch sie im Markt mehr Erfolg hatten.
Vor der Revolution betrugen die durchschnittlichen Herstellungs- und Lieferzeiten einer Fabrik sechs Wochen, wobei weniger als 70 % der Bestellungen pünktlich beim Kunden ankamen.2 Im Jahr 2005 – nach einer weiten Verbreitung von Lean-Praktiken – verringerte sich die durchschnittliche Zeitdauer auf weniger als drei Wochen, und mehr als 95 % der Lieferungen waren pünktlich. Firmen, die keine Lean-Praktiken umsetzten, verloren Marktanteile, und viele mussten ganz aufgeben.
Genauso wurde die Latte bei Technologieprodukten und -Dienstleistungen ebenfalls höher gelegt – was früher gut genug war, reicht jetzt nicht mehr aus. In den letzten 40 Jahren sind die Kosten und Zeiträume, die zum Entwickeln und Deployen von geschäftsentscheidenden Fähigkeiten und Features notwendig waren, kontinuierlich um Größenordnungen gesunken. In den 1970er- und 1980er-Jahren brauchten die meisten Features ein bis fünf Jahre für die Entwicklung und Umsetzung, und sie kosteten oft zweistellige Millionenbeträge.
In den 2000ern verringerte sich die Zeit aufgrund der Fortschritte in der Technologie und der Übernahme von agilen Prinzipien und Praktiken auf Wochen oder Monate, während das Deployen in die Produktivumgebung immer noch ebenfalls Wochen oder Monate brauchte – häufig mit katastrophalen Ergebnissen.
In den 2010er-Jahren – mit der Einführung von DevOps und immer mehr Verbreitung findender Hardware, Software und mittlerweile der Cloud – können Features (und sogar ganze Start-ups) in Wochen entwickelt werden und innerhalb von Stunden oder Minuten in Produktion gehen. Für solche Firmen wurde das Deployment endlich zur Routine mit nur wenigen Risiken. Sie können Experimente durchführen, um Geschäftsideen auszuprobieren, herausfinden, welche Ideen dem Kunden und der Firma als Ganzem den meisten Nutzen bringen, und diese dann in Features umsetzen, die sich schnell und zuverlässig wieder in der Produktion einsetzen lassen.
Tabelle 1: Der sich stetig beschleunigende Trend hin zu einem schnelleren, billigeren und risikoärmeren Ausliefern von Software (Quelle: Adrian Cockcroft, »Velocity and Volume (or Speed Wins)«, Vortrag auf der FlowCon, San Francisco, November 2013)
Heutzutage deployen Unternehmen, die die Prinzipien und Praktiken von DevOps übernehmen, oft Hunderte oder Tausende Änderungen pro Tag. In einer Zeit, in der die Time to Market kurz sein und man fortlaufend experimentieren muss, sind Firmen, die diese Ergebnisse nicht erreichen können, dazu verdammt, Marktanteile zu verlieren und eventuell sogar ganz unterzugehen – so wie die Fertigungsfirmen, die keine Lean-Prinzipien übernahmen.
Egal in was für einer Branche wir uns messen: Heutzutage hängt es von der Technologie-Wertkette ab, wie wir Kunden gewinnen und ihnen etwas bieten können. Oder wie es Jeffrey Immelt, CEO von General Electric, kurz und prägnant zusammenfasst: »Jede Branche und jede Firma, die es nicht schafft, ihr Kerngeschäft mit Software zu unterstützen, wird untergehen.«3 Jeffrey Snover, Technical Fellow bei Microsoft, sagt: »Früher haben Firmen Wert erzeugt, indem sie Atome verschoben. Heute erzeugen sie Wert, indem sie Bits verschieben.«4
Man kann die Größe dieses Problems gar nicht hoch genug ansetzen – jede Firma ist betroffen, unabhängig von Branche, Größe oder ob sie kommerziell oder gemeinnützig ist. Mehr denn je wird durch die Art und Weise, wie Technologiearbeit verwaltet und umgesetzt wird, bestimmt, ob unsere Firmen im Markt wachsen können und ob sie überhaupt überleben werden. In vielen Fällen müssen wir uns Prinzipien und Praktiken zu eigen machen, die sich deutlich von denen unterscheiden, mit denen wir in den letzten Jahrzehnten erfolgreich waren (siehe Anhang A).
Nachdem wir die Dringlichkeit des durch DevOps lösbaren Problems dargestellt haben, wollen wir uns nun genauer dessen Symptome anschauen, herausfinden, warum es auftritt und warum es sich – ohne massive Eingriffe – mit der Zeit verschlimmert.
Die meisten Firmen schaffen es nicht, Änderungen an der Produktivumgebung in Minuten oder Stunden zu deployen, der Zeitrahmen beträgt eher Wochen oder Monate. Und sie können auch keine Hunderte oder Tausende Änderungen pro Tag übernehmen, stattdessen hadern sie schon mit monatlichen oder gar vierteljährlichen Deployments. Zudem sind Deployments für die Produktivumgebung nie Routine, es kommt immer wieder zu Ausfällen, chronischem Feuerlöschen und unvermeidlichen Heldentaten.
In einer Zeit, in der man für einen Vorteil gegenüber dem Wettbewerber schnell am Markt sein, gute Serviceleistungen erbringen und immer wieder experimentieren muss, haben diese Firmen einen deutlichen Wettbewerbsnachteil. Das liegt zu großen Teilen an ihrer Unfähigkeit, einen zentralen chronischen Konflikt innerhalb ihrer Technologieorganisation aufzulösen.
In so gut wie jeder IT-Organisation gibt es einen inhärenten Konflikt zwischen Entwicklung und IT Operations, der zu einer Abwärtsspirale bei der Time to Market für neue Produkte und Features und der Qualität führt. Ausfälle treten häufiger auf, und – am schlimmsten – die technischen Schulden steigen stetig.
