グーグルは、6月12日（現地時間）に発生した同社のクラウドサービスにおける障害について、詳細なレポートを公開した。障害は太平洋夏時間（PDT）の6月12日午前10時51分（日本時間6月13日午前2時51分）に始まり、同日午後6時18分（日本時間6月13日午前10時18分）に完全に終息。約7時間半にわたり、「Google Cloud」および「Google Workspace」の複数製品に影響を及ぼした。
影響は全世界に、日本リージョンも障害発生
今回の障害は、無効な設定情報が全世界のリージョンに伝播したことで発生したため、影響はグローバルに及んだ。日本のユーザーが利用する東京リージョン（asia-northeast1）や大阪リージョン（asia-northeast2）も例外ではなく、同様に障害の影響を受けた。これにより、多くの顧客が外部APIリクエストで503エラーの増加や管理コンソールへのアクセスが断続的にできない状態に陥った。
原因と復旧の経緯、米国中部では遅延も
障害の根本的な原因は、グーグルのAPI管理システムに対する自動化された割り当ての更新が無効な値を含んでいたことにある。同社は障害を検知後、問題となっていた割り当てチェックをバイパスする措置を講じた。この対応により、日本を含むほとんどのリージョンでは、障害発生から約2時間でサービスが回復に向かった。しかし、米国中部リージョン（us-central1）では、復旧プロセス中に割り当てポリシーのデータベースが過負荷状態になったため、他リージョンよりも回復に長い時間を要する結果となった。なお、既存のストリーミングやIaaSリソース自体への影響はなかったとしている。
再発防止へ向けた多角的な改善アプローチ
グーグルは今後の改善策として、複数の具体的なアプローチを箇条書きで明らかにしている。これらの対策を通じて、将来的な同様のインシデントの再発を防止するとしている。
・システムのモジュール化と障害時の処理継続：主要なシステム（Service Control）の構造を、機能ごとに独立した部品（モジュール）のように分割。これにより、一部のチェック機能で障害が発生してもシステム全体が停止せず、APIリクエストの処理を継続できるような、より堅牢な設計を目指す。
・データ更新の段階的な適用と検証：全世界のシステムに設定情報を反映させる際、一度に展開するのではなく、段階的に適用するプロセスを徹底。各段階で問題がないかを検証する時間を設けることで、万が一異常があった場合でも、影響が広がる前に早期発見を可能にする。
・新機能の安全な導入（フィーチャーフラグの徹底）：システムの中核部分に重要な変更を加える際は、新機能をデフォルトで「オフ」の状態にし、安全が確認された後に「オン」に切り替えられる仕組み（フィーチャーフラグ）を徹底。これにより、リスクのある変更を安全に管理し、問題発生時には即座に機能を無効化できるようにする。
・開発段階での品質向上：プログラムコードの自動解析（静的解析）やテストのプロセスを改善し、開発のより早い段階で潜在的なエラーを正確に検知・修正できる体制を強化する。
・システム過負荷時のアクセス制御の徹底：障害からの復旧時などにアクセスが殺到し、さらなる障害を引き起こすことを防ぐ。そのために、アクセスが失敗した際の再試行の間隔を徐々に長くし、タイミングを分散させる仕組み（ランダム化された指数的バックオフ）が、すべてのシステムで確実に採用されているか監査・徹底する。
・顧客への迅速かつ正確な情報伝達：障害発生時、顧客が必要とする情報を迅速かつ正確に提供できるよう、自動通知システムと担当者によるコミュニケーションの両面を改善する。
・障害時でも途切れない情報インフラの確保：Google Cloudの主要サービスが停止している最中でも、障害状況を伝える監視システムやコミュニケーション基盤自体は問題なく稼働し続ける体制を確保し、顧客の事業継続性を支える。
