概況

  • 2017年2月の Amazon S3 障害は、AWS 自身の公開要約が、意図以上にサブシステム容量を削減した運用コマンドについて説明し、通常のオブジェクトストレージ動作が戻る前にインデックスおよび配置サブシステムの回復を余儀なくされたという点で重要である。
  • アカウンタビリティの問題は、大規模な分散サービスが決して失敗しないことではない。問題は、運用ツール、最小容量のセーフガード、再起動の前提、依存サービスのマッピング、サービス健全性のコミュニケーション、顧客のアーキテクチャ選択に対する実質的なコントロールを誰が持っていたかである。
  • AWS の公開事後要約は、影響を受けた S3 サブシステムを特定し、復旧マイルストーンの日付順の経過を示している点で非常に有用である。それでも、すべての内部ログ、顧客の損失、サービス固有のバックログ、契約上の救済手段を公開しているわけではない。
  • 一つのリージョンの S3 可用性を普遍的な基盤として扱った顧客は、より厳しい継続性の教訓を学んだ。フォールバックは、同じクラウド依存関係、同じリージョン集中、同じステータスチャネル、そして一緒に障害が発生する可能性のある同じ下流サービスに対してテストされなければならない。

オブジェクトストレージが公的な依存関係台帳に

Amazon S3 は耐久性のあるオブジェクトストレージとして説明されることが多いが、2017年2月28日のインシデントはより広範な役割を明らかにした。S3 は単に顧客がファイルを保存する場所ではなかった。それは、ウェブサイト、モバイルアプリケーション、ソフトウェアデプロイメントパス、分析ワークロード、メディア配信、データ交換、カスタマーポータル、公共サービスページ、監視ツール、その他の AWS サービスにとっての依存関係台帳であった。S3 US-EAST-1 リージョンでエラー率の上昇と操作不能が発生したとき、その影響は一つのストレージインターフェースに留まらなかった。イベントは、S3 を基本前提として静かに使用していたアーキテクチャ全体に広がった。

AWS の公開事後要約は、https://aws.amazon.com/message/41926/にあり、このケースの中心的な証拠源である。要約は、太平洋標準時午前9時37分に、承認された S3 チームメンバーが S3 課金プロセスで使用されるある S3 サブシステムの容量を削除するための確立されたプレイブックを実行していたと述べている。コマンド入力は意図以上の容量を削除した。AWS は、これにより2つのサブシステム（リージョン内のオブジェクトのメタデータとオブジェクトの場所情報を管理するインデックスサブシステムと、新しいストレージを割り当てる配置サブシステム）の容量が大幅に削除されたと書いている。この枠組みが重要である。インシデントは、停電、光ファイバー切断、自然災害、または顧客側の設定ミスとしては説明されていなかった。これは、プロバイダー側の運用管理イベントであり、重要な内部サブシステムの容量を削減したものであった。

公開タイムラインはその後、インシデントをアカウンタビリティの記録に変える。AWS は、インデックスサブシステムの再起動が必要であり、システムが何年も完全に再起動されていなかったため、再起動に予想以上の時間がかかったと述べた。要約は、太平洋標準時午前11時54分までに GET、LIST、DELETE リクエストをサポートするのに十分なインデックス容量が復元され、これらの操作は午後12時26分までに回復したと報告している。その後、配置サブシステムの回復により、午後1時18分までに PUT リクエストの処理が開始され、PUT 操作は午後1時54分までに完全に回復したと報告している。読み取り/リスト/削除と書き込み配置の違いは重要である。なぜなら、顧客は「S3」を一つの抽象的なスイッチとして経験するわけではないからである。彼らは特定の操作が失敗し、回復し、遅延し、再試行し、順番に正常に戻るのを経験する。

このシーケンスは、オブジェクトストレージのアカウンタビリティが単なる稼働時間の合計に還元できない理由も示している。S3 から静的ウェブサイトを実行する顧客、アーティファクトをアップロードするデプロイメントパイプライン、オブジェクトをリストする分析ジョブ、メディアを取得するモバイルアプリケーションは、異なる症状を見る可能性がある。静的オブジェクトはキャッシュを通じて引き続き利用できる一方で、新しいアップロードは失敗する可能性がある。リスト操作は新しいオブジェクト配置の前に回復する可能性がある。下流の AWS サービスは、S3 への依存が解消されていないため、引き続き障害が発生する可能性がある。プロバイダー全体の回復声明は価値があるが、顧客レベルの依存関係の証拠の代わりにはならない。

