LO
制限または撤回認知の自動化2025-06-12
エラー処理もフィーチャーフラグもない変更にさかのぼる世界規模のクラウド障害が、サービスがフェイルオープンになるような設計のやり直しにつながった——提供者自身の障害報告
DevOps・プラットフォーム・SRE エンジニア職業のページ →
出来事の日付 / 報じられた日
2025-06-12 · 報じられた日 2025-06-13
証拠の段階
制限または撤回失敗、撤回、規制、あるいは費用が導入を抑えている。判断を下げる、あるいはその不確かさを広げることがある。
これが関わる業務
どう作るべきかを決める
構成を選び、受け入れる壊れ方を選び、そして二年後にもこのチームが運用できるものを選ぶ。
いまも人が主導✓ 証拠に基づく
どこに当てはまるか
多くのサービスにまたがる数時間の障害についての、クラウド提供者自身の障害報告である。根本にあった変更には適切なエラー処理がなく、フィーチャーフラグで保護されてもいなかったこと。サービスにランダム化された指数バックオフがなく、そのためある地域では復旧に最大でおよそ2時間40分かかったこと。そして対策として、機能が隔離されてフェイルオープンになるようサービスのアーキテクチャをモジュール化すること、データの複製を検証の時間をとりながら段階的に伝播させることを挙げている——と述べている。一つの会社による自社の障害の説明である。失敗した部分は通常のコードであって、AIではない。
これが意味すること
大きな仕組みが失敗したとき、効いてくる修正は設計の判断である——ここを隔離し、あそこはフェイルオープンにし、ゆっくり展開する——それを下すのは、どの失敗を受け入れるかを決める人々である。それこそ自動化が取っていかない業務である。
これがまだ示していないこと
一つの提供者による一つの障害の説明である。失敗のあと誰が設計し直したかは示すが、AIの道具がいまどれほどアーキテクチャを提案しているかは示さない。
あなたに確かめられること
Google Cloud の2025年6月12日の障害報告を開き、「We will modularize Service Control's architecture」を探すこと。
評価を変えるか
いいえ。影響指数は一件の出来事で動くことはありません。この記録が層を変えたわけでもありません——上にある1項の紐づいた判断はすべて、すでにより早い証拠の上に立っていました。この一件はそこへ足されます。
出典
Google Cloud — Service Health incident report for the Service Control outage of 12 June 2025 (13 Jun 2025 16:45 PDT Incident Report) · 検証 2026-09-29 · Claude (VOLO agent) · 解読 2026-09-29 · Claude (VOLO agent)
一次資料——これを行った当事者、あるいは記録を司る当局が公表したもの。連署は要りません。