Die Rolle des Site Reliability Engineers (SRE) im modernen IT-Betrieb

Der Site Reliability Engineer gehört gemäss einer aktuellen LinkedIn Studie zu den gefragtesten IT-Jobs in der Schweiz. Schauen wir in die USA, ist er dort gemäss einer anderen Studie sogar der bestbezahlte IT-Job.

Unter den gefragtesten Jobs in der Schweiz befinden sich 2023 sieben IT-Berufe. Site Reliability Engineers belegen Platz 2. Quelle: Linkedin Job Trends

Warum das so ist, was ein Site Reliability Engineer macht und welche Kompetenzen dafür erforderlich sind, erfahren Sie in diesem Blogbeitrag.

Und eines vorweg: Das ursprünglich von Google geprägte Site Reliability Engineering ist kein Einheits-Erfolgsmodell, das einer Organisation einfach übergestülpt werden kann, sondern soll primär als Inspiration dienen. Adopt and adapt!

Was ist Site Reliability Engineering (SRE) als Disziplin?

Site Reliability Engineering wendet für IT-Operations einen Software-Engineering Ansatz an. Oder wie es der Ben Treynor von Google treffend formuliert hat: «SRE is what happens when a software engineer is tasked what used to be called operations».

Ziel des Site Reliability Engineering ist es, hochzuverlässige und skalierbare Systeme zu schaffen. Der Fokus liegt dabei  mehr auf dem Design und dem Bau dieser Systeme und weniger auf reaktiven Aspekten wie Wartung und Incident-Handling. Software-Engineering-Methoden werden eingesetzt, um Aufgaben, die bisher manuell ausgeführt wurden, konsequent zu automatisieren.

SRE hilft auch, die richtige Balance zwischen Stabilität und Flexibilität zu erreichen. Dabei spielen die so genannten Service Level Objectives (Beispiel: 99,9% Verfügbarkeit) und das daraus abgeleitete Error Budget (Beispiel: 42 Stunden zulässige Nichtverfügbarkeit pro Monat) eine zentrale Rolle. Ist das Error Budget aufgebraucht, greift die Error Policy (Beispiel: «keine neuen Features mehr»). Die Nichteinhaltung von Error-Budgets muss Konsequenzen haben, auch für die Produktteams.

Warum ist Site Reliability gerade jetzt im Aufwind?

Die steigende Bedeutung von digitalen Services und die Notwendigkeit, Systeme zuverlässig und skalierbar zu gestalten, haben sicherlich zur Popularität beigetragen. Unternehmen, die auf hohe Verfügbarkeit ihrer Dienste angewiesen sind, haben SRE-Praktiken adaptiert, wobei Google als Pionier in diesem Bereich gilt.

Natürlich war Zuverlässigkeit schon immer ein wichtiges Thema. Traditionelle Operations-Ansätze werden neuen, technischen Herausforderungen aber nicht mehr gerecht. Zu nennen sind vor allem:

• Verteilte, komplexe Systeme – z.B. Die Evolution vom Monolithen zu Microservices – mit unvorhersehbaren Benutzern (vs. Monitoring Mythos «alles ist voraussehbar»)
  Systeme müssen schnell und automatisch skalieren können, ohne dass die Probleme und Kosten ebenfalls schnell skalieren und die TCO (Total Cost of Ownership) ins Unermessliche steigt.

DevOps hat uns zwar geholfen, den Graben zwischen Entwicklung und Betrieb zu überbrücken – unter anderem durch gemeinsame Ergebnisverantwortung. Oft fehlt es aber auch in einem DevOps-Umfeld an einer praktischen Handhabe, um Zuverlässigkeit in den Systemen praktisch zu verankern. Daher auch die Aussage von Google: «SRE implements class DevOps». SRE hat so gesehen auch etwas sehr Bodenständiges.

Was macht ein SRE und welche Kompetenzen sind notwendig?

Das Handeln des SRE ist zunächst durch ein ganz bestimmtes Mindset geprägt, welches man oft unter Softwareentwicklerinnen und Softwareentwicklern findet. In der täglichen Arbeit äussert sich dieses durch den intrinsischen Drang, repetitive, manuelle Tätigkeiten automatisieren zu wollen.

«Spätestens wenn ich etwas 2x manuell mache, automatisiere ich es. Oder besser gleich von Anfang an richtig.»

(Ein unbekannter Softwareentwickler, dem schnell langweilig wird)

Site Reliability Engineers sind auch deshalb besonders, weil sie übergreifende Skills benötigen. Vom Background her können das Systemadministratoren mit Interesse oder Skills in der Softwareentwicklung oder umgekehrt Softwareentwickler mit IT-Operations Knowhow sein.

Vieles in der täglichen Arbeit eines SRE dreht sich um Automatisierung:

• Aufsetzen von automatisiertem Monitoring in einem verteilten Umfeld, um Schlüssel Metriken wie Verfügbarkeit oder Latency im Blick zu haben
• Umsetzen von Scripts, z.B. Automatisierung der Incident-Response
• Unterstützung von Plattform-Teams beim Thema Zuverlässigkeit und Skalierung
• Unterstützung von Produktteams und Release-Engineers, um ihre Entwicklungspipelines robuster zu machen

Und jeder, der mal im IT-Betrieb gearbeitet hat, weiss, dass dazu auch das Lösen von auftretenden Störungen gehört. Das ist beim SRE nicht anders, jedoch ist entscheiden, dass diese Art von Arbeit nicht die Überhand gewinnt. Dies lässt sich durch einfache Regeln durchsetzen, hier im Beispiel von Google:

• Es gilt eine 50% “Ops Work” Obergrenze (Störungen lösen, On-Call etc.)
• Ein Minimum 50% muss Engineering-Arbeit sein (z.B. Automatisierung, SW-Entwicklung)

Schlussendlich geht es dabei auch darum, den altbekannten Teufelskreis zu durchbrechen, aus dem Feuerwehrmodus raus zu kommen und Systeme zu schaffen, bei denen Störungen erst gar nicht auftreten. Auch wirtschaftlich betrachtet können wir es uns gar nicht mehr leisten, in einem massiv skalierten Umfeld im reaktiven Modus zu verharren und alles manuell zu machen. Automatisierung und Standardisierung sind der Schlüssel und der Site Reliability Engineer trägt dazu entscheiden bei.