Anzeige
Anzeige
Ratgeber
Artikel merken

Softwareentwicklung und Betrieb: Was du über Site-Reliability-Engineering wissen solltest

Dem Begriff des Site-Reliability-Engineering begegnet man in Zeiten durchdringender Agilität und übergreifendem Denken in der IT an vielen Stellen.

Von Joachim Seidler
5 Min. Lesezeit
Anzeige
Anzeige

(Foto: Shutterstock)

Ob beim Staffing von IT-Projekten oder in Organisationsstrukturen moderner IT-Unternehmen – das Thema ist präsent. Daher wird es höchste Zeit, das Site-Reliability-Engineering in den passenden Kontext einzuordnen: Welchen Ursprung hat das Thema, wie entwickelt es sich, wie sieht der Idealzustand aus und wie die situative Normierung der Begrifflichkeit.

Anzeige
Anzeige

Wie so oft in der IT liegt der Ursprung des Site-Reliability-Engineering bei einem der großen US-amerikanischen IT-Technologie-Konzerne, hier Google LLC im Jahre 2003. Der Unternehmenserfolg ist bei Google eng mit der IT verknüpft und man suchte damals nach Mitteln, Wegen und Organisationsmodellen, um dem Wachstum gerecht zu werden. Zwar wurde und wird die klassische Trennung von Entwicklung und Service-Management (Betrieb) auch bei Google aufrechterhalten, aber man stellte sich zum Thema Service-Management folgende Frage: Wie eng sollten Softwareentwicklung und Betrieb verzahnt werden und welche Regelungsprozesse werden benötigt? Aus dieser Fragestellung und der Umsetzung der Antworten entstand das Site-Reliability-Engineering als ein neues Service-Management-Modell.

Was genau kennzeichnet Site-Reliability-Engineering?

Der typische Kandidat für diese Position ist ein Softwareentwickler, der über tiefgehende Kenntnissen zu typischen Infrastrukturelementen wie Betriebssysteme oder Netzwerke sowie Betriebsprozesse verfügt. Das Wort „tiefgehend (im Sinne von „die Basis von etwas“) erhält hier eine entscheidende Bedeutung und steht für ein wesentliches Qualitätsmerkmal.

Anzeige
Anzeige

Neben den Qualifikationen des Site-Reliability-Engineer stellt sich die Frage nach dem genauen Aufgabenfeld und den damit verbundenen Rahmenbedingungen. Grundsätzlich definiert das Site-Reliability-Engineering Teamwork für den Betrieb von IT-Systemen. Darüber hinaus gelten im operativen Tagesgeschäft zwei gleichwertige Hauptaufgaben:

Anzeige
Anzeige
  1. Sicherstellung des täglichen Betriebs
  2. Auftretende Störungen gezielt reflektieren und daraus lernen

Wie entwickeln Unternehmen das passende Regelwerk?

Was zunächst simpel klingt, setzt sich im Detail aus einem differenzierten Regelwerk mit Vorgaben und Rahmenbedingungen zusammen. Blickt man in die Einzelheiten, ist für die eigene Adaption Vorsicht geboten. In vielen Fällen empfiehlt sich für Unternehmen eine differenziertere Übertragung und die Anpassung auf die eigenen Rahmenbedingungen. Im Vordergrund eines solchen Regelwerks sollten in jedem Fall folgende Aspekte stehen:

  • Umgang mit Risiken
  • Kenngrößen für Qualität im Betriebsalltag
  • Daily Business und Optimierung von Aufgaben (inklusive Automatisierung)
  • Systemüberwachung und relevante Störungen
  • Release-Management

Wie geht man sinnvoll mit Risiken um?

Das Themengebiet Risiken betrachtet und bewertet den IT-Service im Hinblick auf seine erwartete Verfügbarkeit, seine Fehlertoleranz, den Kosten-/Nutzenaspekt entsprechender Maßnahmen zur Erhöhung von Verfügbarkeit und den Umgang mit Risikofaktoren. Interessant sind in diesem Gebiet die Budgets für Fehler. Wie die Erfahrung zeigt, bergen Änderungen an Bestandssystemen ein Risiko. Die Häufigkeit, wie oft solche Änderungen realisiert werden, ist daher unter anderem für die Stabilität und Verfügbarkeit entscheidend. Das Fehlerbudget ist eine zwischen der Softwareentwicklung und dem Betrieb (hier: Site-Reliability-Engineering-Team) vereinbarte Kenngröße für eine bestimmte Zeitperiode (zum Beispiel drei Monate). Jeder Ausfall reduziert das Fehlerbudget. Sinkt es im vereinbarten Zeitraum auf oder unter Null, werden keine Änderungen mehr in den Betrieb übernommen und der Fokus wird auf die Stabilisierung der aktuellen Version verlegt.

Anzeige
Anzeige

Weche Qualitätskenngrößen gibt es im Betriebsalltag?

Der SLA (Service-Level-Agreement) als Vertrag zwischen Nutzer und Provider wird durch Kenngrößen aus Business und Betrieb gespeist. Bei der späteren Überwachung spielen unterschiedliche Messgrößen (Indicators) und Richtwerte (Objectives) eine große Rolle. Sowohl Business als auch Technik müssen sich die jeweils andere Sichtweise und den anderen Wertehorizont vor Augen führen und sich aktiv in die Definition einbringen. Durch das gegenseitige Verständnis bekommt die Qualität somit eine übergreifende Bedeutung.

