SRE

SRE vs. DevOps – Konkurrenten oder Freunde?

Immer mehr Teams bei Swisscom setzen auf Site Reliability Engineering (SRE), um die Erwartungen unserer Kunden und Anwender zu erfüllen. Moment mal – wollten wir nicht mit DevOps die Lücke zwischen Dev und Ops schliessen und eine hohe Qualität unserer Software in der Produktion gewährleisten? Ist SRE einfach nur ein neuer Hype, um Talente zu gewinnen? In diesem Blog möchten die DevOps-Teams von Swisscom ein gemeinsames Verständnis dafür schaffen, wie SRE gegenüber DevOps positioniert ist, und aufzeigen, wie wir in unserer Software-Abteilung bei Swisscom SRE sehen. Zunächst ein wenig Theorie über DevOps und SRE:

Michael Ludwig, Tribe Chief
12. August 2020

DevOps

Am Anfang der DevOps-Bewegung stand die Erkenntnis, dass Entwickler häufig Code verfassten, ohne eine Vorstellung davon zu haben, wie er sich in der Produktion bewähren würde. Anschliessend übergaben sie diesen Code ohne viel Worte an das Operations-Team, das die Anwendungen dann am Laufen halten musste.

Ziel von DevOps war es deshalb, mit einer Arbeitskultur und einer Reihe von Praktiken eine Brücke zwischen Softwareentwicklung und Softwarebetrieb zu schlagen.

Die DevOps-Bewegung gibt für diese Bereiche jedoch keine klaren Erfolgsrezepte vor.

In dieser Hinsicht entspricht DevOps einer abstrakten Klasse oder einer Schnittstelle in der Programmierung. Dabei wird zwar das Gesamtverhalten des Systems definiert, die Details der Implementierung werden jedoch dem Autor überlassen.

Site Reliability Engineering (SRE)

Der Begriff Site Reliability Engineering (SRE) (und das damit verbundene Tätigkeitsfeld) wurde von Ben Treynor Sloss, VP of Engineering bei Google, geprägt.

SRE beschreibt ein Tätigkeitsfeld und eine Reihe von Praktiken, die laut Google funktionieren, sowie bestimmte Überzeugungen, die mit diesen Praktiken einhergehen. Wenn man DevOps als Philosophie und Arbeitsansatz betrachtet, kann man das Ganze so beschreiben, dass SRE einen Teil der von DevOps beschriebenen Philosophie umsetzt.

«SRE findet statt, wenn man einen Software-Ingenieur bittet, eine Funktion für den Betrieb zu entwerfen.»

Ben Treynor, Vice President of engineering bei Google

Wie SRE DevOps konkret berücksichtigt

SRE hat die Philosophie von DevOps verinnerlicht. Allerdings wird hier ein deutlich normativerer Ansatz verfolgt, um Zuverlässigkeit mittels Engineering- und Operations-Tätigkeiten zu messen und zu erzielen. Mit anderen Worten: SRE gibt vor, wie man in den verschiedenen DevOps-Bereichen erfolgreich sein kann. So veranschaulicht die folgende Tabelle die fünf DevOps-Säulen und die entsprechenden SRE-Praktiken:

In gewisser Weise implementiert die Klasse SRE das Interface DevOps.

Unterschiede DevOps <-> SRE

Dennoch gibt es auch hier signifikante Unterschiede. DevOps ist in gewissem Sinne eine breiter gefasste Philosophie und Kultur.

DevOps sagt relativ wenig darüber aus, wie die operativen Funktionen im Detail gestaltet werden. Zum Beispiel macht DevOps keine genauen Vorgaben zur Verwaltung von Diensten. Stattdessen konzentriert sich DevOps auf den Abbau von Barrieren im Unternehmen allgemein, was durchaus wertvoll ist.

SRE hingegen weist relativ eng definierte Verantwortlichkeiten auf und ist eher am Service (und am Endanwender) orientiert als am Gesamtunternehmen. Somit gibt SRE einen eigenwilligen intellektuellen Rahmen (einschliesslich Konzepten wie Fehlerbudgets zur Lösung der Fragestellung vor, wie Systeme effektiv betrieben werden können. Obwohl SRE in professioneller Hinsicht ein hohes Bewusstsein für Anreize und deren Auswirkungen zeigt, sagt es eher wenig über Silodenken und Informationsbarrieren aus. Eine Unterstützung von CI (Continuous Integration) und CD (Continuous Delivery) wäre möglich – weniger wegen des Business Case als vielmehr wegen der damit verbundenen verbesserten Betriebsabläufe.

Anders ausgedrückt: SRE beruht auf den gleichen Überzeugungen wie DevOps, aber aus etwas anderen Gründen.