resilience-and-recovery

レジリエンスと復旧

システムとその依存関係全体にわたるレジリエンスと復旧の動作を設計し、演習し、証拠を残します。このスキルでは、障害モード、依存関係の動作、縮退時の選択肢、復元テスト、災害復旧、ゲームデー、フェイルオーバー、データ整合性、復旧に関するコミュニケーションを単一の手法にまとめます。設計書だけでなく、演習に裏付けられたレジリエンス計画を作成します。

使用する場面

トリガー	対応内容
「このシステムのレジリエンス計画を設計してください」	障害モードのマッピング、依存関係の分析、縮退時の選択肢、RTO／RPO の決定記録、復旧計画のテンプレート
「ゲームデーまたは復元テストを実施してください」	演習の設計、シナリオの定義、証拠の記録、フォローアップ作業台帳
「災害復旧への備えを評価してください」	演習の証拠に照らした DR 計画のレビュー、ギャップ分析、データ整合性の検証
「この依存関係に障害が発生したらどうなりますか？」	依存関係の喪失シナリオ、縮退経路、サーキットブレーカーとフォールバックの戦略
「RTO と RPO を定義してください」	一律の規定ではなく、トレードオフ分析を含む、コンテキストに応じた決定記録
「復元後のデータ整合性を検証してください」	復元後の検証手順、チェックサムと整合性のチェック、照合プロトコル
「フェイルオーバー訓練を計画してください」	フェイルオーバー演習の設計、前提条件、成功基準、ロールバック／フェイルバック計画、証拠の記録

使用しない場面

• 進行中のインシデント指揮またはインシデント対応：インシデント指揮システム、オンコール運用、リアルタイムのインシデント管理については、site-reliability-engineering に引き継ぎます。このスキルはインシデント発生前のレジリエンス設計と演習証拠の手法を担い、SRE は進行中の対応を担います。
• インフラストラクチャの実装詳細：Infrastructure as Code、CI/CD パイプラインの実装、コンテナオーケストレーション、サービスネットワークについては、platform-engineering に引き継ぎます。このスキルはレジリエンス要件と演習証拠を担い、プラットフォームエンジニアリングは実装を担います。
• リリースの段階的な展開とロールバックの仕組み：段階的なデリバリー、カナリアデプロイ、フィーチャーフラグ、ロールバック手順書については、release-engineering に引き継ぎます。このスキルは演習を通じたこれらの仕組みのレジリエンス検証を担います。
• バックアップの実装とパイプライン運用：バックアップ戦略の実装、WAL アーカイブ、スナップショット管理については、data-engineering に引き継ぎます。このスキルは復元テストの証拠とデータ整合性の検証プロトコルを担います。
• セキュリティインシデントの封じ込めとフォレンジック：セキュリティインシデント対応と脅威の封じ込めについては、secure-software-engineering に引き継ぎます。このスキルは、セキュリティインシデント時にも復旧能力を維持できるようにするという、セキュリティインシデントのレジリエンス面を担います。
• インシデント後の学習と検証：インシデントの調査結果を、完了の証拠を伴う検証済みのフォローアップ作業へと変換するには、incident-learning に引き継ぎます。このスキルは、演習および DR テストの調査結果を incident-learning のパイプラインに渡します。

読み込みガイド

ファイル	読み込むタイミング
references/failure-modes-and-dependencies.md	障害モードの整理、依存関係の喪失の分析、または縮退パスの設計を行うとき
references/recovery-plan-template.md	構造化された項目を含むレジリエンス／復旧計画を作成またはレビューするとき
references/exercise-design-and-evidence.md	ゲームデー、復元テスト、フェイルオーバー訓練の設計、または演習の証跡を記録するとき
references/rto-rpo-decision-record.md	コンテキスト固有のトレードオフと意思決定記録のテンプレートを用いて、RTO/RPOを定義するとき
references/data-integrity-verification.md	復元またはフェイルオーバー後に、データの正確性と一貫性を検証するとき
references/recovery-communication.md	復旧イベント中に、誰にいつ通知するかを計画するとき
references/follow-up-work-ledger.md	演習で得られた知見を、担当者が明確な実装、テスト、運用作業に落とし込むとき
references/discovery-brief.md	関連スキルとの間で、担当範囲を把握するとき

レジリエンスの基本原則

レジリエンスは、設計ではなく演習によって証明されます。 一度もテストされていない復旧計画は、能力ではなく希望にすぎません。レジリエンスに関するすべての主張は、ゲームデー、リストアテスト、フェイルオーバー訓練、カオス実験などの演習の証拠によって裏付ける必要があります。設計文書だけでは不十分です。復旧計画には、設計上の主張だけでなく、演習による証拠が必要です。証明の基準となるのは、設計文書だけではなく、演習の証拠です。

