„Site Reliability Engineering“ beschreibt den Prozess der Nutzung von Betriebsprozessen sowie deren Zuweisung an das Software-Engineering-Team zur Automatisierung.
IT-Teams versuchen ständig, SRE-Methoden zu implementieren. Beim Site Reliability Engineering werden betriebliche Praktiken von Softwareingenieuren übernommen, um menschliche Aufgaben zu automatisieren, Probleme zu lösen und Systeme zu verwalten. Ein SRE-Team ist für Change Management, Notfallmaßnahmen, Überwachung, Verfügbarkeit, Leistung, Latenz, Effizienz und Kapazitätsplanung der Services zuständig und schreibt in der Regel Software für die Prozessautomatisierung.
SRE ist ein großartiges Asset für die Zuverlässigkeit von Software und die Skalierbarkeit, da Systeme per Code verwaltet werden können. So entsteht ein Gleichgewicht zwischen der Gewährleistung der Zuverlässigkeit eines Produkts und seiner Funktionen und dem Release von neuen Produkten und Funktionen.
Ben Treynor Sloss von Google ist der Vordenker des SRE und beschreibt es treffend als „das, was passiert, wenn ein Software-Entwickler mit dem betraut wird, was früher als Betrieb bezeichnet wurde“. Das Konzept entwickelte sich aus einer Untersuchung der Konflikte zwischen dem Betrieb – der sicherstellen will, dass Funktionen keine Schäden verursachen oder Benutzer stören – und den Entwicklungsteams – die neue Funktionen entwickelt haben und sie freigeben wollen, sobald sie für den Rollout bereit sind. SRE soll beide Seiten miteinander versöhnen.
Google hat ein Buch über SRE veröffentlicht, das kostenlos online verfügbar ist. Darin wird die Rolle von SRE eingehend erläutert und es werden Best Practices für die Umsetzung empfohlen. Besonders bemerkenswert sind die Teile II und III (Grundsätze und Praktiken).
Prinzipien von SRE: Die Grundprinzipien von SRE sind laut Google folgende:
- Risiken in Kauf nehmen: Neutrale Ansätze für das Servicemanagement unter Verwendung von Fehlerbudgets.
- Servicelevel-Ziele: Dieser Bereich bietet Empfehlungen für entkoppelte Indikatoren aus Vereinbarungen und untersucht, wie SRE die Begriffe verwendet.
- Eintönigkeit beseitigen: Abkehr von banalen und sich wiederholenden Aufgaben, die keinen Wert bieten.
- Überwachung verteilter Systeme: Ständiger Überblick über die Abläufe im Unternehmen, um die Zuverlässigkeit zu steigern.
- Release Engineering: Sorgfältige Vorbereitung von Releases, um sicherzustellen, dass sie einheitlich sind und nicht zu Ausfällen führen.
- Einfachheit: Ein zu komplexes System kann die Zuverlässigkeit beeinträchtigen und die Rückskalierung auf ein einfacheres System erschweren.
Als Site Reliability Engineer eignet sich am besten jemand, der bereits über Erfahrung im Softwarebereich verfügt – diese Position ist keinesfalls für Anfänger geeignet. Die ordnungsgemäße Ausführung von SRE erfordert fundierte Kenntnisse im Software Engineering und ein gutes Verständnis komplexer und umfangreicher Systeme.
Ein Site Reliability Engineer muss die richtige Einstellung für diese Position mitbringen. Technische Fähigkeiten sind eine Grundvoraussetzung, aber ein konzeptionelles Verständnis des Betriebs ist der Schlüssel. Es ist wichtig, dass sich SREs mit traditionellen Software-Engineering-Prozessen auskennen, aber auch ein ganzheitliches Verständnis der Unternehmensprozesse und die Weiterentwicklung eines zuverlässigen Systems sind von großer Bedeutung.
Alle Mitarbeiter eines Unternehmens sollten bestrebt sein, so zuverlässig wie möglich zu sein – und damit die wichtigen Grundsätze von SRE umzusetzen. Erstellen Sie für jedes Team ein Zuverlässigkeitsmodell und besprechen Sie, wie Zuverlässigkeit in jedes Team integriert werden kann und inwiefern sie jeden betrifft.
Die Einführung neuer Produkte wird auf Grundlage der aktuellen Produktleistung genehmigt: Anwendungen sind in der Regel nicht 100 % der Zeit betriebsbereit. Das SRE-Team sollte eine Servicelevel-Vereinbarung ausarbeiten, um das System zu definieren und festzulegen, wie es für die Benutzer verwendet werden soll. Fester Bestandteil einer Servicelevel-Vereinbarung ist ein Fehlerbudget, d. h. der maximale Schwellenwert für Ausfälle und Fehler.
Entwicklungsteams und SREs teilen sich das Personal, was bedeutet, dass ein zusätzlicher SRE einen Entwickler weniger bedeutet und umgekehrt. Das System ist selbstregulierend, um Kämpfe zwischen Entwicklern und SREs um Stellen zu vermeiden. SREs können ebenfalls programmieren und entwickeln, sodass sie problemlos mit dem Entwicklungsteam zusammenarbeiten können.
SREs dürfen zwischen Projekten hin- und herspringen, denn SRE bewirkt eine hohe Motivation und ein großes Engagement, sodass die Teammitglieder ihre persönlichen Ziele verfolgen können.
- Entwicklung von Software zur Unterstützung des Betriebs und der Teams
- Beheben von Eskalationsproblemen
- Optimierung der Bereitschaftsdienstprozesse
- Dokumentation des Teamwissens
- Durchführung von Prüfungen nach Incidents
SREs können direkt an der Schnittstelle zwischen IT-Betrieb, Software Engineering und Support eingesetzt werden, um eine solide Grundlage und Beziehung zwischen den Teams zu schaffen. Auf diese Weise werden Feedbackschleifen, Zusammenarbeit und Zuverlässigkeit verbessert.
Sie behalten das große Ganze im Blick, um verschiedene Teams auf ein einziges Ziel einzuschwören.
Ein großer Teil der Aufgaben von SRE besteht darin, Ineffizienzen auszumerzen und zu erkennen, was sich problemlos automatisieren lässt. So können zeitraubende Aufgaben wegfallen und die Effizienz lässt sich steigern, da weniger manuelle Arbeiten anfallen.
SRE-Verfahren sind nicht nur auf die Technologiebranche beschränkt. Die Kultur des Site Reliability Engineerings lässt sich auch auf E-Commerce, Kundenservice und Fertigung ausweiten.
DevOps ist eine Methode zur Erstellung und Bereitstellung guter Software, bei der Software Engineering und -Betrieb mit dem Ziel kombiniert werden, Betriebs- und Entwicklungsrollen zu verschmelzen. Das Hauptaugenmerk von SRE liegt eher auf der Entwicklungs- als auf der Betriebsseite von DevOps.
Erfahren Sie mehr über DevOps
DevOps- und SRE-Teams einen modernen Betrieb bieten
Linux-Container können die erforderliche Technologie für eine cloudnative Entwicklung bereitstellen – Container unterstützen die Vereinheitlichung der Umgebung für Integration, Automatisierung, Entwicklung und Bereitstellung. Kubernetes kann die erforderlichen Linux-Container automatisieren.
Für SRE gibt es kein bestimmtes, einheitliches Toolset. Wichtig ist jedoch, dass der Aufbau von SRE-Funktionen innerhalb eines Unternehmens immer mit Automatisierung einhergeht, um Skalierbarkeit und Wiederholbarkeit zu gewährleisten.
Der Mehrwert von ServiceNow liegt in der teamübergreifenden Zusammenarbeit, der Registrierung von Microservices, der Korrelation beobachtbarer Daten, der Automatisierung von Changes und der Vorhersage von Fehlern – und das alles unter Beibehaltung Ihrer bestehenden Tools.
Erstellen Sie Ihren nächsten SRE-Transformationsplan mit ServiceNow.