Definition: Methoden für zuverlässige Software und IT-Systeme Was ist Site Reliability Engineering (SRE)?

Autor / Redakteur: chrissikraus / Florian Karlstetter

Site Reliability Engineering (SRE) integriert verschiedene Methoden, die auch in der Softwareentwicklung oder bei DevOps genutzt werden, um die Zuverlässigkeit von Software gezielt auf das gewünschte Niveau zu bringen.

Firma zum Thema

Fokus auf Software-Entwicklung und Betrieb: Site Reliability Engineering beschreibt eine Vorgehensweise des Software Engineerings mit dem Ziel, hochskalierbare und zuverlässige Software-Strukturen zu schaffen.
Fokus auf Software-Entwicklung und Betrieb: Site Reliability Engineering beschreibt eine Vorgehensweise des Software Engineerings mit dem Ziel, hochskalierbare und zuverlässige Software-Strukturen zu schaffen.
(Bild: gemeinfrei © Gerd Altmann / Pixabay )

Die Zuverlässigkeit von Anwendungen und IT-Systemen ist für Unternehmen sehr wichtig, um gute, konkurrenzfähige Produkte und Dienstleistungen anbieten zu können. Diese Zuverlässigkeit sicherzustellen ist für sich allein betrachtet bereits eine Herausforderung. Wenn noch die hohe Geschwindigkeit hinzukommt, mit der der Markt heutzutage fehlerfreie Updates und kontinuierliche Innovation fordert, wächst diese Herausforderung nur noch weiter. Um dabei die Kontrolle über Qualität und Zuverlässigkeit zu behalten, bauen viele Unternehmen weltweit auf eine bewährte Methode namens Site Realiabilty Enineering.

Was bedeutet Site Reliability Engineering?

Site Realiabilty Enineering, kurz SRE, beschäftigt sich während der Entwicklung von Software, IT-Dienstleistungen und IT-Systemen damit, die Zuverlässigkeit dieser Produkte auf das gewünschte Niveau zu bringen und dort zu halten. SRE-Teams unterstützen Unternehmen mit verschiedenen Methoden dabei, dieses Ziel zu erreichen. Der Begriff „Site Realiabilty Enineering“ wurde erstmals von Ben Treynor Sloss geprägt, einem Mitarbeiter von Google. Das Konzept wird seit 2003 bei Google eingesetzt und erwies sich als so nützlich, dass es inzwischen von Unternehmen aller Art auf der ganzen Welt verwendet wird.

Warum ist Site Reliability Engineering so wichtig?

SRE dient also dazu, dass die IT-Produkte eines Unternehmens einen Grad an Zuverlässigkeit erreichen, der einerseits der Sache und den Anforderungen angemessen ist und andererseits langfristig auf diesem Niveau gehalten werden kann. Das alles hat den Zweck, dass man Kunden und Endanwendern ein Produkt anbieten möchte, auf das sie sich im Alltag verlassen können. Denn ein unzuverlässiges System oder eine Software, die regelmäßig unerwartete Fehler produziert, findet bestenfalls dann Akzeptanz, wenn es wirklich gar keine Alternativen gibt. Wahrscheinlicher ist, dass unzuverlässige Produkte und Dienstleistungen dem Unternehmen nachhaltig schaden, z. B. indem es durch verärgerte Kunden einen schlechten Ruf bekommt und so Kunden und Einnahmen verliert.

Perfekte Zuverlässigkeit ist jedoch schwer zu erreichen und nur in den wenigsten Systemen wirklich erforderlich, z. B. bei medizinischen Anwendungen oder in der Raum- und Luftfahrt. In den meisten anderen Szenarien wäre es geradezu verschwenderisch, nach Perfektion zu streben. Damit ein System zu 100 Prozent zuverlässig arbeitet, muss viel Zeit, Arbeit und Geld investiert werden. Das ist ein Aufwand, der nur selten im Verhältnis zum wirklich benötigten Grad an Verlässlichkeit steht. SRE verfolgt daher einen pragmatischen Ansatz, um eine gute Balance aus Anforderungen und Möglichkeiten im Unternehmen zu erreichen.

Welche Methoden kommen für Site Reliability Engineering zum Einsatz?

SRE nutzt viele Methoden, die man bereits aus der Softwareentwicklung kennt. Zudem hat der Ansatz viele Ähnlichkeiten zu Methoden, die für DevOps genutzt werden. Die wohl deutlichsten Unterscheide zu DevOps sind, dass SRE Zuverlässigkeit als oberste Priorität ins Zentrum aller Aufgaben stellt und Vorgaben verbindlicher befolgt werden müssen. Gemeinsamkeiten zu DevOps sind Aufgaben wie kontinuierliche Überwachung und die Automatisierung bestimmter Prozesse.

