架空企業「みらい業務サービス」の社内依頼・承認管理アプリの例。実在する会社・案件・人物は含まない。 記事「構成図を描き、故障時の影響と復旧の方針を決める」（05-04）の本文で使った内容をまとめたもの。空欄版は 05-04-architecture-recovery_template.md。

復旧目標の数値はすべて架空の仮定であり、実測したものではありません。

1. 構成図

[画面]  ── 利用者の入力・閲覧
   │
   ▼
[処理]  ── 権限の確認、状態遷移の実行
   │
   ▼
[保存先] ── 依頼・利用者・履歴のデータ

2. 故障箇所ごとの影響

故障箇所影響を受ける操作影響を受けないもの
画面閲覧・編集・提出・承認・差戻し・割当のすべてが操作できなくなる保存先のデータ自体は保全されている
処理同上保存先のデータ自体は保全されている
保存先同上に加えて、データの閲覧そのものができなくなる—

3. バックアップと復旧目標

項目この記事での扱い確認状況
バックアップ対象保存先のデータ（依頼・利用者・履歴）05-01に基づく
バックアップ頻度1日1回架空の仮定
復旧目標（どの時点まで）直近のバックアップの基準時点まで（最大1日分の変更が戻らない可能性）架空の仮定
復旧目標（どれくらいの時間で）半日以内架空の仮定
確認方法復元後、基準時点の依頼・履歴の件数・内容・関係と照合し、戻らない変更を一覧にする具体的な演習はSAMPLE-Cで扱う

4. 完了条件の確認

5. 次工程へ渡すもの