SRE-Grundlagen: Was Sie im Site Reliability Engineering erwartet

Site Reliability Engineering ist die Praxis, Software-Engineering-Tools und -Prinzipien in den IT-Betrieb zu integrieren. SREs erstellen und pflegen zuverlässige, belastbare, effiziente und skalierbare Infrastruktur und Dienste. SREs verbessern die Zuverlässigkeit skalierbarer Systeme. Sie entwickeln Systeme, die von Haus aus belastbar sind, und nutzen Software und Automatisierung, um eine ständig wachsende Infrastruktur zu verwalten, was eine deutlich nachhaltigere Praxis ist als die manuelle Verwaltung.

Site Reliability Engineers sind die Personen, die für die Verwaltung und Automatisierung des IT-Betriebs verantwortlich sind. Mit ihrer Expertise in der Softwareentwicklung sorgen sie dafür, dass die Systeme belastbar und verfügbar bleiben und automatisch alle Probleme beheben. Diese Rolle überwacht die Bereitstellung und das Deployment neuer Anwendungen und verhindert potenzielle Ausfälle und Unterbrechungen.

Benjamin Treynor Sloss, Vizepräsident von Google Engineering, prägte 2003 den Begriff „Site Reliability Engineering“ und sagte: „SRE ist das, was passiert, wenn man einen Softwareentwickler bittet, ein Betriebsteam zu entwerfen.“ Und genau das tat er.¹

Als neuer Mitarbeiter bei Google wurde ihm die Aufgabe übertragen, eine ingenieurtechnische Lösung für die Verwaltung der sich schnell ausweitenden Operationen und einer massiven, verteilten Infrastruktur zu finden. Bei der Geschwindigkeit, mit der die Infrastruktur des Unternehmens wuchs, wäre es unmöglich gewesen, die erforderliche Anzahl von Ingenieuren einzustellen, um neue Dienste manuell zu verwalten und gleichzeitig mit derselben Geschwindigkeit zu innovieren. Stattdessen brachte Treynors Team Innovation und Systemzuverlässigkeit in Einklang und förderte eine Kultur des kontinuierlichen Lernens und der Verbesserung.  

Schon bald konzentrierte sich das wachsende Team von SREs bei Google darauf, neue Features in die Produktionsumgebung einzuführen und gleichzeitig deren Stabilität und Zuverlässigkeit zu pflegen. Innerhalb weniger Jahre standen weitere Unternehmen vor dem gleichen Problem wie Google. Sie mussten riesige, verteilte Infrastrukturen verwalten und gleichzeitig die Verfügbarkeit und Zuverlässigkeit der Dienste pflegen. Bald verbreitete sich die Praxis des Site Reliability Engineering über Google hinaus und wurde zum Schlüssel für moderne IT-Operationen.

In der heutigen digital-first Welt verlassen sich Unternehmen jeder Größe auf hochverfügbare Systeme mit hoher Skalierbarkeit und Resilienz. Ein Ausfall, sei es eine Website oder eine mobile App, kann zu finanziellen Verlusten, einem schlechten Kundenerlebnis und betrieblichen Ineffizienzen führen. Deshalb spielen SREs eine wesentliche Rolle in jedem Unternehmen. 

SREs erleichtern es, mit der Konkurrenz Schritt zu halten. Sie können Verfügbarkeitsprobleme innerhalb von Minuten (statt Tagen) beheben und schnelle Seitenladezeiten gewährleisten, unabhängig von der Anzahl der Nutzer. 

In Großunternehmen erledigen SREs dieselben Aufgaben in einem anderen Maßstab. Sie automatisieren die Zuverlässigkeit, optimieren die Leistung und verhindern Systemausfälle durch proaktives Monitoring und Vorfallmanagement. Indem sie die Zusammenarbeit zwischen Entwicklungs- und Betriebsteams fördern, schaffen SREs zuverlässige und effiziente Systeme.

Im Kern geht es beim Site Reliability Engineering darum, betriebliche Probleme in der Produktion mit einem Softwareentwicklungsansatz zu behandeln. Weitere Grundprinzipien sind die Übernahme von Risiken, der Einsatz von Automatisierung und die Festlegung von Service-Level-Zielen (SLOs) und Service-Level-Indikatoren (SLIs).

Ein SRE erkennt, dass kein System perfekt arbeiten kann. Im Rahmen des Innovationsprozesses sind Fehler und Ausfälle zu erwarten. Anstatt Misserfolge zu vermeiden, konzentrieren sich SREs darauf, ein akzeptables Risikoniveau zu verstehen.

Risikobereitschaft bedeutet, den Wendepunkt zwischen der Verbesserung der Zuverlässigkeit, der Bereitstellung neuen Codes und der Bewältigung der potenziellen Auswirkungen auf die Nutzer zu finden. Die Zeit, Energie oder andere Ressourcen, die zur Verbesserung der Zuverlässigkeit eines Dienstes benötigt werden, stellen das akzeptable Risiko dar. Der Rest ist der Überschuss. Aber wie viel Risiko ist akzeptabel? Und ab welchem Punkt im Prozess beginnt sich das Benutzererlebnis zu verschlechtern? 