S3 インシデントは、したがって、クラウド依存関係のケースであり、単なるストレージ可用性のケースではない。顧客は、ディスク、レプリケーションコード、物理施設、分散システムの負担の多くを所有しないためにマネージドサービスを購入する。その取引は合理的である。しかし、依存関係はプロバイダーのツール、リージョン設計、サービス健全性コミュニケーション、顧客のアーキテクチャ、サポート証拠に移動する。実質的なコントロールの問題は分散されている。AWS は、運用コマンドインターフェース、内部セーフガード、サブシステム再起動動作、公開説明、回復シーケンスをコントロールしていた。顧客は、自社のシステムが単一リージョンを前提としているかどうか、クロスリージョンレプリケーションを使用しているかどうか、重要な公開アセットをキャッシュしているかどうか、書き込みをキューイングできるかどうか、自社のステータスページを S3 が利用できないときに利用可能に保つことができるかどうかをコントロールしていた。

公開記録はすべての顧客への影響を証明するわけではない。損害、過失、サービス credit、調達失敗に関する法的判断を確立するわけではない。しかし、影響を受けたサービスが共通の基盤である場合、クラウドプロバイダー内の小さな運用アクションが公開のアカウンタビリティテストになる可能性があることを示している。正しい教訓は、単に「クラウドを避ける」または「もっとクラウドを使う」ではない。正しい教訓はより正確である。つまり、どのプロバイダーサブシステムとリージョンが顧客のワークフローを無効にできるかを特定し、インシデント中にプロバイダーがどのようにコミュニケーションするかの証拠を保持し、障害の原因となった同じ依存関係を生き残るフォールバックパスを設計することである。

事後要約がコントロールサーフェスを特定する

AWS の2017年の事後要約の最も価値のある特徴は、コントロールサーフェスを特定していることである。引き金となったイベントはコマンドであった。コマンドは承認されたオペレーターによって実行された。コマンドはプレイブックの一部であった。コマンドは少量の容量を削除することを意図していた。代わりに、コマンドは意図以上の容量を削除した。この連鎖はガバナンスオブジェクトである。それは、ツールが危険なアクションを簡単にしすぎていなかったか、ガードレールが最小容量のフロアを強制していたか、人間の入力を実行前に検証できたか、段階的削除がブラスト半径を制限していたか、回復の前提が完全再起動に対してテストされていたかを問う。

AWS の要約はまた、修復テーマを特定した。S3 は容量をよりゆっくりと削除できるようにセーフガードを追加し、ツールが容量を必要な最小レベル以下に削除するのを防ぐと述べた。AWS は他の容量削除ツールを監査し、重要なサブシステムの回復を高速化するための変更を行っていると述べた。また、S3 はインデックスサブシステムをさらに分割する変更を行っていると述べた。これらは小さな公開関係の詳細ではない。それらは、プロバイダーが「申し訳ありません」と言うのと、失敗した制御のクラスを特定するのとの違いである。

プロバイダーの証拠は外部から見るとまだ不完全である。一般公開は、正確なコマンド、実行前の検証、承認チェーン、アラーム状態、オペレーターインターフェース、ロールバックツール、サブシステムトポロジ、内部レビューを見ることができない。公開要約は、すべての内部修復がどのようにテストされたかを証明するわけではない。すべての顧客や依存する AWS サービスへの正確な影響を証明するわけではない。しかし、要約は障害を分類するのに十分である。運用ツール、サブシステム容量、再起動準備、ブラスト半径制御、サービス健全性コミュニケーション。

その分類は、顧客のデューデリジェンスの出発点である。S3 に依存する顧客は、S3 が耐久性があるかどうかだけを尋ねるべきではない。自社のワークロードが S3 の GET、LIST、DELETE、PUT 操作が個別に劣化したときにどのように動作するかを尋ねるべきである。ワークロードが読み取り可用性と書き込み不可、またはバックログクリアランス前の書き込み回復に耐えられるかを尋ねるべきである。アプリケーションが安全に再試行するか、再試行が負荷を増幅するか、オブジェクトバージョンが偶発的な上書きから保護されているか、キューイングが順序を保持するか、ユーザーに何が起こったかが伝えられるかを尋ねるべきである。プロバイダーのコントロールサーフェスは、顧客の証拠チェックリストになる。

