要約

  • 2021年10月4日、世界規模の基幹網の容量を測る意図で定例保守中に発行されたコマンドが、基幹網内の全接続を落とし、Facebook のデータセンターを世界規模で切り離した。
  • この種のコマンドを止めるために設計された自動監査の仕組みは、それ自身の欠陥によって機能しなかった。ネットワークの喪失と、何が起きているかを見る能力の喪失は、二つの出来事ではなく一つの出来事だった。
  • 事業者はテストと演習、回復力の強化を公約した。確認した範囲の資料には、監査ツールの欠陥が修正されたこと、非常時のアクセスが失敗した網から切り離されたこと、外部の当事者が観測した演習を示す日付入りの文書はない。

2021年10月4日、Facebook、Instagram、WhatsApp が世界の広い範囲で同時に応答を止め、その状態が数時間続いた。翌日、事業者は自社のエンジニアリングチームによる説明を公開した。そこに書かれているのは攻撃でも他人の網の障害でもなく、自社インフラ上で実行された保守作業である。

"During one of these routine maintenance jobs, a command was issued with the intention to assess the availability of global backbone capacity, which unintentionally took down all connections in our backbone network, effectively disconnecting Facebook data centers globally."

この一文は出発点を異例なほど正確に定めている。意図は基幹網にどれだけ容量が残っているかを測ることで、結果は基幹網の接続をすべて撤去することだった。本来この二つの間には広い緩衝があり、この事例が検討に値するのは、その緩衝が設計上は存在しながら、実際には働かなかったからである。

止めるはずだった仕組み

事業者の説明は、そのまま受け取れる程度に率直である。この種のコマンドを遮断するための自動監査の仕組みは確かに存在し、その仕組み自体に欠陥があった。

"Our systems are designed to audit commands like these to prevent mistakes like this, but a bug in that audit tool prevented it from properly stopping the command."

ここが、よくある障害とこの事例を分ける点である。組織に防御が欠けていたのではない。宣言された目的がまさに「保守コマンドが全球の基幹網を落とすことを防ぐ」であった防御が、そこにあった。統制が存在することは、保護が存在することを意味しない。正常に動作し、監督下にあると記録されながら、止めるべきコマンドを通してしまう統制は、覆われているという錯覚を生む。そしてその錯覚こそ、事後に監査しにくい。

公開された記録は、誰がこのコマンドを発行し、誰が承認したかを特定していない。意図的な破壊、職務上の過失、隠蔽のいずれとしても記述できない。記述されているのは道具の欠陥であり、その欠陥がどこから来たのか、これまでどう試験されてきたのかは、この記録では説明されていない。

「見る」ことと「戻す」ことが同時に消えた

説明の第二段こそ、この出来事を統制設計の問題に変える。事業者は二つの障害が同時に生じたと述べている。

"All of this happened very fast. And as our engineers worked to figure out what was happening and why, they faced two large obstacles: first, it was not possible to access our data centers through our normal means because their networks were down, and second, the total loss of DNS broke many of the internal tools we'd normally use to investigate and resolve outages like this."

注意して読めば、これは二つの障害が偶然重なった話ではない。一つの出来事が二つの結びついた結果を生んだという話である。本番網が消えると同時に、何が起きているかを内側から調べる力の相当部分も消えた。停止したシステムに依存する検知の仕組みは、独立した検知の仕組みではない。必要とされない間だけ便利に働く道具である。

対応の段は、その依存がどこまで伸びていたかを示す。事業者は最後に物理的な居場所を頼った。

"Our primary and out-of-band network access was down, so we sent engineers onsite to the data centers to have them debug the issue and restart the systems."

帯域外の経路は、まさに主系統の障害を生き延びるために存在する。この時、両方が落ちていた。復旧は遠隔の操作盤からも、緊急用のコンソールからも行われず、人要員を施設へ送り、システムを再起動するかたちで行われた。正当な手段であると同時に、遠隔アクセスの最後の防衛線がもう防衛線ではなかったことの証拠でもある。

