Flickrs Vortrag „10+ Deploys a Day“ beendet den Krieg zwischen Entwicklern und Betrieb

Im Jahr 2009 aktualisierte Flickr, die Foto-Sharing-Seite innerhalb von Yahoo, seinen Dienst ständig, und die branchenübliche Aufteilung – Entwickler liefern Funktionen, der Betrieb hält die Seite stabil – machte jede Änderung zum Kampf. Änderungen sind die Hauptursache der meisten Ausfälle, also sind die Teams, die die Seite am härtesten „schützen“, die Teams, die am langsamsten ausliefern.

Änderungen sicher statt selten machen: gemeinsame Tools – Feature-Flags, Deploys in einem Schritt, gemeinsame Metriken, Chat-Roboter – plus eine Kultur ohne Schuldzuweisungen machen über 10 Deploys pro Tag zur Routine.

Der Betriebsmanager John Allspaw und der Engineering-Manager Paul Hammond bauten Releases auf gemeinsame Verantwortung um: automatisierte Infrastruktur, ein gemeinsamer Versionskontroll-Stamm, Build-und-Deploy in einem Schritt, Feature-Flags, gemeinsame Metrik-Dashboards und IRC-Chat-Roboter – gepaart mit einer ausdrücklichen Kulturliste: Respekt, Vertrauen, eine gesunde Haltung gegenüber Fehlern und das Vermeiden von Schuldzuweisungen.

Ihre Velocity-Session im Juni 2009 zog mehr Aufmerksamkeit auf sich als jeder andere Vortrag der Konferenz, und die Verbindung von Tools und Kultur wurde zum Kern des DevOps-Playbooks: Monate später benannte sich die Bewegung auf dem ersten devopsdays in Gent selbst, und „Deploys pro Tag“ wurde zu einem Branchen-Benchmark.

Bis 2009 lieferte Flickr, die Fotoseite innerhalb von Yahoo, ständig aus: an einem normalen Tag führte sie zehn oder mehr vollständige Deployments der Website in die Produktion durch. Auf der Velocity-Konferenz von O'Reilly in San Jose im Juni jenes Jahres erklärten die beiden Manager, die Flickrs Betriebs- und Engineering-Seite leiteten, John Allspaw und Paul Hammond, wie das funktioniert, in einem Vortrag mit dem Titel „10+ Deploys Per Day: Dev and Ops Cooperation at Flickr“. Der Bericht von Data Center Knowledge von der Konferenz nannte ihn die Präsentation, die beim Event das meiste Aufsehen erregte.

Ihr Argument griff das branchenübliche Standard-Organigramm an. Das Stereotyp – Entwickler fügen Funktionen hinzu, der Betrieb hält die Seite stabil und schnell – macht Änderungen zum Feind, da Änderungen die meisten Ausfälle verursachen. Allspaw und Hammond kehrten es um: Aufgabe des Betriebs ist es, das Geschäft zu ermöglichen, das Geschäft erfordert Änderungen, also besteht die eigentliche Arbeit darin, das Risiko von Änderungen durch Tools und Kultur zu senken. Der Werkzeugkasten: automatisierte Infrastruktur, ein gemeinsamer Versionskontroll-Stamm, Build-und-Deploy in einem Schritt, Feature-Flags, die Code im Verborgenen ausliefern, gemeinsame Metriken und IRC-Roboter, mit denen jeder Releases beobachten kann.

Die andere Hälfte war kulturell: Respekt, Vertrauen, eine gesunde Haltung gegenüber Fehlern und das Vermeiden von Schuldzuweisungen – einschließlich Feuerübungen, damit selbst junge Ingenieure Produktionsvorfälle vor einem echten geübt haben, denn Fehler werden passieren. Im Oktober organisierte Patrick Debois die ersten devopsdays in Gent, Belgien; die Bewegung, die ihren Namen von dieser Veranstaltung erhielt, trug die Rahmung des Flickr-Vortrags – kleine, sichere, häufige Releases von Teams, die Tools teilen und niemandem die Schuld geben – in Ingenieuroganisationen überall.

Es benannte die eigentliche Einschränkung: In einem Web-Geschäft ist der Release-Zug das Geschäft, und ein Team, das zehnmal am Tag sicher deployen kann, lernt schlicht schneller als eines, das monatlich ausliefert.

Gemeinsame Tools erzeugten gemeinsames Schicksal – ein Stamm, ein Dashboard, ein Deploy-Knopf –, sodass keine Seite gewinnen konnte, indem sie die andere verlieren ließ.

Es definierte den Betrieb vom Hüter der Stabilität zum Ermöglicher von Änderungen um, sodass Automatisierung und Kultur an einer einzigen Frage gemessen werden konnten: Wie oft können wir sicher ausliefern?

Es behandelte Schuldzuweisungen als Engineering-Defekt, nicht als Charakterschwäche: Wenn Menschen Fehler verbergen, wächst das Risiko still; Feuerübungen und Reviews ohne Schuldzuweisungen halten Informationen in Bewegung.

Durchsatz entsteht, indem man Änderungen sicher statt selten macht. Gemeinsame Tools erzeugen gemeinsames Schicksal; Schuldzuweisungen lehren Ingenieure, Risiken zu verbergen; der Betrieb ermöglicht das Geschäft, er verteidigt die Verfügbarkeit nicht gegen das Geschäft.

Die Aufzeichnung der Session ist noch online und wird noch immer als Gründungsartefakt von DevOps gezeigt. Im Oktober gab Debois' erster devopsdays in Gent der Bewegung ihren Namen, und „Wie viele Deploys pro Tag?“ wurde sowohl Benchmark als auch Herausforderung. Allspaw trug den Ansatz zu Etsy, wo seine Verwandten – Postmortems ohne Schuldzuweisungen und kontinuierliches Deployment – eigenständig berühmt wurden. Eineinhalb Jahrzehnte später ist die Deployment-Frequenz eine Standard-Engineering-Metrik, und „Dev versus Ops“ überlebt meist nur als der Strohmann, den dieser Vortrag zerlegte.