AWS S3 の現在の公開製品およびドキュメントページは、そのチェックリストの現代的なコンテキストを提供する。S3 サービスページ（https://aws.amazon.com/s3/）はサービスファミリーと耐久性の枠組みを説明する。S3 ユーザーガイド（https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html）は、バケット、オブジェクト、ストレージクラス、アクセス制御、機能の運用エントリポイントを提供する。S3 レプリケーションドキュメント（https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html）、バージョニングドキュメント（https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html）、およびエンティティ Lock ドキュメント（https://docs.aws.amazon.com/AmazonS3/latest/userguide/エンティティ-lock.html）は、特定の顧客が2017年に使用したものについての調査結果ではない。これらは、顧客側のレジリエンス、変更保護、回復証拠のための制御を定義しているため関連性がある。

プロバイダー制御と顧客制御の区別は、障害発生時に曖昧になりやすい。顧客はリージョナル障害、キャッシュされた読み取り、再試行予算、バックプレッシャー、クロスリージョン継続性を設計するべきであり、また設計できる。しかし、これらの顧客制御は、安全な運用ツールに対するプロバイダーの責任を消し去るものではない。プロバイダー側の容量削除セーフガードと顧客側のマルチリージョン設計は異なる証拠レーンである。真剣なインシデント後レビューはそれらを分離すべきである。プロバイダー制御を検討することを避けるために顧客アーキテクチャの弱点を使用すべきではなく、また顧客の未テストの依存関係集中を許すためにプロバイダー制御を使用すべきではない。

その分離は調達にも有用である。クラウド購入者は、より良い質問をするために AWS の内部詳細すべてを必要とするわけではない。アプリケーションに依存関係インベントリがあるか、ビジネスがどの機能が単一リージョンの S3 に依存しているかを知っているか、組織が AWS Health およびサービス健全性更新に登録しているか、公開ステータスページが同じリージョンに依存しているか、重要なオブジェクトがレプリケートまたはキャッシュされているか、書き込みパスが状態を破損せずにキューイングできるかを尋ねることができる。これらは実用的な質問である。それらは AWS の要約が暴露したコントロールサーフェスから直接派生する。

サービス健全性コミュニケーションは障害の一部であった

2017年のインシデントは、サービス健全性コミュニケーション自体がアカウンタビリティのストーリーの一部となったためにも記憶されている。AWS の要約は、AWS Service Health Dashboard が影響を受けた理由は、その管理コンソールが影響を受けたリージョンの S3 を使用しており、個々のサービスステータスへの更新が遅れたためであると述べている。この詳細は、ダッシュボードの不便さよりも重要である。ステータスシステムは運用制御である。制御が障害が発生している同じサービスに依存している場合、顧客は最も必要とする瞬間に重要な意思決定チャネルを失う。

したがって、現在の AWS Health ステータスページ（https://health.aws.amazon.com/health/status）およびレガシーAWS Service Health Dashboard エントリポイント（https://status.aws.amazon.com/）は単なる情報リンクではない。それらは、多くの顧客がインシデントの分類を開始する公開チャネルを表す。顧客はアップロード失敗、タイムアウト、エラー率の上昇、空白のアセット、停滞したデプロイメント、壊れたダッシュボードを見ている可能性がある。最初の質問は、問題がローカルか、プロバイダー側か、リージョナルか、グローバルか、認証関連か、ネットワーク関連か、または下流のアプリケーションバグかである。プロバイダーのステータスチャネルが遅い、広すぎる、またはそれ自体が障害を受けている場合、顧客は間違った診断に時間を浪費する。

ステータスコミュニケーションはいくつかの実用的なテストを満たさなければならない。影響を受けたサービスとリージョンを特定すべきである。可能であれば操作クラスを区別すべきである。プロバイダーが調査中か、緩和中か、監視中か、解決済みかを示すべきである。依存関係が重要な場合、依存サービスを説明すべきである。失敗した依存関係を共有しないパスを通じて利用可能であり続けるべきである。後の調整のためにインシデント履歴を保持すべきである。顧客に噂、ソーシャルメディアの断片、ユーザーの苦情を一次証拠として依存させるべきではない。

AWS は、事後要約でこの問題の一部を認識し、Service Health Dashboard を複数の AWS リージョンで更新できるように変更したと述べた。これは具体的な修復の主張である。将来の完璧なコミュニケーションを証明するものではないが、失敗のクラスを特定している。すなわち、ステータス管理は同じ障害が発生しているリージョナル依存関係の背後にロックされるべきではない。これは顧客にとっても一般的な教訓である。組織自体の公開ステータスページ、カスタマーサポート知識ベース、インシデントチャット、または経営陣報告ダッシュボードが製品と同じクラウドリージョンとサービスに完全に依存している場合、組織は障害発生時に発言力を失う可能性がある。

