顧客の成果（アウトカム）を中心に準備を定義する
インフラのラベルではなく成果から始めます。到達可能なホームページがあっても、訪問者が重要なタスクを完了できなければ不十分です。各クリティカルなジャーニーについて、誰が何をしようとしているのか、成功は何を意味するのか、受け入れられない結果は何かを明示してください。チームが実際の判断を下せるよう、いくつかのジャーニーに絞って始めます。
各ステップを「必須（essential）」「重要（important）」「遅延可能（deferrable）」に分類します。必須はそれがなければジャーニーが完了しないことを意味します。重要は時間限定の回避策を許容する可能性があり、遅延可能は省略、遅延、または単純化できます。これはエンジニアリングだけで決まる技術的な順位付けではなく、プロダクト判断です。
ページ応答だけでなく、注文が受け付けられ確認が保存されるなど、実用的な結果を記録します。
依存関係をマップし、どこまで劣化できるか決める
各クリティカルパスについて、ホスティングや配信、DNS、アプリケーションサービス、データベース、認証、メール、決済、検索、タグ、同意管理ツール、外部APIをマップします。各項目についてオーナー、サポート経路、関連する制限、利用不可になった場合のユーザー影響を記録してください。OWASPはソフトウェア依存関係への洞察を推奨しており、同様のオーナーシップの管理は運用上の依存性にも有効です。
ハード依存は障害時にタスクが停止するものです。ソフト依存は不在または古い状態でもコアタスクが機能する場合があります。AWSはグレースフルデグラデーション（段階的劣化）を説明しており、依存関係が不健全なときにコア機能を維持することを目的としています。プロダクト固有の判断を定義してください：非必須ウィジェットを隠す、レポートを遅延する、正直なフォールバックを提示するなど。在庫・価格・注文状態・支払い結果をでっち上げないでください。
目的、オーナー、既知の制限、フォールバック、変更連絡先、最終テスト日を各項目について記録します。
トラフィック予測を容量試験に変える
単一のトラフィック数値ではなくシナリオを使います。イベント、到着パターン、リクエストの混合、サインイン済み比率、地理、同時チェックアウトや書き込み活動、ピーク期間を明記してください。ハイケースとその前提も含めます。Googleはリクエストごとに非常に異なるリソースコストがあり、リクエスト数／秒だけでは容量モデルとして不十分になり得ると指摘しています。
承認と安全策を整え、本番に近い構成で持続的かつ代表的なエンドツーエンドのトラフィックをテストします。AWSはコンポーネントのみをテストすること、代表性のないリクエストのサブセットのみを使うこと、予想負荷を小幅上回ったところで止めることを注意喚起しています。最初に制約や遅延が生じた箇所を文書化してください。本番での試験は顧客に影響を与え得るため、計画的かつスタッフ配置された演習でない限り管理された環境を使ってください。
シナリオ、構成、リクエスト混合、継続時間、観察された制約、容量変更、フォローアップの担当者を記録します。
変更、ロールバック、復旧の選択肢を準備する
ハイリスクな変更の前に、復元すべきアーティファクトや構成、必要な承認、権限のある人物、検証方法を特定します。リリースの一時停止、デプロイの巻き戻し、機能フラグの無効化、非重要な統合の縮小、承認された手順によるデータ復元などの短いランブックを用意してください。イベント前に手順の仕組みをテストしてください。未実演のバックアップやロールバック計画は仮定に過ぎません。
ビジネス影響から復旧目標を設定します。復旧時間目標（Recovery Time Objective、RTO）はサービスが復旧するまでに許容できる最大遅延です。復旧時点目標（Recovery Point Objective、RPO）は最後の復旧ポイント以降に許容できる最大データ損失です。AWSは恣意的・非現実的な目標を避けるよう注意喚起しており、依存関係の目標が達成可能性に影響することを指摘しています。目標は顧客への約束ではなく計画のための目安として扱ってください。
限定的で安全なロールバックまたは復元を検証し、何を誰がチェックしたか、見つかったギャップを記録します。
決定が緊急でないうちにオーナーを割り当てる
連絡先リストだけではオーナーシップになりません。各クリティカルパスに対して、受け入れ可能な結果のビジネスオーナー、実装の技術オーナー、保護的変更を行う権限を持つ決定オーナーを割り当ててください。バックアップ要員を明示し、プロバイダー、代理店、決済処理業者、または社内チームが次のアクションを所有する状況を明確にします。
トラフィック到来前に短い準備レビューを実施してください。依存関係の一つの障害を想定して、何が残り利用可能か、どの手段が安全か、誰が承認するか、成功をどう確認するかを検証します。これは事前のリハーサルであり、ライブのステータス報告ではありません。日付入りのアクション、オーナー、期日を記録してください。
保護が不明確な承認チェーンを待たないよう、適切な範囲で事前承認された安全なアクションを設定してください。
決済やセキュリティに関わる経路は特に慎重に扱う
チェックアウトの準備では可用性だけでなく正確性を守る必要があります。認可を回避したり、アクセス制御を弱めたり、認証情報を露出したり、決済ページのスクリプトを軽率に変更したりしてはいけません。PCI SSCは決済ページスクリプトやセキュリティに影響するHTTPヘッダーについて、認可、完全性、改ざん検知に関するガイダンスを提供しています。サイトがカードを受け入れるか埋め込み型の決済フレームを使う場合、マーチャント、プロセッサ、アクワイア、資格のあるセキュリティ／コンプライアンス担当者に重要な変更をレビューしてもらってください。
本番で使われているスクリプト、統合、バージョン、アカウント所有権のインベントリを維持し、変更可能な人を制限してください。OWASPは依存インベントリとバージョン固定がビルドに入るものの不確実性を減らせると指摘しており、自動検出の結果も手動で検証する必要があることを述べています。これらの実践は準備に寄与しますが、PCI適合性を確立するものでもセキュリティ評価の代替にもなりません。
プロセッサが承認した、レビュー済みの代替フローのみを使用し、非公式な経路でカードデータを収集しないでください。