# Site Reliability Engineering

Site Reliability Engineering (SRE) ist eine Reihe von Grundsätzen und Praktiken, die Aspekte der Softwaretechnik umfassen und auf Infrastruktur- und Betriebsprobleme angewendet werden. Die Hauptziele sind die Schaffung skalierbarer und hochzuverlässiger Softwaresysteme. Site Reliability Engineering ist eng mit DevOps verwandt, einer Reihe von Praktiken, die Softwareentwicklung und IT-Betrieb kombinieren, und SRE wurde auch als eine spezifische Umsetzung von DevOps beschrieben.

## Geschichte

Der Bereich Site Reliability Engineering hat seinen Ursprung bei Google mit Ben Treynor Sloss, der nach seinem Eintritt in das Unternehmen im Jahr 2003 ein Site Reliability Team gründete. Im Jahr 2016 beschäftigte Google mehr als 1000 Site Reliability Engineers. Nachdem das Konzept im Jahr 2003 bei Google entstanden war, verbreitete es sich in der gesamten Softwareentwicklungsbranche, und andere Unternehmen begannen daraufhin, Site Reliability Engineers zu beschäftigen. Die Position ist eher in größeren Webunternehmen verbreitet, da kleine Unternehmen oft nicht in einem Umfang tätig sind, der dedizierte SREs erfordern würde. Zu den Unternehmen, die das Konzept übernommen haben, gehören LinkedIn, Dropbox, Airbnb, IBM, und Netflix. Laut einem Bericht des DevOps Institute aus dem Jahr 2021 hatten 22 % der Unternehmen in einer Umfrage unter 2000 Befragten das SRE-Modell übernommen.

## Definition

Die Aufgabe des Site Reliability Engineering kann sowohl von Einzelpersonen als auch von Teams wahrgenommen werden, die in der Regel für eine Kombination der folgenden Aufgaben innerhalb einer breiteren technischen Organisation verantwortlich sind: Systemverfügbarkeit, Latenz, Performance, Effizienz, Change-Management, Monitoring, Notfallreaktion und Kapazitätsplanung. Site Reliability Engineers haben oft einen Hintergrund in Softwaretechnik, Systemtechnik oder Systemadministration. Zu den Schwerpunkten des Site Reliability Engineering gehören Automatisierung, Systemdesign und Verbesserung der Systemausfallsicherheit (Resilienz).
Site Reliability Engineering als eine Reihe von Prinzipien und Praktiken kann von jedem durchgeführt werden. SRE ist dem Security Engineering insofern ähnlich, als von jedem erwartet wird, dass er zu guten Sicherheitspraktiken beiträgt, aber ein Unternehmen kann sich auch dafür entscheiden, Spezialisten für diese Aufgabe einzustellen. Umgekehrt können Unternehmen für die Sicherung von Internet-Systemen Sicherheitsingenieure einstellen und für die Definition und Gewährleistung ihrer Zuverlässigkeitsziele stattdessen SREs engagieren.
Site Reliability Engineering wurde auch als eine spezifische Umsetzung von DevOps beschrieben, aber es konzentriert sich speziell auf den Aufbau zuverlässiger Systeme, während DevOps eher auf die Infrastruktur ausgerichtet ist.
Stephen Gossett schrieb in Built In, dass einige Unternehmen ihre Betriebsteams in SRE-Teams umbenannt haben, ohne dass sich dadurch etwas geändert hat. Dies scheint auch auf Betriebsteams zuzutreffen, die in DevOps-Teams umbenannt wurden.

## Prinzipien und Praktiken