コミュニケーション問題は、重大度評価にも影響する。プロバイダーは、自社のテレメトリの観点からサービスが劣化していると言うかもしれない。顧客は、影響を受ける操作がクリティカルパスにあるため、完全な障害を経験するかもしれない。別の顧客は、キャッシュされたアセットを提供したり書き込みをキューイングしたりするため、限定的な影響しか見ないかもしれない。優れたステータス記録は、すべての顧客ワークフローを知っているふりをすべきではないが、顧客が迅速に独自の重大度判断を下すのに十分な情報を提供すべきである。S3 インシデントは、操作レベルの詳細が重要である理由を示している。読み取り、リスト、削除、書き込み配置は同じ回復瞬間を持っていなかった。

中小企業にとって、ステータスの具体性は継続性手順が使用されるかどうかを決定できる。小規模小売業者、学校、保健所、ローカルメディアサイト、ソフトウェアスタートアップは大規模な運用チームを持っていないかもしれない。彼らはプロバイダーのステータスページとマネージドサービスの健全性チェックに依存して、デプロイメントを一時停止するか、コンテンツ配信を切り替えるか、顧客に警告するか、ローンチを遅らせるか、再試行ストームを停止するかを決定するかもしれない。公開ステータス記録が遅いまたは曖昧な場合、診断のコストは顧客に移る。そのコスト移転は、意図されたものではないにしても、アカウンタビリティの質問の一部である。

公共部門のユーザーにとって、 stakes は異なるかもしれない。公共機関のウェブサイト、データフィード、調達ポータル、緊急情報アーカイブ、オープンデータサービス、請負業者システムはオブジェクトストレージに依存するかもしれない。そのような使用のすべてが重要であるわけではない。しかし、サービスが公開されている場合、組織はベンダーの障害を生き残るコミュニケーションパスを必要とする。プロバイダーのステータス更新は役立つが、機関は依然として市民向けの説明とフォールバックを自前で必要とする。AWS のイベントは、公共部門の継続性にはクラウドステータスの取り込み、ローカルコミュニケーションの独立性、およびチェックされたサービスと影響を受けなかったサービスの証拠を含めるべきであることを思い出させる。

顧客のフォールバックは共通モード依存関係に対してテストされなければならない

フォールバックはあまりにも軽く説明されることが多い。顧客は、別のバケット、別のリージョン、別のプロバイダー、ローカルキャッシュ、コンテンツ配信ネットワーク、手動操作を使用できると言うかもしれない。アカウンタビリティの質問は、そのフォールバックが同じ障害を生き残るかどうかである。影響を受けた同じリージョン内の異なるバケットは役に立たないかもしれない。レプリケートされたオブジェクトは、アプリケーションが一つのリージョンに書き込み、他にテストされた読み取りパスがない場合、役に立たないかもしれない。コンテンツ配信キャッシュは公開アセットには役立つが、新しいアップロード、プライベートデータ、リスト操作、ワークフローステータスには役立たないかもしれない。別のプロバイダーは、データ同期、アイデンティティ、コンプライアンス承認、アプリケーションルーティングがテストされたことがない場合、役に立たないかもしれない。

S3 ドキュメントは多くの顧客側のレジリエンスツールを提供するが、ツールは実装、テスト、ガバナンスが行われた場合にのみ制御になる。Multi-Region Access Points（https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html）は、一部のアーキテクチャでリージョン間のリクエストルーティングに役立つ。Replication Time Control ドキュメント（https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-time-control.html）は、時間制約のあるレプリケーション機能を説明する。S3 Storage Lens（https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage_lens.html）は、ストレージ使用量とアクティビティの可視性をサポートする。イベント通知ドキュメント（https://docs.aws.amazon.com/AmazonS3/latest/userguide/EventNotifications.html）は、オブジェクトイベントをワークフローに統合するのに役立つ。これらのドキュメントのいずれも、顧客が2017年にレジリエンスを持っていたことを証明するものではない。それらは、顧客が現在適用すべき制御の語彙を示している。

鍵は共通モード分析である。アプリケーションがアセット、デプロイメントアーティファクト、ログ、および自社のステータスページのために S3 に依存している場合、それらは別々のリスクではない。それらは一つの依存関係クラスターである。組織がインシデント対応に必要なファイルを保存するために S3 を使用している場合、障害は修復を遅らせる可能性がある。バックアップコピーが同じリージョンにあり、同じ資格情報で管理されている場合、十分に独立していない可能性がある。顧客がそれ自体が同じリージョンの S3 に依存する AWS サービスに依存している場合、アプリケーション層のみを切り替えてもワークフローは復元されない。依存関係インベントリは、調達スプレッドシートのベンダー名ではなく、実際の経路をたどらなければならない。

