SRE: Site Reliability Engineering

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.