Cloudflareのハンブルク障害、修正後も締め切り時点では監視中

要約

Cloudflareの表現は「この拠点を経由する」顧客を対象にしている。ハンブルクの近くにいる利用者が別拠点を通ることも、遠方の利用者がHAMを通ることもある。物理的な地域とネットワークの経路は一致しない。

したがって、ハンブルク全域、ドイツ全体、欧州全体の障害とは言えない。確認できるのは、経路によって定義された都市圏ノードの限定的な故障領域である。

影響を受けたリクエストの割合、総量、顧客数、遅延分布はない。エラーが継続的だったか断続的だったかも分からず、成功した要求と失敗した要求の比率も不明である。

「minor」は運用者によるインシデント分類で、各顧客の損失を測った値ではない。代替経路があるサービスでは小さく、HAMに依存する重要取引では大きく見える可能性がある。

15:20:19.991 UTCの最初の記録は既にidentifiedだった。Cloudflareは問題を特定して修正に取り組んでいるとしたが、装置、設定、容量、上流事業者などの対象を示さなかった。

16:58:19.585には修正を実装し、監視へ移行した。実装は変更を入れたという事実で、監視はその変更が安定して効くかを確認する段階である。正式な解決とは異なる。

Wave 45の終了は監視移行から51分13秒後だった。第一当事者のスナップショットには解決時刻がなく、状態はmonitoringのままだった。本稿が採用すべきなのはこの時点の事実である。

後に解決が公表されれば最終履歴は完成する。しかし、その情報を締め切り以前にさかのぼらせると、当時の不確実性が消えてしまう。

記録は攻撃、不正侵入、情報露出、データ破損を述べていない。ネットワーク、経路、設定、容量、提携先など多様な要因がエラーを起こし得るが、今回はどれも原因として特定されていない。

応答が失敗しても、サーバー側で処理が実行された可能性は残る。読み取りの再試行は安全でも、非べき等な書き込みは重複結果を生むことがある。これは顧客の取引記録で確かめる必要がある。

分散拠点は利用者までの距離を縮め、障害領域を小さくする。一方、特定ノードに割り当てられたトラフィックはそこで集中する。別拠点へ移れるかは、製品、経路制御、接続形態、故障の層による。

Cloudflareは経路変更、上流事業者、影響製品を公表しなかった。顧客は自身のtraceroute、BGP観測、HTTPコード、時刻を使って実際の経路を判断すべきである。

16:58:19.585 UTCの前後でエラー率を比べ、HAMから経路が変わったかを確かめ、繰り返せない操作を照合する。修正後のヘルスチェックが成功しても、以前の要求がすべて一度だけ完了したとは限らない。

解決時刻、影響製品、失敗率、トラフィック比率、迂回の説明、技術原因が出れば評価は更新できる。現段階の結論は、HAMに関係する性能問題へ修正を入れて監視していたが、固定締め切り時点ではまだ解決宣言がなかった、という範囲に限られる。