要約

  • RFC 9940 は Value、Event、Fault、Problem、Symptom、Cause、Alert、Alarm を異なる管理対象として定め、関係を示しても自動的な救済権限を与えない。
  • アラームの解除や担当者によるクローズは、原因、サービス全体の回復、次の変更を行う権限とは別の記録である。

画面の色が変わり、通知が届く。それは一つの特性の値が変化し、方針に照らして重要だと判断されたことを意味し得る。そこで「故障が障害を起こし、自動化が直した」と言い切ると、観測、分類、因果、権限、結果という別々の問いを一つに折り畳んでしまう。

RFC 9940 は、2026 年 4 月に公開された IETF の Informational 文書であり、ネットワーク層以下の障害・問題管理の用語を整える。故障や問題を報告・可視化・管理するデータモデルや管理プロトコルの共通理解が目的である。原因を発見するプロトコルでも、回復を証明するプロトコルでも、他の系に変更を命じる仕組みでもない。

まず Characteristic は Resource に属する観測可能または測定可能な側面であり、Value はその測定である。Change は値の時間的変化、Event は区別できる時点での変化をいう。複数の値を解釈したものが Condition、ある時点に Resource が持つ Condition が State である。値から状態への移行には、すでにサンプリング、時間窓、閾値、視点という解釈が介在する。一つの損失値だけで、サービスの劣化状態は確定しない。

さらに Relevance は方針、視点、意図、ほかの情報に依存する。関連すると見なされた Event または Change が Occurrence であり、望ましくない Occurrence が、望ましくない現在または将来の State を示し得る Fault となる。Problem は補正が必要になり得る望ましくない State で、必ずしも一つの Cause に結び付かない。Symptom は Problem を示し、Cause は複数の Fault、Problem、Symptom から示唆または決定され得る。Alert は Fault の表示、Alarm は是正注意を要する望ましくない Resource State の表示である。

復旧らしく見える瞬間こそ、この区別が重要になる。RFC 9940 の光損失の例では、サービスは戻っても最近の Fault は未説明のままであり得る。マイクロベンドを修理すれば一つの原因は処理できるが、再発を防ぐ問題は残り得る。「今は正常に流れている」は現在の状態についての重要な証拠であって、履歴や原因の不確実性を消す文言ではない。

RFC 8632 も運用上の境界を明示する。root-cause-resource の候補はクライアントへのヒントであり、確定した帰属ではない。また is-cleared と担当者の closed は別である。前者は観測条件が消えたこと、後者は担当者が是正作業を成功と考えたことを表す。どちらも単独では、測定範囲、原因、依存サービスすべての結果を証明しない。

テレメトリを意図と取り違えることもできない。RFC 9940 はテレメトリ、監視、分析、可観測性を連鎖として扱い、テレメトリのデータ自体はサービス定義の intent を含まないとする。RFC 9315 の intent は宣言的な目標と結果であり、ネットワークが提供者の意図を自動的に知るわけではない。RFC 9417 も metric、symptom、health score、収集不能な metric を分ける。スコアは調査の優先順位に役立っても、経路撤回、請求、事故の終結、顧客への約束を単独で許可しない。

Daniel Kade は docs/heng-lu-note.md の現実層という考え方を、IETF の要件ではない編集上のレンズとして用いる。元の値、閾値と方針、分類、原因仮説、承認済みの決定、実施した変更、変更後の観測を別々に残す。そうすれば、速い通知を、完全な証拠の代用品にしないで済む。

出典