SRE: Software Engineering für IT-Operations

Site Reliability Engineering (SRE) ist ein DevOps-Ansatz von Google. Er betrachtet IT-Operations als Softwareaufgabe, die mit Software Engineering zu lösen ist. So entstehen optimierte Prozesse und Systeme, die das Risiko von Fehlern berücksichtigen und damit umgehen können. Continuous Delivery spielt dabei eine zentrale Rolle: Das regelmäßige Ausrollen vieler kleiner Releases senkt das Risiko der einzelnen Entwicklungsschritte. Zudem werden im SRE alle Tasks so geplant, dass Zeit für Verbesserungen und die Automatisierung wiederkehrender Aufgaben bleibt.

Bei ConSol ist Site Reliability Engineering fest in den Betriebsprozessen verankert: Erfahrene Software Engineers arbeiten Hand in Hand mit dem IT-Operations-Team. Gleichzeitig bringen unsere Cloud- und Monitoring-Experten proaktiv ihr Spezialwissen ein. Denn das zentrale Ziel von SRE ist auch unseres:
Je mehr Betriebsthemen wir durch Softwarewerkzeuge und Automatisierung abdecken können, desto deutlicher sinkt die Arbeitslast in Weiterentwicklung und Betrieb. Auch auf lange Sicht.

Site Reliability Engineering in Kürze

o_workshop.svg

Was macht ein Site Reliability Engineering Team?
Ein SRE-Team setzt sich aus Software Engineers zusammen und kümmert sich um den Produktivbetrieb von Services.

o_proof.svg

Warum Software Engineers statt Sysadmins? Im klassischen Betrieb steigt die Arbeitslast linear mit der Anzahl / Größe der Services. Gerade in modernen Microservice-Architekturen ist der klassische Betriebsansatz damit nicht mehr praktikabel. Site Reliability Engineering löst Betriebsaufgaben daher mit Software und nicht manuell. Je mehr Softwarelösungen dabei zum Einsatz kommen, desto deutlicher sinkt die Arbeitslast.

o_applikationen.svg

Wie ist ein SRE-Team organisiert? Es gibt verschiedene Möglichkeiten, diese Teams zu organisieren. Google setzt auf drei Säulen: Der Anteil der Zeit, die die Site Reliability Engineers mit manuellen Aufgaben verbringen, wird begrenzt – damit haben sie Kapazität für die Entwicklung von SRE-Werkzeugen. Bereitschaftsdienste werden so professionell organisiert, dass im Fehlerfall genügend Zeit für eine gründliche Post-Mortem-Analyse ist. Error-Budgets stellen sicher, dass die Entwickler eines Service und das SRE-Team an einem Strang ziehen, wenn es um die Risiko-Einschätzung beim Go-Live neuer Features geht.

o_schulung.svg

Welche Verantwortungsbereiche hat das Team?
SRE-Teams übernehmen Verantwortung für die Verfügbarkeit, Latenz, Performance, Effizienz, das Deployment, Monitoring sowie die Emergency Response und Kapazitätsplanung der Services.

SRE-Praxis-Tipps

Endpunkte für Liveness- und Readiness-Probes sind oft sehr einfach implementiert: Sie antworten mit 200 OK, sobald die Applikation gestartet ist. Wir haben in Projekten die Erfahrung gemacht, dass das nicht ausreicht. Deshalb sind wir dazu übergegangen, mit Hilfe von Health Checks die Erreichbarkeit aller angrenzenden Systeme und Message Queues zu testen. Damit können wir Probleme bereits beim Deployment erkennen und im Idealfall automatisiert beheben.

In einem Projekt führte ein Problem mit EJB Timer Services dazu, dass die Transaktion nach jedem Lauf zurückgerollt wurde. Sofern einer der nächsten Läufe erfolgreich ist, ist dieser Vorgang an sich unproblematisch. Um herauszufinden, ob es sich um erwartete Rollbacks oder echte Fehler handelt, haben wir eine Metrik implementiert, die die Zeit seit dem letzten erfolgreichen Lauf misst. Dadurch konnten wir temporäre Fehler von dauerhaften Fehlern unterscheiden.

Bei Java Applikationen lohnt es sich, regelmäßig Thread Dumps zu ziehen. Die Thread Dumps helfen bei der Post-Mortem-Analyse und beim Profiling. Zum Beispiel bringt es die Entwicklung der Thread Dumps schnell ans Licht, wenn ein externes System blockiert ist und dadurch ständig neue Threads mit blockierten Aufrufen gestartet werden. Insbesondere ist es empfehlenswert, zwei bis drei Thread Dumps im Stopp-Script zu ziehen, um nach einem Neustart der Applikation zu analysieren, wie der Zustand zuvor war.

Logging Frameworks bieten mit dem Mapped Diagnostic Context (MDC) die Möglichkeit, Informationen wie z.B. den Usernamen standardmäßig mitzuloggen. Dadurch lässt sich bei der Loganalyse nachvollziehen, welche Logzeilen zusammengehören. Die MDC-Daten sind jedoch nicht immer verfügbar, wenn der User beispielsweise noch nicht ermittelt ist. Deshalb lohnt es sich, zusätzlich den Thread ins Logformat aufzunehmen. Der Thread bietet eine sichere und einfache Möglichkeit nachzuvollziehen, welche Logzeilen zum selben Request gehören.

In einem Projekt aus der Telekommunikationsbranche standen wir vor der Herausforderung, dass viele Microservices denselben Endpunkt aufriefen, die Gesamtzahl der Aufrufe dabei aber einen bestimmten Schwellwert pro Sekunde nicht überschreiten durfte. Dies haben wir gelöst, indem wir Zookeeper zur Koordination der Aufrufe eingesetzt haben. Der Vorteil: Wir konnten ein zentrales Koordinationssystem als Single Point of Failure vermeiden.

