Durch Site Reliability Engineering die Servicequalität steigern

Softwareentwicklung und Betrieb im engen Schulterschluss zum gemeinsamen Erfolg

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 und die Diskussionen darüber nehmen deutlich zu. Die Berichte über die Thematik haben in den USA ihren Anfang, schwappen aber allmählich nach Deutschland über. Daher wird es höchste Zeit, das Site Reliability Engineering in den passenden Kontext einzuordnen: Welchen Ursprung hat diese Disziplin, wie entwickelt sie sich, wie sieht ihr Idealzustand aus und wie kann der Begriff tatsächlich definiert werden.

Wie so oft in der IT hat das Site Reliability Engineering seinen Ursprung bei einem der großen US-amerikanischen IT-Technologie-Konzernen, nämlich bei Google LLC im Jahre 2003. Knapp fünf Jahre nach der Gründung und dem Start der gleichnamigen Suchmaschine befand man sich auf einem steilen Wachstumskurs. Der Unternehmenserfolg ist bei Google 1:1 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 benötigt dies? 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 die Position eines Site Reliability Engineers ist ein Softwareentwickler, der über tiefgehende Kenntnisse zu Infrastrukturelementen wie Betriebssystemen oder Netzwerken sowie zu den Betriebsprozessen verfügt. Das Wort „tiefgehend“ (im Sinne von „als Basis für etwas“) erhält hier eine entscheidende Bedeutung und steht für ein wesentliches Qualitätsmerkmal. So werden in den Google-Anforderungen beispielhaft Qualifikationen auf Netzwerk-Ebene eins bis drei (das sind die Ebenen Physical Layer, Data Link Layer und Network Layer) im ISO-OSI-Modell angeführt. Das trennt die Spreu vom Weizen, da ein Softwareentwickler im Tagesgeschäft häufig nur nur mit den Ebenen vier bis sieben (Transport Layer, Session Layer, Presentation Layer und Application Layer) konfrontiert ist. In vielen Fällen wird sogar darauf verzichtet und die Themen werden über eine API gelöst.

Neben den Qualifikationen des Site Reliability Engineers stellt sich die Fragen 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. Auftretenden 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. Google hat ein Regelwerk entlang seiner Wertschöpfung in einem Jahrzehnt entwickelt. Ob dies für den eigenen Anwendungsfall exakt passend ist, gilt es zu prüfen. In vielen Fällen empfiehlt sich für Unternehmen eine differenzierte Adaption 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. Hierbei werden bekannte Metriken gebildet, um die Verfügbarkeit und Fehleranfälligkeit zu berechnen und auszuwerten. Interessant sind in diesem Gebiet die Budgets für Fehler.

Wie die Erfahrung zeigt, bergen Änderungen an Bestandssystemen (Never touch a running system) 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.

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

Das 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. Wesentlich für das Site Reliability Engineering ist die Unterstützung bei der SLA-Definition durch entsprechende Messgrößen und Richtwerte sowie bei der technischen Umsetzung von Messung und Auswertung. 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 (zum Beispiel Regeltätigkeiten, Incidents) sowie zu 50 Prozent in die Optimierung der Services aufgeteilt. Tatsächlich wird diese Aufteilung überwacht (etwa im Rahmen einer agilen IT-Organisation auf Basis der Zeiterfassung und deren automatischer Auswertung), 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. Google hingegen sieht in dem Vorgehen die Chance, sich ständig zu verbessern. Dies betrifft nicht nur neue Features, sondern auch eine hohe Servicequalität. Bei der Optimierung ist Automatisierung das Rückgrat. Der hier erreichte Status folgt einer langen Historie des konsequenten Einsatzes von Automatisierung mit dem Ziel, manuelle Tätigkeiten zu eliminieren. Das ist in der heutigen Zeit nicht neu, jedoch wendet Google diesen Workflow deutlich länger so konsequent an, als entsprechende Werkzeuge an Popularität gewonnen und die breite Masse erreicht haben.

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. Tatsächlich werden viele – auch komplexe IT-Systeme – ausschließlich auf dieser groben Ebene überwacht. Beim Site Reliability Engineering liegt eine vordringliche Aufgabe darin, möglichst viele Parameter des Services zu überwachen. Die Kunst besteht darin, die Ergebnisse richtig zu interpretieren und Klarheit darüber zu erhalten, was eine wirklich betriebsrelevante Störung ist, die unmittelbare Aktivität erfordert. Die Vielzahl der Messdaten wird erhoben, um diese auf lange Sicht auszuwerten und so Vorhersagen treffen zu können. Wir berühren hier ein wenig den Bereich des Maschinellen Lernens und der künstlichen Intelligenz und wagen einen Blick in die Zukunft. Zukünftig sollten Störungen vorhersehbar sein, denn eine Vielzahl von ihnen kündigt sich über Hinweise und Warnsignale auch in der IT vorher an. In der Vergangenheit fehlten schlichtweg Kapazitäten für die Überwachung aller Sensoren und deren Auswertung. Das hat sich in der jüngsten Vergangenheit deutlich geändert und beeinflusst die Systemüberwachung.

Welche Aufgabe hat das Release Management?

Das Release Management hängt stark von der Individualisierung der betriebenen IT-Services ab. So oder so ist es integraler Bestandteil des Site Reliability Engineering. 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. Die verwendeten Werkzeuge sind miteinander kombiniert, sodass kaum Tätigkeiten manuell auszuführen sind. Für Google bedeutete dies die Entwicklung eigener Werkzeuge, da weder Open-Source-Lösungen, noch kommerzielle Produkte in den benötigten Dimensionen skalierten.

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, welche die gesamte Wertschöpfung berühren, als Kern des Site Reliability Engineering definiert werden. Bei der Lektüre einschlägiger Informationen (wie Site Reliability Engineering: How Google Runs Production Systems von Beyer, Petoff, Murphy und Jones) sieht man deutlich, wie tief sich das Thema in die DNA eines Unternehmens verankern lässt. Dabei gilt es zu beachten, dass das Google-Geschäftsmodell für diesen Ansatz ideal und die differenzierte Ausarbeitung aller Aspekte absolut rentabel ist. In den zahllosen Verwendungen des Begriffs Site Reliability Engineering findet sich oft der Vergleich mit DevOps. Der Vergleich hinkt allerdings, denn genau betrachtet ist das Thema DevOps eine Unterkategorie des Site Reliability Engineering und beschreibt nur Teile dieser Disziplin.

Für den Hausgebrauch gilt es zu prüfen, wieviel „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. Wie bei allen Veränderungsprozessen müssen alle Teams an einem Strang ziehen und sich aktiv einbringen.

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 der Perspektive der Endkunden. Durch die kontinuierliche Optimierung von Regelabläufen und Automatisierung sollen von Menschen verursachte Fehler deutlich reduziert 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.

Dieser Artikel ist vorab im  Juli 2018 im t3n-Magazin erschienen.