Definition „SRE“ Was ist Site Reliability Engineering?

Site Reliability Engineering oder kurz SRE ist ein von. Google entwickeltes Service-Management-Modell. Entwicklung und Betrieb großer verteilter Systeme werden dabei eng gekoppelt. Die Regelungsprozesse stellen eine Konkretisierung der DevOps-Philosophie dar.

Site Reliability Engineers schlagen eine Brücke zwischen Entwicklung und Betrieb, indem sie bei Themen der Systemadministration eine softwaretechnische Denkweise anwenden. Sie teilen ihre Arbeit gleichmäßig zwischen Betriebs- und Entwicklungsaufgaben auf. Der ideale Kandidat für einen SRE-Posten ist folglich entweder ein Software-Ingenieur mit einem belastungsfähigen Hintergrund als Administrator oder ein hoch qualifizierter Systemadministrator mit Erfahrung in Programmierung und Automatisierung.

SRE-Mitarbeiter untersuchen im Betrieb die Belastbarkeit und Schwachstellen der Systeme, um Optimierungs- und Skalierungsmöglichkeiten ausfindig zu machen. Daneben steht mit gleicher Priorität die Suche nach Lösungen, die Handhabung der Systeme zu vereinfachen. Erfahrungen im Betrieb großer IT-Infrastrukturen fließen so direkt in die Weiterentwicklung der Strukturen.

Zu dem Konzept gehört, dass SREs nicht mehr als die Hälfte ihrer Zeit für den Betrieb aufwenden. Eine Verletzung dieser Regel wird als Zeichen für eine mangelhafte Umsetzung angesehen.

Herkunft

Das SRE-Konzept wurde erfolgreich und bekannt durch die Firma Google, die es lange kultivierte, bevor das Unternehmen die Prinzipien öffentlich machte. Es hat dieselben Ziele der Prozessverbesserung wie die DevOps-Philosophie. DevOps wurde um 2008 herum geprägt und steht für eine Unternehmenskultur teamübergreifender Zusammenarbeit. Alle Instanzen sollen mit der gleichen Vision in Einklang gebracht, es soll gemeinsame Verantwortung zum Gelingen etabliert werden.

SRE und DevOps

Vor der Verbreitung von DevOps arbeiteten die Entwicklungs- und Betriebsteams unabhängig mit jeweils eigenen Zielen und Vorgaben. Um besser zu kommunizieren und reibungsloser zusammzuarbeiten, avancierten DevOps-Teams zu den wichtigsten in jedem Unternehmen.

DevOps und SRE dienen gleichermaßen dazu, die Kluft zwischen Softwareentwicklung und Softwarebetrieb zu verringern, mit dem Ziel, den Release-Zyklus bei komplexen verteilten Systemen zu verbessern. Das DevOps-Konzept definiert, wie die Ergebnisse aussehen sollten; es steht für einen kulturellen Wandel innerhalb eines Unternehmens. Bei SRE geht es darum, den theoretischen DevOps-Ansatz mit passenden Methoden und Werkzeugen als Arbeitsablauf zu gestalten.

SRE umfasst dabei die fortwährende Automatisierung manueller Aufgaben und die kontinuierliche Integration (Continuous Integration) und Auslieferung (Continuous Delivery). SREs übernehmen die Verantwortung für Betriebszuverlässigkeit und Automatisierung während des gesamten Infrastruktur-Lebenszyklus, überwachen Bereitstellung und Betrieb der Releases.

Die 5 Grundprinzipien der DevOps-Philosophie und ihre Umsetzung durch SRE

1. Organisatorische Silos abbauen

Große Unternehmen haben eine komplexe Organisationsstruktur mit einer Vielzahl von Teams, die häufig getrennt in "Silos" arbeiten. Jedes Team hat eine andere Sicht auf das Ganze, was Ineffizienz begünstigt. Die Aufgabe von DevOps und SREs ist es, die Teams untereinander besser auf die übergeordneten Ziele und auf eine gemeinsame Vision hin abzustimmen.

2. Fehlschläge als zum Prozess gehörig ansehen

DevOps geht davon aus, dass Fehlschläge zum Prozess gehören und hilfreich sind, um daraus zu lernen. SREs stellen sicher, dass es nicht zu viele Fehlschläge oder Ausfälle gibt. Dazu nutzen sie Formeln, um Misserfolge mit der Herausgabe neuer Versionen abzuwägen: Service-Level-Indikatoren (SLIs) und Service-Level-Ziele (SLOs). SLIs messen Ausfälle über die Zeit. Ein SLO ist eine Vereinbarung innerhalb eines Service-Level-Agreements über eine bestimmte Metrik wie Betriebszeit oder Reaktionszeit, die einzuhalten ist.

Aus der SRE-Perspektive ist eine klare Übereinkunft zwischen der Business- und der IT-Ebene erforderlich, um optimale Ziele für Service-Level-Ziele und Service-Level-Indikatoren festzulegen. Jede Verletzung führt dazu, die Ziele neu zu bewerten und zu optimieren.

Die SRE-Richtlinien ermutigen zu radikalen Veränderungen innerhalb bestimmter Grenzen. SREs verfügen über ein Risikobudget, um diese Grenzen zu testen und so potenziell schneller innovativ zu sein. SRE quantifiziert dieses akzeptable Risiko als "Fehlerbudget". Wenn die Fehlerbudgets erschöpft sind, verlagert sich der Schwerpunkt von der Entwicklung auf die Verbesserung der Zuverlässigkeit. Verfügbarkeit und Weiterentwicklung werden so ausbalanciert.

3. Änderungen in schnellen kleinen Schritten umsetzen

Wie DevOps fördert SRE die kontinuierliche Verbesserung durch kleine und häufige Entwicklungsschritte. Bei kurzen Iterationszyklen sind etwaige negative Auswirkungen weniger gravierend, und risikoarme Verbesserungen können leicht (möglichst automatisiert) getestet und umgesetzt werden.

4. Gemeinsame Werkzeuge und Automatisierung nutzen

Inkompatibilitäts- und Integrationsprobleme zwischen Technologien verschiedener Anbieter, Epochen und Anwendungsfällen können selbst in einer DevOps-Umgebung Silos schaffen. SRE führt einheitliche Technologien und übergreifenden Informationszugriff in den verschiedenen IT-Teams ein. SRE fordert, dass alle Teams, die am gleichen Service arbeiten, die gleichen Technologien einsetzen.

SRE verfolgt den Grundsatz, manuelle Aufgaben zu automatisieren, die repetitiv und reaktiv sind und keine dauerhafte Verbesserung bringen. Die Automatisierung soll Kapazitäten freimachen für Arbeit, die langfristigen Nutzen bringt.

5. Reliability auf Messdaten gründen

Die Evaluierung geeigneter Ziele für Reliability (Zuverlässigkeit) ist für DevOps und SREs eine kontextbezogene Herausforderung. SREs stellen sicher, dass sich alle Ebenen im Unternehmen darüber einig sind, wie die Zuverlässigkeit zu messen ist und was zu tun ist, wenn der Wert nicht den Vorgaben entspricht.

Die DevOps-Schlüsselmetriken sind die Anzahl der Deployments in der Zeit, die Vorlaufzeit von der Zusage bis zur Freigabe, die Anzahl der fehlgeschlagenen Deployments und die benötigte Wiederherstellungszeit.

Die Grundlagen für SRE sind das Service-Level-Ziel (SLO) und der Service-Level-Indikator (SLI). SREs verwenden diese Metriken, um zu bestimmen, ob ein Release mit einer Änderung in Betrieb gehen wird oder nicht.

(ID:46996014)