Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Ratgeber

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

(Foto: Shutterstock)

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

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.

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.

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:

  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.

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.

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

  • 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.

Bitte beachte unsere Community-Richtlinien

Schreib den ersten Kommentar!

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