SREs bringen ORDER(R) ins CHAOS

Die Herausforderungen und Aufgaben Ihres vertrauten Site Reliability Engineers (SRE) im Überblick.

Von Snyk Ambassador Keith McDuffee, DevSecOps-Experte und Gründer von StackRef.com.

„Was ist der Unterschied zwischen einem DevOps Engineer und einem Site Reliability Engineer?“

Diese Frage höre ich ständig – und auch in Bewerbungsgesprächen wurde sie mir schon oft gestellt (und manchmal habe ich sie selbst gestellt). Gibt es darauf aber eine richtige Antwort? Das hängt davon ab, wen Sie fragen. Ich glaube, dass es eine Grenze gibt, aber sie ist so verschwommen, dass man die Augen zusammenkneifen muss, um sie zu erkennen.

Reden wir zunächst über SREs. Wofür sind sie verantwortlich? Was tun sie? Vor welchen Herausforderungen stehen sie Tag für Tag?

Ich werde (versuchen), hier besonders clever zu sein und ihre Verantwortlichkeiten unter dem Begriff ORDERR zusammenzufassen und ihre Herausforderungen als CHAOS.

CHAOS

Was hält SREs auf Trab und lässt sie nachts nicht schlafen? Die Herausforderungen lassen sich wie folgt einteilen:

Ausfall kritischer Komponenten

Ein Computersystem besteht aus vielen Komponenten. Dabei geht es nicht nur um Hardware. Hardware kann ausfallen – trotz Redundanzen. Aber auch Dienste und Anwendungen müssen berücksichtigt werden. Anwendungen stürzen ab, Dienste werden überlastet und Hardware fällt komplett aus.

Eingreifen durch Menschen

Fehlt eine wirksame Automatisierung, ist das so, als würde ein SRE jede Nacht um 2 Uhr geweckt, um die Zahlen 4, 8, 15, 16, 23 und 42 in eine Tastatur einzugeben. Einen Menschen aus Fleisch und Blut für Aufgaben einzuspannen, die problemlos ein Programm übernehmen könnte, führt nur zu Frust, Erschöpfung und Tippfehlern. Und wenn diese automatisierten Systeme ausfallen – was vorkommen kann –, wird es selbst zum Problem, wenn sich der Prozess nicht schnell und einfach wiederholen lässt.

Fehler im Anwendungscode

Was ein SRE tun kann, hat Grenzen. Manche können programmieren und kennen eine Anwendung in- und auswendig, aber dafür wurden sie normalerweise nicht eingestellt. Ein SRE kann jedoch dabei helfen, die Verantwortlichen ausfindig zu machen und die richtigen Engineers einzuschalten. Mit ihren Tools für Observability sollten SREs außerdem ein gewisses Maß an Voraussicht haben. Denn ohne sie tickt eine Zeitbombe, die sie erneut aus dem Schlaf reißen wird.

Probleme mit Open Source

Manchmal sind Ihre Entwickler nicht allein dafür verantwortlich, wenn Code abstürzt oder unsicher ist (auch wenn sie es im Idealfall besser wissen sollten). Viele Anwendungen basieren auf Open-Source-Abhängigkeiten – manche davon gleichen Blackboxes voller Magie und Komplexität, die kein einzelnes internes Softwareentwicklungsteam vollständig verstehen kann. Ein Modul, das in ein Projekt eingebunden wird, um eine einzelne Funktion zu ermöglichen, kann tausend weitere Komponenten hinzufügen, die gar nicht benötigt werden. Dadurch können bislang unentdeckte Schwachstellen und Performance-Probleme entstehen.

Open-Source-Abhängigkeiten sind nicht die einzigen möglichen Verursacher. Auch kostenpflichtige Komponenten von Drittanbietern können schuld sein – manchmal mit noch schlimmeren Folgen: Dann sind Sie von den Prioritäten des jeweiligen Unternehmens abhängig und nicht von denen der gesamten Community (log4j, anyone?).

Sicherheitsvorfälle

Der wahre Albtraum eines SRE. Wenn es dazu kommt, lässt sich der Vorfall entweder nicht sofort und einfach beheben, oder er bleibt länger unentdeckt, als Sie zugeben möchten. Dazu zählen auch Denial-of-Service-Angriffe (DoS): Sie sind eine Herausforderung, die es abzumildern gilt. Eine aktive, feindselige Präsenz in Ihren Systemen ist jedoch etwas ganz anderes. Als „behoben“ gilt ein Vorfall erst, wenn die akute Situation unter Kontrolle und abgeklungen ist und Sie alles, was kompromittiert worden sein könnte, wie nuklearen Abfall behandeln.

