Der ultimative Guide

Site Reliability Engineering (SRE)

Erfahren Sie, was Site Reliability Engineering ist, welche Vorteile sich aus diesem Software-Engineering-Ansatz ergeben und wie sich SLOs, SLIs und SLAs unterscheiden.

Einleitung

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.

Was ist Site Reliability Engineering?

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.

Was machen Site Reliability Engineers?

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.

Microservices @ LeanIX - then, now and tomorrow

Video

Microservices @ LeanIX - then, now and tomorrow

Live Recording - EA Connect Day 2020 

Per Bernhardt - Staff Software Engineer - LeanIX

 

20 Fragen, die Sie mit einem Microservice-Katalog beantworten können

Poster

20 Fragen, die Sie mit einem Microservice-Katalog beantworten können

In diesem Poster werden die 20 wichtigsten Fragen angeführt, die Sie mit einem Microservice-Katalog problemlos beantworten können.

Maximize the Development Efficiency of Your Microservices Landscape with LeanIX

Webinar

Maximize the Development Efficiency of Your Microservices Landscape with..

Watch this on-demand webinar hosted by The Open Group, where LeanIX shares insights on how we can help bring order and clarity to your complex microservices architecture.

Efficiently Navigate your Microservices with LeanIX

Webinar

Efficiently Navigate your Microservices with LeanIX

Watch this interview-style webinar on how to build reliable software using a microservice catalog - including a product demo

Wie unterscheiden sich SLIs, SLOs, and SLAs?

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.

Was sind SLIs?

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:

  1. Sie ermitteln die SLIs, die die Kunden direkt beeinflussen.
  2. Sie ermitteln die SLIs, die sich direkt auf die Verfügbarkeit, Latenz oder Performance des Service auswirken.

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.

Was sind SLOs?

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.

Was sind SLAs?

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.

Gratis Poster

Erfolg in der Cloud messbar machen

Laden Sie unser Poster herunter und finden Sie heraus, ob Sie bereits über eine gute Cloud-Strategie verfügen und wie der Erfolg der Cloud-Umgebung gemessen werden kann.

Jetzt herunterladen
Poster: Erfolg in der Cloud messbar machen

 

Wie unterscheiden sich Site Reliability Engineering und Platform Engineering?

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 Vorteile von Site Reliability Engineering

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.

  • Verbessertes Reporting: SREs schaffen Transparenz, indem sie die Produktivität, den Servicezustand und die Fehlerrate überwachen und messen. Sie leiten aus Metriken konkrete Elemente ab (z.B. die durchschnittliche Ausfallzeit) und deren Verhältnis zu Einnahmeausfällen für das Unternehmen. Nachdem Bereiche mit Verbesserungspotenzial ausgemacht worden sind, können diese mit geeigneten Lösungen umgehend angegangen werden.

  • Proaktive Fehlersuche: Viele Unternehmen konzentrieren sich auf Innovation und das Deployment neuer Features, um ihrer Konkurrenz immer einen Schritt voraus zu sein. Eine schnelle Entwicklung und Bereitstellung bedeuteten jedoch auch, dass die Wahrscheinlichkeit auftretender Bugs und unentdeckter Schwachstellen größer wird. Da SREs proaktiv arbeiten, finden und beheben sie Probleme, bevor diese den Endanwender erreichen. So ersparen sie dem Unternehmen Ärger, Zeit und natürlich Geld.

  • Mehrwert: Ein zuverlässigeres System führt dazu, dass weniger Probleme behoben werden müssen. Das bedeutet, dass die Entwicklerteams mehr Zeit zur Verfügung haben, die sie bspw. in die Entwicklung neuer Features investieren können. Da SREs potenzielle Probleme ausmachen, können die Entwickler diese vor der Softwarebereitstellung beheben und so ihren Output konstant verbessern.

  • Kulturwandel: Dank Site Reliability Engineering herrscht ein umfassendes Bewusstsein für den Gesundheitszustand von Systemen und deren Schwachstellen. Die kontinuierliche Suche nach Lösungen, durch die das System optimiert werden kann, wirkt sich positiv auf alle Teams, Abteilungen und Services aus und fördert außerdem die team- und abteilungsübergreifende Zusammenarbeit. Dieser gemeinsame Verantwortungssinn verbessert nicht nur die Unternehmenskultur, sondern auch das Produkt als solches.

  • Höherer Automatisierungsgrad: Ein Site Reliability Engineer wird immer versuchen, die Workflows der Product Engineers zu modernisieren und automatisieren. Sie verbessern jedoch auch ihre eigenen Workflows. Mithilfe moderner Tools und Warnsysteme optimieren sie ihre Workflows zur Aufdeckung von Systemschwachstellen. Dadurch können Fehler schneller gefunden, markiert und behoben werden. Die Automatisierung führt somit dazu, dass das System mit der Zeit immer zuverlässiger wird.

  • Zufriedene Kunden: Während sich DevOps eher mit internen Prozessen beschäftigt, fokussieren sich SREs auf die Verbesserung der Customer und Client Experience. Mithilfe von SLAs, SLOs und SLIs setzen Site Reliability Engineers klare Ziele für die Erfüllung der Kundenerwartung. Dies resultiert in zuverlässigeren Produkten und einem deutlich verbesserten ROI.

Fazit

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.

Gratis Poster

20 Fragen, die Sie mit einem
Microservice-Katalog beantworten können

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.

Kostenlose Version herunterladen

Poster: 20 Fragen, die Sie mit einem Microservice-Katalog beantworten können

FAQ: Site Reliability Engineering

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.

EN-Cloud-Microservice-Catalog-Poster_Landing_Page_Preview

Free Poster

20 Key Questions Microservice Catalog Answers

Download