Überblick
Site Reliability Engineering (SRE) ist ein Software Engineering-Ansatz für IT-Operations. SRE-Teams verwenden Software als Tool zur Systemverwaltung, Problemlösung und Automatisierung von operativen Aufgaben.
SRE übernimmt diejenigen Aufgaben, die von Operations-Teams in der Vergangenheit häufig manuell ausgeführt wurden. Diese werden an Engineering- oder Operations-Teams weitergegeben, die Software und Automatisierung zur Behebung von Problemen und Verwaltung von Produktionssystemen verwenden.
SRE ist eine wertvolle Praktik beim Erstellen skalierbarer und hochzuverlässiger Softwaresysteme. Es unterstützt Unternehmen bei der Verwaltung großer Systeme mithilfe von Code, der für Systemadministrationsteams, 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.
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 zwei wichtige Komponenten des SRE-Modells. Site Reliability Engineers suchen hier immer nach Möglichkeiten, operative 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 und bei zukünftigem Wachstum.
SRE unterstützt Teams, die IT-Operations von einem traditionellen Ansatz auf eine cloudnative Strategie umstellen.
Was ist die Aufgabe eines Site Reliability Engineers?
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 SLAs (Service Level Agreements) 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 und Systemdurchsatz. SLOs basieren auf dem Zielwert oder -bereich eines spezifischen auf SLI basierenden Service Levels.
Das SLO für die erforderliche Systemzuverlässigkeit wird dann 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. Ausfälle sind de facto eingeplant und akzeptiert.
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.
Wenn ein Service innerhalb des Fehlerbudgets ausgeführt wird, kann das Entwicklungsteam den Start jederzeit initiieren. Weist er jedoch aktuell zu viele Fehler auf oder fällt länger aus, als es das Fehlerbudget zulässt, können keine neuen Starts durchgeführt werden, bis sich die Fehler im Rahmen des Budgets bewegen.
Das Entwicklungsteam führt automatisierte Operations-Tests durch, um die Zuverlässigkeit nachzuweisen.
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.
DevOps im Vergleich zu 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 für eine beschleunigte Servicebereitstellung zu sorgen.
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 Container-Technologie, 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.
Mehr über DevOps auf Red Hat Developer erfahren
Platform Engineering im Vergleich zu SRE
Sowohl beim Platform Engineering als auch beim Site Reliability Engineering geht es um die Erstellung und Verwaltung von Systemen. Der Unterschied zwischen den beiden Konzepten besteht im Fokus der jeweiligen Praktiken. SREs konzentrieren sich auf die IT-Operations-Teams und unterstützen sie dabei, Software als Tool zur Systemverwaltung, Problemlösung und Automatisierung von operativen Aufgaben einzusetzen.
Platform Engineers konzentrieren sich auf Entwicklungsteams und helfen ihnen, Plattformen für die Systemverwaltung, die Problemlösung und die Automatisierung von Entwicklungsaufgaben zu erstellen.
Technologie zur Unterstützung von SRE
SRE basiert auf der Automatisierung routinemäßiger operativer Aufgaben sowie der Standardisierung über den gesamten Lifecycle einer Anwendung.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.
Ansible Automation Platform bietet insbesondere folgende Vorteile:
- 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.
