Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03236.jsonl.gz/452

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.»
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.
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.
Dieser Blog-Post basiert hauptsächlich auf SRE vs. DevOps: konkurrierende Standards oder enge Freunde?
Michael Ludwig
Tribe Chief
Werde Teil von Swisscom.