RTOとRPOを設定し、テストする

二つの目標を別々に定める

Recovery Time Objective（RTO、目標復旧時間）は、サービスが利用可能な状態に戻るまでの、許容できる中断時間の上限です。Recovery Point Objective（RPO、目標復旧時点）は、時間で表した、許容できるデータ損失の上限です。サービスと障害シナリオを定め、業務の責任者と目標を合意します。

可用性の目標は、一定期間のサービスの稼働状況を示します。RTOとRPOは、復旧に求める条件を示します。答えている問いが異なります。

架空の注文サービスでは、責任者がRTOを60分、RPOを15分と定めます。これらは例の値であり、一般的な推奨値ではありません。注文の消失とレポートの遅延では影響が違うため、別のサービスには別の上限が必要かもしれません。

復旧全体を測る

サービスは10:00に停止します。チームは演習を次のように記録します。

復旧までの経過時間は55分です。この演習は、60分のRTOを満たします。復元操作の25分だけを数えると、中断時間の大半を隠してしまいます。

使用可能な最新の復旧時点は09:40です。10:00の中断までの差は20分です。15分のRPOを5分超えています。同じデータをより速く復元しても、この差は縮まりません。

実際に欠落したレコードや、不整合なレコードを調べます。時間の差は、損失が起こり得る範囲を示すもので、影響を受けた注文数ではありません。通常処理を再開する前に、外部の決済記録と注文履行記録を照合します。復旧演習で、異なる仮定を試してください。

復旧戦略を選ぶ

戦略は、必要なサービス、データ、依存先を含む必要があります。次の方式を、測定した目標と比較します。

これらの方式に、普遍的な復旧時間はありません。実装、データ量、依存先、テスト条件によって結果が決まります。判断には、運用費用とチームの対応能力も含めます。

停止以外にも備える

レプリカは、意図しない削除や破損したレコードもコピーする可能性があります。必要に応じて、復旧可能なバージョンや、特定時点への復旧機能を維持します。保存期間、復元権限、暗号鍵へのアクセスを確認します。プライマリーアカウントへのアクセス喪失も含め、シナリオに合わせてバックアップを分離します。

リージョンをまたぐ復旧では、許可されたデータの保管場所と依存関係全体を確認します。ID、DNS、証明書、シークレット、デプロイ成果物、クォータ、ネットワークアクセスを含めます。必要な鍵が一つ欠けただけでも、復旧環境を使えない場合があります。

誰が災害発生を宣言し、誰が復旧を実行し、誰が復旧したサービスを受け入れるかを定めます。元の環境への切り戻し、または復旧先での継続運用を計画します。複数のコンポーネントによる競合する書き込みを防ぎ、再び切り替える前にデータを照合します。

計画を証拠に変える

runbookを作り、管理された条件下で演習します。シナリオ、データセットの大きさ、開始と終了の時刻、復旧したデータの時点、失敗した手順、責任者を記録します。安全なテストレコードで、実際の業務操作を検証します。

関連する変更の後と、合意した日程で演習を繰り返します。スキーマの変更、新しい外部依存先、異なるデータ量によって、以前の結果が有効でなくなる場合があります。演習の証拠を、リリースと運用の責任分担に結び付けます。