Observability rettet Sie nicht um 3 Uhr morgens

Die SRE-Branche erzählt sich immer wieder dieselbe Geschichte: Investieren Sie genug in Observability, und Ihre Betriebsprobleme verschwinden. Die Tool-Anbieter lieben diese Erzählung. Geben Sie ein paar Millionen Euro im Jahr für ihre Plattformen aus, und Sie bekommen "volle Sichtbarkeit". Nur ist Sichtbarkeit eben nicht dasselbe wie Behebung.

Viele Jahre in Observability und Betrieb haben mich unter anderem eines gelehrt: Observability ist ein Schritt in einem Problem aus drei Schritten, und über die anderen beiden spricht fast niemand. Die drei Schritte sind Observability, Interpretierbarkeit und Actionability.

Observability

Der Großteil der Branche stützt sich weiterhin auf die "drei Säulen" der Observability: Metriken, Logs, Traces. Sie instrumentieren Ihre Services, Sie sammeln Ihre Daten, Sie bauen Dashboards, Sie justieren Alerts. Und das kostet Sie ein Vermögen. Mit dieser Denkweise ist Observability zu einem der größten Kostentreiber im Engineering geworden. Unternehmen haben Millionen in Instrumentierung gesteckt, in riesige Datenplattformen, in Teams, die das alles betreuen.

Das Versprechen lautete stets: Mit genug Daten lösen Sie Ihre Betriebsprobleme. Genau hier bricht es zusammen. "Observability, so wie sie heute von vielen umgesetzt wird, sagt Ihnen, was Ihr System tut und ob etwas nicht stimmt. Sie sagt Ihnen nicht, warum" und was diese Daten bedeuten, wenn etwas schiefgeht. Dieser Teil bleibt an Ihnen hängen.

Interpretierbarkeit

Es ist 3 Uhr morgens, ein Alert geht los. Vielleicht gehen hundert Alerts los. Sie steigen aus dem Bett, klappen den Laptop auf, und da ist es: Millionen Log-Zeilen, 10 Millionen Metriken, Dutzende Dashboards, eine Wand aus Rauschen. Einige dieser Alerts hängen mit dem eigentlichen Problem zusammen. Andere nicht. Viel Glück dabei, das auseinanderzuhalten.

Das ist Interpretierbarkeit: von rohen Signalen dahin zu kommen, dass man tatsächlich versteht, was kaputt ist. Und das läuft fast vollständig manuell. Ihre Observability-Plattform gibt Ihnen die Daten, vielleicht eine angenehmere Query-Sprache, vielleicht eine Anomalieerkennung, die so oft anschlägt, dass ihr niemand mehr traut. Aber die Punkte zu verbinden, den Root-Cause zu finden, zu verstehen, warum das System gerade jetzt kaputt ist: Das bleibt dem Engineer überlassen. Eine Person, halb wach, unter Druck, auf der Suche nach der Nadel im Heuhaufen.

Wenn Sie Observability richtig, richtig gut umsetzen, nicht die Drei-Säulen-Variante, sondern echte event-getriebene Observability mit hoher Kardinalität und sorgfältig strukturierten Daten, kommen Sie der Lösung nahe. Ein erfahrener Engineer findet in einem gut instrumentierten System schnell den Root-Cause. Aber "erfahren" trägt hier die ganze Last, und in der Praxis erreicht fast kein Unternehmen dieses Niveau. Die meisten Teams sitzen damit fest, dass jemand dreißig Minuten bis zwei Stunden Daten durchforstet, während der Incident weiter eskaliert.

Actionability

Nehmen wir an, der Engineer findet den Root-Cause. Schön. Und jetzt?

Observability kann hier nicht helfen. Sie ist konstruktionsbedingt vollständig von den Systemen getrennt, die sie überwacht. Sie hat keine Verbindung zu den APIs, der Infrastruktur, den Deployment-Pipelines, den Konfigurations-Endpoints, an denen Sie tatsächlich Änderungen vornehmen. Ihr Dashboard kann Ihnen sagen, dass ein Pod in einer Crash-Loop hängt. Es wird das Deployment, das den Fehler ausgelöst hat, nicht zurückrollen. Ihre Logs können Ihnen eine falsche Umgebungsvariable zeigen. Sie werden sie nicht beheben.

Der Engineer muss das Observability-Tool komplett verlassen. kubectl öffnen, oder die Cloud-Konsole, oder die CI/CD-Pipeline. Die richtige Behebung herausfinden. Das Risiko einschätzen. Den Fix ausführen. Das ist Actionability, und dorthin kommt Observability nie. Sie ist dazu architektonisch nicht in der Lage.

Wo lässt uns das also stehen?

Observability erreicht Schritt drei nie. Sie kratzt kaum an der Oberfläche von Schritt zwei. Sie erzeugt zu hohen Kosten riesige Datenmengen und überlässt dem Engineer dann die schweren Teile: zu interpretieren, was die Daten bedeuten, und auf Basis dessen zu handeln, was er findet.

Wenn der Produktivbetrieb um 3 Uhr morgens kaputt ist, wollen Sie nicht Schritt eins. Sie wollen das Problem behoben haben. Sie wollen es abschließen, zurück ins Bett kommen, wissen, dass das System gesund ist. Das heißt, Sie brauchen alle drei Schritte, und Observability deckt nur den ersten ab.

In diese Richtung bauen wir bei Hyground. Wir nehmen die Flut an Signalen, die Ihr Observability-Stack ohnehin schon erzeugt, und geben Ihnen eine Deutung dessen, was wirklich falsch läuft. Einen Root-Cause. Eine Hypothese zur Behebung. Und sehr bald die Möglichkeit, diesen Fix direkt anzuwenden, oder den Engineer zumindest genau an den Punkt zu führen, an dem ein Klick das Problem behebt.

Denn am Ende interessiert es niemanden, wie viele Metriken Sie gesammelt haben. Es interessiert sie, ob das Problem behoben wird.