Site-Reliability-Engineering (SRE) nutzt Software-Engineering, um IT-Betriebsaufgaben zu automatisieren, z. B. Produktionssystemmanagement, Änderungsmanagement, Reaktion auf Vorfälle und sogar Notfallabwehr, die andernfalls manuell von Systemadministratoren (Sysadmins) durchgeführt würden. 

Das Prinzip hinter SRE ist, dass die Verwendung von Softwarecode zur Automation der Überwachung großer Softwaresysteme eine skalierbarere und nachhaltigere Strategie ist als manuelle Eingriffe – insbesondere, wenn diese Systeme erweitert oder in die Cloud migriert werden.

SRE kann auch viele der natürlichen Reibungen zwischen Entwicklerteams, die ständig neue oder aktualisierte Software in die Produktion einbringen wollen, und Betriebsteams, die keine Updates oder neue Software freigeben wollen, ohne absolut sicher zu sein, dass sie keine Ausfälle oder andere Betriebsprobleme verursachen, verringern oder beseitigen. Obwohl SRE für DevOps nicht unbedingt erforderlich ist, orientiert es sich stark an den DevOps-Prinzipien und kann eine wichtige Rolle für den Erfolg von DevOps spielen.

Das Konzept von SRE geht auf Ben Treynor Sloss, VP of Engineering bei Google, zurück, der schrieb: „SRE ist das, was dabei herauskommt, wenn man einen Softwareentwickler bittet, ein Betriebsteam aufzustellen“.

Ein Site-Reliability-Engineer ist ein Softwareentwickler mit Erfahrung im IT-Betrieb – jemand, der nicht nur weiß, wie man programmiert, sondern auch, wie man in einer großen IT-Umgebung „stets die Fäden in der Hand hält“. 

Site-Reliability-Engineers verbringen nicht mehr als die Hälfte ihrer Zeit mit manuellen IT-Betriebs- und Systemverwaltungsaufgaben – Analyse von Protokollen, Leistungsoptimierung, Anwendung von Patches, Testen von Produktionsumgebungen, Reaktion auf Vorfälle, Durchführung von Postmortems – und verbringen den Rest ihrer Zeit mit der Entwicklung von Code, der diese Aufgaben automatisiert. Ihr Ziel ist es, im Laufe der Zeit viel weniger Zeit auf Erstere und viel mehr Zeit auf Letztere zu verwenden.

Auf einer höheren Ebene dient das SRE-Team als Brücke zwischen den Entwickler- und Betriebsteams. Es ermöglicht dem Entwicklerteam, neue Software oder neue Funktionen so schnell wie möglich in Produktion zu bringen und gleichzeitig ein vereinbartes akzeptables Niveau der IT-Betriebsleistung und des Fehlerrisikos in Übereinstimmung mit den Service Level Agreements (SLAs) zu gewährleisten, die das Unternehmen mit seinen Kunden abgeschlossen hat. Auf der Grundlage seiner Erfahrung und einer Fülle von Betriebsdaten unterstützt das SRE-Team die Entwickler- und Betriebsteams bei der Erstellung von

• Service Level Indicators (SLIs): Messungen des von den Systemen bereitgestellten Service-Levels – Metriken wie Verfügbarkeit (Betriebszeit) oder Latenz
  
  
• Service Level Objectives (SLOs): Vereinbarte Mittel zur Messung von Service Level Indicators
  
  
• Fehlerbudgets: Die Höchstdauer, die ein System ausfallen oder nicht die erwartete Leistung erbringen darf, ohne gegen die Vertragsbedingungen des SLA zu verstoßen. Das Fehlerbudget ist mehr als eine Metrik, es ist das Tool, mit dem das Team für Site-Reliability-Engineering automatisch das Innovationstempo des Unternehmens mit seiner Servicezuverlässigkeit in Einklang bringen kann. 

Das Fehlerbudget ist das Werkzeug, mit dem ein SRE-Team die Servicezuverlässigkeit des Unternehmens automatisch mit dem Tempo der Softwareentwicklung und Innovation in Einklang bringt. 

Angenommen, das SLA eines Unternehmens verspricht eine Betriebszeit von 99,99 % (ein gängiges Verfügbarkeitsziel) pro Jahr. Das bedeutet, dass das monatliche Fehlerbudget – die Gesamtsumme an Ausfallzeiten, die ohne vertragliche Konsequenzen für einen bestimmten Monat zulässig sind – etwa 4 Minuten und 23 Sekunden beträgt.

Nehmen wir an, das Entwicklerteam möchte einige neue Funktionen oder Verbesserungen am System implementieren. Wenn das System unter dem Fehlerbudget läuft, kann das Team die neuen Funktionen bereitstellen. Ist dies nicht der Fall, kann das Team die neuen Funktionen erst dann bereitstellen, wenn es mit dem Betriebsteam zusammenarbeitet, um diese Fehler oder Ausfälle auf ein akzeptables Niveau zu reduzieren.

