Das DevOps-Handbuch (eBook)

Teams, Tools und Infrastrukturen erfolgreich umgestalten

Gene Kim, Jez Humble, Patrick Debois, John Willis, Nicole Forsgren (Autoren)

eBook Download: EPUB

2022 | 2. Auflage
520 Seiten
O'Reilly Verlag
978-3-96010-697-5 (ISBN)

Infos

Praxiswissen von den führenden Köpfen der DevOps-Bewegung

• 2., aktualisierte und erweiterte Auflage, ergänzt durch aussagekräftige neue Fallstudien
• DevOps-Prinzipien, die auch in den Romanen »Projekt Phoenix« und »Projekt Unicorn« illustriert wurden, werden in diesem Handbuch in die Praxis umgesetzt
• Mit zahlreichen konkreten Case Studies aus Firmen wie Google, Amazon oder Facebook - und jetzt neu: Adidas, American Airlines, Fannie Mae, Target oder der US Air Force

Mehr denn je ist das effektive Management der IT entscheidend für die Wettbewerbsfähigkeit von Organisationen. Viele Managerinnen und Manager in softwarebasierten Unternehmen ringen damit, eine Balance zwischen Agilität, Zuverlässigkeit und Sicherheit ihrer Systeme herzustellen. Auf der anderen Seite schaffen es High-Performer wie Google, Amazon, Facebook oder Netflix, routinemäßig und zuverlässig hundert- oder gar tausendmal pro Tag Code auszuliefern. Diese Unternehmen verbindet eins: Sie arbeiten nach DevOps-Prinzipien.
Dieses Handbuchs zeigt, wie die DevOps-Philosophie praktisch implementiert wird und Unternehmen dadurch umgestaltet werden können. Die Autor:innen beschreiben konkrete Tools und Techniken, die Ihnen helfen, Software schneller und sicherer zu produzieren. Zudem stellen sie Ihnen Maßnahmen vor, die die Zusammenarbeit aller Abteilungen optimieren, die Arbeitskultur verbessern und die Profitabilität Ihres Unternehmens steigern können. - Die 2. Auflage wurde vollständig aktualisiert und durch die neuesten Forschungsergebnisse und 15 neue Case Studies erweitert.

Gene Kim ist mehrfach ausgezeichneter CTO, Researcher und Autor der DevOps-Romane Projekt Phoenix und Projekt Unicorn. Er ist Begründer von IT Revolution und richtet die DevOps-Enterprise-Summit-Konferenzen aus. Jez Humble ist Koautor des mit dem Jolt Award prämierten Buchs Continuous Delivery und des wegweisenden Lean Enterprise. Er arbeitet bei Google und unterrichtet an der UC Berkely. Patrick Debois ist Director of DevOps Relations und Advisor bei Snyk. Er gilt als Begründer der DevOps-Bewegung: 2009 organisierte er in Belgien die namensgebende Konferenz DevOps Days. John Willis ist Senior Director of Global Transformation Office bei Red Hat und arbeitet seit über 35 Jahren im IT-Management. Er ist Koautor von Beyond The Phoenix Project und Host des Profound Podcast. Nicole Forsgren, PhD, ist Partnerin bei Microsoft Research und leitet das Developer Velocity Lab. Sie ist Autorin des Buchs Accelerate und als leitende Forscherin der bis dato größten DevOps-Studien bekannt.

Textauszug

Einleitung

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 Technologie-Firmen 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 und in diesem Buch. Mich und viele andere, die in diesem Bereich unterwegs sind, treibt das Wissen an, dass wir es trotz aller Einschränkungen immer noch besser machen können 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 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.

DevOps-Mythen

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...

Produkt-Details

• Erscheint lt. Verlag: 29.7.2022
• Übersetzer: Thomas Demmig
• Verlagsort: Heidelberg
• Sprache: deutsch
• Themenwelt: Mathematik / Informatik ► Informatik
• Schlagworte: Agile • Aplication Lifecycle Management • Change Management • Chef • Continuous Delivery • Continuous Integration • Deployment • Deployment Pipeline • DevOps • Docker • IT • operations • Puppet • Roman • Testing • Vagrant
• ISBN-10: 3-96010-697-1 / 3960106971
• ISBN-13: 978-3-96010-697-5 / 9783960106975