ORDERR

Ich habe es versucht – wirklich versucht –, das Ganze auf ORDER zu verkürzen. Aber die beiden letzten Rs auf der Liste lassen sich einfach nicht ignorieren oder weglassen.

Observability

Wie sollen Sie mit dem CHAOS umgehen, wenn Sie es nicht sehen können? Bei Observability geht es einfach darum, alles im Blick zu behalten – Verfügbarkeit, Performance und Aktivität.

Es reicht aber nicht, diese Informationen einsehen zu können. Für Ereignisse, die Aufmerksamkeit erfordern, braucht es umsetzbare, zuverlässige Alerts. „Umsetzbar“ und „zuverlässig“ gehören hier zusammen. Wird ein SRE nachts durch einen Fehlalarm geweckt – und häufen sich solche Fehlalarme –, kann das zu Ermüdung führen und schließlich zum „Wolf!“-Effekt: Ein Alarm wird für falsch gehalten, obwohl tatsächlich Grund zur Sorge besteht.

Auch wenn aussagekräftige, zeitnahe Alerts wichtig sind, kann sich ein SRE nicht allein darauf verlassen. Monitoring ermöglicht SREs, den Zustand laufender Systeme kontinuierlich im Blick zu behalten, und ist der erste Schritt zur Einrichtung solcher Alerts. Manche SRE-Teams nutzen Tools von Drittanbietern, andere entwickeln eigene Lösungen. Entscheidend sind das Budget und die Frage, ob es eine Lösung gibt, die zu Ihrer individuellen Situation passt.

Es gibt zu viele Tools in dieser Kategorie, um sie alle aufzuzählen. Hier sind einige Beispiele: Datadog, New Relic, ELK Stack (kann kostenlos gehostet und unterstützt werden), SolarWinds und Splunk.

Zuverlässigkeit

Ein weitreichendes Thema. Viele Faktoren können den zuverlässigen Betrieb von Systemen und Anwendungen beeinträchtigen. Von Grund auf spielt der gesamte Stack – und noch mehr – eine Rolle: Geolokalisierung, Hosting-Standort, Server und Hardware, Netzwerk, Betriebssystem, Dienste, Anwendungscode und die Bereitstellung Ihrer Dienste. Schon müde? SREs sind es.

Ich hätte hier ein „A“ für Availability ergänzen können, glaube aber, dass die Begriffe eng genug miteinander verwandt sind, um dasselbe zu meinen. Zur Zuverlässigkeit gehört, die nötigen Voraussetzungen für die Verfügbarkeit Ihrer Systeme zu schaffen: Redundanz, automatisierte und/oder manuelle Failover-Verfahren, Sicherheit und der Umgang mit Denial-of-Service-Vorfällen.

Abgesehen vom Anwendungscode sind SREs allein für die Pflege und Wartung der Systeme verantwortlich, die für die Zuverlässigkeit der Systeme einer Organisation sorgen. Beim Anwendungscode dienen SREs oft lediglich als Observability-Schnittstelle für die Softwareentwickler, die ihn geschrieben haben – sie beheben nicht selbst die Fehler. Das wird zum Teil durch statische Codeanalyse-Tools erreicht, die Probleme melden, sobald sie gefunden werden, oder durch das eingerichtete Monitoring und Logging. Sobald Probleme entdeckt werden, ist es Aufgabe der SREs, sicherzustellen, dass sie an die zuständigen Teams weitergeleitet und zeitnah behoben werden.

Tools von Snyk unterstützen Sie in dieser Kategorie.

Notfallreaktion

„Katastrophe“ ist für SREs ein weit gefasster Begriff. Er kann alles umfassen – vom Ausfall kritischer Infrastruktur bis hin zu (Gott bewahre) einem Flugzeugabsturz, bei dem Ihr leitender Software Engineer ums Leben kommt. Natürlich zählen auch alle sicherheitsbezogenen Vorfälle dazu.