Wie funktionieren Daily Business und die Aufgabenoptimierung (inklusive Automatisierung)?

Beim Site-Reliability-Engineering ist die zur Verfügung stehende Zeit zu 50 Prozent in Tätigkeiten des Daily Business und zu 50 Prozent in die Optimierung der Services aufgeteilt. Tatsächlich wird diese Aufteilung überwacht und sie unterliegt besonderer Aufmerksamkeit. Warum ist das wichtig? Beschreibt man das klassische Bild eines IT-Betriebsteams, so erhält die Optimierung in der Regel nicht die Hälfte der Ressourcen. Bei der Optimierung ist Automatisierung das Rückgrat. Automatisierung schafft den Freiraum, sich von Regeltätigkeiten zu lösen und deren Qualität zu optimieren.

Wie erfolgt die Systemüberwachung und die Beseitigung relevanter Störungen?

Bei der Systemüberwachung denkt man oft an typische Parameter wie Auslastung, Latenzen oder Füllstände. Beim Site-Reliability-Engineering liegt eine vordringende Aufgabe darin, möglichst viele Parameter des Service zu überwachen. Die Vielzahl der Messdaten wird erhoben, um sie auf lange Sicht auszuwerten und so Vorhersagen treffen zu können. Wir berühren hier ein wenig den Bereich maschinelles Lernen und künstliche Intelligenz und wagen einen Blick in die Zukunft: Dort sollen Störungen vorhersehbar sein, denn eine Vielzahl von ihnen kündigt sich über Hinweise und Warnsignale auch in der IT vorher an.

Anzeige
Anzeige

Welche Aufgabe hat das Release-Management?

Das Release-Management hängt stark von der Individualisierung der betriebenen IT-Services ab. Zu den wesentlichen Faktoren zählen die frühe und kontinuierliche Integration in die Softwareentwicklung und das Software-Customizing. Im Site-Reliability-Engineering sind Entwicklung und Betrieb eng verzahnt. Der Einsatz von Automatisierung, Continous Development, Continous Integration und Continous Deployment gehört zum Standard. Die Hauptherausforderung besteht darin, alle Stakeholder, Tätigkeiten und Übergabepunkte in einem geschlossenen Prozess zu vereinen und in klare Abhängigkeiten voneinander zu setzen. Interessant ist die Berücksichtigung von Fehler-Budgets (siehe Umgang mit Risiken), welche den Regelprozess in einem Aspekt klar verdeutlicht.

Site-Reliability-Engineering für den Hausgebrauch

Es gibt wenige Unternehmen, die in IT-Dimensionen wie Google agieren und entsprechenden Anforderungen gerecht werden müssen. Auch sind viele Aspekte des Site-Reliability-Engineering (zum Beispiel Automatisierung, Werkzeuge, Monitoring) in vielen Unternehmen bereits etabliert. Interessant bleibt der Ansatz klarer Definitionen von Aufgaben und Kapazitäten in Kombination mit einer konkreten Teamorientierung. Davon ausgehend können etablierte Regelungsprozesse, die die gesamte Wertschöpfung berühren, als Kern des Site-Reliability-Engineering definiert werden. Bei der Lektüre einschlägiger Fachliteratur (wie Site-Reliability-Engineering: How Google Runs Production Systems von Beyer, Petoff, Murphy und Jones) sieht man deutlich, wie tief sich das Thema in der DNA eines Unternehmens verankern lässt. In den zahllosen Verwendungen des Begriffs Site-Reliability-Engineering findet sich oft der Vergleich mit Devops. Diese Komparation hinkt allerdings, denn genau betrachtet ist das Thema Devops eine Untermenge des Site-Reliability-Engineering und beschreibt nur Teile dieser Disziplin.

Für den Hausgebrauch gilt es zu prüfen, wie viel Google das eigene Geschäftsmodell verträgt. Wesentlich sind hierbei die drei Faktoren

Anzeige
Anzeige
  • Automatisierung
  • Betriebsorientierung aus der Softwareentwicklung
  • Unternehmensweite Regelprozesse

Mit der gezielten Kombination dieser drei Faktoren lassen sich signifikante Verbesserungen erzielen.

Fazit

Das Site-Reliability-Engineering kombiniert geschickt Kompetenzen der Softwareentwicklung und des Betriebs in Teams, die klar der Wertschöpfungsorientierung unterliegen. Oberstes Ziel der Teams ist die Servicequalität aus Sicht des Endkunden. Durch die kontinuierliche Optimierung der Regelabläufe und Automatisierung soll der Fehlerfaktor Mensch minimal klein gehalten werden. Unverzichtbar sind die automatischen Regelprozesse zur Beibehaltung von Qualitätsstandards.

Spannend bleibt der individuelle Prozess zur Adaption auf die jeweilige Situation im Unternehmen oder im Projekt. Die Prinzipien skalieren von Startup bis Tech-Welt-Konzern. Für den Anfang empfehlen sich kleine Schritte und die Einführung einzelner Artefakte (zum Beispiel der Regelprozess-Fehler-Budgets). Site-Reliability-Engineering hat auf jeden Fall das Potenzial, IT-Organisationen eng an die Wertschöpfung zu knüpfen und damit klar aufzuwerten.

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
Schreib den ersten Kommentar!
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Anzeige
Anzeige