テストには操作固有の障害を含めるべきである。PUT が失敗した場合でもユーザーは重要なコンテンツを読み取れるか？ビジネスは順序を失ったり重複処理状態を失ったりせずに後で書き込みをキューイングできるか？LIST が遅いまたは利用できない場合、アプリケーションはグレースフルに劣化できるか？サポートスタッフはコンテンツの欠落と新しいアップロードの失敗を区別できるか？プライベートアセットが利用できない場合、サイトは有用なメッセージを表示できるか？デプロイメントはプロダクション状態を破損せずに停止できるか？課金、分析、コンプライアンスログはインシデント後に調整できるか？これらの質問は珍しいものではない。それらは AWS 要約の操作シーケンスから派生する。

再試行動作は特別な注意に値する。分散システムのクライアントはエラー後に再試行することが多く、再試行は有用である。また、負荷を増幅し、コストを増加させ、重複作業を作り出し、ユーザーへの影響を隠す可能性がある。タイムアウト、再試行、およびジッター付きバックオフに関する AWS Builders Library の記事（https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/）は、再試行設計が過負荷と同期再試行ストームを防ぐ方法を説明しているため関連性がある。分散システムでのフォールバック回避に関する記事（https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/）も、フォールバックパスがほとんど実行されない場合に信頼性が低くなる可能性があると警告しているため関連性がある。これらは現在の AWS エンジニアリングリファレンスであり、2017年のインシデント調査結果ではない。これらは、顧客が設計しなければならない障害パターンに一致するため有用である。

同じことがブラスト半径にも当てはまる。セルベースアーキテクチャによる影響範囲の削減に関する AWS Builders Library の記事（https://aws.amazon.com/builders-library/reducing-scope-of-impact-with-cell-based-architecture/）および Availability Zones を使用した静的安定性に関する記事（https://aws.amazon.com/builders-library/static-stability-using-availability-zones/）は、障害が封じ込められたシステムを設計するための公開言語を提供する。S3 自体はリージョナルサービスであり、顧客のアーキテクチャはさまざまであるが、一般的なアカウンタビリティの概念は明確である。テストされた封じ込め境界なしに一つの共有コンポーネントに依存するシステムは、プロバイダーのインシデントをはるかに広い顧客インシデントに変える可能性がある。

これは、すべての顧客が高価なアクティブ-アクティブマルチリージョンシステムを構築すべきという意味ではない。コスト、複雑さ、データ一貫性、コンプライアンス、レイテンシ、スタッフの専門知識、運用リスクはすべて重要である。低リスクのウェブサイトは遅延を受け入れるかもしれない。重要な公共サービスページ、支払いサポートワークフロー、ソフトウェア配布パスはより強力な制御を必要とするかもしれない。アカウンタビリティファイルはビジネスの重要度に一致すべきである。単一リージョンのマネージドサービス依存関係がテスト済みの継続性設計と同じであるふりをすべきではない。

依存する AWS サービスがブラスト半径を可視化した

S3 の混乱は、US-EAST-1 で S3 に依存する他の AWS サービスにも影響を与えた。AWS の要約は、一部のサービスが影響を受け、S3 の運用が回復した後に回復したと述べている。これは重要である。なぜなら、クラウド顧客は、マネージドサービスが顧客の目的のために十分に独立して障害が発生するという前提で、同じプロバイダーからサービスを組み立てることが多いからである。時にはそうなる。時には、インシデントまで明らかでない依存関係を共有する。エコシステム内での S3 の役割により、2017年のイベントはサービス依存関係マッピングの教訓となった。

AWS の一般的なアーキテクチャと運用資料は、これを枠組みするのに役立つ。AWS Well-Architected の信頼性の柱（https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html）は、障害回復、スケーリング、変更管理のためのワークロード設計を強調する。AWS のレジリエンスガイダンス（https://aws.amazon.com/resilience/）は、プロバイダーレベルのレジリエンス言語を提供する。ヘルスチェックの実装に関する Builders Library の記事（https://aws.amazon.com/builders-library/implementing-health-checks/）は、ヘルスチェックが実際のユーザー体験を決定する依存関係を反映している場合にのみ有用であるため関連性がある。サービスは、ユーザーが必要とするストレージ操作で失敗している一方で、ある層では正常に見える可能性がある。

