Was ist Site Reliability Engineering (SRE)?

Site Reliability Engineers schaffen einen Mehrwert für den Kunden, indem Sie die Zuverlässigkeit der Softwareentwicklungs- und Incident Response-Lebenszyklen sicherstellen. Dies bringt verschiedene Vorteile mit sich, wie z.B.:

• Observability beim Zustand von Services: SRE-Teams sind in viele verschiedene Bereichen der Systeme eines Unternehmens involviert, was ihnen Einblicke in die Verbindung und das Zusammenspiel dieser Systeme ermöglicht. Site Reliability Engineers wissen, wie sich Metriken, Logs und Tracing-Daten über viele verschiedene Dienste hinweg verfolgen lassen, sodass sie sich ein ganzheitliches Bild vom Zustand des Systems machen können und den Kontext kennen, den sie benötigen, falls es zu einem Incident kommt.
• Engere Verbindungen zwischen Entwicklern und Operations-Teams: Site Reliability Engineers stärken die Beziehungen zwischen Entwickler und ITOps-Teams, indem sie Automatisierungsprozesse einführen und die Kommunikation optimieren, von der beide Teams profitieren. SREs sind in der Lage, Schwachstellen in der Release-Pipeline aufzudecken und zu beheben und Verantwortlichkeiten in den Bereichen On-Call-Verfügbarkeit und Incident Response zuzuweisen.
• Modernisierung der NOCs: Network Operations Centers (NOCs) haben bei der Sichtung und Weiterleitung an die richtige Person von Vorfällen und Warnmeldungen meist stark auf repetitive von Menschen ausgeführte Arbeitsvorgänge gesetzt. SRE modernisiert diese Prozesse durch Automatisierung und Machine Learning, sodass die Benachrichtigungen automatisch an die Person weitergeleitet werden, die für die Behebung des Problems zuständig ist.
• Organisation von Bereitschaftsplanung und Warnmeldungs-Workflows: Site Reliability Engineers verfügen über umfassende Kenntnisse, wenn es darum geht, effektive Bereitschaftsprozesse zu erstellen und Benachrichtigungswege zu optimieren. Sie sind in der Lage, den jeweils besten Ansatz für On-Call-Pläne und Benachrichtigungsregeln festzulegen, den optimalen Weg zu finden, um diese Warnmeldungen durch die Systeme weiterzuleiten und selbst einige der Bereitschaftsaufgaben zu übernehmen.
• Aufdeckung von Problemen im Production-Bereich: Da sie umfassend Einblick in Produktionsumgebungen haben, sind Site Reliability Engineers dafür verantwortlich, dass Systemzustände und Services überwacht werden, sodass sie Mängel erkennen können, die sich potenziell auf Kunden auswirken. Wenn diese Probleme zutage treten, können die Teams frühzeitig in der Roadmap der Produkte Gegenmaßnahmen einleiten.
• Verwaltung sämtlicher Engineering-Teams: Neben vielen anderen Dingen tragen Site Reliability Engineers zur Verbesserung, Erweiterung und Umsetzung von Best Practices und zur Unterstützung abteilungsinterner Resilienz in der gesamten Organisation bei.
  

Alle SRE-Vorgehensweisen haben die Optimierung der Systemzuverlässigkeit zum Ziel. Sie lassen sich in fünf Hauptkategorien unterteilen:

