Bist du von DevOps begeistert? Warte bis du SRE kennenlernst

Was ist SRE überhaupt?

Googles Vordenker für SRE, Ben Treynor, hat immer noch keine Definition in einem Satz veröffentlicht, beschreibt aber Site Reliability als "das, was dabei herauskommt, wenn ein Softwareentwickler mit dem beauftragt wird, was früher als Operations bezeichnet wurde".

Das zugrunde liegende Problem lautet wie folgt: Entwicklungsteams möchten großartige neue Funktionen für die Allgemeinheit veröffentlichen und sehen, wie sie zu einem großen Erfolg werden. Ops-Teams möchten sicherstellen, dass diese Funktionen nichts beeinträchtigen. In der Vergangenheit hat dies einen großen Machtkampf verursacht, bei dem Operations-Teams versucht haben, so viele Releases wie möglich zu bremsen, und Entwickler immer auf der Suche nach findigen neuen Methoden waren, um die Prozesse zu umgehen, die ihnen im Weg standen. (Klingt doch bekannt, oder?)

Bei SRE gibt es keine Mutmaßungen und Debatten mehr darüber, was wann eingeführt werden kann. Stattdessen kommt eine mathematische Formel mit grünem oder rotem Licht für Releases zum Einsatz, und ein spezielles Team mit Operations-Kenntnissen (entsprechend Site Reliability Engineers oder SREs genannt) überwacht kontinuierlich die Zuverlässigkeit des Produkts. Andrew Widdowson aus dem SRE-Team von Google beschreibt dies folgendermaßen: "Unsere Arbeit fühlt sich an, als wären wir Teil der härtesten Boxencrew der Welt. Wir wechseln die Reifen eines Rennwagens, während er mit 160 km/h unterwegs ist."

Klingt das noch nicht revolutionär genug? Ein Großteil der Magie liegt in der Funktionsweise. Im Folgenden stellen wir einige der Kernprinzipien vor, die gleichzeitig auch zu den größten Abweichungen vom traditionellen IT-Betrieb gehören.

Zunächst einmal erhalten neue Releases grünes Licht auf Basis der aktuellen Produktleistung

Die meisten Anwendungen erreichen keine Verfügbarkeit von 100 %. Daher legt das SRE-Team für jeden Service ein Service Level Agreement (SLA) fest, das definiert, wie zuverlässig das System für Endbenutzer sein muss. Wenn das Team sich auf ein SLA von 99,9 % einigt, beträgt das Fehlerbudget 0,1 %. Ein Fehlerbudget ist genau das, was der Name vermuten lässt: Es ist der maximal zulässige Schwellenwert für Fehler und Ausfälle.

Profitipp: Mit diesem praktischen Betriebszeiten-Merkzettel rechnest du SLAs ganz einfach in "Minuten Ausfallzeit" um.

Das Fehlerbudget ist eine Art Trumpfkarte: Das Entwicklerteam kann dieses Fehlerbudget beliebig "investieren". Wenn das Produkt derzeit einwandfrei und mit wenigen oder keinen Fehlern läuft, kann das Team jederzeit ein beliebiges neues Produkt auf den Markt bringen. Wenn es das Fehlerbudget jedoch ausgereizt oder überzogen hat und das definierte Service Level Agreement (SLA) gerade noch oder nicht mehr einhält, werden alle Einführungen auf Eis gelegt, bis die Anzahl der Fehler auf ein Niveau reduziert ist, das weitere Einführungen erlaubt.

Das Geniale daran? Sowohl die SREs als auch die Entwickler haben einen starken Anreiz, zusammenzuarbeiten, um die Anzahl der Fehler zu minimieren.

SREs können auch programmieren

Im alten Modell werden Mitarbeiter mit einem Zuverlässigkeitsproblem konfrontiert und müssen (manchmal für ein Jahr oder länger) damit zurechtkommen, bis das Problem entweder verschwindet oder völlig eskaliert.

