ZoomのWhiteboardとTasks、一度の復旧では終わらなかった

要約

開始から最初の監視移行までは35分44秒だった。この時点でWhiteboardとTasksはいずれも稼働中の表示に戻った。

次に低下したのは14時28分05秒である。したがって、開始から最終解消までの2時間58分54秒を、そのまま連続停止時間とみなすことはできない。

一方で、最初の復旧だけを採用するのも不十分だ。重要なのは、復旧表示の後に同じ機能群が再び影響を受けた点にある。

最初の通知が確認したのは、米国リージョンでWhiteboardの一覧を取得できないことだった。既存のボードが消えた、すべての直接アクセスが失敗した、内容が破損したとは書かれていない。

15分後、Tasksの新規作成ができない状態も加わった。共有資料を探す機能と、会議後の行動を登録する機能が同時に使いにくくなったことになる。

Zoom Meetingsの音声や映像は対象コンポーネントに含まれない。会議は続けられても、合意事項を残す工程が止まるという障害だった。

本ウェーブの収集窓は14時06分29秒UTCに閉じた。その時、最初の復旧から約81分が経過し、両コンポーネントは稼働中だったが、resolved_atは空欄だった。

再低下は締め切りの21分36秒後に公表された。完全な時系列には必要だが、締め切り時点で既知だった事実として扱うことはできない。

速報の信頼性は、この「当時の状態」と「後から確定した推移」を混ぜないことで保たれる。

Zoomは12時33分と14時28分に、ほぼ同じ文章で原因を特定したと発表した。しかし依存サービス、変更内容、障害モード、対策の詳細はいずれもない。

最初の緩和が不十分だったのか、ロールバックが起きたのか、別の障害が同じ機能に達したのかは判断できない。

状態の変化は確認できる。技術的な因果関係は確認できない。この線引きが必要だ。

Tasksを作成できない間、利用者はチャットや個人メモに作業を仮置きする。復旧後に転記されなければ漏れ、複数人が転記すれば重複が起きる。

Whiteboardの一覧が見えなければ、既存のボードに気付かず別のボードを作る可能性もある。短時間の障害が記録の分裂として長く残る構図だ。

影響アカウント数や失敗率、顧客区分が公表されていないため、全体損失の推計はできない。

二度目の監視移行は14時49分23秒、最終解消は15時08分45秒だった。管理上のインシデントは閉じたが、障害中のTasks作成要求が自動的に再実行されたとは記録されていない。

Zoomはデータ消失や破損を報告していない。ただし、キュー、失敗した書き込み、未処理操作について明示的に問題がないとも述べていない。

「現在は正常」と「過去の操作がすべて正しく反映された」は別の確認事項である。

影響を受けた組織は、二つの局面で決まった事項と最終的に表示されるTasksを突き合わせ、担当者、期限、重複を確認すべきだ。

Whiteboardの識別子を一覧画面以外にも保存し、会議記録をエクスポート可能な形で残せば、単一の表示経路への依存を下げられる。

今後必要なのは技術的な事後説明、局面別の失敗率、拒否または保留された書き込みの処理結果である。現時点で確かなのは、Zoomが同じ二機能を二度復旧させ、最初の復旧が維持できなかった理由を公表していないことだ。