LeanIX Continuous Transformation Platform®
Cloud Native SaaS-Plattform, die die höchsten Sicherheits- und Datenschutzstandards erfüllt
Erleben Sie LeanIX in Aktion
Erfahren Sie, was Site Reliability Engineering ist, welche Vorteile sich aus diesem Software-Engineering-Ansatz ergeben und wie sich SLOs, SLIs und SLAs unterscheiden.
Da sich Unternehmen mit einer stetig wachsenden IT-Infrastruktur auseinandersetzen müssen, die auch Cloud-native Services unterstützt, wird Site Reliability Engineering (SRE) immer wichtiger. Dies lässt sich unter anderem auf die Softwareentwicklung zurückführen, die sich in den letzten Jahren drastisch verändert hat.
Laufende Aktualisierungsprozesse, schnelle Releases und Softwarepatches in verteilten IT-Umgebungen haben die Einführung von DevOps-Methoden beschleunigt und führten folglich zu einem grundlegenden Wandel in Unternehmen – weg von Abteilungssilos und hin zu einer neuen Engineering-Kultur. Diese Kultur ist der Inbegriff der „You build it, you run it“-Mentalität.
Um diese neue IT-Architektur zu stabilisieren und den daraus resultierenden Wettbewerbsvorteil zu festigen, stellen Unternehmen Site Reliability Engineers ein. SREs hilft dem Product Engineering bei der Optimierung ihrer Workflows, indem sie sich auf unterschiedliche Engineering-Prinzipien stützen. Ihr Hauptziel ist die Entwicklung verlässlicher Softwaresysteme, indem sie die bestehende Infrastruktur kontinuierlich analysieren und diese mithilfe von Softwarelösungen optimieren.
In diesem Guide erfahren Sie mehr über die Tätigkeitsbereiche und Vorteile von Site Reliability Engineering, die SRE-Grundprinzipien sowie die Unterschiede zwischen Site Reliability Engineers und Platform Engineers.
Site Reliability Engineering oder SRE ist ein Software-Engineering-Ansatz, mit dem große Systeme mittels Code verwaltet werden. Site Reliability Managern kommt die Aufgabe zu, mithilfe von SRE-Best-Practices sowohl eine resiliente Infrastruktur als auch effiziente Engineering-Workflows zu gestalten. Dies beinhaltet unter anderem auch die Nutzung von Metriken und Tools, um IT-Operations zu überwachen und zu verbessern.
Auch wenn SRE noch eine relative neue Disziplin von Cloud-native Engineering und Management zu sein scheint, findet dieser Engineering-Ansatz noch vor DevOps seinen Ursprung – eine Bewegung, die Softwareentwicklung und IT-Operations erfolgreich miteinander verbindet. Google war das erste Unternehmen, das seine Software Engineers beauftragte, großangelegte Softwaresysteme durch automatisierte Lösungen zuverlässiger, effizienter und skalierbarer zu gestalten. Die Praktiken, die die Google Engineers 2003 zu entwickeln begannen, sind das Fundament des heutigen Site Reliability Engineering.
Site Reliability Engineering befasst sich mit Aufgaben, die früher in den Verantwortungsbereich von IT-Operations fielen. Betriebsprobleme werden jedoch nicht manuell gelöst, sondern aus einer Engineering-Perspektive angegangen. Dank fortgeschrittener Software und Tools können SREs eine Brücke zwischen Entwicklung und Operations schlagen und dadurch eine IT-Infrastruktur gestalten, die zuverlässig ist und eine schnelle Implementierung neuer Services und Features ermöglicht. Daher sind Site Reliability Engineers besonders dann von Bedeutung, wenn Unternehmen von einem traditionellen IT-Ansatz auf einen Cloud-native-Ansatz umsatteln möchten.
Ein Site Reliability Engineer kommt meist aus der Softwareentwicklung und beachtliche Erfahrung in den Bereichen Operations und Business Analytics sammeln können. Dies ist auch notwendig, um Betriebsprobleme auf Codeebene zu beheben. Während DevOps sich eher auf die Automatisierung von IT-Operations fokussiert, konzentrieren sich SRE-Teams auf die Planung und das Design. Sie überwachen Systeme in der Produktionsumgebung und analysieren deren Performance, um Verbesserungspotenzial auszumachen. Ihre Beobachtungen helfen ihnen auch bei der Berechnung potenzieller Kosten, die aus Systemausfällen entstehen könnten, und planen das nötige Kontingent ein.
SREs teilen ihre Arbeitszeit meist zwischen Operations und der Entwicklung von Systemen und Software aus. Zu ihren direkten Tätigkeiten zählen die Aktualisierung der Runbooks, Tools, und Dokumentation, um Engineering-Teams auf mögliche Vorfälle vorzubereiten. Im Falle einer IT-Störung führen sie nach deren Lösung meist ausführliche Interviews durch, um herauszufinden, was funktioniert und was verbessert werden muss. So erfassen sie auch wichtiges undokumentiertes Wissen. Da sie auch in der Softwareentwicklung, im Support und der IT-Entwicklung mitwirken, bleibt dieses Wissen nicht in Abteilungssilos verborgen, sondern kann genutzt werden, um zuverlässigere Systeme zu gestalten.
Neben diesen organisatorischen Aufgaben befassen sich Site Reliability Engineers vornehmlich mit der Entwicklung und dem Deployment von Services, die IT-Workflows optimieren und die unterschiedlichen Abteilungen eines Unternehmens unterstützen. Dies kann auch bedeuten, dass sie ein Tool von Grund auf entwickeln, mit dem die Schwachstellen in der Softwarebereitstellung oder dem Incident-Management ausgebessert werden können. Neben der Reduzierung von IT-Vorfällen legen SREs außerdem mithilfe von Service-Level Agreements (SLAs), Service-Level Indicators (SLIs) und Service-Level Objectives (SLOs) fest, welche neuen Features wann implementiert werden können.
Im nächsten Abschnitt erfahren Sie mehr über die SRE-Kennzahlen SLA, SLI und SLO und wie sie im Site Reliability Engineering eingesetzt werden.
Wie bereits erwähnt nutzen SREs drei Metriken, um die Performance von IT-Systemen zu überwachen, zu messen und letztendlich zuverlässiger zu gestalten: Sie entwerfen Service-Level Agreements (SLAs), Service-Level Indicators (SLIs) und Service-Level Objectives (SLOs). Diese Service-Level-Metriken helfen Unternehmen nicht nur dabei, zuverlässigere Systeme zu entwickeln, sondern gewinnen zusätzlich auch mehr Vertrauen bei ihren Kunden.
SLI steht für Service-Level Indicator. Das Google SRE-Handbuch beschreibt diese Metrik als „ein sorgfältig definiertes quantitatives Maß für einen Aspekt des Service-Levels, der bereitgestellt wird.“ SLIs werden also verwendet, um die Eigenschaften eines Service zu messen, um Input für die Ziele eines Service-Provider zu bieten.
Produktorientierte SLIs messen Verhaltensweisen, die die Customer Experience stark beeinflussen. Insgesamt gibt es vier goldene Signale des Monitorings: Latenz, Traffic, Fehlerrate und Sättigung.
Wenn SRE-Teams SLIs für die Messung eines Service nutzen, definieren sie die Indikatoren meist in zwei Stufen:
Die Formel für die Berechnung von SLIs lautet SLI = Good Events * 100 / Valid Events. Ein SLI-Wert von 100 ist ideal, wohingegen ein Wert von 0 bedeutet, dass das System nicht funktioniert.
Es sollten jedoch SLIs erstellt werden, die der Journey des Nutzers entsprechen. Ein einziger SLI wird nicht die gesamte Customer Experience erfassen können, da einem Nutzer bei der Verwendung eines Service mehr als nur eine Sache wichtig sein könnte. Gleichzeitig sollte vermieden werden, SLIs für jede mögliche Metrik zu erstellen, da man so schnell den Blick für das wirklich Wichtige verliert.
Als Faustregel kann gesagt werden, dass Site Reliability Engineers versuchen, die Pain Points entlang der User Journey ausfindig zu machen, die dann zu einer kompletten Umgestaltung eines Systems führen könnten.
Mit der Festlegung der SLIs werden SLOs definiert, die sich auf die Verfügbarkeit und Qualität von Services richten und quantifizierbare Metriken darstellen.
SLOs oder Service-Level Objectives werden als objektives Maß für die Zuverlässigkeit oder Leistungsziele eines Service verwendet. Im Google SRE-Handbuch heißt es, dass sie „ein Zielniveau für die Zuverlässigkeit Ihres Service festlegen“ und „weil SLOs der Schlüssel zu datengetriebenen Entscheidungen über die Zuverlässigkeit sind, bilden Sie den Kern der SRE-Praktiken.“
Während SLIs produktorientiert sind, liegt der Fokus der SLOs ganz klar auf den Kunden. SLOs werden mithilfe von SLIs gemessen, sodass diese beiden Indikatoren inhärent miteinander verbunden sind. Die natürliche Struktur kann folgendermaßen definiert werden: Untere Grenze SLOs ≤ SLI ≤ Obere Grenze SLOs.
Die Auswahl der richtigen SLOs ist jedoch keine leichte Aufgabe. In der Regel sollten die Ziele nie auf der aktuellen, sondern auf einer historischen Systemleistung basieren. Manchmal machen SRE-Teams auch den Fehler, nach Perfektion zu streben und setzen sich Ziele, die viel zu hoch sind und kaum erreicht werden können. Es müssen auch keine absoluten Werte festgelegt werden. Dennoch ist es eine gute Idee, bei SLOs eine Sicherheitsmarge einzuplanen, indem man einen auf Daten basierenden Durchschnitt festlegt. Bei der Einführung von SLOs ist es wichtig, langsam zu starten und sich Schritt für Schritt hochzuarbeiten, da SLOs einen Kulturwandel erfordern.
SLOs schaffen ein gemeinsames Verständnis und gemeinsame Ziele über verschiedene Teams hinweg schafft. Und es ist viel wahrscheinlicher, dass Sie Erfolg haben, wenn Sie auf die Unterstützung Ihrer Stakeholder zählen können. Viele Unternehmen fokussieren sich jedoch auf Produktinnovationen und sehen den Zusammenhang zwischen Unternehmensleistung und Zuverlässigkeit nicht mehr. Häufige Hindernisse sind Daten, die sich in Silos versteckt finden, und die Annahme, das SLOs nur einmal erstellt und nicht regelmäßig neu bewertet und angepasst werden müssen.
SLAs oder Service-Level Agreements sind Verträge zur Serviceverfügbarkeit und -leistung. Genauso wie SLOs sind SLAs kundenorientierte Metriken. Laut dem Google SRE-Handbuch sind SLAs explizite oder implizite Verträge mit den Benutzern, in denen Konsequenzen für die Erfüllung (oder Nichterfüllung) der festgelegten SLOs beschrieben werden.
Ein SLA wird dann aktiv, wenn ein SLO versagt. Häufig ist mit Vertragsstrafen oder finanziellen Konsequenzen zu rechnen, wenn die vereinbarten Objectives nicht erreicht bzw. eingehalten werden. Wenn Unternehmen gegen vertragliche Verpflichtungen des SLA verstoßen, müssen diese ihre Kunden entschädigen.
SLAs schaffen Transparenz und Vertrauen zwischen Service und den Nutzern. Im Grunde genommen ähneln sich SLAs und SLOs stark – nur, dass SLAs für externe Zwecke genutzt werden. Im Vergleich zu SLOs sind SLAs nicht so konservativ. Das bedeutet, dass der Zuverlässigkeitswert immer etwas geringer ist als der Zuverlässigkeitsdurchschnitt von SLOs. Dies kann als Sicherheitsmaßnahme verstanden werden, für den Fall, dass der Durchschnitt aufgrund von sehr wenigen Vorfällen in der Vergangenheit zu hoch ist.
Site Reliability Engineers müssen also mit allen drei Metriken arbeiten, um eine stabile und zuverlässige Infrastruktur zu schaffen. Nach der Festlegung von SLIs (Metriken im Monitoringsystem), definieren sie Grenzwerte für diese Metriken basierend auf den internen SLOs. So können sie sicherstellen, dass externe SLAs jederzeit eingehalten werden.
Site Reliability Engineers und Platform Engineers haben ähnliche Aufgaben und sich überschneidende Zielsetzungen. In kleineren Unternehmen kann es sogar dazu kommen, dass diese beiden Rollen für dieselben Tätigkeiten verantwortlich sind und einander theoretisch vollumfänglich vertreten könnten. Mit der steigenden Anzahl von Entwicklern wird die Trennlinie zwischen SREs und Platform-Teams zunehmend schärfer.
Platform Engineers konzentrieren sich eher auf die Optimierung von Workflows, indem Sie bestimmte Infrastrukturkomponenten deployen. Dadurch können Product Engineers Applikationen entwickeln und ausliefern. Um Flaschenhälse zu vermeiden, müssen Platform Engineers bestehende Workflows anpassen und sicherstellen, dass die richtigen Personen diese nutzen können.
Site Reliability Engineers hingegen befassen sich eher mit dem allgemeinen „Gesundheitszustand“ eines Systems, indem sie dessen Zuverlässigkeit messen und Service-Level Objectives festlegen.
Die enge Zusammenarbeit beider Teams mit Entwicklern, Operations und Support führt zu besseren Produkten, einem schnelleren Deployment, geringeren Vorfällen sowie glücklicheren Entwicklern und Kunden.
Die DevOps-Kultur hilft Engineering-Teams dabei, effizienter zusammenzuarbeiten und Software schneller bereitzustellen. Daraus lässt sich jedoch nicht unbedingt eine bessere Zuverlässigkeit und Performance der Software ableiten, weswegen viele Unternehmen nach SREs Ausschau halten. Aber wie genau können Unternehmen von Site Reliability Engineering profitieren? Wir haben sechs der wichtigsten Argumente zusammengefasst, die für die Aufstellung eines SRE-Teams sprechen.
Es gibt viele Gründe, warum Cloud-native Unternehmen einen Site Reliability Engineer oder ein ganzes SRE-Team einstellen sollten. Sie stellen eine Bereicherung für die DevOps-Kultur dar, da sie die Lücke zwischen Entwicklern und der IT-Infrastruktur schließen.
Durch kontinuierliche Überwachung und Analyse der Applikationsleistung erkennen sie Probleme frühzeitig und tragen zur Optimierung der gesamten Produktroadmap bei. Außerdem verbringen die Entwicklerteams viel weniger Zeit mit Eskalationen und können ihre Zeit voll und ganz der Entwicklung neuer Funktionen und Services widmen.
Durch die Dokumentation von Microservices können DevOps-Teams ihre Microservices-Landschaft detailliert visualisieren und erhalten akkurate Informationen zu Ownership, Abhängigkeiten und dem Geschäftskontext.
Was ist Site Reliability Engineering (SRE)?
Site Reliability Engineering oder SRE ist ein Software-Engineering-Ansatz, mit dem große Systeme mittels Code verwaltet werden. Site Reliability Managern kommt die Aufgabe zu, mithilfe von SRE-Best-Practices sowohl eine resiliente Infrastruktur als auch effiziente Engineering-Workflows zu gestalten. Dies beinhaltet unter anderem auch die Nutzung von Metriken und Tools, um IT-Operations zu überwachen und zu verbessern.
Was sind die Vorteile von Site Reliability Engineering?
Es gibt eine Vielzahl von Vorteilen, darunter: verbessertes Reporting, proaktive Fehlersuche, mehr Zeit für Mehrwert schaffende Tätigkeiten, positiver Kulturwandel, höherer Automatisierungsgrad und zufriedene Kunden.
Was macht ein Site Reliability Engineer?
Ein Site Reliability Engineer kommt meist aus der Softwareentwicklung und beachtliche Erfahrung in den Bereichen Operations und Business Analytics sammeln können. Dies ist auch notwendig, um Betriebsprobleme auf Codeebene zu beheben. Während DevOps sich eher auf die Automatisierung von IT-Operations fokussiert, konzentrieren sich SRE-Teams auf die Planung und das Design. Sie überwachen Systeme in der Produktionsumgebung und analysieren deren Performance, um Verbesserungspotenzial auszumachen. Ihre Beobachtungen helfen ihnen auch bei der Berechnung potenzieller Kosten, die aus Systemausfällen entstehen könnten, und planen das nötige Kontingent ein.
Welche Metriken nutzen Site Reliability Engineers?
SREs nutzen drei Metriken, um die Performance von IT-Systemen zu überwachen, zu messen und letztendlich zuverlässiger zu gestalten: Sie entwerfen Service-Level Agreements (SLAs), Service-Level Indicators (SLIs) und Service-Level Objectives (SLOs). Diese Service-Level-Metriken helfen Unternehmen nicht nur dabei, zuverlässigere Systeme zu entwickeln, sondern gewinnen zusätzlich auch mehr Vertrauen bei ihren Kunden.
Wie unterscheiden sich Site Reliability Engineering und Platform Engineering?
Site Reliability Engineers und Platform Engineers haben ähnliche Aufgaben und sich überschneidende Zielsetzungen:
Site Reliability Engineers befassen sich eher mit dem allgemeinen „Gesundheitszustand“ eines Systems, indem sie dessen Zuverlässigkeit messen und Service-Level Objectives festlegen.
Platform Engineers hingegen konzentrieren sich eher auf die Optimierung von Workflows, indem Sie bestimmte Infrastrukturkomponenten deployen. Dadurch können Product Engineers Applikationen entwickeln und ausliefern. Um Flaschenhälse zu vermeiden, müssen Platform Engineers bestehende Workflows anpassen und sicherstellen, dass die richtigen Personen diese nutzen können.