10 月 26 日には、初期報告をもとに Google Cloud のロンドンにある europe-west2-b ゾーンを停止させた停電をお伝えしました。11 月 4 日、Google Cloud はステータスページに最終的なインシデント報告を掲載し、根本原因を初期報告よりはるかに具体的に説明しました。最終報告によると、主な影響は 6 時間 8 分以内に解消されました（初期報告では 6 時間 10 分）。

根本原因：保守中の構成とセンサーの位置

  • この施設は 2N の商用電源構成です。独立した 2 系統の商用電源 A と B があり、その後ろに高圧発電機群があって、二重化されたプログラマブルロジックコントローラー（PLC）が管理しています。UPS のバッテリーはおよそ 5 分もち、その間に PLC が電圧低下を検知し、ディーゼル発電機を起動・同期させて負荷を切り替える設計です。
  • 10 月 14 日の四半期ごとの発電機負荷試験で問題が見つかり、B 系統を修理するためにその遮断器が開かれ、施設は一時的に商用電源 1 系統（1N）の保守状態となって、A 系統だけで重要負荷をすべて支えていました。
  • 太平洋時間 10 月 19 日 22:53（英国夏時間 20 日 06:53）、施設外の電力網の地下ケーブル故障で A 系統が停止しました。PLC の電圧低下の検知は各系統の遮断器の上流につながれていました。B 系統の遮断器は開いていたものの、その上流は通電していたため、同じロジックで動く稼働系と待機系の PLC はどちらも「健全な商用電源がある」と判断し、発電機に起動を指示しませんでした。現場のチームが PLC 経由で遠隔の負荷切り替えを試みましたが、同じ読み取り値によって阻止されました。
  • 遠隔操作を立て直す前に UPS が尽きると判断したチームは、施設を予備の商用電源に切り替えましたが、切り替えの途中でバッテリーが尽き、データホールは電源を失いました。

復旧に 6 時間かかった理由

  • 時刻はすべて英国夏時間です。07:00 に影響が始まり、07:54 に予備の商用電源が復旧、08:20 にデータホールの電源が戻り、08:40 にクラスターが復旧を始め、08:45 にネットワーク機器が戻りました。
  • 時間がかかったのはストレージです。突然の停電で多数のストレージ機器が正常にシャットダウンできず、08:50 から復旧が始まりましたが、対応チームは状況を悪化させかねないサービスの復旧をあえて控えました。機器の数が多く時間がかかり、ストレージが十分に復旧したのは 11:13 で、11:45 から段階的にトラフィックを戻しました。
  • 12:11 に Google Cloud のサービスと API がすべて利用可能になり（一部の GCE 仮想マシンはまだ戻っていませんでした）、12:29 にプラットフォームの中核的な障害が終わり、13:08 には GCE 仮想マシンの 99.5% が正常で新規作成も可能になり、15:03 に終了通知が出されました。
  • 他の 2 つのゾーンも影響を受けました。停止したゾーンへのゾーン間呼び出しがタイムアウトし、フェイルオーバーで移ってきた負荷が残りのゾーンのコンピューティング容量を圧迫して、リージョン全体で断続的な 500 と 503 のエラーが出ました。

Google の対策と、自分のサーバーへの教訓

Google の対策には次のようなものがあります。PLC は 10 月 20 日と 26 日に再設定・検証され、26 日には重要負荷すべてを載せた発電機の切り替え試験も完了しました。電力会社は 10 月 26 日にケーブルの故障箇所を特定し、11 月 13 日までに A 系統を修理する見込みで、11 月 17 日までに施設を A・B 両系統に戻して発電機の負荷試験をもう一度行います。PLC のコードの全面的な見直しは 11 月 6 日までに行う予定です。自分のサーバーについては 3 つのことを覚えておく価値があります。保守中は冗長性がいつのまにか単一障害点になること（1 台を保守している間は、もう 1 台が唯一の存在です）、監視は 1 つの上流の信号ではなく実際の状態を確かめるべきこと、そして突然の停電の後で最も遅いのはストレージの復旧であることが多いので、バックアップ方法のいずれかでデータのコピーを別の場所に置くことです。マルチリージョン構成の考え方は1 つのノードでは足りない理由を、拠点の選び方は低遅延のデータセンターノードの選び方を参照してください。