Das Arbeitsbuch zur Standortzuverlässigkeit

Vorwort II

Andrew Clay Shafer

Als ich erfuhr, dass an einem zweiten SRE-Buch gearbeitet wird, habe ich mich gemeldet und gefragt, ob ich ein paar Worte dazu schreiben könnte. Die Grundsätze aus dem ersten SRE-Buch stimmen so gut mit dem überein, was ich mir immer unter DevOps vorgestellt habe, und die Praktiken sind aufschlussreich, auch wenn sie außerhalb von Google nicht zu 100 % anwendbar sind. Nachdem ich die Prinzipien aus dem ersten SRE-Buch zum ersten Mal gelesen hatte - die Akzeptanz vonRisiken (Kapitel 3), Service-Level-Ziele (Kapitel 4) und die Beseitigung von Mühen (Kapitel 5)- wollte ich diese Botschaft von den Dächern schreien. Das Wort "Risiko akzeptieren" kam deshalb so gut an, weil ich diese Worte schon oft verwendet hatte, um traditionelle Organisationen zu Veränderungen zu motivieren. Kapitel 6 war schon immer ein implizites DevOps-Ziel, nämlich den Menschen mehr Zeit für kreative, übergeordnete Aufgaben zu geben und ihnen zu ermöglichen, mehr Mensch zu sein. Aber ich habe mich wirklich in die "Service Level Objectives" verliebt. Ich finde es toll, dass die Sprache und der Prozess einen sachlichen Vertrag zwischen betrieblichen Überlegungen und der Bereitstellung neuer Funktionen schaffen. SRE, SWE (Softwareentwicklung) und das Unternehmen sind sich einig, dass der Service stimmen muss, um wertvoll zu sein, und die SRE-Lösung quantifiziert die Ziele, um Maßnahmen und Prioritäten festzulegen. Die Lösung - den Service Level als Ziel zu setzen und bei Unterschreitung des Ziels der Zuverlässigkeit Vorrang vor den Funktionen zu geben - beseitigt einen klassischen Konflikt zwischen Betrieb und Entwicklern. Das ist eine einfache und elegante Umstellung, die Probleme löst, indem sie sie nicht hat. Ich gebe diese drei Kapitel fast jedem, den ich seitdem getroffen habe, als Hausaufgabe mit. Sie sind so gut. Das sollte jeder wissen. Erzähl es all deinen Freunden. Ich habe es allen meinen erzählt.

Die letzten zehn Jahre meiner Karriere habe ich mich darauf konzentriert, Menschen dabei zu helfen, Software mit besseren Werkzeugen und Prozessen bereitzustellen. Manchmal wird behauptet, ich hätte DevOps miterfunden, aber ich war nur in der Lage, erfolgreiche Muster aus vielen verschiedenen Organisationen und Projekten zu leihen und zu stehlen. Es ist mir peinlich, wenn Leute sagen, dass "DevOps" von irgendjemandem erfunden wurde, aber besonders von mir. Ich betrachte mich nicht als Experte für irgendetwas, außer dass ich neugierig bin. Meine Idealvorstellung von DevOps basierte immer auf den Informationen, die ich von meinen Freunden bekommen konnte, und meine Freunde bauten das Internet. Ich hatte das Privileg, hinter die Kulissen von Menschen zu schauen, die eine repräsentative Auswahl der unglaublichsten Infrastrukturen und Anwendungen der Welt einrichten und betreiben. DevOps symbolisiert Aspekte der aufkommenden und existentiellen Optimierungen, die erforderlich sind, um schnell hochverfügbare Software über das Internet bereitzustellen. Der Wechsel von Software, die auf physischen Datenträgern ausgeliefert wird, zu Software, die als Service bereitgestellt wird, zwang zu einer Weiterentwicklung der Tools und Prozesse. Diese Entwicklung hat den Beitrag des Betriebs zur Wertschöpfungskette erhöht. Wenn die Systeme nicht funktionieren, hat die Software keinen Wert. Die gute Nachricht ist, dass du nicht auf den Versand des nächsten eingeschweißten Kartons warten musst, um die Software zu ändern. Für manche ist das auch die schlechte Nachricht. Ich hatte einfach die Gelegenheit und die Perspektive, einem aufgeschlossenen Publikum die erfolgreichsten Muster des neuen Weges zu erläutern.

