Site Reliability Engineer (SRE) – Rollen und Zuständigkeiten

Die Software­entwicklung wird immer dynamischer und komplexer, sodass die IT-Operations-Teams kaum mehr mithalten können. Daher wird DevOps immer beliebter, weil es abgeschottete Workflows aufbricht, die Zusammenarbeit verbessert und Transparenz schafft. Nun können die Teams in einer DevOps-Kultur zwar besser zusammen­arbeiten und schneller zuverlässige Software bereit­stellen, aber wer kümmert sich darum, dass die entwickelten Systeme auf Site Reliability und Performance optimiert sind? An diesem Punkt kommen Site Reliability Engineers (SREs) ins Spiel.

Site Reliability Engineering ist ein Konzept, das Benjamin Treynor Sloss 2003 in die Welt gesetzt hat, seines Zeichens technischer Leiter bei Google. Dessen Site Reliability Team veröffentlichte bald darauf ein E-Book zu SRE, das viel Aufmerksamkeit erhielt und dafür gesorgt hat, dass sich SRE in der Branche etabliert hat. Site Reliability Engineers sitzen am Schnitt­punkt zwischen klassischer IT und Software­entwicklung. Im Grunde genommen sind SRE-Teams Entwicklungs­teams, die Software programmieren und implementieren – und zwar mit dem Ziel, die Zuverlässigkeit ihrer Systeme zu verbessern.

Am besten sehen wir uns zuerst einmal die grund­legenden SRE-Rollen und -Zuständig­keiten an – und wie Site Reliability Engineering die Resilienz eurer Leute, Prozesse und Technologien drastisch verbessern kann.

Was ist Site Reliability Engineering (SRE)?

Laut Ben Treynor ist SRE „das, was passiert, wenn man einen Software­ingenieur bittet, eine Operations-Funktion zu entwerfen“. In der klassischen Konstellation getrennter ITOps- und Dev-Teams übergibt die Entwicklung ihren Code an die IT-Leute. Die IT übernimmt dann die Bereitstellung, die Wartung und alle Bereitschafts­aufgaben im Produktions­system. Die gute Nachricht: DevOps hat die Entwicklungs­teams in die Pflicht genommen und dafür gesorgt, dass sie ihren Teil der Verantwortung für die Produktions­systeme tragen, für ihren Code geradestehen und Bereitschafts­aufgaben übernehmen.

So hat DevOps die gemeinsame Verantwortung für die Zuverlässigkeit von Anwendungen und Infrastruktur gebracht. Dies ist zwar ein wirklich guter erster Schritt nach vorn, hilft den Teams aber noch nicht, die Resilienz ihrer Systeme aktiv zu steigern. Trotz verkürzter Feedback-Schleifen und verbesserter Zusammen­arbeit sind viele DevOps-Teams noch immer in der Situation, dass sie im Eiltempo neue, unzuverlässige Services in der Produktion bereitstellen müssen.

Site Reliability Engineering stellt eine Möglichkeit dar, die Lücke zwischen Entwicklung und IT-Betrieb zu schließen, die selbst in einer DevOps-Kultur noch besteht. Dabei arbeitet SRE nicht gegen DevOps, sondern mit DevOps. SRE lässt sich als eine Art aktiver Qualitäts­sicherung begreifen. Site Reliability Engineers widmen sich in Vollzeit der Entwicklung von Software, die die Zuverlässigkeit der Produktions­systeme verbessert. Sie beheben Probleme, reagieren auf Incidents und übernehmen in der Regel auch Bereitschaftsaufgaben.

Gängige Rollen und Zuständigkeiten von Site Reliability Engineers

Von der Einrichtung eines SRE-Teams profitieren sowohl ITOps- als auch Dev-Teams enorm. SRE steigert nicht nur die Zuverlässigkeit der Produktions­systeme, sondern kann auch dazu führen, dass IT-, Support- und Entwicklungs­teams weniger Zeit für Support-Eskalationen aufwenden müssen und mehr Zeit für die Entwicklung neuer Funktionen und Services haben.

Werfen wir also einen kurzen Blick auf die gängigen SRE-Rollen und -Zuständigkeiten, auf die ihr euch einstellen könnt.

Operations- und Support-Teams mit eigener Software unterstützen

SRE-Teams sind dafür zuständig, Services zu erstellen und zu implementieren, die den IT- und Support-Teams die Arbeit erleichtern. Hierbei kann es sich um alles Mögliche handeln, von Anpassungen bei Monitoring und Benachrichtigungen bis hin zu Code-Änderungen in der Produktion. Site Reliability Engineers könnten beispielsweise die Aufgabe bekommen, in eigener Verantwortung ein ganz neues Tool zu entwickeln, mit dem sich Schwach­stellen bei der Software­bereitstellung oder beim Incident Management beheben lassen.

Eskalierte Support-Probleme beheben