• Verfügbarkeit: Das SRE-Team ist dafür verantwortlich, die Verfügbarkeit der Systeme und Services aufrechtzuerhalten, sobald sie in Produktion gegangen sind. Zunächst legen sie Service-Level-Objectives (SLOs), Service-Level-Agreements (SLAs) und Service-Level-Indicators (SLIs) für die zugrundeliegenden Services fest. SLIs grenzen die Metriken, wie z. B. Verfügbarkeit oder Anfragelatenz, ab, die Unternehmen zum Messen der Services verwenden, die sie ihren Kunden bieten. Mit SLOs wird definiert, wie auf der Grundlage dieser SLIs die Service-Performance gemessen wird – z.B. 99,99% Verfügbarkeit. Aus beiden wird dann das SLA erstellt, in dem erklärt wird, welche Zuverlässigkeit von dem Service erwartet wird und wie das Team reagiert, wenn dieses Ziel nicht erfüllt wird. 
• Performance: Sobald sich die Verfügbarkeit stabilisiert hat, können sich die SRE-Teams auf die Optimierung der Service-Performance konzentrieren. Probleme mit der Latenz, der Seitenladegeschwindigkeit und anderen Performance-Metriken wirken sich nicht unbedingt auf die Verfügbarkeit im Ganzen aus, aber sie verstärken sich gegebenenfalls im Laufe der Zeit und verhindern letztendlich, dass die Kunden den Service nutzen können, wenn sie zu oft auftreten. SRE-Teams unterstützen Entwicklungsteams und den Anwendungs-Support, beheben Fehler und identifizieren proaktiv Performance-Probleme des Systems, indem sie sich sukzessive um kleinere Performance-Probleme und Lösungen kümmern, während sich die Service-Zuverlässigkeit insgesamt verbessert.
• Monitoring: SRE-Teams entscheiden, was überwacht wird, und wie die entsprechenden Monitoring-Lösungen implementiert werden, je nach dem wie die jeweiligen Services die Verfügbarkeit und die Performance messen. Letztendlich müssen sie eine Lösung implementieren, die den Engineering- oder IT-Teams einen ganzheitlichen Überblick über den Zustand des Systems bietet. Dies ist eine der größten SRE-Herausforderungen.
• Incident Response: SRE-Teams sind entscheidend für das Incident-Response-Management – die Mobilisierung bei einem Vorfall (nicht zu verwechseln mit dem Incident Management, bei dem es sich um das Record- und Audit-Trail-System handelt). Die Mitglieder des SRE-Teams müssen zur Verfügung stehen, um auf jegliche Incidents, die innerhalb des Systems auftreten, zu reagieren, sie zu erklären und zu überprüfen. Dies kann das Auditing von Produktions-Workflows, Prozessen, Warnkriterien und anderen Faktoren rund um die Bereitstellung beinhalten. In der Regel verwenden SRE-Teams ein On-Call-Playbook zur Koordination ihrer Reaktionen auf ein Ereignis. Ferner moderieren sie vorwurfsfreie Post-Mortem-Besprechungen, um zu ermitteln, wodurch ein bestimmtes Problem verursacht wurde, wie verhindert werden kann, dass es erneut auftritt, und um Verbesserungen zu dokumentieren, die vorgenommen werden müssen.
• Vorbereitung: Schließlich unterstützen SRE-Teams Entwicklungs- und IT-Teams, besser vorbereitet zu sein, ein besseres Verständnis für den Zustand ihrer Services zu erlangen und schnell und effektiv auf Vorfälle zu reagieren. Die Einbeziehung von Site Reliability Engineers in die Entwicklungs- und IT-Teams ermöglicht es Entwicklern, mehr über die Produktionsumgebung zu erfahren. Außerdem werden ITOps-Teams so früher in den Entwicklungszyklus einbezogen. Einen Großteil dieses Aufwands macht die Bereitstellungsvorbereitung aus, bei der in Zusammenarbeit mit den Technikern dafür gesorgt wird, dass ein neuer Service beobachtbar ist. Das Ergebnis ist ein proaktiverer, reaktionsschnellerer Ansatz im Umgang mit Zuverlässigkeitsproblemen.

SRE-Methoden erfordern über alle Dienste und Anwendungen in einem verteilten System hinweg Sichtbarkeit und Transparenz. Die Leistung und Verfügbarkeit unterschiedlicher Dienste in diesen Umgebungen zu messen, ist jedoch ein komplexes Unterfangen. Damit der Prozess besser funktioniert, hat das SRE-Team von Google die vier goldenen Signale entwickelt, eines von mehreren Frameworks für das effektive Monitoring verteilter Systeme, die Benchmarks festlegen, welche anzeigen, wann ein System gesund ist. 