Eine funktionierende Möglichkeit, auf solche Katastrophen zu reagieren, gehört zu den grundlegenden Aufgaben eines SRE. Deshalb sind verfügbare, aktuelle Runbooks – weiter unten unter E behandelt – entscheidend, denn Sie können sich nicht immer allein auf Ihren Verstand verlassen. Tabletop-Übungen und regelmäßige Tests der Notfallwiederherstellung lassen sich nur schwer in den Zeitplan einbauen. Insgesamt sind sie jedoch entscheidend, damit die Reaktion auf katastrophale Situationen schneller und besser organisiert abläuft.

Zu den kostenpflichtigen (sowie eingeschränkt kostenlos verfügbaren oder kostenlosen) Tools dieser Kategorie gehören Mattermost und PagerDuty.

Zu einer wirksamen Reaktion gehört außerdem ...

Wirksame Kommunikation

Es gibt viele Kommunikationswege, besonders wenn Teams remote arbeiten und über verschiedene Zeitzonen verteilt sind. Für problematische Situationen braucht es einen etablierten Kommunikationsweg – nicht nur das Wo, sondern auch das Wie und Wann.

Geeignete Kommunikationswege helfen SREs nicht nur dabei, den Überblick über die jeweilige Situation zu behalten. Sie tragen auch dazu bei, dass Probleme korrekt und zeitnah bearbeitet und Arbeiten nicht doppelt ausgeführt werden.

Auch die externe Kommunikation mit internen und externen Stakeholdern gehört dazu. Wird eine Anomalie festgestellt, beginnt die Kommunikation mit den internen Teams, bevor externe Kunden über Probleme informiert werden, die sich auf die Nutzung Ihrer Dienste auswirken. SREs geben den Ausschlag dafür, ob, wann und wie extern kommuniziert wird.

Einige gängige Kommunikationstools kennen Sie sicher: Slack, Microsoft Teams und Atlassian StatusPage.

Wiederherstellung

All das führt zum übergeordneten Ziel (abgesehen davon, dass nichts schiefgeht): alles wieder in einen stabilen, sicheren Zustand zu versetzen. Wie schnell das gelingt, hängt von all den genannten Faktoren ab.

• Beobachten Sie, was vor sich geht.

• Verfügen Sie über zuverlässige Failover- und Redundanzmechanismen.

• Stellen Sie sicher, dass Ihr Notfallplan befolgt wird.

• Setzen Sie auf wirksame Kommunikation.

SREs müssen eine festgelegte MTR (Mean Time to Recovery) einhalten. Das gelingt nicht mit blindem Glück. Sobald alles wiederhergestellt ist, kommt es erneut auf wirksame Kommunikation an, um die Stakeholder zu beruhigen. Für den SRE ist es damit aber noch nicht getan. Als Nächstes steht ...

Retrospektive

Wenn sich der Staub gelegt hat, können SREs eine wohlverdiente Verschnaufpause einlegen – aber nicht allzu lange. Etwas Schlimmes ist passiert. Und wenn nichts unternommen wird, passiert es wahrscheinlich wieder.

Damit sind wir wieder bei der wirksamen Kommunikation. Wir müssen verstehen, wann, was, wo, warum und wie etwas passiert ist – und außerdem was wir tun werden, um eine Wiederholung zu verhindern.

Die gewonnenen Erkenntnisse müssen zusammen mit dem Vorfall dokumentiert werden – inklusive eines Maßnahmenplans, der nicht einfach in Vergessenheit gerät. Alle zuvor genannten Punkte müssen möglicherweise angepasst werden: bessere Observability, gehärtete Systeme und mehr Sicherheit, zusätzliche Zuverlässigkeitsebenen oder sogar eine bessere Kommunikation. Anschließend müssen angemessene Fristen festgelegt werden, damit die Maßnahmen umgesetzt werden. Die SREs sollten den Verantwortlichen dabei auf die Finger schauen und sicherstellen, dass die Probleme behoben werden.

DevOps vs. SRE

Was machen also DevOps-Teams, wenn sie nicht auch als SREs arbeiten? Ich werde nicht auf alles eingehen, aber in Bezug auf SREs helfen DevOps dabei, all das zwischen SREs und Entwicklern zu ermöglichen – und stärken beide Seiten, damit sie ihre Aufgaben erfüllen können, ohne sich zu viele Dinge gegenseitig zuzuschieben. DevOps unterstützt SREs mit allem, was sie für ORDERR brauchen, um mit dem CHAOS umzugehen, und ermöglicht gleichzeitig allen, die keine SREs sind, sich im nötigen Umfang einzubringen.

Viel Erfolg da draußen …

– K