依存関係マッピングは具体的でなければならない。顧客は、アプリケーションアセット、ログ、バックアップ、デプロイメントパッケージ、機械学習入力、サポート添付ファイル、ユーザーアップロード、静的ウェブサイト、公開ダウンロード、分析ジョブのすべてが一つのリージョンの S3 に依存しているかどうかを知るべきである。アーキテクチャ内のどの AWS マネージドサービスが S3 を使用しているか、または S3 の可用性によって影響を受けるかを知るべきである。どの依存関係が自社のテレメトリで可視であるか、どの依存関係がプロバイダーステータスを通じてのみ可視であるかを知るべきである。単一のオブジェクトストレージ操作が利用できない場合、どのビジネスプロセスが停止するかを知るべきである。

この種のマッピングは、マルチリージョンアーキテクチャよりも魅力的でないことが多い。また、より即座に有用である。多くのインシデントは混乱から始まる。ユーザーが障害を報告し、エンジニアは散在するエラーを見て、ダッシュボードは一致せず、チームは症状を追いかける。依存関係マップはその期間を短縮する。チームに、画像読み込みの失敗、エクスポートの破損、デプロイメントの失敗、分析の停滞が一つの原因を共有する可能性があることを伝える。また、過剰反応を防ぐ。マップがカスタマーサポートシステムが影響を受ける S3 パスに依存していないことを示す場合、組織はそのサービスを実行し続け、顧客とのコミュニケーションを維持できる。

プロバイダー側には並行した義務がある。クラウドプロバイダーは、重要なサービスに依存する内部サービスを理解し、回復を順序付ける方法を理解するべきである。2017年には、S3 のインデックスおよび配置サブシステムが通常のリクエスト動作が戻る前に回復する必要があった。その後、他の AWS サービスは自身の依存関係の影響をクリアする必要があった。一般の顧客はその順序付けのすべてを見ることはできないため、プロバイダーのステータスと事後要約は追加の重みを持つ。それらはインフラストラクチャの可視性の公開代替である。

公開証拠は過大解釈されるべきではない。外部者に、どの AWS サービスがどの正確な内部依存関係をどの分に持っていたか、またはどの顧客が最も影響を受けたかを伝えるわけではない。しかし、問題のクラスを証明する。クラウドエコシステムは、顧客の継続性に影響する共有内部依存関係を持つことができる。これは、プロバイダーと購入者の両方によるより強力な依存関係レビューを正当化するのに十分である。

修復証拠は制御の主張として扱われるべきである

AWS の事後要約には修復の主張が含まれていた。すなわち、より遅い容量削除、容量が最小レベルを下回るのを防ぐツールのセーフガード、運用ツールの監査、重要なサブシステムのより高速な回復作業、インデックスサブシステムのさらなる分割、サービス健全性ダッシュボードの変更である。これらの主張は制御の主張として読まれるべきである。それぞれがテスト可能な制御目標を暗に示している。遅い削除は突然の容量崩壊の可能性を減らす。最小容量のセーフガードは危険なオペレーター入力を減らす。ツール監査は他の場所で同様の危険を探す。回復作業は再起動の前提をテストする。分割はブラスト半径を減らす。ステータスダッシュボードの独立性はコミュニケーションを改善する。

一般公開はそれらの制御の完全なテスト証拠を受け取らない。これはプロバイダーの内部運用にとって正常である。しかし、顧客と監査人は依然としてその主張を自らのレビューを形成するために使用できる。プロバイダーが容量削除ツールが現在制限を強制していると言う場合、購入者はプロバイダーが将来の運用インシデントをどのように伝えるか、および同様のセーフガード言語が事後要約に現れるかどうかを尋ねることができる。プロバイダーがサブシステムをさらに分割したと言う場合、顧客はサービスステータスが現在リージョンと操作クラスを十分に明確に区別しているかどうかを尋ねることができる。プロバイダーがダッシュボードツールを変更したと言う場合、顧客は自社のステータス監視が複数のチャネルを通じて更新を確認するかどうかをテストできる。

安全でハンズオフなデプロイメントの自動化に関する AWS Builders Library の記事（https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/）は、変更安全性、自動化、ベイクタイム、アラーム、ロールバックに関するより広範な AWS エンジニアリング語彙を示しているため関連性がある。2017年の S3 インシデントは通常の顧客向けデプロイメント問題ではなかったが、同じガバナンス論理を共有している。危険な変更には自動安全チェック、段階的効果、高速検出、テスト済みロールバックまたは回復が必要である。手動プレイブックは確立されているという理由だけで安全になるわけではない。ツールが人間が見逃す可能性のある制約を強制するときに安全になる。