Im Jahr 2008, bevor wir das Wort DevOps so benutzten wie heute, hatte ich als Entwickler den Zusammenbruch der Dotcoms, mein Studium und ein paar wagnisfinanzierte Achterbahnfahrten hinter mir - und die ganze Zeit über täglich Google nach Antworten durchsucht. Ich arbeitete hauptberuflich an Puppet und war fasziniert von dem Potenzial der Automatisierung, die IT-Organisationen zu verändern. Puppet versetzte mich in die Lage, Probleme im operativen Bereich zu lösen. Zu dieser Zeit nutzte Google Puppet, um seine unternehmenseigenen Linux- und OS X-Workstations in einem Umfang zu verwalten, der die Möglichkeiten des Puppet-Servers überstieg. Wir hatten eine großartige Arbeitsbeziehung zu Google, aber Google hielt bestimmte Details seiner internen Abläufe grundsätzlich geheim. Ich weiß das, weil ich von Natur aus neugierig bin und ständig auf der Suche nach mehr Informationen war. Ich wusste immer, dass Google über großartige interne Tools und Prozesse verfügen musste, aber was diese Tools und Prozesse waren, war nicht immer ersichtlich. Irgendwann akzeptierte ich, dass tiefgründige Fragen über Borg wahrscheinlich bedeuteten, dass das aktuelle Gespräch nicht sehr weit führte. Ich hätte gerne mehr darüber gewusst, wie Google alles macht, aber das war zu dieser Zeit einfach nicht erlaubt. Zur Bedeutung des Jahres 2008 gehören auch die erste O'Reilly Velocity Konferenz und das Jahr, in dem ich Patrick Debois kennenlernte. "DevOps" war damals noch kein Begriff, aber er war im Begriff, es zu werden. Die Zeit war reif. Die Welt war bereit. DevOps symbolisierte einen neuen Weg, einen besseren Weg. Wäre Site Reliability Engineering damals veröffentlicht worden, hätte sich die Gemeinschaft, die sich bildete, für die "Eliminierung von Mühsal" stark gemacht und der Begriff DevOps hätte vielleicht nie existiert. Ungeachtet der kontrafaktischen Tatsachen weiß ich, dass das erste SRE-Buch mein persönliches Verständnis des Möglichen gefördert hat, und ich habe schon vielen anderen allein mit den SRE-Prinzipien geholfen.

In den Anfängen der DevOps-Bewegung haben wir es bewusst vermieden, Praktiken zu kodifizieren, weil sich alles so schnell entwickelt hat und wir dem, was aus DevOps werden könnte, keine Grenzen setzen wollten. Außerdem wollten wir ausdrücklich nicht, dass jemand DevOps "besitzt". Als ich 2010 über DevOps geschrieben habe, habe ich drei Punkte herausgestellt. Erstens: Entwickler und Betrieb können und sollten zusammenarbeiten. Zweitens: Die Systemadministration wird der Softwareentwicklung immer ähnlicher werden. Und schließlich beschleunigt und vervielfacht der Austausch mit einer globalen Community of Practice unsere kollektiven Fähigkeiten. Etwa zur gleichen Zeit prägten meine Freunde Damon Edwards und John Willis das Akronym CAMS für Culture, Automation, Metrics, and Sharing. Jez Humble erweiterte dieses Akronym später zu CALMS, indem er Lean, die kontinuierliche Verbesserung, hinzufügte. Was jedes dieser Wörter im Kontext bedeutet, wäre ein ganzes Buch wert, aber ich erwähne sie hier, weil Site Reliability Engineering ausdrücklich auf Culture, Automation, Metrics und Sharing verweist und Anekdoten über Googles Reise zur kontinuierlichen Verbesserung erzählt. Mit der Veröffentlichung des ersten SRE-Buches hat Google seine Prinzipien und Praktiken mit der weltweiten Gemeinschaft geteilt. Heute definiere ich DevOps einfach als "Optimierung der menschlichen Leistung und Erfahrung beim Betrieb von Software, mit Software und mit Menschen". Ich möchte niemandem Worte in den Mund legen, aber das scheint mir auch eine gute Beschreibung für SRE zu sein.

Letztendlich erkenne ich DevOps, wenn ich es sehe, und ich sehe SRE bei Google in Theorie und Praxis als eine der fortschrittlichsten Implementierungen. Ein guter IT-Betrieb war schon immer von guter Technik abhängig, und die Lösung von Betriebsproblemen mit Software war schon immer ein zentraler Bestandteil von DevOps. Site Reliability Engineering macht den technischen Aspekt noch deutlicher. Ich erschaudere, wenn ich jemanden sagen höre "SRE versus DevOps". Für mich sind beide Begriffe zeitlich und räumlich untrennbar miteinander verbunden, da sie die soziotechnischen Systeme beschreiben, die moderne Infrastrukturen mit Software bereitstellen. Ich betrachte DevOps als einen losen, allgemeinen Satz von Prinzipien und SRE als eine fortgeschrittene, explizite Implementierung. Eine parallele Analogie wäre die Beziehung zwischen Agile und Extreme Programming (XP). XP ist zwar agil und wohl das Beste an Agile, aber nicht alle Organisationen sind in der Lage oder bereit, XP zu übernehmen.

