要約

  • draft-ietf-opsawg-rfc5706bis-06 は、新しいプロトコル、拡張、またはその利用を定めるIETFストリームの新規RFCに「Operational Considerations」節を求める提案である。Best Current Practiceを想定した活発なInternet-Draftであり、承認済みRFCではない。
  • 専用の節は、導入、移行、監視、障害、性能、セキュリティ運用、ツールを設計段階で議論させる。しかし、実装の運用可能性を認証せず、個々の事業者に代わって残余リスクを受諾することもない。
  • 重大な導入では、仕様とは別に事業者が管理する「運用可能性の決定票」が必要だ。未解決事項ごとに、適用範囲、検証結果、監視条件、切り戻し、担当者、見直し日、受諾権限を結び付ける。

あるプロトコル拡張の文書には、必要なことがかなり率直に書かれていた。混在バージョンで状態が曖昧になる。診断ツールはまだそろっていない。監視要求が集中すると管理プレーンを圧迫する可能性がある。設計レビューは、運用上の論点を十分に扱ったと評価した。

一方、本番導入票には「運用上の考慮事項を確認済み」としかない。採用製品が必要なカウンターを実装しているか、試験規模が本番のピークに届いたか、切り戻しが状態を保持するか、誰が顧客影響を受諾できるかは分からない。

前者は共通仕様についての判断であり、後者は特定のネットワークについての決定である。両者を一つにすると、文書の著者やレビュー担当者が、見たこともない本番環境の承認者にされてしまう。

運用の問いを本文の端から救い出す

OPSAWG草案の第06版はRFC 5706を置き換え、RFC 2360に残るMIB必須という古い考え方を更新しようとしている。管理を一つのデータ形式へ縮めず、導入、設定、観測、障害分離、移行、性能、セキュリティ運用、会計、ツールを含む全体として扱う。

新しいプロトコルや拡張、その使い方を技術的に規定するIETFストリームのRFCには、関連するYANGモデルも含め、専用節を置く。手続、方針、管理事務の文書まで一律に対象とする案ではない。節はSecurity Considerationsの直前が推奨され、読者が探しやすく、存在を機械的に検出しやすい配置とされる。

調査時点のDatatrackerでは、文書は活動中のInternet-Draftだった。ワーキンググループ状態はSubmitted to IESG for Publication、IESG状態はPublication Requestedで、telechatの日付は表示されていない。Best Current Practiceは予定する到達点であって、現在の資格ではない。

それでも、節を定位置にする効果は大きい。運用課題は、知識がないからではなく、設計文書のどこにも置き場がなく後回しになることがある。見出しがあれば、移行経路、異常時の挙動、観測できない状態、設定ミス、規模上限を早い段階で問いやすい。

この制度が生むのは可視性である。可視性は統治の材料だが、統治の最終行為ではない。

網羅性を装わないことが草案の強み

草案は、運用上の問題をすべて列挙するとは言っていない。固定的な解決策、特定の管理プロトコル、正式なデータモデルも一律には要求しない。相互運用可能な管理方式が不要だとワーキンググループが判断する余地もある。ただし、単なる見落としではなく、意図した判断として記録する必要がある。

内容が大きければ別文書に置き、仕様本体には短い概要と規範的参照を残すこともできる。また、運用手段や支援ツールがすべて完成するまで仕様の発行を待つ趣旨でもない。設計時に合理的に予測できる範囲を書き、実地経験からしか得られない知識があることを認める。

この柔軟性は正しい。世界中の設備構成、サービス契約、監視能力、法的義務を一つのワーキンググループが先回りして解決することはできない。すべてを待てば標準化は止まり、すべてを想像で埋めれば文書の信頼性が下がる。

ただし、柔軟である以上、「検討した」は「解決した」ではない。「文書にある」は「導入してよい」でもない。公表に十分な説明と、本番で受け入れ可能な残余リスクは、異なる主体が判断する。

「新しい要件はない」という出口の読み方

新しい管理・導入上の考慮事項がない場合、草案はその旨と短い理由を節に書くよう求める。何も書かない場合と、検討したうえで差分がないと結論した場合を区別できる点は有用だ。

拡張が基礎プロトコルの監視、警報、復旧をそのまま利用できるなら、この結論は妥当かもしれない。しかし、本番でそれを言うには、採用実装が機能を備え、有効化され、想定規模で働くことを確認しなければならない。基礎機構が存在することと、手元の製品・設定で利用できることは同じではない。