Manuelle Schritte beim Build und Deployment sind eine häufige Fehlerquelle. Hier lohnt es sich, alles zu automatisieren. Moderne CI/CD-Pipelines verringern nicht nur das Fehlerrisiko, sondern nehmen den SREs auch lästige wiederkehrende Aufgaben ab.

Die größte Herausforderung bei Lasttests ist das Erzeugen realistischer Testdaten. Dazu gehört nicht nur der Inhalt der Daten. In einem großen Migrationsprojekt haben wir die Erfahrung gemacht, dass sich die Art der Fragmentierung von Daten in einer Datenbank erheblich auf die Performance auswirken kann. Dass wir dies bereits in der Phase der Lasttests feststellten, war für das Projekt erfolgsentscheidend.

Je mehr Messpunkte eine Applikation hat, desto besser. Das hilft nicht nur im Betrieb. Lasttests sind beispielsweise erheblich wertvoller, wenn sie nicht nur zeigen, ob ein Service die SLOs einhält, sondern auch, wo potenzielle Bottlenecks sind.

Software Engineers verwenden gerne moderne Design Patterns wie Circuit Breaker. Um Überlast zu vermeiden, sollten Sie aber auch die klassischen Konfigurationsmöglichkeiten nicht aus den Augen verlieren. Poolgrößen in Java-Application-Servern sollten beispielsweise so ausgelegt sein, dass bei einer unerwarteten Lastspitze der Anschlag möglichst weit "vorn" erreicht wird und nachgelagerte Komponenten nicht überlastet werden.

Site Reliability Engineers müssen sich mit dem Normalverhalten ihrer Services vertraut machen und ihre Logs regelmäßig prüfen. Andernfalls geht im Fehlerfall viel Zeit dabei verloren, Merkwürdigkeiten nachzugehen, die mit der akuten Störung gar nichts zu tun haben.

Projekt-Steckbriefe

ConSol steht für technologische Exzellenz und praktische Expertise. Wir schöpfen aus drei Jahrzehnten branchenübergreifender Projekterfahrung – im Mittelstand genauso wie bei DAX-Konzernen und anderen Schwergewichten. Mit unserer Arbeit unterstützen wir Sie bei wichtigen Softwarearchitektur-Entscheidungen und stellen Ihre Lösung auf ein solides, zukunftssicheres Fundament.


Branche: Automobil

Projektinhalt: Anwendung zur Marktforschung und Absatz-Prognose von Automobilkomponenten.
Technologien: React, SpringBoot, MSSQL


Branche: Behörde

Projektinhalt:
Kundenportal einer großen Behörde zur Bereitstellung verschiedener Services für Privatpersonen und Firmen.
Technologien: Angular, SpringBoot

Branche: IT

Projektinhalt: Administrations-GUI für eine Enterprise Cloud Software.
Technologien: React

Branche: Automobil

Projektinhalt: B2B-Anwendung zum detaillierten Vergleich von Fahrzeugen und deren Ausstattungsmerkmalen.
Technologien: Angular, JavaEE, MongoDB

Branche: Telekommunikation

Projektinhalt: Klassisches customer self care Portal für einen Telekommunikationsanbieter.
Technologien: Backbone.js, SpringBoot, JWT

Branche: Behörde

Projektinhalt: Kunden-Management für eine städtische Behörde.
Technologien: Angular, Grails, CM

Branche: Automobil

Projektinhalt: Administrations-GUI für eine Anwendung zur Provisionierung von Fahrzeugen.
Technologien: Angular, JavaEE, Microservice

Branche: Telekommunikation

Projektinhalt: Anwendung zur Marktforschung und Absatz-Prognose von Automobilkomponenten.
Technologien: Microservice, Spring, REST, SOAP, Citrus


Branche: Telekommunikation

Projektinhalt: Integrationsplattform zum Austausch von Smart-Meter-Daten mit SAP.
Technologien: Weblogic, SpringIntegration, SOAP, Messaging, Citrus


Branche: Automobil

Projektinhalt: Online-Schnittstellen zur Provisionierung von Neufahrzeugen
Technologien: Microservice, REST, MQTT


Branche: Automobil

Projektinhalt: Gateway für die Fahrzeug-Internet-Kommunikation
Technologien: Microservice, REST, SOAP, MQTT, Citrus


Branche: Telekommunikation

Projektinhalt: Webbasierte Mail- und Messaging-Plattform
Technologien: SOAP, Messaging, SMS, Citrus


Branche: Telekommunikation

Projektinhalt: Online-Schnittstelle für den Datenaustausch mit Telekommunikationsanbietern
Technologien: SOAP, Spring, Citrus



Lidl
Branche: Einzelhandel

Lösung: Business-Service- und System-Monitoring auf Basis von Nagios


pbb Deutsche Pfandbriefbank
Branche: Finanzen

Lösung: End-to-End Application Monitoring mit Sakuli


it@M, zentraler IT-Dienstleister der Stadt München
Branche: Öffentliche Verwaltung

Lösung: Open Source Monitoring mit OMD


M-net
Branche: Telekommunikation

Lösung: Zukunftssicheres Monitoring auf Nagios-Basis


Kassenärztliche Vereinigung Niedersachsen (KVN)
Branche: Öffentliche Verwaltung

Lösung: Lückenloses IT-Monitoring der Serverlandschaft

Technologien / Kompetenzen

Sakuli
Thruk
OMD
Grafana
Prometheus
coshsh
Jolokia
Mod-Gearman

Ihr Ansprechpartner

Lutz Keller

Tel.: +49-89-45841-100