Die Softwareentwicklung 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 zusammenarbeiten und schneller zuverlässige Software bereitstellen, 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 Schnittpunkt zwischen klassischer IT und Softwareentwicklung. Im Grunde genommen sind SRE-Teams Entwicklungsteams, 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 grundlegenden SRE-Rollen und -Zuständigkeiten 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 Softwareingenieur 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 Bereitschaftsaufgaben im Produktionssystem. Die gute Nachricht: DevOps hat die Entwicklungsteams in die Pflicht genommen und dafür gesorgt, dass sie ihren Teil der Verantwortung für die Produktionssysteme tragen, für ihren Code geradestehen und Bereitschaftsaufgaben ü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 Zusammenarbeit 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ätssicherung begreifen. Site Reliability Engineers widmen sich in Vollzeit der Entwicklung von Software, die die Zuverlässigkeit der Produktionssysteme 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 Produktionssysteme, sondern kann auch dazu führen, dass IT-, Support- und Entwicklungsteams 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 Schwachstellen bei der Softwarebereitstellung 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 Bereitschaftsaufgeben übernehmen. In den meisten Unternehmen haben SREs ein umfassendes Mitspracherecht, wenn es darum geht, wie das Team den Bereitschaftsdienst optimieren kann, sodass davon die Systemzuverlä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 Dokumentationsmaterial aktualisieren, sodass die Bereitschaftsteams in Zukunft auf Incidents besser vorbereitet sind.
Ungeschriebenes Wissen dokumentieren
Wie alle technischen Teams sammeln auch SRE-Teams Erfahrungen mit Systemen in Staging- und Produktionsumgebungen. Sie sind bei Entwicklung, Support, IT Operations und Bereitschaft beteiligt, und das bedeutet, dass sie im Laufe der Zeit eine Menge Erfahrungswissen 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 Softwareentwicklungs- 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 weiterentwickeln. 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 Schnittpunkten von IT Operations, Support und Softwareentwicklung 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 Softwareentwicklung 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 Bereitschaftsteams, 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.