• Latenz: Dies ist die Zeit bis zur Erfüllung einer Anfrage. Die Teams definieren einen Bezugswert für „gute“ Latenzraten und überwachen die Latenz erfolgreicher Anfragen vor dem Hintergrund fehlgeschlagener Anfragen, um den Zustand des Systems nachzuvollziehen. Indem sie die Latenz über das gesamte System hinweg verfolgen, können SRE-Teams ermitteln, welche Dienste ihre Leistung nicht ordnungsgemäß erbringen und Incidents früher aufdecken.
• Traffic: Hierbei handelt es sich um einen Messwert dafür, wie sehr das System durch die Benutzer oder die Transaktionen belastet ist, die den Service zu einem bestimmten Zeitpunkt durchlaufen. Indem SRE-Teams die Interaktionen echter Benutzer und den Traffic in der Anwendung oder dem Service überwachen, können sie ermitteln, wie die Kunden das betreffende Produkt erleben, während sie gleichzeitig sehen, wie sich Änderungen in der Nachfrage auf das System auswirken.
• Fehler: Dies bezieht sich auf die Rate, mit der Anfragen fehlschlagen. SRE-Teams müssen die Rate der Fehler überwachen, die im gesamten System auftreten, ein Fehlerbudget erstellen und definieren, welche Fehler kritisch sind. Dies ermöglicht es den Teams, den Zustand eines Services aus Sicht des Kunden zu beurteilen und schnell zu reagieren, um häufig auftretende Fehler zu beheben.
• Sättigung: Dies bezieht sich auf die Gesamtkapazität des Systems und der zur Verfügung stehenden Ressourcen, sodass SRE-Teams Einblick in die Kapazität eines bestimmten Services haben. Die Leistung der meisten Systeme beginnt abzunehmen, bevor sie 100% Auslastung erreichen, sodass die SRE-Teams einen Bezugswert für eine „gesunde“ prozentuale Auslastung festlegen müssen (d.h. einen Bezugswert, der die Performance des Services und seine Verfügbarkeit für die Kunden sicherstellt).

Die Rolle von SRE in DevOps-Ansätzen besteht darin, sicherzustellen dass die von DevOps-Teams entwickelten Anwendungen und Services den Endbenutzern zur Verfügung stehen, wenn sie diese brauchen. Obwohl SRE und DevOps oftmals gemeinsam diskutiert werden, handelt es sich doch um zwei unterschiedliche Disziplinen. 

DevOps ist sowohl als Praxis als auch als eine Reihe von Grundsätzen zu verstehen. DevOps als Praxis ist ein Ansatz zur Bereitstellung von IT-Leistungen, der Menschen, Methoden und Tools zusammenbringt, damit die Silostrukturen zwischen Entwicklungs- und Operations-Teams abgebaut werden können. Wie der Name schon sagt, überbrückt DevOps die Lücke zwischen Software-Development-Teams, die den Anwendungscode erstellen, und IT-Operations-Teams, die diese Anwendungen produzieren, den Endbenutzern zur Verfügung stellen und ihre Zuverlässigkeit aufrechterhalten. 

DevOps als Grundsatz, auch DevOps-Kultur genannt, ist aus der Agile-Bewegung entstanden, in deren Rahmen Grundsätze festgelegt wurden, mit denen sich Softwareentwicklungsverfahren besser durchführen lassen, wobei die Betonung hier auf schrittweiser Bereitstellung, Zusammenarbeit im Team und kontinuierlichem Planen und Lernen liegt. Indem DevOps Softwareentwicklung und IT-Operations zusammenbringt, werden Agile-Grundsätze auf den gesamten Softwareentwicklungszyklus ausgedehnt, sodass der gesamte Workflow mit dem Ziel fortwährender Verbesserung optimiert wird. Leistungsstarke DevOps-Teams können sich nicht nur über schnellere Code-Iterationen und Bereitstellungen freuen, sondern auch über insgesamt kürzere Markteinführungszeiten für neue Ideen, weniger Bugs und eine stabilere Infrastruktur.

SRE ist eine Schlüsselfunktion der DevOps-Grundsätze und ein Pendant zu DevOps als Praxis, allerdings mit enger gefassten Zuständigkeiten. Obwohl DevOps vorsieht, dass Entwickler in der Praxis ihr eigenes Produkt besitzen und betreiben – indem sie Code schreiben und damit verbundene Probleme angehen –, führt die Notwendigkeit, dauernd neue Funktionen für ihre Anwendungen zu entwickeln, oftmals dazu, dass dieses Unterfangen unmöglich wird. Site Reliability Engineers können sich einbringen und ihre eigenen Kenntnisse in den Bereichen Softwareentwicklung und IT-Operations einsetzen, um die Codeverwaltung einschließlich Bereitstellung, Konfiguration und Monitoring zu beaufsichtigen. Auf einer höheren Ebene wird die Beziehung zwischen Entwicklung und Operations dank SRE dadurch enger, dass die schnelle Bereitstellung von neuer Software und neuen Funktionen sowie die Stabilität der IT-Infrastruktur sichergestellt wird.