高可用性は復旧可能性ではありません。 HA（冗長化、フェイルオーバー、クラスタリング）は、コンポーネントの障害が発生してもシステムの稼働を維持します。復旧（バックアップ、リストア、災害復旧）は、システムの障害後にシステムを再構築します。HAは復旧の代わりにはなりません。冗長化されたシステムでも、データ破損、論理エラー、レプリカ間に伝播する連鎖障害が発生する可能性があります。可用性が99.99%でも、テスト済みのリストア機能がないシステムは、レジリエントではありません。利用可能ではあっても、復旧不能です。HAと復旧の両方が必要であり、どちらも他方の代わりにはなりません。

RTOとRPOは状況に依存し、普遍的なものではありません。 目標復旧時間と目標復旧時点は、システムの役割、データ分類、ユーザーへの影響、規制要件、コストによって異なります。「RTOは1時間未満にすべき」という普遍的な基準はありません。決済システム、社内Wiki、バッチ分析パイプラインでは、RTO/RPOの要件は根本的に異なります。テンプレートの値をそのまま流用せず、明示的なトレードオフを記録した意思決定記録を通じて、システムごとにRTO/RPOを定義してください。構造化されたテンプレートについては、RTO/RPOの意思決定記録のリファレンスを参照してください。

依存関係が障害の影響範囲を決めます。 上流と下流の依存関係は、すべて障害モードとなり得ます。障害発生時の依存関係の挙動を考慮していないレジリエンス計画は不完全です。各依存先が利用不能、性能低下、または遅延したときに何が起こるか、また各状況で自システムが利用者に何を約束するのかを把握してください。

完全に停止するのではなく、段階的に機能を縮退させてください。 依存先や内部コンポーネントに障害が発生した場合、システムは完全に停止するのではなく、許容可能な範囲で機能を縮退させて動作を続けるべきです。どの機能を停止し、どの機能を維持し、その結果どのようなユーザー体験になるのか、許容可能な縮退経路を定義してください。すべての障害が全面停止を正当化するわけではありません。

演習で発見した障害は貴重なものです。 演習で、リストアに時間がかかりすぎた、フェイルオーバーでデータが失われた、依存先の喪失が予想外の連鎖障害を引き起こしたなどのギャップが明らかになった場合、その発見は資産となります。演習で発見したすべての事項を、担当者、目標日、検証方法を明記したフォローアップ作業に結び付けてください。ギャップが一つも見つからなかった演習は、十分に徹底されていなかったか、システムが未テストであることを示しています。

復旧時のコミュニケーションも復旧の一部です。 復旧対応中、関係者は、何が起きたか、何が影響を受けているか、どのような対応を行っているか、いつ解決する見込みか、誰に連絡すればよいかを知る必要があります。コミュニケーション用テンプレート、通知チャネル、エスカレーション経路を事前に計画してください。復旧中のコミュニケーション不備は、技術的な障害をさらに悪化させます。

レジリエンスパターン

パターン A：グレースフルデグラデーション

コンポーネントや依存関係に障害が発生しても、システムは許容できる縮退モードで動作を続けます。これは全面的な停止ではありません。コア機能を維持しながら、重要度の低い機能を意図的に切り離す選択です。

縮退の判断基準：

• 障害が発生したコンポーネントは、システムのコア機能に不可欠ですか？　不可欠な場合、縮退は許容できない可能性があります。システムをフェイルクローズまたはフェイルセーフにする必要があるかもしれません。
• 残りの機能で、想定される復旧期間中にユーザーへ許容できるサービスを提供できますか？　ユーザーが主要なタスクを完了できないのであれば、縮退は機能していません。
• 縮退モードで動作を続けた場合、影響範囲はどの程度ですか？　縮退運用によって、データ破損、セキュリティリスク、または連鎖的な障害が発生するおそれはありますか？

例：

• E コマースのチェックアウト機能でレコメンデーションエンジンが停止しても、注文は受け付けます。レコメンデーション機能は切り離されますが、注文機能は維持されます。
• ダッシュボードでリアルタイムのメトリクスフィードが停止しても、「データが古い可能性があります」というインジケーターを表示して、前回の更新時にキャッシュされたデータを表示します。リアルタイム性は切り離されますが、可観測性は維持されます。
• API ゲートウェイで下流のマイクロサービスが停止しても、500 エラーを返す代わりに、キャッシュされた応答または適切なフォールバックペイロードを返します。データの新しさは切り離されますが、可用性は維持されます。

階層別の機能切り離し：

• 階層 1（維持）： コア機能。システムの存在理由となる機能です。常に利用可能でなければなりません。
• 階層 2（必要に応じて切り離す）： 体験を向上させる機能ですが、不可欠ではありません。最初に切り離します。
• 階層 3（早期に切り離す）： あれば便利な機能。重要度の低い装飾的な機能です。負荷が高まったら直ちに切り離します。

パターン B：リストアによる復旧

冗長化や縮退では緩和できない障害が発生した後、バックアップ、スナップショット、またはレプリカからシステムを復旧します。これには、災害復旧、データ破損からの復旧、システム全体の再構築が含まれます。

リストアの判断基準：