したがって「新規要件なし」は「残余リスクなし」を意味しない。草案自身も、ガイダンス文書であり新しいプロトコル、拡張、アーキテクチャを定義しないため新規の運用要件はない、と自らの節で述べる。これは文書の作用範囲についての説明で、ネットワークの安全証明ではない。

導入票には、継承したどの機構を、どの版で、どの証拠によって確認したかを残す必要がある。理由が短くても、ローカルな確認まで省略してよいわけではない。

実運用は、過去の合理性に有効期限を与える

草案に登場するBGPフラップダンピングの例は象徴的だ。頻繁な経路変動を抑えるための仕組みだったが、実装のメモリー制約やパス探索によって誤った抑制が生じ、到達性を失う場合があった。大規模運用で初めて現れた挙動もあり、多くの場所でネットワーク全体には有効化されなかった。

設計者がすべてを予言できなかったという非難ではない。導入時の受諾を永久化してはいけないという教訓である。規模、実装、障害、観測手段が変われば、以前の判断を開き直す必要がある。

現代的な論点も同じだ。OAMやテレメトリーの負荷は管理プレーンを圧倒し得るため、レート制御を考える。セキュリティ運用にはログ、監査証跡、アクセス制御、フォレンジック用ツールが要る。AIを使う管理機能は機器やコントローラーへ高頻度で強い問い合わせを送る可能性がある。仕様は問題の型を示せるが、設備の余力、問い合わせ密度、保存義務、自動判断の誤りが生む損害は各事業者しか測れない。

「スケーラブル」という語だけでは、件数も時間も破綻時の姿も分からない。

レビューと受諾を同じ印章にしない

草案は、著者、ワーキンググループ、OpsDir、PERFMETRDIR、さらに広いコミュニティを利用者として想定する。著者は設計を説明する。グループは共通仕様を議論する。各ディレクトレートは典型的な問いが扱われたか確かめる。IESGは発行要求を審査する。実装者は機能を作る。運用者は特定版を特定サービスへ入れる。

好意的なレビューは、レビュー担当者へサービス責任を移さない。RFCになっても、製品に推奨ログが存在する証明にはならない。適合試験が移行全体を覆うとは限らず、小規模な試行は全地域の展開を承認しない。

この線引きはIETFも守る。IETFは本番の構成、負荷、契約、規制上の責務を見ていない。各ネットワークの遠隔変更委員会になるのではなく、共通の判断材料を提供する役割にとどまる方がよい。

運用可能性の決定票に残すもの

重大な導入については、仕様の実質的な論点ごとに、事業者が次を記録する。

  • 問題、前提、または未解決点と、それを示す文書の箇所
  • 製品、版、有効な機能、依存関係、対象サービス、許可する範囲
  • ローカルな故障経路、観測可能な結果、影響を受ける利用者
  • ラボ、試行、本番の証拠と、試験が対象外とした条件
  • 監視する健全性指標、容量しきい値、イベント発生率
  • 切り戻しまたは隔離の手順、発動条件、最後に動作確認した時点
  • 課題担当者、サービス責任者、残余リスクを受諾できる人物または機関
  • 決定、条件、異論、発効日、有効期限
  • 草案改訂、ソフト更新、規模超過、事故、新しいツールなど再審査の契機
  • 後の経験が当初の前提を覆した場合の訂正履歴

処置も分ける必要がある。「解決」は定義した条件を証拠が満たすこと。「延期」は作業を残しつつ範囲を制約すること。「受諾」は権限者が残りの影響を引き受けること。「非該当」は対象にその機能や依存がない理由を示すことだ。「確認済み」という一語では区別できない。

決定票は秘密の構成情報や会話全文を保存する必要はない。後から見た人が、当時の知識、許可範囲、判断理由を復元できる最小限でよい。

IETFの提案を第二の承認制度にしない

逆方向の過剰も避けたい。各事業者の署名権限、リスク選好、変更手続までIETF文書に定めさせれば、草案の柔軟性を損なう。

共通仕様は問いを持ち運べるようにし、答えは結果に近い場所へ残す。小規模な事業者は一枚の記録で済むかもしれない。重要インフラなら独立試験、段階導入、厳格な受諾権が必要だろう。形式は違っても、一般的な設計知識からローカルな撤回可能な決定への接続は示せる。

これはHeng Luが論じる、最小限の初期仕様と、その後の地域・主体別の判断を分ける発想にも合う。協調は最終決定の集中を必要としない。標準は設計時に見えることを記録し、運用者は確認したこと、未確認のこと、前へ進む責任者を記録する。

運用上の懸念を正しく書くことは重要だ。しかし、その見出しの下に、他人の受諾署名まで現れることはない。

出典