Ein Hauptanliegen von SRE besteht darin, überflüssige menschliche Arbeitskraft durch Automatisierungsprozesse zu ersetzen. Site Reliability Engineers profitieren von automatisierten Aufgaben aus dem Bereich Operations, wie z. B. Log-Analysen, Leistungsoptimierungen und mehr. Automatisierung ist außerdem ausschlaggebend für die Reduzierung der MTTR (Mean Time To Resolution), die Abschwächung der Auswirkungen von Ausfällen und Downtime und die Bereitstellung von erweitertem Kontext für Incident Response-Aktivitäten wie z. B. Monitoring, Warnmeldungen und Patching. 

Automatisierung ist in modernen Entwicklungsumgebungen unerlässlich, wenn Geschwindigkeit, Konsistenz, Effizienz und Anpassungsfähigkeit entscheidend sind. Am wichtigsten ist vielleicht, dass Automatisierung die Zahl monotoner, repetitiver Operations-Aufgaben reduziert, sodass sich SRE-Teammitglieder auf die Erstellung neuer Tools, die Überwachung von Infrastrukturänderungen und die Durchführung sonstiger Aufgaben konzentrieren können, die die Zuverlässigkeit erhöhen.

Effektives SRE erfordert ein umfassendes Verständnis der Systeme und ihres Zusammenspiels. Site Reliability Engineers müssen sich dem System als Ganzem annähern und seinen Vernetzungen und seinen einzelnen Komponenten dieselbe Bedeutung beimessen. Vor diesem Hintergrund können Teams SRE effektiv umsetzen, indem sie die im „Site Reliability-Workbook“ dargelegten sieben Grundsätze befolgen:

• Bei Operations geht es um die Software: Als wichtigster SRE-Lehrsatz bedeutet dies, dass die Lösung eines Softwareproblems in einem Software-Engineering-Ansatz liegt.
• Verwaltung auf der Grundlage von Service-Level-Objectives: Die Aufrechterhaltung 100%-iger Verfügbarkeit ist nicht das Ziel von SRE und Fehler sind eingeplant. Gemeinsam mit dem Produktteam arbeitet SRE an einem vereinbarten Verfügbarkeitsziel und verwaltet den Service vor dem Hintergrund dieses SLOs.
• Arbeiten, um die Anstrengungen zu minimieren: Sich wiederholende, langweilige manuelle Tätigkeiten sollten niemals zu den Standardaufgaben gehören. Alle Aufgaben und Prozesse, die automatisiert werden können, sollten auch automatisiert werden.
• Die Arbeit eines ganzen Jahres automatisiert erledigen: Festlegen, welche Aufgaben und Vorgänge automatisiert werden sollen, und eine Strategie für die Umsetzung erstellen.
• Durch Reduzierung von Ausfallkosten schnell vorankommen: Probleme frühzeitig erkennen und beheben, um die Auswirkungen für den Kunden zu reduzieren oder zu minimieren.
• Verantwortung mit Entwicklern teilen: Silos entfernen und Grenzen abbauen, sodass Entwicklungs- und SRE-Teams gleichermaßen sichtbar und verantwortlich sind.
• Unabhängig von Aufgabe und Position dieselben Tools verwenden: Ein SRE-Team kann mehrere Entwicklungsteams nicht effektiv unterstützen, wenn jedes Team seine eigenen Tools verwendet. Die Standardisierung von Toolsets ist der Schlüssel für eine erfolgreiche SRE-Praxis.
  

Site Reliability Engineers haben verschiedene Zuständigkeiten. Einige der häufigsten SRE-Rollen beinhalten:

