要約
- DigitalOcean は7月19日14:52 UTC、Volume 接続障害の根本原因を特定して修正したと発表し、事象を監視段階へ移した。
NYC1、NYC3、SGP1、SYD1、BLR1では Volume を Droplet へ再び接続できるとしているが、原因そのものは公開していない。- 監視中は解決済みではない。顧客は要求結果、最終接続状態、デバイス、マウント、アプリを確認してから自動化を戻す必要がある。
DigitalOcean は、5拠点でネットワーク型ブロックストレージを Droplet へ接続できなかった問題を修正したと説明した。運用上は前進だが、情報面では空白が残る。
14:52 UTC の更新は、技術チームが根本原因を特定し、修正を正常に実装したとする。利用者は今後、エラーなしに Volume を接続できるはずだという。状態は「監視中」であり、まだ「解決済み」ではない。
DigitalOcean は、把握したという原因を説明していない。5拠点をつないだ共通依存、失敗率、顧客数、拠点別の開始・終了時刻も不明だ。
復旧したのは制御操作である
DigitalOcean Volume はネットワーク接続型のブロックストレージだ。利用する Droplet と同じリージョン、同じプロジェクトで作成し、接続してマウントする。新規構築、別 Droplet への移動、容量追加、復旧でこの操作が必要になる。
今回の範囲は接続である。既存の全ファイルシステムが読み書き不能になった、データが失われた、全 Droplet が停止した、5つのデータセンター全体が落ちた、とは発表されていない。
それでも復旧経路には重大だ。計算資源とスナップショットが利用可能でも、代替マシンへストレージを結び付けられなければ手順は完了しない。
1つの Volume は同時に1台の Droplet だけへ接続できる。移動時には最終状態の確認が欠かせない。Volume は Droplet バックアップにも含まれないため、必要な保護は別の Volume スナップショットで設計する。
事業者の特定は顧客への説明ではない
「根本原因を特定した」という文言は、DigitalOcean 内部の調査が到達したことを示す。顧客の設計上の疑問は閉じない。
共通の制御サービス、デプロイ、API 依存、容量制約だったのか、複数の障害を一つの事象として扱ったのかは分からない。5拠点の列挙から、5つの独立障害も、単一の世界的制御面障害も導けない。
仕組みが非公開なら、マルチリージョン構成が失敗した依存を本当に分離していたか判断できない。顧客は復旧を実測し、未知の共通故障に備えるしかない。
ステータスページの緑は個別試験ではない
顧客は実際の経路、つまり管理画面、API、またはdoctlで確認する。要求時刻、リソース ID、エラーまたは成功、最終接続状態、Droplet からのデバイス認識、マウント、アプリの健全性を残すべきだ。
状態を変える要求を再実行する前に、現在のリソース状態を照合する。無条件の再試行は、事業者の修正後に別の運用事故を生む可能性がある。
接続成功はアプリ復旧と同義ではない。意図したファイルシステムがマウントされ、正しいデータを読み、遅延の影響が残っていないかは別に確認する。
SLA は申告と検証を要求する
Volume SLA は月間99.99%を掲げるが、利用不能は個別リソースへの全要求が5分を超えて失敗する状態として定義される。クレジットには顧客の申請と DigitalOcean の検証が必要だ。
公開ページは、個別要求、拠点別時間、クレジット適格性を証明しない。次に必要なのは、すでに特定したという原因と、再発なしで監視が終わったことだ。修正は公表されたが、設計へ戻せる教訓はまだ公表されていない。