Wie kann Google nie ausfallen?

Offiziellen Angaben von Google zufolge war die Google App Suite des Unternehmens im Jahr 2015 99,97 % der Zeit verfügbar.

Vielleicht halten wir das für selbstverständlich, aber es ist eine bemerkenswerte Tatsache, und die Milliarden von Google-Nutzern auf der ganzen Welt scheinen nie darüber nachzudenken, wie Google mit so einer Leichtigkeit mit etwas so Aufregendem umgehen kann.

Ersetzen menschlicher Arbeitskraft durch Software

Google verwendet diese drei Wörter, um dieses Problem zu erklären: Site Reliability Engineering (ins Chinesische übersetzt als: Website Reliability Engineering, im Folgenden als SRE bezeichnet). Vielleicht klingen diese drei Worte nicht besonders sexy, aber sie sind tatsächlich die Kernphilosophie, an der Google seit 10 Jahren festhält (der Name klingt sogar noch weniger sexy).

Dieses Konzept lässt sich nur schwer in ein oder zwei Sätzen erklären, kann aber in einer zentralen Idee zusammengefasst werden: Lassen Sie die Netzwerkdienste von Programmierern und nicht von auf Netzwerkdienste spezialisierten IT-Experten betreiben. Wenn diese Idee umgesetzt wird, entwickeln Programmierer ein Tool, das zur Erledigung operativer Arbeiten (mit „Betrieb“ ist hier hauptsächlich die Aufrechterhaltung der Stabilität und Leistung des Dienstes gemeint) keinen menschlichen Eingriff erfordert.

„So bauen wir ein Team auf, in dem die Leute es satt haben, Dinge selbst zu tun, und stattdessen Software schreiben, um Dinge zu erledigen, die zuvor manuell erledigt wurden“, schrieb ein Google-Mitarbeiter namens Ben Treynor Sloss in einem Beitrag.

Für viele im Silicon Valley scheint dies gesunder Menschenverstand zu sein. Von Amazon bis Box.com wurde dieser Ansatz in der gesamten Technologiewelt übernommen. Man nennt es das DevOps-Modell (Development plus Operations), was bedeutet, dass Softwareentwickler und Systemadministratoren durch eine Art von Zusammenarbeit miteinander verbunden sind. Doch wie Chef und Puppet zeigen, hat sich das DevOps-Modell seit seiner schrittweisen Weiterentwicklung aus Googles SRE stark verändert. Google hat sich im letzten Jahrzehnt nicht zu SRE geäußert, tat dies jedoch in der Vergangenheit, wenn es um groß angelegte, effiziente Netzwerkoperationen ging.

Allerdings ist Google nun in eine neue Phase eingetreten, in der es eher bereit ist, SRE-bezogene Themen zu diskutieren. Dies liegt vor allem daran, dass Google seine eigenen Cloud-Dienste vorantreiben möchte, damit auch externe Unternehmen die eigenen Software-Dienste nutzen können. Darüber hinaus hat Google auch ein Buch geschrieben, das sich speziell mit SRE-bezogenen Themen befasst.

Nun, der Name des Buches lautet Site Reliability Engineering. Dieses Buch wurde gerade von O'Reilly (einem auf Technologiebücher spezialisierten Verlag) veröffentlicht, und das Papier von Sloss wird als erstes Kapitel dieses Buches verwendet.

Wenn Sie sich für DevOps interessieren, ist dieses Buch ein Muss. auch wenn es Sie nicht interessiert, reicht der Anfang des Buches – das Vorwort, die Einleitung und das erste Kapitel – aus, um die treibende Kraft von Google, dem größten Netzwerkimperium der Welt, zu verstehen.

Für viele Technologieunternehmen – und tatsächlich auch für viele Menschen außerhalb der Technologiewelt – ist die Systemadministration (oder der Systembetrieb, wie auch immer Sie es nennen wollen) der letzte Schliff und einer der nervigsten Aspekte der Informatik.

Doch Sloss, intern als Googles Vizepräsident für „Always-On-Operations“ bekannt, drehte den Spieß um und argumentierte, dass die Zuverlässigkeit einer Website „die grundlegendste Funktion eines jeden Produkts“ sei. Denn: „Wenn ein System nicht funktioniert, ist es nicht sehr nützlich.“

Hegels Theorie der Einheit der Gegensätze

