要約

  • インシデントモデル第16版は confidence から独立する方針を明記し、第17版も原因名と関連イベントを保持しつつ、確信度や分析者の版を持たない。
  • 一方、NMOP の anomaly lifecycle と semantics は confidence、concern、annotator、version を表現する。インシデント化で両者の結合が切れることが運用上の問題になる。
  • 原因分類、信頼の強さ、緊急度、変更権限、実際の回復は別々の証拠である。自動修復には、その全てを再現できる外部レシートが要る。

夜間担当者が受け取るのは結論の形である

大量のメトリクスとアラームをそのまま人に渡しても、障害対応は速くならない。NMOP のインシデント中心モデルは、それらを少数の運用対象へまとめる。ノード、リソース、優先度、カテゴリ、推定根本原因が一つのレコードに並ぶ。

夜間担当者にとってはありがたい。だが、表示された原因が「どの程度信じられていたか」は別問題である。光レベルの規則が出したのか、履歴を学習した検出器なのか、現場の技術者なのか。検出器の版は何か。観測窓は十分だったか。別の原因候補との差はどれほどか。

draft-ietf-nmop-network-incident-yang は第15版から第16版への変更として、インシデントモデルを confidence から独立させたと記録する。第15版は、関連する anomaly detection 文書が confidence と concern を使って結果を評価すると説明していた。第16版ではその一文が削られ、アーキテクチャ上の関係だけが残った。2026年9月24日付の第17版も同じ境界を保つ。

これは「確信度は不要」という宣言ではない。共通インシデントモデルが特定の分析手法や尺度に従属しない、という範囲の選択である。

共通コアが保証するのは語彙と参照

第17版では、原因が分からない段階でもインシデントを作成できる。sources は空でよく、診断後に追加される。probable-causes はネットワーク、ノード、必要ならリソースを参照し、cause-name の identity と詳細を持つ。probable-events は関連イベントを指す。domain、priority、category は必須である。

この形は、複数の装置や管理系で原因分類を共有するために有効だ。loss of signal と routing misconfiguration を同じ自由記述として扱わずに済む。原因を特定のポートへ結び付け、関連観測へ戻る入口も保てる。

ただし、語彙の精度は認識の精度ではない。priority は急ぐべき度合いであり、正解確率ではない。category は整理の軸であって校正ではない。関連イベントは因果の十分条件ではない。型の一致は、物理状態の一致を証明しない。

文書が定義する Probable Root Cause は強い概念である。その故障条件を完全に除去すれば、進行中のインシデントが止まり再発も防げるものを指す。影響を与えただけの条件は区別される。しかし原因オブジェクトには、除去試験、再発なしの期間、反実仮想、競合仮説の項目がない。定義は意味を制限するが、個々のレコードを実験済みにしない。

上流には別の評価レコードがある

draft-ietf-nmop-network-anomaly-lifecycle-07 は、異常または検出戦略に対する 0–100 の confidence score を定義する。さらに、運用者がどれほど調査や対応を重視すべきかを示す concern score を分ける。anomaly の version と stage、annotator の ID、名称、人かアルゴリズムか、annotator version も扱う。

Detection、Validation、Refinement は循環し、最初の判断を修正可能にする。draft-ietf-nmop-network-anomaly-semantics-06 も、strategy、confidence、concern、annotator type、annotator version をシリアライズされた形で表す。例では confidence が null の場合もある。つまり、上流レコードを残すだけで確実性が生まれるわけではない。

問題は変換時の参照である。anomaly の豊かな評価情報からインシデントを作るとき、選ばれた原因だけが長期保存され、annotator の版や落選仮説が短期ストレージに残るなら、後から判断を再現できない。下流では整然とした原因名が見え、上流で付いていた留保は見えない。

情報圧縮は必要だが、中立ではない。何を耐久データにし、何を一時データにするかという統治判断だからである。

三つの数値を一つの色にしてはいけない

confidence は「異常だという判断の強さ」、concern は「サービス影響を踏まえてどれほど注意すべきか」、incident priority は「運用上どれほど急ぐか」に近い。三者は一致しない。

定期的なトラフィック変化は高 confidence でも低 concern になり得る。重要回線の弱い光信号は低 confidence でも高 concern になり得る。原因が未確定でも、影響が大きければ priority は critical になり得る。

さらに、異なる検出器の 90 は同じ意味とは限らない。基準集団、誤検知の費用、観測期間、校正方法が違う。共通コアが一つの尺度を強制しないことは、誤った普遍化を防ぐ。

その代わり、運用者は各値の生産者と意味を外部レコードに保存しなければならない。「赤」という表示だけに変換すれば、独立性ではなく忘却になる。

アクセス制御は分析を正しくしない

第17版は、安全な YANG 管理トランスポートと相互認証を求め、NACM による操作・内容の制限を示す。インシデントには顧客サービスや故障箇所が含まれ、無権限の閲覧はネットワークの弱った状態を露出するためである。

相互認証は接続相手を、NACM は操作権限を説明する。どちらも原因仮説を校正しない。正規の運用者が誤った仮説に基づいて動くことはあり得るし、高 confidence の検出器が変更権限を自動的に得るわけでもない。

したがって、自動化は少なくとも二つの承認を分ける必要がある。原因を信じる根拠と、ネットワークを変える権限である。実際にサービスが回復したかは第三の観測になる。

実装記載を拡大解釈しない

実装状況の節には Huawei iMaster NCE が挙げられ、RESTCONF、インシデントのライフサイクル管理、通知、一覧照会を実装するとされる。稼働コードに関する有用な情報である。

同じ節は、情報が寄稿者から提供され、IETF が検証しておらず、掲載が推奨を意味せず、完全なカタログでもないと明記する。凍結した資料には、confidence や annotator provenance がインシデント化の後も保持されることを示す相互運用ログ、精度測定、校正結果はない。

問うべきは「実装があるか」だけではない。どの分析版が、どの観測に基づき、どの代替仮説を退けたかを再生できるかである。

既存記事が所有する境界を越えない

既存の A Cleared Incident Does Not Prove Which Command Cleared It は、第14版の incident-resolve と後続の cleared 通知を一つの要求へ結び付けにくい問題を扱う。そこでの問いは、どの命令が状態変化を起こしたかである。

本稿の問いはその前にある。命令を選ぶ時点で、原因を信じた根拠は何だったか。完全な task ID があっても消えた confidence は戻らない。完全に校正された原因でも権限は別に要る。両者を分けることで、同じ記事を別タイトルで繰り返さない。

情報源