• HA では対処できない障害モードですか（データ破損、論理エラー、リージョンの喪失、ランサムウェアなど）？
• 検証済みの RTO はどのくらいですか。リストアにはどれだけ時間がかかりますか。また、テスト済みですか？
• 検証済みの RPO はどのくらいですか。どれだけのデータが失われますか。また、バックアップは検証済みですか？
• データ整合性の検証を含め、リストア手順を最初から最後まで実施したことがありますか？

例：

• プライマリデータベースのリージョンが失われます。システムは DR リージョンにフェイルオーバーし、直近の検証済みクロスリージョンバックアップからリストアします。RTO と RPO は、意思決定記録に照らして測定されます。
• 論理的なデータ破損（不適切なデプロイ、バグなど）がすべてのレプリカに伝播します。すべてのレプリカが破損しているため、HA では対処できません。システムは破損が発生する前の時点のバックアップからリストアし、リストア後にデータ整合性を検証します。
• ランサムウェアにより、プライマリとレプリカのデータストアが暗号化されます。システムは、エアギャップされたイミュータブルバックアップからリストアします。リストアテストでは、意思決定記録で定めた RTO の範囲内でこの機能を実行できることが確認されています。

リストアテストの要件：

• バックアップの検証だけでなく、最初から最後までのリストアを実施する必要があります。
• リストア後にデータ整合性を検証する必要があります。チェックサム、行数、アプリケーションレベルの整合性チェックを使用します。
• 意思決定記録の RTO に照らして、リストアにかかる時間を測定する必要があります。書面上は RTO を満たしていても、実際には満たせないリストアは課題です。
• リストア手順は文書化してバージョン管理し、担当者を定める必要があります。担当者は、訓練結果に対して説明責任を負います。

レジリエンス計画のテンプレート項目

すべてのレジリエンス計画には、次の構造化された項目を含める必要があります。

項目	説明	必要な証拠
システム境界	この計画の対象範囲と対象外の範囲	アーキテクチャ図または境界を記した文書
障害モード	システムがどのように障害を起こしうるか：コンポーネント、依存関係、リージョン、データ、オペレーターのエラー	発生可能性と影響を含む障害モード分析
依存関係マップ	このシステムが依存する上流システム、およびこのシステムに依存する下流システム	システム名、依存先ごとの障害時の動作、利用側との契約
縮退時の選択肢	各障害シナリオで何を停止し、何を維持するか	根拠を含むティアの割り当て、ユーザーへの影響評価
RTO/RPO の意思決定記録	システムおよびシナリオごとの、コンテキストに応じた復旧目標	数値をハードコードせず、トレードオフを記録する意思決定記録のテンプレート
データの完全性	復旧後にデータの正確性と一貫性をどのように検証するか	復元後の検証手順、チェックサム、照合プロトコル
復旧手順	前提条件と成功基準を含む、段階的な復旧プロセス	バージョン管理された手順、担当者の割り当て、最終訓練日
コミュニケーション計画	各復旧シナリオで、誰に、いつ、どのチャネルを通じて通知するか	通知テンプレート、関係者リスト、エスカレーション連絡先
訓練スケジュール	各復旧シナリオを最後に訓練した時期と、次回の再訓練時期	訓練の証拠：日付、シナリオ、結果、所見
フォローアップ作業台帳	訓練での所見を、担当者が割り当てられた実装・テスト・運用作業に変換したもの	所見ごとの担当者、目標日、検証方法、ステータス

ルーティングと関連スキル

このスキルは、次の機能を組み合わせ、関連スキルにルーティングします。

• site-reliability-engineering — インシデント指揮、オンコール運用、SLO/SLI フレームワーク、エラーバジェット。Resilience-and-recovery はインシデント発生前の設計と訓練の証拠を担い、SRE は実際のインシデント対応を担います。
• platform-engineering — インフラストラクチャの実装、CI/CD、コンテナオーケストレーション、サービスネットワーキング。Resilience-and-recovery はレジリエンス要件を担い、Platform engineering はその要件を満たす実装を担います。
• data-engineering — バックアップ戦略の実装、WAL アーカイブ、スナップショット管理。Resilience-and-recovery は、復元テストの証拠とデータ完全性の検証プロトコルを担います。
• secure-software-engineering — セキュリティ要件、脅威モデリング、セキュア設計。Resilience-and-recovery は、セキュリティインシデントにおけるレジリエンスの側面、つまりセキュリティイベント発生後も復旧能力が維持されることを担います。
• release-engineering — 段階的デリバリー、カナリアデプロイ、ロールバック手順書。Resilience-and-recovery は訓練を通じてこれらの仕組みを検証し、その証拠をリリース準備状況に反映します。
• incident-learning（wave 5）— インシデントと訓練の所見を、完了の証拠を伴う検証済みのフォローアップ作業に変換します。Resilience-and-recovery は、インシデントをまたいだパターン分析のために、訓練と DR テストの所見を incident-learning パイプラインに提供します。

このスキルは、コンポーネント機能として production-excellence バンドル（wave 6）に情報を提供します。訓練結果、RTO/RPO の意思決定記録、フォローアップ作業台帳といったレジリエンスの証拠が production-excellence の証拠パケットに反映され、実施／中止／延期／例外の準備状況を判断します。