Sloss ist der Ursprung von SRE. Er gründete dieses Projekt, als Google ihn in den Anfangsjahren als Leiter des Betriebsprojekts des Unternehmens anwarb. „SRE ist das, was passiert, wenn Sie einen Softwareentwickler bitten, ein Betriebsteam zusammenzustellen“, sagte er. „Ich habe das Team zusammengestellt und geleitet. Es hat so gearbeitet, als wäre ich selbst ein SRE.“

Todd Underwood ist derzeit SRE-Direktor bei Google. Er hält es für selbstverständlich, dass Google Programmierer wie Sloss einstellt. „Als Google noch in der Anfangsphase steckte, gab es Softwareentwickler, die eine klare Vorstellung davon hatten, was schiefgehen könnte und wie man es beheben könnte, aber niemand wollte es selbst tun.“

Das ist tatsächlich eine lästige Sache. Adam Jacob, CTO (Chief Technology Officer) von Chef, ist jedoch auch davon überzeugt, dass eine solche Transformation notwendig ist, wenn man zu einem Großunternehmen heranwachsen möchte. „Es ist ganz natürlich, Softwareentwicklung und tatsächlichen Betrieb miteinander zu verknüpfen. Man kann beides nicht zwangsläufig trennen. Besonders wenn man dieses Problem aus historischer Perspektive betrachtet, ist man sich dessen vielleicht stärker bewusst.“

Wenn man bedenkt, dass Entwicklung und Betrieb traditionell zwei völlig unabhängige Ebenen sind, werden Sie diese Transformation sehr interessant finden. Entwickler sind bestrebt, eine neue Software zu schreiben, sie dann zu modifizieren und sie schließlich so schnell wie möglich der breiten Öffentlichkeit zugänglich zu machen. Das Betriebspersonal hingegen ist bestrebt, sicherzustellen, dass nichts schief geht. Der beste Weg hierfür besteht darin, Änderungen auf ein Minimum zu reduzieren. „Das sind voneinander unabhängige Ziele“, sagte Underwood, „aber der Witz ist: Wenn man Entwicklung und Betrieb verknüpft, beginnt man, ihre konkurrierenden Ziele zu eliminieren.“

Underwood nannte es „Hegels Theorie der Einheit der Gegensätze“; aber als er das sagte, kaufte es ihm niemand ab. „Die Leute lesen Hegel nicht mehr“, sagte er selbstironisch. Aber diese Beschreibung trifft den Nagel auf den Kopf. Nachdem dies umgesetzt war, beschleunigte Google den Prozess, alle seine guten Ideen in dieses Modell zu übertragen.

Die Balance zwischen Entwicklung und Betrieb

Dabei gibt es einen wichtigen Gedanken: Um den Konflikt zwischen Entwicklung und Betrieb zu verringern, verlangt Google keine 100-prozentige Verfügbarkeit. Wie Sloss in dem Buch schreibt, ist es eigentlich nicht notwendig, sicherzustellen, dass die Netzwerkdienste jederzeit zu 100 % verfügbar sind. Benutzer können den Unterschied zwischen 100 % und 99,999 % nicht wirklich erkennen (tatsächlich sind ihre Laptops, ihr WLAN und ihr Akku viel häufiger als 0,001 % der Zeit offline). Wenn Sie einen angemessenen Prozentsatz der Betriebszeit unter 100 % festlegen – das Fehlerbudget –, haben Sie genügend Zeit, Änderungen vorzunehmen und diese zu debuggen.

„Fehlerbudgets beseitigen die Reibung zwischen Entwicklung und SRE“, sagt Sloss. Ein Ausfall ist nichts Schlimmes mehr. Er ist Teil des erwarteten Innovationsprozesses, und sowohl die Entwicklung als auch SRE können ihn ohne Bedenken angehen.

Gleichzeitig hat Google auch einige entsprechende Regelungen eingeführt, um sicherzustellen, dass sich SRE nicht zu einem altmodischen Systemmanagement entwickelt. Grundsätzlich darf SRE nicht mehr als 50 % seiner Zeit mit traditioneller Betriebsarbeit verbringen (die im Konflikt mit der Programmierung steht). Wenn in einem SRE-Team der Betrieb Vorrang vor der Entwicklung hat, wird Google einen Teil des Betriebspersonals in die allgemeine Softwareentwicklungsarbeit versetzen.

„Ein bewusstes Gleichgewicht zwischen Entwicklung und Betrieb stellt sicher, dass SREs genügend Spielraum haben, um in kreatives, automatisiertes Engineering zu investieren“, sagte Sloss. „Natürlich müssen sie auch auf die operativen Abläufe achten.“