Eine wichtige Methode, die SRE nutzt, sind positive Kreisläufe. Dabei werden Ziele definiert, Methoden, diese zu messen, festgelegt. Daraus ergibt sich eine ungefähre Kenngröße für die Toleranz von Fehlern. Teil positiver Kreisläufe ist auch der Umgang mit Fehlern.

SLO und SLI

SRE definiert für jede Anwendung, wie genau die angemessene Zuverlässigkeit aussehen muss. Das „Service Level Objective“ (SLO) gibt an, wie zuverlässig ein Dienst funktionieren muss, damit er den Vorgaben entspricht. Das könnte z. B. bedeuten, dass eine Anwendung zu 70 Prozent erfolgreiche Ergebnisse innerhalb eines vordefinierten Zeitfensters liefern muss. Um festzustellen, ob diese Ziele und damit die gewünschte Zuverlässigkeit erreicht werden, verwendet man „Service Level Indicator“ (SLI). Das sind Messpunkte, die dann z. B. Aufschluss darüber geben, wie viele Anfragen erfolgreich verlaufen und wie viele dieser erfolgreichen Antworten das vorgegebene Zeitfenster einhalten. So kann eine qualifizierte Aussage getroffen werden, ob die SLOs erreicht werden oder ob und an welcher Stelle es Verbesserungsbedarf gibt.

Fehlerbudgets

Updates bringen neue Funktionen, verbessern bestehende Funktionen und schließen Sicherheitslücken. Ein Problem hierbei ist, dass Entwickler nicht unendlich viel Zeit einplanen können, um vor jedem neuen Release jede erdenkliche Situation lückenlos abzudecken. Und wie bereits erwähnt ist perfekte Zuverlässigkeit ohnehin nur selten notwendig oder angemessen.

SRE arbeitet mit dem Grundsatz, dass in jedem System ein gewisses Budget für Fehler vorhanden ist. Dieses errechnet sich aus der theoretisch möglichen Zuverlässigkeit von 100 Prozent abzüglich der tatsächlich angewandten Zuverlässigkeit und bezieht sich in der Regel auf einen festgelegten Zeitraum, z.B. einen Monat. Am Beispiel von oben würde das Fehlerbudget also 30 Prozent betragen (100%- minus 70%). Damit wäre es akzeptabel, wenn die entsprechende Funktionalität eine Fehlerquote von bis zu 30 Prozent aufweisen würde.

Solange die SLOs zufriedenstellend erfüllt sind, muss also mit dieser Vorgehensweise keine Zeit und kein Geld damit verschwendet werden, einem theoretischen Idealzustand hinterherzujagen. Erst wenn das Fehlerbudget verbraucht ist, entsteht ein direkter Handlungsbedarf und es muss nachgebessert werden, z.B. indem ein Release zurückgehalten wird, um die Zuverlässigkeit zu verbessern.

Ohne Schuldzuweisung aus Fehlern lernen

Bei schwerwiegenden Fehlern ist es grundsätzlich ratsam, dass die Ursachen für diese Fehler im Nachhinein gründlich analysiert werden. So kann man aus diesen Fehlern neue Erkenntnisse gewinnen und im Idealfall vermeiden, dass ähnliche Fälle in der Zukunft auftreten. Das Besondere bei SRE ist, dass diese Analysen in einem positiven Rahmen stattfinden sollen. Statt eine Person oder ein Team für den Fehler verantwortlich zu machen, soll das Problem selbst und dessen Ursachen im Mittelpunkt stehen. Man fragt also nicht "Wer hat Schuld an diesem Fehler?", sondern "Welche Umstände führten dazu, dass dieser Fehler passieren konnte?".

Dadurch können Umstände wie fehlende Informationen oder unzureichende betriebliche Prozesse aufgedeckt werden, die das Entstehen dieses Fehlers mit herbeigeführt haben könnten. Es soll niemand für den Fehler bestraft werden, sondern eine Möglichkeit gefunden werden, diesen in Zukunft durch geeignete Maßnahmen zu verhindern. So kann das gesamte Unternehmen durch Fehler wachsen und die Zuverlässigkeit Ihrer Produkte nachhaltig verbessern.

Microservices, Cloud Native, REST API , Kubernetes & Co.: Cloud Computing Wiki

Definitionen rund um Cloud ComputingVon AWS bis XaaS: Alle relevanten Schlagworte aus dem Bereich Cloud Computing finden Sie verständlich erklärt in unseren Definitionen. Ganz im Sinne eines kleinen, aber feinen Glossars lesen Sie hier neutral verfasste und leicht verständliche Erklärungen zu den wichtigsten Begriffen. Als Service für Sie haben wir die hier erklärten Begriffe in unseren Beiträgen auch direkt mit den zugehörigen Lexikoneinträgen verlinkt. So können Sie die wichtigsten Erläuterungen direkt dort nachschlagen.  

Zum Special: Definitionen rund um Cloud Computing

(ID:47079822)