Es hat mehrere Versuche gegeben, eine kanonische Liste von Prinzipien der Standortzuverlässigkeitstechnik zu definieren, aber obwohl es keinen Konsens gibt, sind die folgenden Merkmale normalerweise in den meisten dieser Definitionen enthalten:
* Automatisierung oder Eliminierung von sich wiederholenden Tätigkeiten, die auch kosteneffektiv zu automatisieren oder zu eliminieren sind.
* Vermeidung des Strebens nach viel mehr Zuverlässigkeit als unbedingt notwendig. Die Definition dessen, was notwendig ist, ist ein eigenes Verfahren (siehe Liste der Verfahren unten).
* Systemdesign mit der Tendenz, die Risiken für Verfügbarkeit, Latenz und Effizienz zu reduzieren.
* Beobachtbarkeit, d. h. die Möglichkeit, beliebige Fragen über Ihr System zu stellen, ohne vorher zu wissen, was Sie fragen wollen.
Die Praktiken des Site Reliability Engineering sind ebenfalls sehr unterschiedlich, aber die folgende Liste wird relativ häufig zumindest teilweise umgesetzt:
* Arbeitsmanagement als Umsetzung des ersten oben genannten Grundsatzes.
* Definition und Messung von Zuverlässigkeitszielen - SLIs, SLOs und Fehlerbudgets.
* Nicht-abstrakter Entwurf von Großsystemen (NALSD) mit Schwerpunkt auf der Zuverlässigkeit.
* Entwurf und Implementierung von Beobachtbarkeit.
* Definieren, Testen und Ausführen eines Störungsmanagementprozesses.
* Kapazitätsplanung.
* Änderungs- und Versionsmanagement, einschließlich CI/CD.
* Chaos-Engineering.

## Implementierungen

Site-Reliability-Engineering-Teams arbeiten mit den anderen Teams in ihren Unternehmen und den SRE-Prinzipien und -Praktiken in verschiedenen Formen zusammen. Im Folgenden findet sich ein Überblick über gängige SRE-Team-Implementierungen:

### Kitchen Sink, auch bekannt als „Everything SRE“

Der Umfang der abgedeckten Dienste oder Arbeitsabläufe ist in der Regel unbegrenzt.

### Infrastruktur

Konzentriert sich auf die Zuverlässigkeit der Systeme hinter den Kulissen, die die Arbeit anderer Teams effizienter machen. Diese Teams werden oft mit „Plattform“-Teams oder „Platform Operations“-Teams verwechselt. Infrastruktur-SRE-Teams können sich mit einem oder mehreren Plattform-Engineering-Teams zusammentun, aber sie unterscheiden sich darin, dass sich Infrastruktur-SRE-Teams auf die Durchführung der meisten, wenn nicht aller in der obigen Liste der Grundsätze und Praktiken beschriebenen Arbeiten konzentrieren. Plattformteams konzentrieren sich in der Regel auf die Entwicklung der Plattform, und obwohl Zuverlässigkeit wünschenswert ist, ist dies nicht ihre einzige Priorität.

### Werkzeuge

Konzentriert sich auf Tools zur Messung, Wartung und Verbesserung der Systemzuverlässigkeit.

### Produkt oder Anwendung

SRE-Team für Produkt und/oder Anwendung. Einige große Unternehmen beschäftigen mehrere dieser Teams.

### Eingebettet

In der Regel SRE-Einzelkämpfer oder Paare, die innerhalb eines Software-Engineering-Teams arbeiten und die meisten der oben beschriebenen Prinzipien und Praktiken anwenden.

### Beratung

Beratung bei der Umsetzung von SRE-Prinzipien und -Praktiken. Dabei handelt es sich in der Regel um erfahrene SREs, die in Teams mit einer oder mehreren der oben genannten Implementierungen gearbeitet haben. SREs in externen SRE-Beratungsteams werden oft als „Customer Reliability Engineers“ bezeichnet. Sie ändern selten, wenn überhaupt, die Konfiguration oder den Code des Kunden.
Große Unternehmen, die SRE eingeführt haben, verfügen in der Regel über eine Kombination der oben beschriebenen Implementierungen, einschließlich mehrerer Teams derselben Implementierung, z. B. mehrere Produkt-/Anwendungs-SRE-Teams, um die spezifischen Anforderungen verschiedener Produkte zu erfüllen, und ein Infrastruktur-SRE-Team, das sich mit einer Plattform-Engineering-Gruppe zusammenschließt, um die Zuverlässigkeitsziele einer gemeinsamen Plattform für beide Produkte/Anwendungen zu erfüllen.

## Branchenumfeld

Die USENIX-Organisation veranstaltet seit 2014 eine jährliche SREcon-Konferenz für Site Reliability Engineers in der Industrie und hält auch regionale Konferenzen mit ähnlichen Themen ab.