Als Site Reliability Engineer muss man damit rechnen, dass man einige Zeit mit der Behebung von Support-Eskalationsfällen verbringt. Doch mit zunehmender Reife eurer SRE-Abläufe werden eure Systeme insgesamt zuverlässiger, sodass in der Produktion weniger kritische Incidents auftreten und die Zahl der Eskalationen zurückgeht. Weil ein SRE-Team mit vielen verschiedenen Bereichen von Entwicklung und IT-Organisation zu tun hat, ist es außerdem oft eine gute Quelle von Know-how und kann bei der Weiterleitung von Problemen an die richtigen Personen und Teams sehr hilfreich sein.

Bereitschaftspläne und -prozesse optimieren

Oftmals müssen Site Reliability Engineers auch Bereitschafts­aufgeben übernehmen. In den meisten Unternehmen haben SREs ein umfassendes Mitsprache­recht, wenn es darum geht, wie das Team den Bereitschafts­dienst optimieren kann, sodass davon die System­zuverlässigkeit profitiert. SRE-Teams können beispielsweise Benachrichtigungen automatisieren und mit Kontext anreichern und auf diese Weise für eine verbesserte, konzertierte Incident Response in Echtzeit sorgen. Sie können außerdem Runbooks, Tools und Dokumentations­material aktualisieren, sodass die Bereitschafts­teams in Zukunft auf Incidents besser vorbereitet sind.

Ungeschriebenes Wissen dokumentieren

Wie alle technischen Teams sammeln auch SRE-Teams Erfahrungen mit Systemen in Staging- und Produktions­umgebungen. Sie sind bei Entwicklung, Support, IT Operations und Bereitschaft beteiligt, und das bedeutet, dass sie im Laufe der Zeit eine Menge Erfahrungs­wissen aufbauen. Dieses Wissen sollte aber nicht nur in den Köpfen eines Teams oder einer Person verbleiben. Vielmehr sollten SREs die Aufgabe haben, ihr Wissen weitgehend zu dokumentieren. Die kontinuierliche Pflege von Dokumentationen und Runbooks sorgt dafür, dass eure Teams die nötigen Informationen genau dann bekommen, wenn sie sie brauchen.

Incidents nachbereiten

Ohne sorgfältige Nachbereitung von Incidents lässt sich nicht feststellen, was funktioniert und was nicht. Die SRE-Teams müssen dabei auf die ehrliche Mitwirkung der Teams setzen und dafür Sorge tragen, dass nach einem Incident alle Beteiligten – sowohl die Fachleute aus der Entwicklung als auch die aus der IT – Überprüfungen vornehmen, ihre Ergebnisse dokumentieren und auf der Grundlage der gewonnenen Erkenntnisse Maßnahmen ergreifen. Im Anschluss daran haben die Site Reliability Engineers meist die Aufgabe, den Software­entwicklungs- bzw. Incident-Lebenszyklus zu ergänzen oder zu optimieren und dadurch die Zuverlässigkeit des Services zu verbessern.

An welcher Stelle passt SRE in euer Team?

Die Rollen und Zuständigkeiten von Site Reliability Engineering tragen entscheidend dazu bei, dass sich die Leute, Prozesse und Technologien im Unternehmen kontinuierlich weiter­entwickeln. Ganz gleich, ob euer Team bereits eine DevOps-Kultur nach allen Regeln der Kunst pflegt oder noch mitten in der Umstellung steckt: SRE bietet zahlreiche Vorteile in puncto Tempo und Zuverlässigkeit. SRE ist direkt an den Schnitt­punkten von IT Operations, Support und Software­entwicklung angesiedelt; die Kombination der erforderlichen Fertigkeiten passt perfekt, um die Beziehung zwischen IT und Entwicklung noch mehr zu stärken. Das Ergebnis sind kürzere Feedback-Schleifen, bessere Zusammenarbeit und zuverlässigere Software.

Eine Stelle als Site Reliability Engineer?

Der SRE-Report 2021 von Catchpoint hat gezeigt, dass von allen Beschäftigten aus Software­entwicklung und IT die Site Reliability Engineers zu den zufriedensten zählen. SREs entwickeln zwar nicht ständig neue Funktionen für Kunden, aber trotzdem hat ihre Arbeit laufend Auswirkungen auf die Customer Experience. Eigentlich ist es sogar so: Wenn ihr eine Rolle sucht, die den Kunden wirklich weiterhilft, dann ist es SRE.

Site Reliability Engineering ist nicht nur gut für die Kunden, sondern macht auch Bereitschafts­teams, IT-Fachleuten und den Dev-Teams das Leben leichter (sofern es richtig gemacht wird). SRE kann für Software Engineers geradezu die Erfüllung sein. Ihr lernt dann, die Probleme von IT und Support besser zu verstehen, und werdet dadurch selbst immer besser, auch im Entwickeln.

Seid ihr bereit für umfassende End-to-End-Transparenz bei euren Systemen und Anwendungen? Dann testet Splunk Observability Cloud 14 Tage lang kostenlos!

_{*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier.}