DevOps ist eine Philosophie bzw. ein Gesamtpaket aus Prozessen, Tools und Organisationsprinzipien, um entlang der Wertschöpfungskette von Softwareentwicklung (Development = „Dev“) bis Deployment (Operations = „Ops“) einen reibungslosen und effizienten Ablauf zu gewährleisten. Nehmen Sie eine Firma wie Amazon, wo in Entwicklungsabteilungen neue Features entwickelt werden, die einen Qualitätssicherungsprozess durchlaufen, die Compliance-Kriterien erfüllen müssen und anschließend in den Produktivbetrieb übernommen werden. Je effizienter dieser Prozess läuft, desto schneller kann Amazon neue Produktideen GoLive bringen, kann umso agiler im eCommerce auf neue Markt- / Kundenanforderungen reagieren. De facto gelingt es Amazon mit einem ausgereiften DevOps-Prozesse, pro Tag 23.000 (sic!) Änderungen in die Produktivumgebung einfließen zu lassen. Bei Google sind es ca. 5.000 / Tag, bei Netflix 500 / Tag, während bei einer „klassischen“ Firma eine Änderung alle paar Monate deployed wird.
Es gibt das Buch „Projekt Phoenix“, das den halbwegs gelungenen Versuch macht, die Idee von DevOps in Buch-/Romanform darzustellen. Der Plot geht etwa so: Der IT-Manager Bill eines Unternehmens wird zum Vice President von IT-Operations ernannt und wird sogleich mit der Aufgabe betraut, ein strategisch bedeutsames IT Projekt („Projekt Phoenix“) zu retten, das – um es salopp zu formulieren – ziemlich beschissen läuft. Qualitätsprobleme, Engpässe, Chaos, zwischenmenschliche Reibereien. Bill ist – Gottseidank – ein Ex-Marine, man kann auf ein Happy End hoffen. Zunächst aber taucht man ein in die vielfältigen Problem, mit den Bill konfrontiert ist, gar nicht schlecht, für LeserInnen mit wenig Einblick in die weitläufig verzahnten Prozesse und IT-Themen eines größeren Unternehmens ist das durchaus lehrreich. Eine Leseprobe:
[Bill trifft ein neues Aufsichtsratsmitglied, Eric Reid. Der Roman ist eine Ich-Erzählung aus Perspektive von Bill]
„Okay … und wie ist ihr Eindruck bisher?“, frage ich vorsichtig. Er hört auf zu kauen, streicht sich ein paar Krümel aus seinem Bart und überlegt. „Es sieht so aus, als ob Sie in einer Welt des Schmerzes leben. IT Operations hat sich irgendwie bei jedem wichtigeren Arbeitsablauf mit ins Boot manövriert, auch in die wichtigsten Firmenprojekte. Alle Executives springen im Dreieck und legen den Entwicklern die Daumenschrauben an, damit alles getan wird, was nötig ist, um produktiv gehen zu können.“
„Er sieht mir in die Augen. „Sie haben chronische Probleme mit der Verfügbarkeit der IT und sorgen dafür, dass Firmenverantwortliche auf den Titelseiten der Zeitungen auftauchen – und zwar nicht mit positiven Nachrichten. Und jetzt ist Ihnen das Audit-Team auf den Fersen, was zu weiteren schlechten Nachrichten führen kann und vielleicht sogar zu einer unschönen Fußnote im Geschäftsbericht. Und jeder, der irgendetwas von Phoenix mitbekommen hat, weiß, dass da noch viel mehr schlechte Nachrichten am Horizont auftauchen werden …“
[Bill im Gespräch mit einer Mitarbeiterin, Patty]
In Pattys Büro bleibe ich stehen, bis ich die ungeteilte Aufmerksamkeit beider Kollegen habe. „Lasst mich eines klarstellen. Bei Sev-1-Zwischenfällen können wir nicht einfach aus dem Bauch heraus handeln. Patty, ich bitte dich als diejenige, die eine Sev-1-Telefonkonferenz leitet, von jetzt an solch eine Runde mit dem bisherigen Ablauf der Geschehnisse einzuleiten, insbesondere mit den Änderungen.
Du bist dafür verantwortlich, dass diese Informationen zur Verfügung stehen. Das sollte einfach sein, weil du ja auch den Change Prozess steuerst. Diese Informationen kommen von dir und nicht von den ganzen Krakeelern in der Telefonkonferenz. Ist das klar?“
Patty sieht mich an, offensichtlich frustriert. Ich widerstehe dem Drang, sanftere Worte zu wählen. Ich weiß, dass sie hart gearbeitet hat und ich ihr in letzter Zeit noch mehr aufgebürdet habe.
„Jaja, klar“, sagt sie müde. „Ich werde den Prozess dokumentieren und so schnell wie möglich umsetzen.“
„Das reicht nicht“, sage ich, „ich will, dass du alle zwei Wochen Übungstelefonkonferenzen durchführst. Jeder muss daran gewöhnt sein, Probleme methodisch zu lösen und die bisherigen Ereignisse zur Hand zu haben, bevor wir solche Meetings durchführen. Wenn wir das nicht bei eine Übung schaffen – wie sollen die Leute das dann bei einem echten Notfall machen?“
Klar ist: Die Leserschaft lernt im Verlauf des Buches die Kernprinzipien von DevOps, quasi in der Praxis.
“Projekt Phoenix. Der Roman über IT und DevOps.“ von Gene Kim, Kevin Behr & George Spafford, O’Reilly Verlag, 340 Seiten, 22 Euro als Paperback)