Zusammenfassung

  • RFC 9940 trennt Value, Event, Fault, Problem, Symptom, Cause, Alert und Alarm als verschiedene Objekte; die erläuternden Abläufe verleihen keinem Objekt automatisch Eingriffsgewalt.
  • Ein Alarm kann einen unerwünschten Zustand anzeigen und ein Operator kann ihn schließen, während Ursachenbefund, Servicewiederherstellung und Änderungsfreigabe getrennt nachzuweisen bleiben.

Eine Kennzahl überschreitet einen Grenzwert. Ein System bewertet die Abweichung als relevant. Eine Meldung erreicht den Bereitschaftsdienst. Das ist ein wertvoller Ablauf, solange er nicht nachträglich zu einer einzigen Behauptung verdichtet wird: „Der Fehler war die Ursache, und die Automatisierung hat den Dienst repariert.“ Jede Teilaussage benötigt andere Belege.

RFC 9940, ein im April 2026 veröffentlichtes IETF-Informational-Dokument, legt Begriffe für das Fehler- und Problemmanagement auf Netzwerkschicht und darunter fest. Es soll Datenmodelle und Managementprotokolle beim Berichten, Sichtbarmachen und Behandeln von Fehlern sprachlich ausrichten. Es ist kein Protokoll zur Ursachenfindung, kein Nachweis eines Dienstresultats und kein Mandat, ein anderes System zu ändern.

Eine Characteristic ist ein beobachtbarer oder messbarer Aspekt einer Resource, ein Value ihre Messung. Change bezeichnet die Veränderung eines Werts über Zeit; ein Event ist eine Veränderung zu einem unterscheidbaren Zeitpunkt. Eine Condition interpretiert Werte, und ein State ist die Condition einer Resource zu einer bestimmten Zeit. Zwischen Messwert und Zustand liegt damit bereits Auslegung: Abtastung, Zeitfenster, Schwelle und Perspektive sind nicht bloß Dekoration.

Relevance wird durch Policy, Perspektive, Intent und weitere Informationen bestimmt. Ein relevantes Event oder Change ist eine Occurrence. Ein Fault ist eine unerwünschte Occurrence, die auf einen jetzigen oder künftigen unerwünschten State hinweisen kann. Ein Problem ist ein unerwünschter State, der Abhilfe verlangen kann, aber nicht notwendig eine einzelne Cause besitzt. Ein Symptom weist auf ein Problem hin; eine Cause kann aus mehreren Faults, Problems und Symptoms abgeleitet oder bestimmt werden. Ein Alert zeigt einen Fault an. Ein Alarm bezeichnet einen unerwünschten Resource State, der korrigierende Aufmerksamkeit braucht.

Das bleibt wahr, wenn der Verkehr wieder normal aussieht. Das Lichtverlust-Beispiel in RFC 9940 lässt Dienste zurückkehren, während der jüngste Fault ungeklärt bleibt. Eine reparierte Mikrobiegung kann eine unmittelbare Ursache beheben und dennoch die Frage offenlassen, wie ihre Wiederkehr verhindert wird. Wiederhergestellter Verkehr ist Evidenz über einen aktuellen Zustand, keine globale Abschlussformel.

RFC 8632 formuliert die betriebliche Vorsicht ausdrücklich: Kandidaten für Root-Cause-Ressourcen sind Hinweise für den Client, keine fertige Zurechnung. Zudem unterscheidet das Modell den Alarmzustand is-cleared vom Operatorzustand closed. Ein gelöschtes beobachtetes Signal und ein als erfolgreich betrachteter Arbeitsschritt können zusammenfallen, belegen aber jeweils weder Messabdeckung noch Ursache noch die Wirkung auf alle abhängigen Dienste.

Auch Telemetrie ist nicht gleich Intent. RFC 9940 ordnet Telemetrie, Monitoring, Analytik und Observability als Kette ein und stellt klar, dass Telemetriedaten keine Dienstdefinition enthalten. RFC 9315 beschreibt Intent als deklarierte Ziele und Ergebnisse, die ein Netz nicht von selbst kennt. RFC 9417 hält Metrik, Symptom, Health Score und nicht erhebbaren Metrikwert getrennt. Ein Score kann Untersuchung priorisieren, aber nicht allein Routen entziehen, abrechnen, einen Vorfall beenden oder einem Kunden ein Ergebnis zusagen.

Daniel Kade verwendet die Wirklichkeitsebenen aus docs/heng-lu-note.md als redaktionelle Linse und nicht als IETF-Forderung. Rohwert, Schwelle und Policy, Klassifikation, Ursachenhypothese, autorisierte Entscheidung, ausgeführte Änderung und Beobachtung danach müssen getrennte Einträge bleiben. So bleibt ein Alarm schnell, ohne die ganze Beweiskette vorzutäuschen.

Quellen