Jump to section

Was ist SRE? Site Reliability Engineering im Detail erklärt

URL kopieren

Site Reliability Engineering (SRE) ist ein Software-Engineering-Ansatz für IT-Operations. SRE-Teams verwenden Software als Tool zur Verwaltung von Systemen, Behebung von Problemen und Automatisierung von Operations-Aufgaben.

SRE übernimmt diejenigen Aufgaben, die von Operations-Teams in der Vergangenheit häufig manuell ausgeführt wurden. Diese werden an Engineering- oder Ops-Teams weitergegeben, die Software und Automatisierung zur Behebung von Problemen und Verwaltung von Produktionssystemen verwenden. 

SRE ist eine wertvolle Praktik bei der Erstellung skalierbarer und hochzuverlässiger Softwaresysteme. Es unterstützt Unternehmen bei der Verwaltung großer Systeme mithilfe von Code, der für IT Teams, die Tausende oder Hunderttausende von Computern verwalten, skalierbarer und nachhaltiger ist. 

Das Konzept des Site Reliability Engineering stammt vom Google Engineering-Team und wird Ben Treynor Sloss zugeschrieben. Er selbst beschreibt Site Reliability als „das, was dabei herauskommt, wenn ein Softwareentwickler mit dem beauftragt wird, was früher als Operations bezeichnet wurde“.

SRE hilft Teams dabei, ein Gleichgewicht zwischen der Veröffentlichung neuer Features und ihrer Zuverlässigkeit für die Nutzenden zu finden. Standardisierung und Automatisierung sind dabei zwei wichtige Komponenten des SRE-Modells. Site Reliability Engineers suchen hier immer nach Möglichkeiten, Operations-Aufgaben zu verbessern und zu automatisieren.

Auf diese Weise trägt SRE dazu bei, die Zuverlässigkeit eines Systems zu verbessern – in seinem aktuellen Zustand als auch bei zukünftigem Wachstum. SRE unterstützt Teams, die IT-Operations von einem traditionellen Ansatz auf eine moderne cloudnative Strategie umzustellen.

Es handelt sich hier um eine besondere Rolle: Sie erfordert entweder einen Hintergrund in der Systemadministration, in der Softwareentwicklung mit zusätzlicher Operations-Erfahrung oder in einer IT-Operations-Rolle mit Softwareentwicklungsfähigkeiten. 

SRE-Teams sind verantwortlich für die Bereitstellung, Konfiguration und Überwachung von Code sowie Verfügbarkeit, Latenz, Änderungsmanagement, Notfallreaktion und Kapazitätsmanagement von Services in der Produktion.

Mithilfe von Site Reliability Engineering können Teams über Service Level Agreements (SLAs) bestimmen, welche neuen Features wann eingeführt werden können, um die erforderliche Zuverlässigkeit des Systems mithilfe von SLIs (Service-Level Indicators) und SLOs (Service-Level Objectives) zu definieren. 

SLIs messen bestimmte Aspekte bereitgestellter Service-Levels. Zu den wichtigsten SLIs gehören:

  • Latenz
  • Verfügbarkeit
  • Fehlerrate
  • Systemdurchsatz

SLOs basieren auf dem Zielwert eines spezifischen, auf der SLI basierenden Service-Levels. Die SLO für die erforderliche Systemzuverlässigkeit wird basierend auf der als akzeptabel angesehenen Ausfallzeit bestimmt. Diese Ausfallzeit wird als „Fehlerbudget“ bezeichnet – der maximal zulässige Schwellenwert für Fehler und Ausfälle. Mit SRE wird keine 100%ige Zuverlässigkeit erwartet, eher werden Ausfälle akzeptiert und de facto eingeplant.

Sobald das Fehlerbudget festgelegt ist, kann das Entwicklungsteam es sozusagen in Anspruch nehmen, wenn ein neues Feature veröffentlicht wird. Mithilfe des SLO sowie unter Berücksichtigung des Fehlerbudgets bestimmt das Team dann, ob ein Produkt oder ein Service eingeführt werden kann.

Liegt der Service innerhalb des Fehlerbudgets, kann das Entwicklungsteam die Ausführung jederzeit initiieren. Wenn er jedoch aktuell zu viele Fehler aufweist oder länger ausfällt, als das Fehlerbudget zulässt, können keine Neuerungen durchgeführt werden. Dies ist erst möglich, wenn sich der Service wieder innerhalb des Fehlerbudgets bewegt. 

SRE-Teams teilen ihre Zeit zwischen Operations-Aufgaben und Projektarbeit auf. Gemäß den Best Practices von Google für SRE dürfen Site Reliability Engineers maximal 50 % ihrer Zeit für Operations aufwenden. Dieser Wert sollte überwacht werden, um sicherzustellen, dass er nicht überschritten wird.  

Der Rest ihrer Zeit sollte für Entwicklungsaufgaben wie das Erstellen neuer Features, das Skalieren des Systems und das Implementieren der Automatisierung aufgewendet werden. Darüber hinausgehende operative Aufgaben und leistungsschwache Services können dem Entwicklungsteam zugewiesen werden, damit die Site Reliability Engineers nicht zu viel Zeit mit dem Betrieb von Anwendungen oder Services verbringen. 

Die Automatisierung ist ein wichtiger Bestandteil der Rolle. Wenn Site Reliability Engineers sich wiederholt mit einem Problem befassen müssen, wird die entsprechende Lösung wahrscheinlich von ihnen automatisiert. 

Die Aufrechterhaltung des Gleichgewichts zwischen Operations- und Entwicklungsarbeit ist eine Schlüsselkomponente von SRE. 