Nicht so bei SRE. Sowohl die Entwickler- als auch die SRE-Teams teilen sich einen einzigen Personalpool, sodass für jeden SRE-Mitarbeiter, der eingestellt wird, ein Mitarbeiter weniger für das Entwicklerteam verfügbar ist (und umgekehrt). Dies beendet den unendlichen Mitarbeiterkampf zwischen Dev und Ops und schafft ein selbstüberwachendes System, bei dem Entwickler mit mehr Teamkollegen belohnt werden, wenn sie Code schreiben (d. h. Code, für den weniger Unterstützung von SREs erforderlich ist).

Auch Entwickler machen sich die Hände schmutzig

Ben Treynor musste bei Google für diese Klausel kämpfen und er ist froh, dass er es getan hat. Tatsächlich betont er in seiner großartigen Keynote zu SRE bei der SREcon14, dass es obligatorisch sein sollte, diese Verpflichtung von den Führungskräften vor der Einführung von SRE einzuholen.

Grundsätzlich übernimmt das Entwicklerteam 5 % aller Operations-Aufgaben (Bearbeitung von Tickets, Bereitschaftsunterstützung usw.). Dies ermöglicht es ihnen, eng mit ihrem Produkt verbunden zu bleiben und zu sehen, wie es funktioniert, um bessere Entscheidungen bezüglich Programmierung und Release zu treffen.

Darüber hinaus werden den Entwicklern immer dann Operations-Aufgaben zugewiesen, wenn der Workload die Kapazität des SRE-Teams übersteigt. Wenn das System gut funktioniert, beginnen sich die Entwickler auch hier selbst zu regulieren, schreiben soliden Code und führen ihn vorsichtig ein, um zukünftige Probleme zu vermeiden.

SREs sind frei und ungebunden (und können bei Bedarf herangezogen werden)

Um sicherzustellen, dass die Teams fit und zufrieden bleiben, empfiehlt Treynor, SREs zu gestatten, nach Belieben zu anderen Projekten oder sogar zu einer anderen Abteilung zu wechseln. SRE fördert hochmotivierte, engagierte und effektive Teamarbeit – daher sollte kein Teammitglied davon abgehalten werden, seine eigenen persönlichen Ziele zu verfolgen.

Wenn ein ganzes Team von SREs und Entwicklern einfach nicht miteinander auskommt und mehr Probleme als zuverlässigen Code produziert, gibt es eine letzte drastische Maßnahme: Ziehe das SRE-Team vom Projekt ab und weise den gesamten Operations-Workload direkt dem Entwicklerteam zu. Treynor hat dies in seiner gesamten Karriere nur ein paar Mal getan. Die Drohung reicht normalerweise aus, um beide Teams zu einer positiveren Arbeitsbeziehung zu bringen.

SRE hat einiges mehr zu bieten, als ich in einem Artikel abdecken kann – zum Beispiel, wie SRE Produktionsvorfälle verhindert, wie Bereitschaftsteams besetzt sind und welche Regeln sie bei jeder Schicht befolgen usw.

Unsere Meinung

Die IT ist sicher voller Buzzwords und Trends. Einmal ist es die Cloud, ein anderes Mal ist es DevOps, Kundenerlebnis oder Gamification. SRE könnte jedoch viel mehr werden, zumal es weit mehr um die Menschen und den Prozess geht als um die zugrunde liegende Technologie. Auch wenn sich die Technologie sicherlich an das Konzept im Laufe seiner Weiterentwicklung und weiteren Verbreitung anpassen kann (und wird), benötigst du keine neuen Tools für die Ausrichtung deiner Entwicklungs- und Operations-Abteilungen an den Prinzipien des Site Reliability Engineering.

In zukünftigen Artikeln werden wir uns genau das ansehen: praktische Schritte, um sich in Richtung SRE zu bewegen, und die Rolle, die Technologie spielen kann.