Verteilte IT-Landschaften brauchen mehr als gesammelte Daten. Telemetrie muss verlässlich entstehen, einheitlich beschrieben sein und in den Arbeitsablauf der Teams passen. Diese Aufgabe bündelt die Rolle des Observability Managers. Er legt fest, welche Daten ein Service liefern muss, und priorisiert Anwendungen nach ihrer betrieblichen Bedeutung. Ein Service gilt erst als betriebsbereit, wenn sich sein Zustand diagnostizieren lässt und die vereinbarten Betriebsziele messbar sind. Die Quelle nennt dafür vier Bausteine: ein Mindestniveau für die Instrumentierung, offene Standards wie OpenTelemetry für einheitliche Benennungen und Metadaten, Alarme mit Bezug zu Service Level Objectives sowie eine Nachbetrachtung nach jedem Incident. Auch die Datenpipeline gehört in die Überwachung, denn ein überlasteter Collector kann Signale verzögern oder verlieren. Aus unserer Erfahrung bei Kunden aus Versicherung und Bank beginnt die Umsetzung mit drei Schritten. Erstens benennen Sie die zehn wichtigsten Services nach betrieblicher Bedeutung. Zweitens legen Sie je Service fest, welche Telemetrie Pflicht ist. Drittens nehmen Sie die Diagnosefähigkeit in die Definition of Done auf. Wer automatisierte Reaktionen zulässt, bestimmt vorab, welche Eingriffe freigegeben sind und wann eine Person entscheidet.