修復証拠は顧客固有でもあるべきである。顧客は「AWS が S3 を修正した」でレビューを終了すべきではない。どの内部アプリケーションが失敗したか、どのユーザーが影響を受けたか、どの再試行が実行されたか、どのデータが遅延したか、どのステータスメッセージが送信されたか、どの依存関係が新たにマッピングされたか、どのアーキテクチャ変更が行われたかまたは拒否されたかを尋ねるべきである。一部の顧客は合理的に主要な変更は正当化されないと判断するかもしれない。他の顧客はクロスリージョンレプリケーション、キャッシュされた公開アセット、独立したステータスホスティング、キューデザイン、代替運用ランブックを選択するかもしれない。ポイントはすべてのインシデントが最大限の冗長性を必要とするわけではないことである。ポイントは決定が証拠に基づくべきであることである。

取締役会は特に曖昧なクロージャーに懐疑的であるべきである。「ベンダーは回復した」はローカル制御ではない。「製品画像、デプロイメントアーティファクト、ステータスページすべてが一つの S3 リージョンに依存しており、ステータスページと重要なアセットを独立したパスに移動した」は制御である。「S3 PUT 不可時に書き込みキューイングをテストした」は制御である。「AWS Health に登録し、S3 操作エラーのローカル相関を構築した」は制御である。「非重要なアップロードの残余リスクを受け入れた」はガバナンスの決定である。2017年のインシデントは、組織にそれらの区別を行うための語彙を提供する。

顧客の証拠ファイルは同じ障害を生き残るべきである

S3 クラスのインシデント後の最も有用な顧客対応は、それが説明するインシデントを生き残ることができる証拠ファイルである。つまり、組織はすべてのインシデント手順、連絡先リスト、ステータスドラフト、アーキテクチャ図、回復スクリプト、現在の依存関係マップを影響を受けるサービスまたはリージョンにのみ保持すべきではない。対応の調整に必要な証拠が失敗している同じオブジェクトストレージパスに保存されている場合、インシデントはサービスとマップの両方を削除する。成熟した継続性設計は、既知のアクセスルールを持つ別のパスに少量のインシデント証拠を保持する。

そのファイルは、非専門家が理解できる依存関係ラベルで始めるべきである。「S3」は広すぎる。より良い記録は、公開静的アセット、顧客アップロード、プライベート添付ファイル、デプロイメントアーティファクト、アプリケーションログ、バックアップエクスポート、分析入力、機械学習データセット、コンプライアンスアーカイブ、組織自身のステータスコミュニケーションを分離する。各依存関係は、リージョン、操作タイプ、ビジネスオーナー、許容遅延、フォールバックルート、回復後に必要な証明を指定するべきである。これにより、インシデントレビューが象徴的ではなく運用可能になる。

ファイルはまた時間を保存すべきである。障害発生中、チームは最初の苦情、最初のアラート、最初のプロバイダー更新、最初の回避策、ユーザーが苦情をやめた時間を覚えていることが多い。これらの記憶は有用だが弱い。より強力な記録は、アプリケーションログ、プロバイダーステータスページ、利用可能な場合は AWS Health イベント、サポートチケット、インシデントチャット、顧客通知、回復後チェックからのタイムスタンプを保存する。タイムスタンプは完璧である必要はなく、価値があるために十分である。ローカル検出が遅れたか、プロバイダーコミュニケーションが遅れたか、フォールバックアクティベーションが遅れたか、回復が想定ではなく検証されたかを示すのに十分でなければならない。

ファイルはデータ整合性とサービス継続性を区別すべきである。2017年の S3 インシデントはサービス中断であり、公開データ窃盗記録ではなかった。これはすべての顧客リスクが同じであることを意味しない。一部の顧客は、遅延書き込みが再試行されたか、重複リクエストが繰り返しオブジェクトを作成したか、古いオブジェクトが提供されたか、ログが欠落していたか、デプロイメントアーティファクトが部分的にアップロードされたか、ユーザー向けトランザクションの調整が必要かを知る必要があった。サービスは回復するが、顧客にはまだクリーンアップ作業が残る可能性がある。それらを一つのイベントとして扱うと、実際にユーザーを保護する作業が隠れる。