Dieses Kernprinzip von SRE basiert auf vier Faktoren:

1. Ein akzeptables Maß an Zuverlässigkeit für Nutzer, bestimmt durch die Einrichtung von SLOs und SLIs.

2. Kosten für Zuverlässigkeitsverbesserungen, einschließlich Automatisierung und Werkzeugen.

3. Risiko einer ausbleibenden Verbesserung 

4. Kosten vs. Risiko (ermittelt durch Fehlerbudgets)

Oft liegt der Schlüssel zur Risikoakzeptanz in einer kulturellen Perspektive. SREs arbeiten in einer nicht-punitiven Kultur. Diese umfasst das Lernen aus Fehlern und die Implementierung präventiver Maßnahmen, um die Systemzuverlässigkeit kontinuierlich zu verbessern und die Anwendungsleistung zu steigern.

Fehlerbudgets
Ein Fehlerbudget ist eine klare Kennzahl zum Verständnis und Management von Risiken. Es ist die Menge an Betriebsausfallzeit (oder die Anzahl der Fehler), die ein Dienst innerhalb eines bestimmten Zeitraums erfahren kann. 

Ein zulässiges Maß an Systemunzuverlässigkeit (auch als Fehlerbudget bezeichnet) trägt dazu bei, Innovation und Zuverlässigkeit ins Gleichgewicht zu bringen. Die Ingenieure werden ermutigt, Risiken einzugehen, z. B. die Deployments zu beschleunigen und neue Features freizugeben, weil sie ein Fehlerbudget haben. Sobald dieser Schwellenwert erreicht ist, stabilisieren die Ingenieure das System und verbessern die Zuverlässigkeit.

SRE-Teams berechnen ein Fehlerbudget, indem sie das akzeptable Niveau an Fehlern (oder die Betriebsausfallzeit) basierend auf dem SLO bestimmen. Mit anderen Worten, es ist die Fehlerspanne, die ein SLO zulässt.

Service Level Objectives, oder SLOs, sind die Zielwerte für die Leistung über einen bestimmten Zeitraum. Sowohl die Entwicklungsteams als auch die Geschäftsinteressenten müssen diese Ziele verstehen, um klare Erwartungen zu formulieren, die die Entscheidungsfindung leiten. 

Service-Level-Indikatoren, oder SLIs, messen die Serviceleistung. Normalerweise repräsentieren SLIs Nutzerprioritäten wie Latenz, Verfügbarkeit, Durchsatz, Fehlerraten und andere. 

Weder SLOs noch SLIs sind statisch. Sie entwickeln sich im Laufe der Zeit weiter und müssen regelmäßig überprüft und verbessert werden.

Schließlich: Automatisierung. SREs streben an, manuelle und repetitive Aufgaben durch Automatisierung zu ersetzen. Die Reduzierung von Mühsal bedeutet, die Zuverlässigkeit des Systems zu verbessern und schneller sowie effizienter zu innovieren.

Einige SRE-Teams verbringen bis zur Hälfte ihrer Zeit mit der Entwicklung von Automatisierungstools für Deployment, Incident-Response und Tests. Im Laufe der Zeit tragen fortschrittliche Automatisierungsfunktionen dazu bei, die Kosten für das Skalieren zu senken und gleichzeitig die Zuverlässigkeit der Dienste und eine optimale Leistung zu gewährleisten.

Monitoring und Beobachtbarkeit sind für SREs entscheidend. Sie bieten echte Einblicke, ob Dienste funktionieren, wie gut sie funktionieren, wo die Probleme liegen und so weiter. 

Monitoring hilft Site Reliability Engineers, Probleme schnell zu erkennen und zu beheben. Beobachtbarkeit bietet Einblicke in die Systemleistung in Echtzeit und historisch, um unbekannte Unbekannte anzugehen. Traces, Logs und Metriken sind die Hauptsignale der Beobachtbarkeit.

Die vier goldenen Signale des Site Reliability Engineering sind Latenz, Traffic, Fehler und Sättigung. Diese Metriken sind die Grundlage für die Anwendungszuverlässigkeit, also die Gesundheit und Leistung eines Dienstes in einem verteilten System. 

• Latenz ist die Zeit, die ein System benötigt, um auf eine Anfrage zu antworten (entweder erfolgreich oder mit einem Fehler). Hohe Latenz signalisiert Leistungsprobleme, die sofortige Aufmerksamkeit von SREs erfordern.

• Traffic misst die Nachfrage im System. Je nach System kann es die Anzahl der Transaktionen pro Sekunde oder HTTP-Anfragen pro Sekunde sein. SREs nutzen Traffic, um herauszufinden, ob die Nutzererfahrung sich verschlechtert oder nicht.