Manche sagen "Software frisst die Welt auf", und ich verstehe, warum sie das tun, aber "Software" allein ist nicht der richtige Rahmen. Ohne die Allgegenwart von Computerhardware, die mit Hochgeschwindigkeitsnetzwerken verbunden ist, wäre vieles von dem, was wir als "Software" betrachten, nicht möglich. Das ist eine unbestreitbare Wahrheit. Ich glaube, viele übersehen in diesem Gespräch über Technologie die Menschen. Die Technik existiert wegen der Menschen und hoffentlich für die Menschen, aber wenn du etwas tiefer schaust, erkennst du auch, dass die Software, auf die wir uns verlassen und die wir wahrscheinlich als selbstverständlich ansehen, größtenteils von Menschen abhängig ist. Wir verlassen uns auf die Software, aber die Software verlässt sich auch auf uns. Dies ist ein einziges, miteinander verbundenes System aus unvollkommener Hardware, Software und Menschen, die sich auf sich selbst verlassen, um die Zukunft zu gestalten. Verlässlichkeit frisst die Welt auf. Bei der Zuverlässigkeit geht es aber nicht nur um Technologie, sondern auch um Menschen. Die Menschen und die Technologie bilden ein einziges technosoziales System. Das Schöne daran, dass Google SRE mit dem Rest der Branche geteilt hat, ist, dass alle Ausreden darüber, welche Art von Prozessen im großen Maßstab funktionieren, hinfällig wurden. Google hat den höchsten Standard für Zuverlässigkeit und Umfang gesetzt. Es mag stichhaltige Argumente geben, warum jemand die SRE-Praktiken von Google nicht direkt übernehmen kann, aber die Leitprinzipien sollten trotzdem gelten. Wenn ich mir die Landschaft der Möglichkeiten anschaue, die Zukunft zu gestalten, und den Ehrgeiz, die menschliche Erfahrung mit Software zu verändern, dann sehe ich viele ehrgeizige Projekte, die buchstäblich alles mit dem Internet verbinden. Meine Berechnungen zeigen, dass die erfolgreichen Projekte unglaubliche Datenmengen aufnehmen und indexieren werden. Nur wenige, wenn überhaupt, werden die Größe von Google heute übertreffen, aber einige werden so groß sein wie Google, als es mit SRE begann, und werden die gleichen Zuverlässigkeitsprobleme lösen müssen. Ich behaupte, dass in diesen Fällen die Einführung von Werkzeugen und Prozessen, die verdächtig nach SRE aussehen, nicht optional, sondern existenziell ist - obwohl es nicht nötig ist, auf diese Krise zu warten, da die SRE-Prinzipien und -Praktiken in jeder Größenordnung gelten.

SRE wird in der Regel als die Art und Weise betrachtet, wie Google den Betrieb durchführt, aber das geht am Gesamtbild vorbei: SRE ermöglicht in der Praxis nicht nur die Softwareentwicklung, sondern verändert auch Architektur, Sicherheit, Governance und Compliance. Wenn wir den SRE-Fokus auf die Bereitstellung einer Serviceplattform legen, erhalten all diese anderen Überlegungen einen erstklassigen Stellenwert, aber wo und wie das geschieht, kann ganz anders aussehen. Genauso wie SRE (und hoffentlich auch DevOps) immer mehr Last auf die Softwareentwicklung verlagert hat, entwickeln sich moderne Architektur- und Sicherheitspraktiken von Folien, Checklisten und Hoffnung hin zur Ermöglichung der richtigen Verhaltensweisen mit laufendem Code. Unternehmen, die SRE-Prinzipien und -Praktiken einführen, ohne diese anderen Aspekte zu überdenken, verpassen eine große Chance, sich zu verbessern, und werden wahrscheinlich auch intern auf Widerstand stoßen, wenn die Menschen, die sich für diese Aspekte verantwortlich fühlen, nicht zu Verbündeten gemacht werden.

Ich lerne immer gerne. Ich habe jedes Wort des ersten SRE-Buches durchgelesen. Ich liebte die Sprache. Ich liebte die Anekdoten. Ich fand es toll, mehr darüber zu erfahren, wie Google sich selbst sieht. Aber die Frage ist für mich immer: "Welches Verhalten werde ich ändern?" Lernen bedeutet nicht, Informationen zu sammeln. Lernen heißt, Verhalten zu ändern. In bestimmten Disziplinen lässt sich das leicht feststellen oder sogar quantifizieren. Du hast gelernt, ein neues Lied zu spielen, wenn du das Lied spielen kannst. Du bist besser im Schach, wenn du Partien gegen stärkere Spieler gewinnst. Beim Site Reliability Engineering sollte es wie bei DevOps nicht nur darum gehen, den Titel zu ändern, sondern definitive Verhaltensänderungen vorzunehmen, die sich auf die Ergebnisse und natürlich die Zuverlässigkeit konzentrieren. Das Site Reliability Workbook verspricht, von einer Aufzählung von Grundsätzen und Praktiken von Google für Google zu kontextbezogenen Aktionen und Verhaltensweisen überzugehen. Website-Zuverlässigkeit ist für alle da, aber Zuverlässigkeit entsteht nicht durch das Lesen von Büchern. Auf die Übernahme von Risiken und die Beseitigung von Mühen.