SRE:
Software Engineering
für IT-Operations

Mehr automatisierte Softwareprozesse und weniger Arbeitslast in Weiterentwicklung und Betrieb, dafür steht Site Reliability Engineering. Durch SRE, einen DevOps-Ansatz von Google, entstehen optimierte Prozesse und Systeme, die das Risiko von Fehlern berücksichtigen und damit umgehen können. Eine zentrale Rolle spielt dabei Continuous Delivery, die kontinuierliche Auslieferung vieler kleiner Releases, um das Risiko in der Entwicklung zu minimieren. 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.

Site Reliability Engineering in Kürze

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.

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.

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.

Welche Verantwortungs­bereiche 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.

Mehr als
200 Kund*innen vertrauen
ConSol in Sachen IT & Software

SRE Know-how bei ConSol

SRE-Praxistipps

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.

Site Reliability Engineering: Technologien & Kompetenzen

Thruk
OMD
Grafana
Prometheus
coshsh
Jolokia
Mod-Gearman

Mehr Tec-Know-how gewünscht?

Profitieren Sie vom Insiderwissen der ConSol-Experten und subscriben sich für unsere Mailings & Newsletter.

Newsletter abonnieren

Ihr Ansprechpartner

Marc Mühlhoff

Jetzt Kontakt aufnehmen

Durch Absenden des Formulars stimmen Sie unserer Datenschutzerklärung zu.