• Entwicklung von Software zur Unterstützung von Operations- und Support-Teams: Site Reliability Engineers setzen ihre Entwicklungsfertigkeiten ein, um Software zu entwickeln und zu implementieren, die IT- und Support-Mitarbeitern hilft, ihre Arbeit besser zu erledigen. Dies kann von der Entwicklung neuer Tools über die Aufdeckung von Schwächen in der Softwarebereitstellung und die Anpassung vorhandener Monitoring-Tools bis hin zur Änderung von Code in der Produktion reichen. 
• Behebung von Problemen bei der Support-Eskalation: Anfangs verwenden Site Reliability Engineers Zeit auf die Behebung von Support-Eskalationsfällen, was mit zunehmender Systemzuverlässigkeit abnimmt. Da sie über vielfältige Fertigkeiten und Erfahrungen verfügen, haben Site Reliability Engineers das nötige Fachwissen, um Probleme an die entsprechenden Personen und Teams weiterzuleiten.
• Optimierung von Bereitschafts-Rotationsmodellen und -prozessen: Von Site Reliability Engineers wird in der Regel erwartet, dass sie während eines Vorfalls zur Verfügung stehen, was ihnen ein Mitspracherecht verleiht, wenn es darum geht, zu entscheiden, wie der On-Call-Prozess zur Verbesserung der Systemzuverlässigkeit optimiert werden kann. SRE-Teams können Warnmeldungen automatisieren und mit Kontext versehen, um die gemeinschaftliche Incident Response zu verbessern und um Runbooks und Dokumentationen so zu aktualisieren, dass Bereitschaftsteams auf zukünftige Incidents vorbereitet sind.
• Dokumentationskenntnisse: SRE-Teams sind an so gut wie allen Aspekten des Softwareentwicklungszyklus beteiligt, sodass sie traditionell sehr viel über Services und Prozesse wissen. Site Reliability Engineers können das Gelernte regelmäßig wiederholen und Runbooks führen, sodass Engineering-Teams Informationen dann erhalten, wenn sie diese benötigen – ein Vorteil, der die Möglichkeiten der Verwaltung erweitert und für Vertrauen zwischen den Teams sorgt.
• Nachbereitung von Incidents: Eine der Aufgaben der SRE-Teams besteht darin, dafür zu sorgen, dass Softwareentwickler und ITOps-Fachleute Incidents ohne Schuldzuweisungen nachbereiten, ihre Ergebnisse dokumentieren und ihre Erkenntnisse in die Tat umsetzen. Darüber hinaus sind Site Reliability Engineers für jegliche Aktionen nach einem Vorfall zuständig, bei denen es um die Entwicklung bzw. Optimierung von Teilen des Softwareentwicklungslebenszyklus oder des Incident-Lebenszyklus geht.
  

SRE ist nah an der DevOps-Bewegung ausgerichtet und auf die enge Interaktion zwischen Entwicklungs- und Operations-Teams angewiesen, sodass eine Kultur des Vertrauens, der Kooperation und der fortwährenden Verbesserung unerlässlich ist, damit ein Team erfolgreich ist.

Außerdem benötigen Site Reliability Engineers eine Kombination aus Fertigkeiten aus den Bereichen Entwicklung und Operations und müssen die herkömmlichen Softwareentwicklungs-Tools und -Vorgehensweisen kennen. Darüber hinaus ist es erforderlich, dass sie Systeme umfassend verstehen und offen für neue Wege sind, um sie immer zuverlässiger zu machen.

Letztlich erfordert SRE ein erhebliches Engagement. Es ist kein Tool oder Patch, das Sie anwenden, um ein fehlerhaftes System zu korrigieren. Es erfordert ein gewisses Maß an kultureller Veränderung, die Einführung neuer Prozesse und neuer Einstellungen zu operativen Abläufen. Wie andere Initiativen auch, kann SRE mit einem einzelnen Fürsprecher beginnen, aber ein ausgereiftes SRE-Vorgehen braucht letztendlich die Zustimmung von ganz oben.

Die Uptime aufrechtzuerhalten und zu erhöhen, ist für jedes Unternehmen mit konstantem Aufwand verbunden. Unternehmen, die über effektive SRE-Prozesse verfügen, sind ihrer Konkurrenz jedoch immer einen Schritt voraus, da ihre Systeme widerstandsfähiger sind, sodass sie einen größeren prozentualen Anteil an erfolgreichen Releases vorzuweisen haben. Wenn es zu Incidents kommt, dauern die Feststellungs- und Reparaturprozesse (MTTA/MTTR) im Durchschnitt weniger lange. Wenn die Behebung von Produktionsproblemen weniger Zeit in Anspruch nimmt, bedeutet dies, dass sich alle Teams – Entwicklungs-, SRE- und Operations-Teams – in ihren jeweiligen Disziplinen allein auf den Wertschöpfungsprozess konzentrieren können. Folglich wird Zuverlässigkeit zu einem Merkmal der Softwareentwicklung und steht ihr nicht mehr im Weg.