Site Reliability Engineering

IT-Infrastruktur wie ein Schweizer Uhrwerk

01.02.2024 von André Schindler
Schweizer Uhrwerke sind bekannt für ihre Genauigkeit und Zuverlässigkeit, dank der präzisen Ingenieurskunst, die in ihr Design und ihre Herstellung einfließt. Diese gleiche Zuverlässigkeit kann mit dem Site Reliability Engineering (SRE) gleichgesetzt werden.
Schweizer Uhren sind für ihre Genauigkeit und Zuverlässigkeit bekannt. Das gleiche gilt für das Site Reliability Engineering (SRE).
Foto: Adam Vilimek - shutterstock.com

Der Begriff des Site Reliability Engineering (SRE) wurde ursprünglich 2003 vom Google-Ingenieur Benjamin Treynor Sloss geprägt. SRE beschreibt einen Ansatz, um IT-Umgebungen effizienter, zuverlässiger und skalierbarer zu gestalten. Was kann der Channel davon lernen?

Was ist Site Reliability Engineering?

Die Ziele des Site Reliability Engineering haben viele Gemeinsamkeiten mit denen von DevOps. Beide verbinden Entwicklung und Betrieb mit dem Zweck, neue Anwendungen und Funktionen schnell zu erstellen, während Betriebsteams sich auf die Stabilität konzentrieren?. SRE fügt dieser Gleichung eine zusätzliche Komponente hinzu: Zuverlässigkeit. Aufgabe von SRE-Teams ist es, sicherzustellen, dass die Systeme immer verfügbar sind. Erreichen lässt sich das durch die Automatisierung von Aufgaben, die zuvor manuell ausgeführt wurden.

Das SRE-Mindset

Googles Verständnis von Site Reliability Engineering folgt einer analytischen Denkweise mit einem klaren Ziel: Die Lösung von Problemen mit einer entwicklungsorientierten Herangehensweise. Die Servicequalität soll zum Beispiel nicht nur allgemein gesteigert werden, sondern es soll ein Zielwert festgelegt und messbar erreicht werden. Diese Benchmarks können zum Beispiel in Service Level Agreements festgelegt werden.

Auch die Balance zwischen der Geschwindigkeit der Produktentwicklung und der Zuverlässigkeit des Systems wird mittels sogenannter Error Budgets festgelegt - eine Schwelle an akzeptabler Ausfallzeit, bei deren Erreichen die Priorität zugunsten der Sicherung der Uptime verlegt wird. Und wenn etwas schief geht, ist das Ziel des SRE-Teams, daraus zu lernen und sich zu verbessern, anstatt Schuld zuzuweisen: Blameless Postmortems dienen dazu, sich konstruktiv auf das "Warum" und "Wie" eines Vorfalls zu konzentrieren, statt auf das "Wer".

Das Einhalten dieser Prinzipien, kombiniert mit Automatisierung, verspricht folgende Vorteile:

Zum Video: IT-Infrastruktur wie ein Schweizer Uhrwerk

Drei Säulen des Site Reliability Engineering

IBM nennt drei wichtige Aufgaben, die SREs übernehmen, um die Zuverlässigkeit der Systeme zu gewährleisten: Überwachung, Protokollierung und Automatisierung.

Überwachung

Um ein System zuverlässig am Laufen zu halten, muss ein Team es natürlich im Blick behalten - und zwar in seiner Gesamtheit, zu jeder Zeit. Von der Systemlast über die Netzwerkkapazität bis hin zur Speichernutzung: Je transparenter, desto besser. Denn so können IT-Teams ermitteln, welche der Kennzahlen gerade im grünen Bereich sind und welche nicht. Automatische Alerts können Serviceteams darauf aufmerksam machen, wenn jene Kennzahlen in den gelben Bereich (wenn ein Problem auftreten könnte) oder in den roten Bereich (wenn eines aufgetreten ist) fallen. Sie ermöglicht also nicht nur die Identifizierung von bereits vorhandenen Schwierigkeiten, sondern auch die Prävention von Störungen oder Ausfällen. Wenn Teams diese proaktiv beheben, verkürzen sich entsprechend die Ausfallzeiten.

Protokollierung

Was ist passiert? Und wann? Diese elementaren Fragen und mehr beantworten Protokolldateien bzw. Logfiles, die Bestandteil einer jeden SRE-Strategie sind. Wann immer eine Systemkomponente ausfällt, ein Fehler auftritt oder etwas Unerwartetes passiert, sind die Logfiles die erste Adresse zur sogenannten Root Cause Analysis (RCA, zu Deutsch: Ursachenanalyse). Denn nur, wenn das ursprüngliche Problem diagnostiziert und behoben wird, kann es in Zukunft zuverlässig verhindert werden.

Automatisierung

Die Einrichtung, Wartung und Problembehandlung von IT-Systemen ist voll mit Routineaufgaben: das Einrichten von Servern, das Installieren von Software, das Aktualisieren von Konfigurationen, das Durchführen von Tests, das Beheben von Fehlern, das Reagieren auf bestimmte Arten von Systemereignissen… Kernidee von SRE ist es, solche Aufgaben wo immer möglich zu automatisieren. Ein Beispiel für Automatisierung könnte ein Skript sein, das eigenständig einen neuen Server einrichtet, die notwendige Software installiert und die Konfiguration anpasst, sobald der Bedarf an zusätzlicher Kapazität festgestellt wird.

Ein KMU als Fall für das SRE-Team?

Für wen sind dedizierte SRE-Teams also geeignet? Tech-Riesen wie Google und IBM sind sicher komplex und weitläufig genug aufgebaut, um ein ganzes SRE-Team zusätzlich zu ihren DevOps-Abteilungen zu rechtfertigen. Als sehr große Unternehmen profitieren sie von einem systematischen Gleichgewicht zwischen der Entwicklung neuer Softwarefunktionen und der Aufrechterhaltung der Systemstabilität.

Aber auch kleine und mittelständische Unternehmen können von der Systematik hinter SRE profitieren - ohne dieser gleich ein eigenes Team zuweisen zu müssen. Viele Funktionen zur Überwachung, Protokollierung und Automatisierung von IT-Systemen sind auch in IT-Management-Plattformen verfügbar. Mit ihnen können Systemadmins und MSPs ihre Systeme im Blick behalten, Probleme diagnostizieren und vorbeugen sowie Routineaufgaben automatisieren.

Mehr vom Autor:
Mehr Sicherheit in Cloud-Umgebungen
Managed Services-Verträge
8 Vertriebstipps für MSPs
In 6 Schritten zum Fachkräftemagneten
Microsofts New Commerce Experience
Die 4 großen Risiken für MSPs