要約

  • Cloudflare は11時51分07秒 UTC、軽微・調査中としてインシデント pgcdxsjxkl0q を開始した。
  • 固定締め切りの11時53分12秒時点では Analytics が性能低下で、復旧情報はなかった。
  • 最初の通知は Dashboard と関連 API でリクエスト失敗やエラー表示の可能性を示した。
  • キャッシュ済みファイルの CDN 配信とその他の Edge セキュリティ機能は影響外とされた。
  • 後続更新で API、Dashboard、Pages、Workers ビルドへ範囲が広がり、12時43分57秒に監視へ移った。
  • 13時01分59秒に解消したが、原因、顧客数、地域別の影響は公表されていない。

最初の2分間に分かったこと

本稿のニュース窓は11時53分12秒に閉じた。開始から2分05秒後であり、当時の確定情報は Analytics の低下と調査開始だった。

監視や解消はその後の出来事である。最終状態を追記しても、締め切り時点で復旧が見えていたかのようには扱えない。

この時間管理が、速報と事後記録を混同しないために必要になる。

既存ページは動いても変更できない

Cloudflare はキャッシュ配信とその他の Edge セキュリティ機能を影響外と明記した。一方、Dashboard や API のリクエストは失敗する可能性があった。

利用者にはサイトが見えていても、運用者は設定変更や状態確認ができない場合がある。可用性は一枚岩ではない。

DNS や全 API、全セキュリティ機能の停止を示す記録もない。

12時37分にビルド影響が加わった

12時25分44秒、API と Dashboard も性能低下として表示された。12時37分35秒には Pages と Workers のビルドへの影響が公表された。

最終記録は、ビルド障害が11時51分から始まっていたとは記していない。後から確認された範囲を開始時点へ遡及させるべきではない。

部品ごとの正確な影響時間には、なお不明部分が残る。

デプロイ待ちが業務影響を左右する

直前の正常なビルドが配信され続ければ、閲覧者は変化に気づかない可能性がある。しかし新しいデプロイ、修正、ロールバックは遅れる。

平常運転のサイトと、緊急修正中のサービスでは同じ障害時間の意味が異なる。

失敗リクエスト率、ビルド件数、顧客層は公表されず、総影響を金額換算できない。

復旧は確認されたが原因は残った

修正は12時43分57秒に監視へ移され、12時46分20秒にも監視継続が通知された。13時01分59秒に解消となった。

Analytics、API、Dashboard、Pages、Workers は operational へ戻った。顧客側で必要な作業や技術的原因の説明はない。

サービス状態の回復と、原因の説明責任は別の段階である。

制御面だけを失う事態に備える

構成情報をバージョン管理し、重要指標を Dashboard 外にも保持すれば、管理画面への即時依存を抑えられる。

また、エッジ配信障害と制御面障害で手順を分ける必要がある。観測できないだけなのに正常なトラフィックを切り替えれば、二次障害を招く。

原因、エラー率、失敗ビルド数、遅れた分析データの補完状況が次の確認点となる。現在の根拠が示すのは、約70分の管理・ビルド系障害と、エッジのキャッシュ配信が維持されたという境界である。

出典