Auf diese Weise helfen Fehlerbudgets Entwicklerteams und Betriebsteams dabei,

• die Stabilität und Leistung von Services zu verbessern
  
  
• datengesteuerte Entscheidungen über den Einsatz neuer Funktionen oder Anwendungen zu treffen
  
  
• Innovation durch Eingehen von Risiken innerhalb akzeptabler Grenzen zu maximieren

DevOps ist eine moderne Methode zur schnelleren Bereitstellung von Anwendungen mit höherer Qualität – durch Automation der Lebensdauer der Softwarebereitstellung und indem Entwickler- und Betriebsteams mehr gemeinsame Verantwortung und mehr Einfluss auf die Arbeit des jeweils anderen Teams erhalten. 

Wie SRE macht DevOps ein Unternehmen flexibler, indem es die Notwendigkeit, mehr Anwendungen und Änderungen schneller bereitzustellen, mit der Notwendigkeit in Einklang bringt, die Produktionsumgebung nicht ernsthaft zu schädigen. Und wie SRE zielt auch DevOps darauf ab, dieses Gleichgewicht zu erreichen, indem ein akzeptables Fehlerrisiko festgelegt wird. Tatsächlich scheinen SRE und DevOps so ähnlich zu sein, dass einige Experten sagen, sie seien ein und dasselbe – aber die meisten sehen SRE-Praktiken als hervorragende Möglichkeiten, DevOps-Prinzipien zu implementieren. Zum Beispiel:

DevOps-Prinzipien: Abbau von Organisationssilos, Nutzung von Tools und Automation

SRE-Praxis: Nutzung der gleichen Tools zur Automation und Verbesserung der Abläufe, die Entwickler nutzen, um Software zu entwickeln und zu verbessern

DevOps-Prinzipien: Störungen als normal akzeptieren, schrittweise Änderungen vornehmen

SRE-Praxis: Fehlerbudgets nutzen, um kontinuierlich neue Features und Funktionalität mit einem akzeptablem Fehlerrisiko bereitzustellen

DevOps-Prinzip: Alles messen

SRE-Praxis: Entscheidungen zum Release neuer Software basierend auf SLA-Metrik treffen

Wenn Sie mehr über DevOps erfahren möchten, sehen Sie sich dieses Video an (5:58):

Neben der Unterstützung des DevOps-Erfolgs kann Site-Reliability-Engineering einem Unternehmen helfen,

• sich einen umfassenden Überblick über den Zustand der Services zu verschaffen, indem Metriken, Protokolle und Traces für alle Services im Unternehmen verfolgt und im Falle eines Vorfalls der Kontext für die Identifizierung der Ursachen geliefert werden.
  
  
• die Kosten von Ausfallzeiten zu quantifizieren, indem Entwickler- und Betriebsteams geholfen wird, die Kosten von SLA-Verletzungen zu verstehen, und das Management dabei unterstützt wird, die Auswirkungen der Systemzuverlässigkeit auf Produktion, Vertrieb, Marketing, Kundendienst und andere Geschäftsfunktionen zu quantifizieren.
  
  
• die Reaktion auf Vorfälle zu optimieren, indem effiziente Bereitschaftsdienste aufgebaut und Workflows bei der Alertausgabe optimiert werden.
  
  
• ein modernes Network Operations Center aufzubauen, indem ein umfassendes Verständnis des IT-Betriebs mit maschinellem Lernen und Automation kombiniert wird, um Warnmeldungen direkt an die für das Problem zuständige Person zu senden.

Die Migration von traditionellen IT- und lokalen Rechenzentren zu Hybrid-Cloud-Umgebungen ist einer der Hauptgründe dafür, dass ein durchschnittliches Unternehmen jedes Jahr zwei- bis dreimal so viele Betriebsdaten generiert. SRE wird zunehmend als entscheidend für die Nutzung dieser Daten angesehen, um Systemverwaltung, Unternehmensaktivitäten und Reaktion auf Vorfälle zu automatisieren und die Zuverlässigkeit des Unternehmens zu verbessern, auch wenn die IT-Umgebung immer komplexer wird.

Ein cloudnativer Entwicklungsansatz – insbesondere die Erstellung von Anwendungen als Microservices und deren Bereitstellung in Containern – kann die Entwicklung, Bereitstellung und Skalierbarkeit von Anwendungen vereinfachen. Die cloudnative Entwicklung schafft aber auch eine zunehmend verteilte Umgebung, die Administration, Abläufe und Management erschwert. Ein SRE-Team kann das schnelle Innovationstempo unterstützen, das durch einen cloudnativen Ansatz ermöglicht wird, und die Systemzuverlässigkeit sicherstellen oder verbessern, ohne die DevOps-Teams mit zusätzlichem Betriebsdruck zu belasten.