最後に、ファイルは拒否された制御を記録すべきである。すべての組織がアクティブ-アクティブマルチリージョン設計を採用するわけではない。低重要度のワークフローにはコストと複雑さが価値を超えると判断するものもある。それが明示的であれば、それは正当なガバナンスの選択である。弱いのは黙認である。依存関係マップなし、テストなし、オーナーなし、フォールバックなし、リスクが受け入れられた理由の記録なし。2017年の S3 中断は、組織がそれらの決定を書き留めるための具体的な障害モードを提供するため、依然として有用である。

証拠ファイルには回復調整ステップも含めるべきである。S3 が通常運用に戻った後も、顧客は自社のキューイングされた書き込み、遅延読み取り、失敗したアップロード、部分的なレポート、静的アセット、ユーザー向けワークフローが正しい状態に落ち着いたことを証明する必要がある。プロバイダーの回復は自動的に顧客の回復を証明するわけではない。バックログは順序通りに排出されない可能性があり、再試行ループは重複オブジェクトを作成する可能性があり、キャッシュされたページは古いアセットを隠す可能性があり、コア依存関係が健全になった後もサポートワークフローは失敗し続ける可能性がある。調整ステップは、ローカルクロージャーを証明する記録を指定すべきである。キュー深さ、失敗したジョブのリプレイ、オブジェクト数、該当する場合は書き込みチェックサム、ユーザー苦情トレンド、デプロイメントアーティファクト検証、ステータスメッセージのクロージャー。この証拠は、顧客が早期に勝利を宣言するのを防ぐ。

プロバイダーにとって、同じ考えが内部で当てはまる。重要なサブシステムが回復したとき、依存サービスはまだキャッチアップ作業、キャッシュ再構築、再試行スムージング、または遅延した顧客可視ヘルスチェックを必要とする可能性がある。プロバイダーサブシステムの回復を依存サービス回復から区別する事後要約は、顧客により現実的な復旧モデルを提供する。また、顧客が自社のテストを設計するのにも役立つ。アカウンタビリティの教訓は、依存関係の回復はシーケンスであり、スイッチではないことである。

読者向け証拠ファイル

この記事では、以下の公開情報源を S3 US-EAST-1 中断、AWS ステータスコミュニケーション、S3 サービスコンテキスト、顧客側のレジリエンス制御、分散システム障害設計の証拠ファイルとして使用する。プロバイダー執筆の情報源は、AWS が公開した内容と AWS が現在のサービスを文書化する方法の証拠として扱われる。すべての内部ログ、顧客への影響、契約上の救済、内部監査結果の独立した証明としては扱われない。

取締役会のレビュー質問

取締役会またはリスク委員会は、AWS S3 が2017年に障害を起こしたかどうかだけを尋ねるべきではない。現在のどのビジネスプロセスが S3 に依存しているか、どのリージョンを使用しているか、どの操作が重要か、どのアセットまたはワークフローに独立したフォールバックがあるか、クラウドインシデント中にどのステータスチャネルが利用可能か、影響と回復を証明できるローカルテレメトリは何かを尋ねるべきである。回答は日付付きで、テスト可能で、ビジネスの重要度に関連付けられるべきである。

レビューは5つの証拠レーンを分離すべきである。最初のレーンはプロバイダー証拠である。AWS の事後要約、現在のステータスチャネル、公開レジリエンス資料。2番目のレーンはアプリケーション証拠である。ローカルログ、リクエストエラー、影響を受けた操作、キュー動作、ユーザー影響、バックログクリアランス。3番目のレーンはアーキテクチャ証拠である。レプリケーション、キャッシング、マルチリージョン設計、再試行ポリシー、独立したコミュニケーション。4番目のレーンはガバナンス証拠である。誰が残余リスクを受け入れたか、誰がフォールバックテストを所有するか、誰がサービスがローカルで復旧したと判断するか。5番目のレーンは顧客コミュニケーションである。ユーザー、機関、従業員、取引先に何がいつ伝えられたか。

この特定のケースでは、支配的な質問は依然として次のとおりである。運用コマンド、サブシステム容量のセーフガード、リージョン集中、サービス依存関係マッピング、顧客フォールバックアーキテクチャ、ステータスの可視性、およびオブジェクトストレージの回復が依存サービスを復元したことの証明について、実質的なコントロールを誰が持っていたか？完全な回答は、AWS の制御、顧客の制御、証拠のギャップ、影響を受けたオーディエンス、および将来のクラウド購入またはアーキテクチャ決定を変える修復証拠を特定すべきである。