Das DevOps-Handbuch (eBook)

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