• Fehler sind die Rate der Anfragen, die fehlschlagen. Sie können explizit fehlschlagen (z.B. HTTP 500), implizit (z.B. HTTP 200, aber mit Inhaltsfehlern) oder per Richtlinie (z.B. alle Anfragen, die länger als eine Sekunde brauchen, um fehlzuschlagen). Je nach System kann SRE einer bestimmten Art von Fehlern Vorrang vor anderen einräumen und wiederkehrende Probleme angehen.

• Sättigung gibt die Gesamtkapazität des Systems an oder wie "voll" der Dienst ist. Sie kann auf verschiedene Weise gemessen werden, abhängig von den Ressourcen, die am stärksten eingeschränkt sind, oder von der verbleibenden Last, die ein System verarbeiten kann.

Die vier goldenen Signale helfen SREs, sich auf die Kapazitätsplanung, die Verbesserung der Systemzuverlässigkeit im Laufe der Zeit, die Reaktion auf und das Management von Zwischenfällen sowie die Suche nach der Ursache eines Problems zu konzentrieren. 

Dennoch werden die vier goldenen Signale allein komplexe verteilte Systeme nicht absolut zuverlässig machen. An dieser Stelle kommt Verteiltes Tracing ins Spiel. Es stellt alle Leistungszahlen in einen Kontext.

Wie wir bereits erwähnt haben, sind bei SRE Vorfälle und Ausfälle unvermeidlich. Dennoch erfordert jeder Vorfall eine Reaktion. Ein effektiver Incident-Response-Plan umfasst Triage-Verfahren, klare Kommunikationsprotokolle und Eskalationspfade.

Vielleicht ebenso wichtig sind die Postmortem-Analysen. Sie sind eine konstruktive Praxis und bieten eher eine Lernerfahrung als die Möglichkeit, mit dem Finger auf jemanden zu zeigen. SREs sollten jeden Vorfall protokollieren, seine Ursache ermitteln und gemeinsam mit dem Entwicklerteam den Code reparieren oder (wenn möglich) Tools entwickeln, um ein erneutes Auftreten zu verhindern. 

Tauchen Sie tiefer in das Vorfallmanagement ein.

Die Kapazitätsplanung stellt die Zuverlässigkeit der Dienste heute und morgen sicher. Es Protect sowohl vor Überprovisionierung als auch vor Unterprovisionierung. 

SRE-Teams erstellen eine Prognose der Nachfrage, indem sie historische Nutzungsmuster analysieren und den zukünftigen Ressourcenbedarf vorhersagen. Sie suchen nach Ineffizienzen, optimieren und verteilen die Ressourcen basierend auf Echtzeitinformationen neu und aktualisieren diese Pläne regelmäßig je nach den sich ändernden Daten. 

Mithilfe der Kapazitätsplanung stellen Site Reliability Engineers sicher, dass Systeme Wachstums- und Nachfragespitzen bewältigen können.

Änderungen führen oft zu Ausfällen, was selbst traditionelle ITOps bestätigen können. Anstatt jedoch Ausfälle und damit Veränderungen zu fürchten, begrüßen SREs den Wandel mit einer Reihe von drei Best Practices:

• Progressive, kontrollierte Rollouts minimieren die Auswirkungen potenzieller Probleme und ermöglichen eine frühzeitige Erkennung.

• Durch Monitoring wird sichergestellt, dass SREs Probleme in Echtzeit genau erkennen können.

• Ein Rollback-Plan garantiert ein sicheres und schnelles Verfahren zur Rückgängigmachung von Änderungen, wenn Probleme auftreten.  

Alle drei dieser Praktiken sollten nach Möglichkeit automatisiert werden.

Elastic Observability bietet eine einheitliche Lösung für das Sammeln, Monitoring und Analysieren von Beobachtbarkeit-Metriken in Ihrem gesamten Technologie-Stack. Mit Elastic Observability können Sie Beobachtbarkeit-Metriken aus beliebigen Quellen sammeln, speichern und visualisieren und die Problemlösung mit der Elastic Search AI Platform beschleunigen. Kombinieren Sie Conversational Search und Agenten-KI mit Elastic Observability für ein kontextbezogenes Chat-Erlebnis, das auch Ihre eigenen Daten und Runbooks einbezieht. 


Elastic AI Assistant kann SREs dabei helfen, Logmeldungen und Fehler zu interpretieren, Code zu optimieren, Berichte zu schreiben und sogar ein Runbook zu identifizieren und auszuführen. Beschleunigen Sie die Problemlösung, fördern Sie die Zusammenarbeit und erschließen Sie Wissen, um alle Nutzer zu befähigen und die Zuverlässigkeit zu gewährleisten.

Erfahren Sie mehr über Beobachtbarkeit mit Elastic.