Site Reliability Engineering

Große Online-Dienste wie Suchmaschinen, Streamingportale oder Banking-Apps laufen auf tausenden Computern in Rechenzentren. Diese Computer fallen aus, werden überlastet oder bekommen fehlerhafte Software-Updates. Jemand muss dafür sorgen, dass der Dienst für die Nutzer trotzdem funktioniert. Site Reliability Engineering ist die Antwort, die Google um das Jahr 2003 darauf gefunden hat. Der Grundgedanke: Diese Betriebsarbeit übernehmen keine reinen Technikadministratoren, sondern Leute, die programmieren können. Sie behandeln Zuverlässigkeit als ein Problem, das man mit Software löst, und nicht als eine Aufgabe, die man mit mehr Personal erschlägt.

Warum Ausfälle so teuer sind

Wenn ein Onlineshop eine Stunde nicht erreichbar ist, kauft niemand. Bei großen Anbietern gehen dabei Millionenbeträge verloren, dazu kommt der Schaden am Ruf. Für börsennotierte Technologiekonzerne ist Verfügbarkeit deshalb keine technische Randnotiz, sondern eine Zahl, die Investoren interessiert. Genau deshalb tauchen SRE-Teams inzwischen auch bei Banken, Versicherungen und Autoherstellern auf.

Der zweite Grund ist ein alter Konflikt in der Softwareentwicklung. Entwickler wollen möglichst schnell neue Funktionen veröffentlichen. Der Betrieb will möglichst wenig verändern, denn jede Änderung kann etwas kaputt machen. Beide Seiten haben recht, und ohne klare Regeln blockieren sie sich gegenseitig.

Site Reliability Engineering löst diesen Streit mit einer Rechnung statt mit Meinungen. Man legt vorher fest, wie viel Ausfall erlaubt ist, etwa 0,1 Prozent der Zeit im Monat. Solange der Dienst besser läuft, dürfen die Entwickler neue Versionen ausliefern. Ist das Ausfallbudget aufgebraucht, wird gestoppt und erst einmal stabilisiert.

Fehlerbudgets, Messwerte und Automatisierung

Am Anfang steht immer Messung. SRE-Teams definieren wenige Kennzahlen, die aus Nutzersicht wirklich zählen: Wie oft schlägt eine Anfrage fehl? Wie lange dauert eine Antwort? Für diese Kennzahlen wird ein Zielwert vereinbart, im Fachjargon Service Level Objective. Die Differenz zwischen Ziel und Perfektion ist das Fehlerbudget.

Ein Beispiel macht das greifbar. Bei einem Ziel von 99,9 Prozent Verfügbarkeit darf ein Dienst pro Monat rund 43 Minuten ausfallen. Das ist erstaunlich wenig, aber immerhin nicht null. Diese 43 Minuten sind eine Ressource, die man ausgeben darf, etwa für ein riskantes Update. Der Vergleich mit einem Taschengeld passt gut: Solange etwas übrig ist, kann man sich Experimente leisten.

Der zweite Baustein ist der Kampf gegen wiederkehrende Handarbeit. Diese nennt man im SRE-Umfeld Toil, also stumpfe Routinearbeit wie das nächtliche Neustarten eines Servers. Eine typische Regel lautet, dass höchstens die Hälfte der Arbeitszeit dafür draufgehen darf. Der Rest fließt in Programme, die solche Aufgaben künftig selbst erledigen. Nach jeder größeren Störung gibt es außerdem eine schriftliche Analyse ohne Schuldzuweisung, ein sogenanntes Postmortem, damit derselbe Fehler nicht zweimal passiert.

Von Streamingdiensten bis zu KI-Rechenzentren

Am deutlichsten merkt man SRE, wenn es fehlt. Eine Störungsmeldung bei einer Bahn-App oder einem Spieleserver ist meist der Moment, in dem solche Teams stundenlang arbeiten. Viele Anbieter betreiben öffentliche Statusseiten, auf denen Verfügbarkeit und Störungen dokumentiert werden. Auch die Berichte nach großen Ausfällen, die etwa Cloud-Anbieter veröffentlichen, stammen aus dieser Praxis.

In Stellenanzeigen ist Site Reliability Engineer heute ein gängiger Titel, oft gut bezahlt. Verwandt, aber nicht identisch, ist der Begriff DevOps: Der beschreibt allgemein die engere Zusammenarbeit von Entwicklung und Betrieb. SRE ist eine konkrete Umsetzung dieser Idee mit festen Kennzahlen und Regeln.

Besonders gefragt sind solche Teams inzwischen im KI-Bereich. Wenn Millionen Menschen gleichzeitig einen Chatbot benutzen, muss dessen Rechenleistung verlässlich bereitstehen. Ein häufiger Irrtum ist übrigens, dass hundert Prozent Verfügbarkeit das Ziel wäre. SRE geht vom Gegenteil aus: Perfekte Zuverlässigkeit ist zu teuer und verhindert jeden Fortschritt.