# 復旧のための設計 ## 定義 復旧のための設計(design for recovery)とは、システムが障害・侵害から既知の良い状態(known-good state)へ戻る能力を、事後の対応ではなく設計時の要求として組み込む考え方である。復旧を要する原因は、物理ハードウェアに起因する**ランダムエラー**、善意の人間が起こす**偶発的エラー**、その延長にある**ソフトウェアエラー**、意図的にシステムを妨害しようとする**悪意ある行為**の4種に分類され、原因の種別を問わず「意図した状態」をどれだけ正確に把握し逸脱を検知・修復できるかが復旧可能性の基盤になる。中心的な設計原則は、変更を展開する速度そのもの(機構がどこまで速く動けるか)と、実際にどれだけ速く動かすか(現在のリスク許容度に基づくポリシー)を分離することであり、この分離によって平常時のロールアウト機構をそのまま緊急時のロールバック機構として使い回せる——緊急用に別のシステムを用意すると、めったに使われないがゆえに肝心なときに機能しないというリスクを抱える。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 9 Design for Recovery]] §Design to Go as Quickly as Possible (Guarded by Policy)) ## 横断的知見 - **「レジリエンス」と「復旧」は、同一書籍が意図的に対にした2つの設計原則である**: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 8 Design for Resilience]] は、レジリエンスを障害の発生を**遅らせる・耐える**("before")設計品質として要約文で明示的に位置づけ、[[@2020__OReilly__Building Secure and Reliable Systems - Chapter 9 Design for Recovery]] は自らを、障害が起きた**後**にシステムを戻す("after")設計原則として同じく要約文で位置づける。両者は互いを参照し合う形で書かれており(第8章は「第9章が扱う復旧とは対照的に」、第9章は「第8章が扱うレジリエンスに対して」と述べる)、単独の章では閉じない対概念として設計されている。第8章が扱う多層防御・グレースフルデグラデーション・影響範囲の制御はいずれも障害の**進行**を制御する仕組みであるのに対し、第9章が扱う MASVN・失効機構・意図した状態の把握はいずれも障害が**確定した後**の巻き戻しを制御する仕組みであり、両者を併せて初めて「人手の介入を最小限に抑えて障害から立ち直る」というシステムの全体像が完成する。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 8 Design for Resilience]] §冒頭, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 9 Design for Recovery]] §要約) - **「機構の能力とポリシーの分離」という同型のパターンが、レジリエンスと復旧という異なる設計原則の双方で独立に採用されている**: 第8章は自動応答の設計で、反応速度を上げるための自動化そのものは推進しつつ、変更の規模・範囲を制限する「変更予算(change budget)」という別のポリシー層を明示的に重ねるべきだと論じる。第9章は、更新機構は想定しうる最速で動作するように作り、リスクと混乱に関する現在のポリシーに応じた速度制約は独立した仕組み(レートリミッティングマイクロサービス)として後から加えるべきだと論じる。前者は「自動化の暴走を防ぐ」動機、後者は「ポリシー変更のたびに侵襲的なコード変更をしなくて済むようにする」動機から出発しており、動機は異なるが、「機構自体は能力を最大化しつつ、実際の挙動を絞るのは分離された明示的なポリシー層に任せる」という設計判断は同一書籍の2つの章で独立に到達された共通解と言える。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 8 Design for Resilience]] §Automate Responsibly, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 9 Design for Recovery]] §Design to Go as Quickly as Possible (Guarded by Policy), §Isolate Your Rate-Limiting Mechanism to Increase Reliability) ## 未解決の問い - 「機構の能力とポリシーの分離」という設計パターンは、変更予算(第8章)とレートリミッティングマイクロサービス(第9章)という異なる実装で現れるが、両者を統一的な設計原則として定式化し、他の設計判断(例えばアクセス制御のポリシーエンジン分離)にも一般化できるか。 - 復旧速度を平常運用の変更速度と完全に同一機構にすることは、緊急時の即応性を高める一方で、平常運用のリズムを乱すコストをどこまで許容できるか。両章とも定性的な推奨にとどまり、定量的なトレードオフの分析はない。 - 復旧のための設計に投資する意思決定は、エラーバジェットの枠組みでどう定量化できるか。第9章は「システムは定期的にエラー状態に陥ることが前提」だから早期投資すべきだと述べるが、投資額とエラーバジェット消費の関係は示されていない。 ## 関連 - ソース: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 9 Design for Recovery]] / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 8 Design for Resilience]] - 概念: [[ロールバックとバージョン単調性]](復旧の速度制御を具体化する巻き戻し機構) / [[カナリアテスト]] / [[継続的デプロイ]] / [[ソフトウェア変更管理]] - 関連 MOC: なし(新規 concept) ## 出典 - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 9, §Design to Go as Quickly as Possible (Guarded by Policy). - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 8, §冒頭, §Automate Responsibly.