Das DevOps-Konzept umfasst die Aspekte Unternehmenskultur, Automatisierung und Plattformdesign mit dem Ziel, den geschäftlichen Mehrwert und die Reaktionsfähigkeit durch die schnelle Bereitstellung hochwertiger Services zu steigern. SRE kann als Implementierung von DevOps betrachtet werden.

Denn wie bei DevOps geht es auch bei SRE um Teamkultur und Beziehungen. SRE wie auch DevOps soll die Lücke zwischen Entwicklungs- und Operations-Teams schließen, um eine beschleunigte Servicebereitstellung zu gewährleisten. 

Schnellere Lifecycles für die Anwendungsentwicklung, eine verbesserte Servicequalität und -zuverlässigkeit sowie weniger IT-Zeit pro entwickelter Anwendung sind Vorteile, die sowohl mit DevOps- als auch mit SRE-Praktiken erzielt werden können.

SRE unterscheidet sich jedoch von DevOps, da es sich auf Site Reliability Engineers innerhalb des Entwicklungsteams stützt, die auch über einen Operations-Hintergrund verfügen. So werden Kommunikations- und Workflow-Probleme vermieden.

Ihre Rolle selbst ist eine Kombination aus den Kompetenzen von DevOps- und Operations-Teams, was eine Überschneidung der Verantwortlichkeiten erfordert. SRE kann DevOps-Teams helfen, deren Entwicklerinnen und Entwickler mit Operations-Aufgaben überfordert sind und jemanden mit spezielleren Ops-Fähigkeiten benötigen. 

Beim Programmieren und beim Entwickeln neuer Features konzentriert sich DevOps darauf, die Entwicklungs-Pipeline effizient zu durchlaufen. SRE hingegen ist darauf fokussiert, ein Gleichgewicht zwischen Funktionssicherheit und der Erstellung neuer Features zu schaffen. 

Moderne Anwendungsplattformen, die auf Containerisierung, Kubernetes und Microservices basieren, sind dabei für DevOps-Praktiken von großer Bedeutung und unterstützen die Sicherheit und die Bereitstellung innovativer Software-Services.

Lernen Sie mehr über DevOps von unserer Red Hat Developer Community

SRE basiert auf der Automatisierung routinemäßiger Aufgaben sowie der Standardisierung über den gesamten Lifecycle einer App. Red Hat® Ansible® Automation Platform ist eine umfassende, integrierte Plattform, die SRE-Teams dabei unterstützt, mit Automatisierung für mehr Geschwindigkeit, Zusammenarbeit und Wachstum zu sorgen. Dabei bietet sie Sicherheit und Support für die technischen, operativen und finanziellen Funktionen des Unternehmens. 

Vorteile der Nutzung von Red Hat Ansible Automation Platform

  • Orchestrierung der Infrastruktur in Cloud- und On-Premise-Umgebungen für Instanzen, Routing, Load Balancing, Firewalls und mehr 
  • Optimierung der Infrastruktur, u. a. durch genaues Anpassen von Cloud-Ressourcen und Hinzufügen oder Entfernen von Ressourcen wie CPUs und RAM nach Bedarf 
  • Cloud-Operationen wie Anwendungsbereitstellung mit CI/CD-Pipelines (Continuous Integration/Continuous Delivery), Patching von Betriebssystemen und Wartung
  • Business Continuity, u. a. durch Migrieren und Kopieren von Ressourcen aus der Cloud, Erstellen und Verwalten von Richtlinien für Backups sowie Verwalten von Unterbrechungen und Fehlern

SRE stützt sich zudem auf eine Basis, die für die cloudnative Entwicklung konzipiert ist. Linux-Container unterstützen eine einheitliche Umgebung für die Entwicklung, Bereitstellung, Integration und Automatisierung.

Und Kubernetes ist die moderne Art, Operationen mit Linux-Containern zu automatisieren. Mit Kubernetes können Teams Cluster einfacher und effizienter verwalten, auf denen Linux-Container in Public, Private oder Hybrid Clouds ausgeführt werden.

Red Hat® OpenShift® ist eine unternehmensgerechte Kubernetes-Plattform, die SRE-Initiativen unterstützt. Dadurch hilft sie Teams bei der Implementierung des kulturellen und prozesstechnischen Wandels, der die Modernisierung der IT-Infrastruktur ermöglicht und Organisationen besser für das Erreichen ihrer geschäftlichen Ziele und einer höheren Kundenzufriedenheit aufstellt. 

Weiterlesen

ARTIKEL

Was ist DevSecOps?

Wenn Sie die Agilität und Reaktionsfähigkeit von DevOps vollständig ausschöpfen möchten, muss die IT-Sicherheit im gesamten Lifecycle Ihrer Apps eine Rolle spielen.

ARTIKEL

Was ist CI/CD?

CI/CD sorgt für eine kontinuierliche Automatisierung und Überwachung über alle Phasen des App-Lifecycles hinweg, von der Integration und Tests bis hin zur Bereitstellung und Implementierung.

ARTIKEL

Was ist ein DevOps-Ingenieur?

DevOps-Ingenieure besitzen verschiedene besondere Fähigkeiten und Kenntnisse, die für eine bessere Zusammenarbeit, mehr Innovationen und kulturelle Verschiebungen innerhalb einer Organisation sorgen können. 

Mehr über DevOps erfahren

Produkte

Ein fokussierter Intensiv-Workshop mit Red Hat Experten, bei dem Sie lernen, eine agile Methodik und Open Source-Tools zu verwenden, um die geschäftlichen Probleme Ihres Unternehmens anzugehen.

Interaktionen mit unseren strategischen Beratern, die sich ein Gesamtbild von Ihrem Unternehmen machen, Ihre Herausforderungen analysieren und Ihnen helfen, diese mit umfassenden, kosteneffektiven Lösungen zu meistern.

Ressourcen