Jobprofil für Cloud-native IT: der Observability Manager Wer macht Telemetrie betriebstauglich?

In verteilten IT-Landschaften reicht es nicht, Daten zu sammeln. Sie müssen verlässlich entstehen, einheitlich beschrieben sein und in den Arbeitsablauf der Teams passen. Der Observability Manager organisiert diese Voraussetzungen und entwickelt daraus ein nutzbares Betriebsmodell.

Ein neues Release durchläuft die automatisierten Tests erfolgreich, die Container starten und die Endpunkte antworten. Erst im laufenden Betrieb zeigt sich, dass eine wichtige Transaktion deutlich länger dauert als zuvor. Zwar sehen die zuständigen Teams einzelne Hinweise, doch niemand hat unmittelbar das vollständige Bild, weil ein Teil der Daten im Anwendungsteam und ein anderer im Plattformbetrieb liegt. Die Ursachenanalyse wird dadurch zu einer Suchaufgabe zwischen Zuständigkeiten.

Hier übernimmt der Observability Manager eine erste zentrale Aufgabe. Er schafft gemeinsame Regeln für Telemetrie und legt fest, welche Daten ein Service liefern muss, wie sie auffindbar bleiben und wie Teams daraus Entscheidungen ableiten.

Der Engpass liegt zwischen den Werkzeugen

Cloud-native Anwendungen verändern sich durch neue Versionen, automatische Skalierung und externe Abhängigkeiten laufend. Das Monitoring meldet, dass ein Zustand auffällig ist. Häufig fehlt jedoch die Information, welche Änderung den Zustand ausgelöst hat und welchen Teil des Services sie betrifft.

Observability verbindet Telemetrie mit dem Ablauf einer Anwendung. So lässt sich ein Fehler einer Transaktion und ihrem technischen Weg zuordnen. Das unterstützt die Root Cause Analysis, auch wenn das konkrete Fehlerbild bisher unbekannt war. Der Unterschied liegt weniger in der Oberfläche als in der Organisation der Informationen. Teams müssen Ereignisse dann nicht mehr aus isolierten Werkzeugen rekonstruieren.

Observability als Plattformleistung

Der Observability Manager definiert für die Instrumentierung ein Mindestniveau und priorisiert die abzudeckenden Anwendungen nach ihrer betrieblichen Bedeutung. Ein interner Test kann mit einer einfachen Diagnose auskommen. Für einen zentralen Kundendienst gelten höhere Anforderungen an Laufzeitdaten und Nachvollziehbarkeit.

Auch vorhandene Monitoring- und Logging-Systeme müssen in dieses Modell passen. Wo eine Konsolidierung sinnvoll ist, wird sie angestoßen. So entstehen keine weiteren Dashboards ohne gemeinsamen Zusammenhang.

Telemetrie braucht verlässliche Datenwege

Auf dem Weg vom Entstehungsort bis zur Analyse dürfen möglichst keine Lücken entstehen. Offene Standards wie OpenTelemetry unterstützen eine einheitliche Erfassung über verschiedene Technologien hinweg. Der Observability Manager legt die Regeln für Services und Umgebungen fest und prüft, ob Benennungen und Metadaten den nötigen Kontext liefern.

Fehlen diese Angaben, kann eine Plattform Signale zwar speichern, aber nur schwer zuordnen. Auch die Datenpipeline selbst gehört in die Überwachung. Ein überlasteter Collector oder eine fehlerhafte Konfiguration kann dazu führen, dass Telemetrie verspätet ankommt oder verloren geht. Der Vergleich empfangener und weitergeleiteter Signale macht solche Lücken sichtbar.

Self-Service statt zentralem Flaschenhals

Die zentrale Rolle kann nicht jede Anwendung selbst instrumentieren und jeden Alarm pflegen. Der Observability Manager stellt deshalb wiederverwendbare Vorgaben bereit, mit denen Teams diese Arbeit in Entwicklungs- und Bereitstellungsprozesse integrieren.

