要約

  • Proxy-Statusは、応答を扱った中継者と観測したエラー種別を示せるが、どの組織が障害を統率し、修復すべきかまでは示さない。
  • 配備識別子を当番、開示方針、証拠の保管先、訂正権、迂回判断へ対応させる別個の引き継ぎ表が要る。

502や504だけを見ても、利用者に分かるのは「オリジンへ至る途中で何かが失敗した」という程度だった。名前解決、接続、証明書、応答サイズの制限、中継者自身の不具合は同じように見える。RFC 9209は、この診断上の空白を埋めるためにProxy-Status応答フィールドを定義した。プロキシやゲートウェイは、要求と応答をどう扱い、どのエラーを生成または観測したかを共通の形式で伝えられる。

これは大きな前進である。ただし、診断情報を責任分担表として読むと判断を誤る。

フィールド値はHTTP Structured Fieldsのリストである。各メンバーは応答を扱った中継者を表し、オリジンに近いものから利用者エージェントに近いものへ並ぶ。メンバーは、その値を加えた配備を識別する。任意パラメーターとしてerror、next-hop、next-protocol、received-status、detailsを付けられる。単純なBad Gatewayよりは、はるかに具体的な切り分けが可能になる。

しかし、サービス名は責任を負う法人やチームの名前とは限らない。生成された文字列が一社の運用室では有効でも、取引先には意味不明なこともある。connection_timeoutは、その中継者が次の接続先へ到達しようとして時間切れを観測したことを示すだけで、応答しなかった原因、次の接続先の管理者、しきい値を変更できる者は確定しない。「中継者が生成した応答だけで起こるエラー」という分類も、メッセージの成り立ちを説明するのであって、障害指揮権を割り当てるものではない。

複数の組織が一つのHTTP経路を運用すると、この違いは決定的になる。顧客はアプリケーション事業者と契約し、その事業者は配信網を使い、配信網はゲートウェイを介して別チームのサービスへ接続する。通信経路と義務の経路は重なるが一致しない。最初に異常を観測する者が原因を直せるとは限らず、直せる者が顧客向け応答を見ているとも限らない。顧客への説明義務を負う者が、問題の区間を直接運用していない場合さえある。

RFC 9209は、開示について意図的な裁量を残す。中継者は、常時、設定時のみ、あるいは要求がデバッグ機能を有効にした場合だけ、フィールドを加えられる。フィールドも各パラメーターも任意である。全経路の診断には既存メンバーの維持が推奨されるが、内部ネットワーク情報の漏えいを防ぐため削除してもよい。セキュリティ上、構成やバックエンドの地形は攻撃者を助け得るため、一部情報は許可された相手だけに示すべきだとされる。内容そのものも検証済みとは限らない。

したがって、メンバーがないことは中継者がいなかった証明にならない。未実装、未設定、閲覧者の権限不足、下流での削除のいずれでも起こる。next-hopがないのは地形保護かもしれず、運用者の無知を意味しない。detailsは役立つ一方、実装固有であり、意図的に隠されることもある。任意の開示を完全な責任の連鎖として扱うことはできない。

応答後半の障害は境界をさらに明確にする。本文をストリーミング中に上流接続が切れれば、中継者は新しい情報をトレーラに置くしかない。RFC 9209はそれを許すが、トレーラは途中で黙って失われ得るため、ヘッダーで送れる場合の利用を勧めない。またトレーラに記す中継者は、対応するメンバーをあらかじめヘッダーにも置かなければならない。これで相対順序は復元しやすくなるが、全ての受信者がトレーラを保存し、元の要求に結び付け、停止・迂回・再試行を決められる担当者へ連絡する保証はない。

そこで必要になるのが中継障害引き継ぎ表である。Proxy-Statusを生成、保存、秘匿化、削除する各境界について、少なくとも十項目を持つべきだ。公開または限定識別子、運用法人とサービス責任者、その境界で信頼できるエラー種別と死角、各パラメーターの開示対象、当番連絡先と確認期限、応答外に残す証拠、誤った対応付けを直す権限、迂回・代替判断の責任者、顧客や上流への通知義務、最後の共同訓練日である。

表では、観測の責任と障害対象の責任を分けなければならない。配信網のメンバーにerror=connection_timeoutがあれば、発信した中継者は観測の正確さに責任を持つ。だが、次の接続先の可用性まで自動的に所有するわけではない。接続先運用者が復旧を担い、統合事業者が再試行方針を持ち、顧客向け事業者が説明を担うことがある。一つのエラートークンで並行する義務を決めてはならない。

公開識別子と問責可能な身元も階層化できる。公開応答には内部ホスト名を漏らさない安定別名を置く。契約別紙で別名を運用会社へ対応させ、当番台帳でチームと連絡経路まで解決する。監査用には、障害時点でどの版が有効だったかを残す。この構造なら秘密を守りつつ、権限を持つ対応者まで解読できない記号を避けられる。

IANAのレジストリは、パラメーターとプロキシエラー種別の共通語彙を提供する。RFC 9209は、製品固有の語より、十分に定義された汎用的な語を重視する。しかしレジストリは、個々のサービスが全種別を実装することも、発信内容が真実であることも、推奨状態コードが利用者の受け取った値と一致することも保証しない。各境界には、対応種別、ローカルなしきい値、閲覧者別の非開示項目、主張を検証する独立証拠を記した能力表が必要になる。

障害対応の自動化も「トークンからチームを引く」だけでは足りない。トークンは報告地点と条件を表し、原因判定ではない。メンバー順、エラー種別、HTTP状態、要求相関、独立した観測、現行の責任表を組み合わせ、「受領する観測者」「調査・修復する者」「顧客へ伝える者」を分けるべきだ。判別できなければ、未解決の引き継ぎとして扱う方が、根拠のない確定割り当てより安全である。

標準は障害を読めるようにした。ガバナンスは、その情報を誰がどう扱う義務を負うかという次の問いから始まる。永続的な答えがなければ、診断は速くなっても古い問題は残る。複数の当事者が同じ障害を説明できるのに、終結させる責務だけが宙に浮く。

情報源