Jacob von Chef hält das hier erwähnte Verhältnis von 50 % nicht für so wichtig, aber ihm gefällt die Einstellung. Er sagte: „So ist das Geschäft. Jemand muss sich um die Abläufe kümmern. Und die Abläufe sind nahezu endlos, daher ist es verständlich, dass man ihnen einen Riegel vorschieben möchte.“

Google hat sogar strenge Richtlinien für die Einstellung von SREs. 50 bis 60 Prozent der neuen Mitarbeiter müssen die gleiche strenge Prüfung bestehen wie alle anderen Google-Ingenieure. Der Rest muss über 85 bis 99 Prozent der Fähigkeiten der Google-Ingenieure verfügen und zusätzlich über einige Fähigkeiten, die speziell für SRE relevant sind, den meisten Software-Ingenieuren jedoch fehlen – etwa umfassende Kenntnisse des UNIX-Betriebssystems und der Hardware-Netzwerkprotokolle.

All dies soll ein ausgewogenes Gleichgewicht zwischen Entwicklung und Betrieb gewährleisten.

Die Ambition von SRE

Dies ist auf vielen Ebenen ein neues Konzept. Doch als das Google-Team in seinem Buch versuchte, diese Idee zu beschreiben, wählte es ein älteres Beispiel. Die geistige Vorläuferin von Google SRE war eine Programmiererin vom MIT namens Margaret Hamilton, die in den 1960er Jahren das Mondlandeprogramm für das Apollo-Raumschiff schrieb. Wie Hamilton selbst sagte, bestand ein Teil der Kultur, die aus dem Apollo-Programm hervorging, darin, von jedem und allem zu lernen, auch von denen, von denen es scheinbar nichts zu lernen gab.

Obwohl Hamilton Programmiererin ist, spielt sie im operativen Geschäft eine wichtige Rolle. Um diesen Punkt zu veranschaulichen, erzählt das Buch eine Geschichte darüber, wie sie ihre Tochter Lauren oft mit ins Computerlabor nahm und Lauren eines Tages zufällig einen Knopf drückte und das Apollo-Vorstartprogramm in einen Computer implantierte, auf dem das Programm „Nachstart-Szenario“ lief.

Dies führte zum Einfrieren des gesamten Systems. Hamilton versuchte, dem System einen Fehlererkennungscode hinzuzufügen, um diesen Fehler während eines echten Fluges zu verhindern. Ihre Vorgesetzten lehnten die ganze Idee mit der Begründung ab, dass Astronauten niemals einen solchen Fehler machen würden. Aber bei Apollo 8 machten die Astronauten genau einen solchen Fehler. Glücklicherweise hat Hamilton in die Systemdokumentation eine Problemumgehung aufgenommen. In ihrer nachfolgenden Arbeit fügte sie diesen Fehlerüberwachungscode noch hinzu.

Wenn Sie zu mir kommen und sagen: „Es ist eiskalt“, dann nützt das nichts. aber wenn Sie sagen: „Es ist eiskalt, ich sage Ihnen, wie Sie das beheben können“, dann ist alles in Ordnung – sagte Underwood. „Bei uns haben wir Leute, die wissen, dass etwas schiefgehen wird, die wissen, wo es schiefgehen wird, und die herausfinden können, wie man das verhindern kann.“

Dies ist DevOps oder in der Google-Sprache SRE. Diese drei Worte klingen vielleicht nicht nach viel, aber sie sind eine sehr kraftvolle Idee. Dadurch wurde Google geboren, doch einige SREs, die so philosophisch eingestellt sind wie Underwood, haben größere Ambitionen. Ihrer Vision zufolge schreiten die Betriebsabläufe schneller voran als die Entwicklung.

„Wir hoffen, dass es auf lange Sicht niemand mehr betreiben wird“, sagte Underwood.

Als Gewinner des Qingyun-Plans von Toutiao und des Bai+-Plans von Baijiahao, des Baidu-Digitalautors des Jahres 2019, des beliebtesten Autors von Baijiahao im Technologiebereich, des Sogou-Autors für Technologie und Kultur 2019 und des einflussreichsten Schöpfers des Baijiahao-Vierteljahrs 2021 hat er viele Auszeichnungen gewonnen, darunter den Sohu Best Industry Media Person 2013, den dritten Platz beim China New Media Entrepreneurship Competition Beijing 2015, den Guangmang Experience Award 2015, den dritten Platz im Finale des China New Media Entrepreneurship Competition 2015 und den Baidu Dynamic Annual Powerful Celebrity 2018.