Dadurch erhalten Entwicklungsteams Zugang zu Laufzeitdaten und können die Auswirkungen ihrer Änderungen selbst prüfen, während Plattformteams die technischen Grundlagen bereitstellen und die Einhaltung übergreifender Standards steuerbar bleibt. Instrumentierung wird so zu einem festen Bestandteil der Architektur und der Definition of Done (DoD): Ein Service gilt erst dann als betriebsbereit, wenn sich sein technischer Zustand diagnostizieren lässt und die vereinbarten Betriebsziele messbar sind.

Alerting braucht einen Betriebsbezug

Bei der Entwicklung einer Alerting-Strategie stimmt sich der Observability Manager mit Operations und SRE (Site Reliability Engineering) über die relevanten Zustände ab. Ein einzelner Schwellwert kann ein Hinweis sein., doch für die Bewertung zählt auch die Auswirkung auf den Service. Service Level Indicators und Service Level Objectives zeigen, welche Qualität ein Dienst liefern soll und wann ein Team eingreifen muss. Ein Alarm gewinnt an Wert, wenn er auf eine erkennbare Beeinträchtigung hinweist und die erste Analyse unterstützt.

Nach einem Incident prüfen die Teams, ob die entscheidenden Signale vorhanden waren und ob sich die Ursache schnell genug eingrenzen ließ. Daraus können Anpassungen an Instrumentierung, Alerting oder Runbooks entstehen. Die Ergebnisse fließen anschließend in den Betriebsstandard ein.

Eine verbindende Rolle im IT-Betrieb

Entwicklungsteams nutzen Observability, um die Auswirkungen von Releases zu bewerten, während Operations die gewonnenen Daten für einen stabilen Betrieb benötigt. Security erhält zusätzliche Hinweise, wenn sich auffällige Zugriffe im Zusammenhang mit einer Systemänderung oder einer Störung beobachten lassen.

An den Schnittstellen klärt der Observability Manager Zugriffsrechte und Entscheidungswege. Bei automatisierten Reaktionen legen die verantwortlichen Teams fest, welche Eingriffe freigegeben sind und wann eine manuelle Entscheidung erforderlich bleibt.

KI erweitert die Analyse

KI-gestützte Observability wertet große Mengen von Telemetrie aus und setzt Auffälligkeiten in Beziehung. Kausale Verfahren beziehen Abhängigkeiten, Systemänderungen und historische Betriebsdaten ein. Nach einem Release lässt sich so prüfen, ob eine veränderte Antwortzeit mit dieser Änderung zusammenhängt.

Bei KI-gestützten Analysen entscheidet der Observability Manager, welche Empfehlungen automatisch in einen Workflow übergehen. Eine Änderung an einem kritischen Dienst braucht eine nachvollziehbare Freigabe. Historische Daten helfen, Kapazitätsengpässe und schleichende Verschlechterungen früher zu erkennen. Der präventive Betrieb entsteht, wenn daraus eine abgestimmte Reaktion folgt.

Resilienz durch wiederholbare Abläufe

Wie belastbar ein IT-Betrieb ist, zeigt sich im Umgang mit Veränderungen und Störungen. Kennzahlen zur Abdeckung wichtiger Services und zur Geschwindigkeit der Ursachenklärung machen sichtbar, ob das Betriebsmodell funktioniert. Die Einhaltung von SLOs zeigt, ob technische Qualität und Nutzererfahrung zusammenpassen.

So verbindet der Observability Manager Standards, Datenqualität und Arbeitsabläufe. Unternehmen schaffen damit eine Grundlage, auf der digitale Services kontrolliert verändert und auch unter Belastung verlässlich betrieben werden können.

Über die Autorin

Tamara Altendorf ist Regional Director Germany & Austria bei Dynatrace https://www.dynatrace.com/. Sie unterstützt Unternehmen dabei, die Komplexität moderner Cloud- und Software-Landschaften mit AI-powered Observability, Automatisierung und kontextbasierter Analyse beherrschbar zu machen.

(ID:50998054)