要約

  • Cloudflareは8月21日17時39分20秒UTC、事象xl112dfsfz6qを開き、アジア太平洋地域のネットワーク性能問題を調査中とした。17時47分56秒UTCには修正を実施し、結果を監視していると更新した。
  • BTWが19時14分34秒UTCに公開記録を取得した時点でも状態は監視中で、解決時刻は空欄だった。構造化された影響はnone、Networkコンポーネントは二つの更新で運用中から運用中のままだった。

この公表から分かるのは、Cloudflareの対応工程が8分36秒で調査から修正後の監視へ進んだことだ。顧客影響が8分36秒続いたことではない。最初の症状の時刻、修正前に影響した経路、修正と同時に正常化した経路は公表されていない。

「アジア太平洋」は観測単位として広すぎる。Cloudflareのネットワーク一覧には、アジアとオセアニアの多数の都市が載る。しかし今回の記録には都市、国、データセンター、アクセス網、ASN、ルートの名前が一つもない。地域名を母数にすれば、限定された可能性のある問題を全域の障害へ拡大してしまう。

製品も特定されていない。CDN、DNS、Workers、Zero Trust、Magic Transitなどのうち、どれが影響したかを推定する根拠はない。性能という語から、遅延、パケット損失、接続失敗、経路変動、輻輳のいずれかを選ぶこともできない。原因、変更トリガー、修正内容も非公開だ。

構造化データは、この不明点を解消しない。二つの更新はNetworkコンポーネントを関連付ける一方、状態遷移を運用中から運用中と記録している。影響フィールドはnoneだ。それでも本文は性能問題の分析と緩和、その後の修正を明記する。これは「問題がなかった」という証拠ではなく、集約コンポーネントが顧客体験の計測値ではないことを示す。

実務では、一つの経路を一つの検証単位にする。Cloudflareのトラブルシューティング文書は、coloフィールドで実際に応答したデータセンターを確認し、リクエストの各時間を測り、tracerouteやMTRで経路症状を調べるよう案内する。Origin Analyticsはオリジン応答とエッジ応答を分け、応答時間のパーセンタイルを扱う。

利用者側ネットワーク、応答したcolo、対象ホスト、エッジの結果、オリジンの結果を同じUTC窓で並べれば、故障領域を狭められる。異常がなかった別経路を対照に含めることも重要だ。地域平均では、影響した経路と正常な経路が互いを消してしまう。

この整理は過剰な帰属も防ぐ。オリジンの遅延を地域事象だけでCloudflareのせいにはできない。逆に、ある監視地点が修正後に正常化しても、全経路の回復を証明したことにはならない。観測は、その測った経路だけに効く。

確定時点では監視が86分以上続き、resolved_atは空欄だった。修正は検証の開始点であり、終了点ではない。顧客が自分の経路と取引を閉じるには、プロバイダーの状態と顧客側の証拠が一致する必要がある。

情報源