{"id":52942,"date":"2023-08-08T12:05:11","date_gmt":"2023-08-08T10:05:11","guid":{"rendered":"https:\/\/www.skaylink.com\/?p=52942"},"modified":"2024-04-08T12:58:27","modified_gmt":"2024-04-08T10:58:27","slug":"sitereliability-engineering","status":"publish","type":"post","link":"https:\/\/www.skaylink.com\/de\/insights\/blog\/sitereliability-engineering\/","title":{"rendered":"Site Reliability Engineering"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Home<\/a><\/span><\/span><\/p>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t
\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Blog<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Site Reliability Engineering<\/h1>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t
\n\t\t\t\t\t
\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t8. August 2023\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\n\t\t\t
\n\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\n\t\t\t\t\t\t\tJohann Ingibergsson\t\t\t\t\t\t<\/span>\n\t\t\t\t\t<\/div>\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Mit SRE ein perfektes Gleichgewicht zwischen Agilit\u00e4t und Stabilit\u00e4t erreichen<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Wenn Sie einen kundenorientierten Ansatz f\u00fcr Ihre L\u00f6sungen w\u00fcnschen, sollten Sie hierf\u00fcr Methoden wie Site Reliability Engineering (SRE) in Betracht ziehen.<\/span>\u00a0<\/span><\/p>

Wir bei Skaylink konzentrieren uns verst\u00e4rkt auf DevOps und es ist uns ein Anliegen, Aufgaben kundenorientiert zu l\u00f6sen. Unser vorrangiges Ziel besteht darin, die Interessen von Entwickler*innen und Betriebsverantwortlichen unter einen Hut zu bringen \u2013 auch dann, wenn es Konflikte gibt (beispielsweise der Wunsch nach neuen Funktionen ohne Einschr\u00e4nkungen, der dem Widerwillen, etwas in einem gut funktionierenden System zu \u00e4ndern, gegen\u00fcbersteht).<\/span>\u00a0<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Site Reliability Engineering<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Google hat SRE entwickelt und ver\u00f6ffentlicht, um die eigenen gro\u00dfen Systeme verwalten zu k\u00f6nnen. Die Grundlagen und Vorgehensweisen von SRE als technisches Werkzeug wurden allerdings von vielen weiteren Unternehmen \u00fcbernommen, um den zuverl\u00e4ssigen Betrieb ihrer Software-Systeme zu verbessern. SRE beschreibt grunds\u00e4tzlich eine Reihe an Vorgehensweisen und Grundlagen, mit denen Software Engineering und Betrieb miteinander verkn\u00fcpft werden. Mithilfe von Automatisierung, \u00dcberwachung, Vorfallsbearbeitung und kontinuierlicher Verbesserung werden die Zuverl\u00e4ssigkeit, die Leistung und die Verf\u00fcgbarkeit von komplexen Software-Systemen sichergestellt.<\/span>\u00a0<\/span><\/p>

Site Reliability Engineering unterst\u00fctzt Unternehmen bei der nachhaltigen Gestaltung des zuverl\u00e4ssigen Betriebs ihrer Systeme. Dabei ist es wichtig, ein gutes Gleichgewicht zwischen Agilit\u00e4t und Stabilit\u00e4t im jeweiligen Unternehmen zu erreichen.<\/span>\u00a0<\/span><\/p>

\u00a0<\/span>Die SRE-Teams betreuen folgende Bereiche:<\/span>\u00a0<\/span><\/p>

Verf\u00fcgbarkeit \/ Stabilit\u00e4t \/ Latenzzeit \/ Leistung \/ Effizienz \/ Change Management \/ \u00dcberwachung \/ Notfallbearbeitung und Kapazit\u00e4tsplanung der Dienste<\/span><\/b>\u00a0<\/span><\/p>

Damit sich das Team auch bei Gro\u00dfprojekten um diese Bereiche k\u00fcmmern kann, haben wir uns das Ziel gesetzt, alle repetitiven Aufgaben zu automatisieren oder ganz zu streichen. Das SRE-Team konzentriert sich verst\u00e4rkt darauf, dass das Systemdesign zuverl\u00e4ssig funktioniert, und zwar auch dann, wenn h\u00e4ufige Updates von Entwicklerteams eingespielt werden.<\/span>\u00a0<\/span><\/p>

Damit sich das SRE-Team auch auf ein sich in Entwicklung befindliches System einstellen kann, muss eine umfangreiche \u00dcberwachung des Systems m\u00f6glich sein. Daf\u00fcr m\u00fcssen ausreichend Daten im System gespeichert werden, die f\u00fcr ausf\u00fchrliche Untersuchungen genutzt werden k\u00f6nnen. Auf diese Weise kann das SRE-Team laufend neue User-Flows beurteilen und projektkritische Prozesse \u00fcberwachen.<\/span>\u00a0<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Agilit\u00e4t oder Stabilit\u00e4t<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In der Vergangenheit sorgte die Diskrepanz zwischen Entwicklung und stabilem Betrieb h\u00e4ufig f\u00fcr Konflikte. Man war sich nicht einig, was nun f\u00fcr Kunden wichtiger ist: Agilit\u00e4t, um neue Funktionen einf\u00fchren zu k\u00f6nnen, oder die Aufrechterhaltung der Stabilit\u00e4t in einem System.<\/span>\u00a0<\/span><\/p>

Mit dem SRE-Konzept k\u00f6nnen wir dieses Dilemma genauer betrachten. Dazu nutzen wir Service Level Indicators (SLIs), Service Level Objectives (SLOs) sowie das sich daraus ergebende Fehlerbudget.<\/span>\u00a0<\/span><\/p>

Die SLIs dienen der \u00dcberwachung von wichtigen User-Flows, beispielsweise bei einer IoT-L\u00f6sung. So kann es vorkommen, dass Benutzer*innen einen Sensor installieren und in einem Administrationspanel best\u00e4tigen, dass dieser aktiv ist. Zu den SLOs geh\u00f6ren Regeln bez\u00fcglich der von den Benutzer*innen erwarteten Latenzzeit, Verf\u00fcgbarkeit und Fehlerspanne.<\/span>\u00a0<\/span><\/p>

Das SRE-Team und das Unternehmen k\u00f6nnen die SLOs f\u00fcr einen gemeinsamen Austausch nutzen und so eine Einigkeit bez\u00fcglich konkreter Zahlen f\u00fcr Betriebsbereitschaftszeiten und Leistung erlangen. Die Differenz zwischen den gemessenen SLIs und den vorgegebenen SLOs wird Fehlerbudget genannt. Ist die Leistung besser als vereinbart, d\u00fcrfen die Entwicklerteams neue Funktionen so oft sie m\u00f6chten einf\u00fchren. Sobald das Budget aber negativ ausf\u00e4llt, ist das SRE-Team daf\u00fcr verantwortlich, s\u00e4mtliche Neueinf\u00fchrungen zu stoppen, das Problem zu analysieren und St\u00f6rfaktoren zu beseitigen \u2013 oder alternativ dem Entwicklerteam die Aufgabe zu erteilen, diese zu entfernen. Grunds\u00e4tzlich bedeuten negative SLOs bei einem Projekt, dass man sich verst\u00e4rkt auf die Qualit\u00e4t konzentrieren muss. Der Interessenkonflikt zwischen Betrieb und Entwicklung kann entsch\u00e4rft werden, indem man sich danach richtet, ob die vereinbarten SLOs positiv oder negativ ausfallen.<\/span>\u00a0<\/span><\/p>

Um das Fehlerbudget genauer definieren zu k\u00f6nnen, m\u00fcssen wir festlegen, wie viel \u201eInstabilit\u00e4t\u201c innerhalb eines vereinbarten Zeitraums zul\u00e4ssig ist. Dieser Begriff ist wichtig, denn s\u00e4mtliche Implementierungen bergen ein Risiko f\u00fcr Instabilit\u00e4t. Selbst die gr\u00f6\u00dften Unternehmen, wie z.\u202fB. Microsoft, bringen manchmal Neuerungen heraus, die trotz aller Tests und Best Practices mit einem Systemausfall enden.<\/span>\u00a0<\/span><\/p>

Vielleicht wirft man dem SRE-Team vor, dass es sich nur auf den User-Flow konzentriert, anstatt auch auf die Verf\u00fcgbarkeit und Antwortzeit zu achten. Dabei kann der User-Flow aber auch aus einer gesch\u00e4ftlichen Perspektive wie Einnahmen oder K\u00fcndigungen (Verlust von Kunden) gesehen werden. Betrachten wir dazu das folgende Beispiel, bei dem wir eine Machine-Learning-L\u00f6sung f\u00fcr die Benutzerempfehlungen verwenden.<\/span>\u00a0<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In der Abbildung ist eine Pipeline dargestellt, die Benutzeraktivit\u00e4ten und w\u00f6chentliche K\u00e4ufe als Grundlage nutzt und diese f\u00fcr die Aktualisierung einer\u00a0<\/span>Machine<\/span>-Learning-L\u00f6sung f\u00fcr Empfehlungen kombiniert. F\u00e4llt diese Pipeline aus, st\u00fctzt sich die L\u00f6sung auf veraltete Daten.\u00a0<\/span>Eventuell ist der*die Benutzerin\u00a0<\/span>an den\u00a0<\/span>Empfehlungen e<\/span>ventuell gar nicht mehr interessiert. Dies\u00a0<\/span>kann<\/span>\u00a0die Einnahmen eines Unternehmens nach und nach beeinflussen. In einem solchen Fall k\u00f6nnten die Konsequenzen f\u00fcr das Unternehmen aus sinkenden Konvertierungsraten beim Verkauf oder einem gr\u00f6\u00dferen Verlust an Kunden bestehen. Daher m\u00fcssen diese\u00a0<\/span>User-<\/span>Flows<\/span>\u00a0eines Unternehmens unbedingt \u00fcberwacht werden.<\/span><\/span>\u00a0<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Die Bedeutung der SRE-orientierten Teams<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Es ist nicht wichtig, viele SLOs zu definieren, sondern es geht vielmehr darum, die richtigen SLOs festzulegen.<\/span>\u00a0Ein guter Hinweis darauf, ob ein SLO relevant ist oder nicht, ist: \u201eWenn Sie eine Diskussion bez\u00fcglich der Priorisierung eines bestimmten SLO nie gewinnen, ist es wahrscheinlich nicht so wichtig, das SLO zu behalten.\u201c<\/span>\u00a0<\/span><\/p>

Ein SRE-Team kann f\u00fcr ein Unternehmen gro\u00dfen Mehrwert bedeuten, da Unternehmensanforderungen standardisiert und in einen Code verpackt werden k\u00f6nnen. Das SRE-Team besteht aus Entwickler*innen, die Infrastruktur, CI\/CD-Pipelines und Unternehmensfunktionen verbessern.<\/span>\u00a0<\/span><\/p>

F\u00fcr uns hat das SRE-Team u.\u202fa. kontinuierlich strukturelle Verbesserungen des Projekts bewirkt und so Mehrwert geschaffen. Auf diese Weise k\u00f6nnen andere Entwicklerteams auch rascher Ergebnisse erzielen, denn die daf\u00fcr ben\u00f6tigten technischen Anforderungen, die das gesamte Projekt betreffen, werden von einem daf\u00fcr vorgesehenen Team bereitgestellt. Bei verschiedenen Projekten hat unser SRE-Team bewiesen, dass es Mehrwert generieren kann. Es hat Belastungstests durchgef\u00fchrt, SLOs \u00fcberwacht und als CoE-Team fungiert sowie fachbereichs\u00fcbergreifende Funktionen f\u00fcr Entwicklerteams implementiert. Dadurch konnten wir Probleme und Engp\u00e4sse identifizieren, noch bevor sie f\u00fcr die Benutzer*innen zum Problem wurden.<\/span>\u00a0<\/span><\/p>

Der wichtigste Arbeitsbereich eines SRE-Teams besteht letztendlich darin, dass jeder unbeabsichtigte Vorfall sofort identifiziert und priorisiert werden kann. Das bedeutet aber nicht, dass immer das SRE-Team das urs\u00e4chliche Problem l\u00f6sen muss. Dieser Teil der Arbeit kann an andere Teams abgegeben werden. Aber nat\u00fcrlich wird man sich vorrangig darauf konzentrieren, die Situation so schnell wie m\u00f6glich zu l\u00f6sen und sicherzustellen, dass alles funktioniert. Dabei sollte stets die zuk\u00fcnftige Entwicklung und nicht das R\u00fcckg\u00e4ngigmachen der \u00c4nderungen priorisiert werden, um die Agilit\u00e4t des Projektes zu bewahren.<\/span>\u00a0<\/span><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Wie beginnt man am besten?<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Um noch einmal zu unterstreichen, welchen konkreten Mehrwert SRE-Teams liefern k\u00f6nnen, m\u00f6chte ich die folgenden 3 Punkte zusammenfassen:<\/span>\u00a0<\/span><\/p>