外から日付で確かめられること

この記事の独立した裏づけは観測の層にあり、原因の層にはない。独自のネットワーク上の位置から観測する第三者が、この障害の分析を UTC の時刻とともに公開している。

"But at around 15:40 UTC we saw a peak of routing changes from Facebook. That's when the trouble began."

"At 15:58 UTC we noticed that Facebook had stopped announcing the routes to their DNS prefixes."

"It stopped being available at around 15:50 UTC and returned at 21:20 UTC."

"At around 21:00 UTC we saw renewed BGP activity from Facebook's network which peaked at 21:17 UTC."

"as of 21:28 UTC Facebook appears to be reconnected to the global Internet and DNS working again."

この系列は三つのことを行い、四つ目は行わない。事業者のドメイン名の前置を運ぶ経路が撤回された時刻を記録し、主要なドメイン名が解決しなかった時間帯を記録し、経路活動の再開とサービス復帰を記録する。内部の統制経路は見えず、監査ツールがなぜ失敗したかを確かめることもできず、その後の修復については何も語らない。この外部観測を内部の検知能力の証拠として読むのは誤りである。外部の観測者が見ていたのは、事業者自身が見られなくなっていた部分である。

修復：記録はどこまで到達しているか

説明は公約で締めくくられている。

"From here on out, our job is to strengthen our testing, drills, and overall resilience to make sure events like this happen as rarely as possible."

この一文には明確な位置があり、検証可能な階段の最も低い段にしか置けない。階段とは、公開された公約、日付のある実装、実際に行使された統制、独立した観測または第三者による保証である。確認した範囲――事業者が公開した説明、独立したネットワーク観測者の分析、その後の是正措置に関する文書を対象とした一度の的を絞った検索――からは、この事例をより上の段へ押し上げる資料は返ってこなかった。Meta はテスト、演習、全体的な回復力を強化すると述べている。しかしこの範囲の資料には、監査ツールの欠陥が修正されたこと、非常時のアクセスが失敗した網への依存から切り離されたこと、あるいは後に行われた演習が外部の当事者によって観測されたことを示す日付入りの文書はない。したがってこの資料の中では、事後に設けられた統制が試験済みであると示されたものは一つもない。この空白は、当時何も修復されなかったということを意味しない。確認した資料に何が含まれているかを示すだけである。この空白を埋めるのは、日付のある実装記録、実際に行使された統制の結果、または外部の当事者が同席した演習である。

責任はどの層にあるのか

この記事が採る割り当ては四つの層に分かれる。コマンドは直接の引き金であり、引き金は過失と同じではない。監査ツールは機能しなかった予防的統制である。基幹網の喪失、DNS の喪失、診断ツールの喪失、そして二つの遠隔アクセス経路の喪失が結びついたことが、封じ込めと復旧の失敗である。そして事業者は、自らが運用していた統制の積み重ねと回復力の設計に対して説明責任を負う。確認した記録は個人を特定せず、事前の警告があったことを示さず、手続き上の違反があったことも示さず、この出来事に関する規制当局の文書、裁判所の記録、正式な調査を含んでいない。

既存の報道に対して何を足すのか

同じ事業者について存在する報道は、別の事柄を扱っている。Cambridge Analytica の記録を経た開発者権限とプラットフォーム上のデータ統制、2012年の上場時の注文突き合わせの仕組み、この規模の下で働くインフラ技術者の横顔、そして後年に別個に起きたサービス障害に関する短い記事である。これらの記事のいずれも、2021年10月4日の統制の失敗、本番の喪失と診断の喪失が同時だったこと、人が現地へ行かねばならなかったという事実、あるいは修復が耐久性を持つかという問いを扱っていない。この記事が足すのは統制の連鎖と、その修復を囲む証拠の境界であり、障害の経過をなぞり直すことではない。この主体には BTW のディレクトリに独立した項目がある。