これは何か
レジリエンス試験計画・結果は、部品の故障、相手システムの停止、通信の遅延、処理の集中といった「壊れる状況」を意図的に起こし、システムが設計どおりに耐え、戻るかを確かめた計画と結果をまとめた成果物です。
性能試験（TST-005 性能試験結果報告書）が「速さ」を確かめるなら、この試験は「壊れ方」を確かめます。06-05 「絶対に止まらない」は要件になるのか で学んだとおり、止まらないことは約束できません。約束できるのは「壊れたときにこう振る舞い、これだけで戻る」です。その約束が本当かを、本番の前に壊して確かめます。
なぜ作るか
- 二重化や自動の切り替えが、設計どおりに動くことを本番の前に確かめる
- 相手システムが止まったとき、自分のシステムが止まらずに業務を続けられることを確かめる
- 「戻る」までの時間を測り、復旧時間の目標と比べる
- 障害対応（13-01 本番障害が起きたら最初に何をするか）の手順と監視が、実際の壊れ方で機能するかを確かめる
誰が使うか・いつ作るか
- 作る人：テストの責任者と、基盤を担当する会社。システムアーキテクトが「壊れる状況」の一覧を提供し、運用の担当が監視と手順の確認に加わる
- 使う人：設計者、運用・監視の担当、障害対応の指揮者、稼働判定を行う人
- 一般的には、つなげたテストが安定したあと、性能試験と並行して計画を作り、本番相当の環境で実施します。稼働後も、構成の変更や訓練に合わせて繰り返します
- アステリア案件でこの種の試験が行われたか、どんな状況を試したかは、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
壊れ方に関係する記載
- 約36本のシステム連携。連携の経路に SYS-06 システム連携基盤を通るものと、直接つなぐものがある
- 外部サービスとして SYS-03 勤怠・工数管理SaaS（Vendor D タイムリンク）がある
- システムに SYS-11 監視・ログ基盤 がある。Vendor B クラウドブリッジの担当範囲に クラウド基盤、ネットワーク、連携、監視 が含まれる
- 成果物に TST-001 テスト戦略書、OPS-004 障害対応計画、OPS-008 災害復旧計画・訓練結果 がある
- P-010 宮田 直人 — テスト・品質管理リーダー、P-011 山下 恵 — 本番移行・運用リーダー
どの部品の故障や相手の停止が試され、システムがどう振る舞ったかは、正本に記載がありません。未確定
主な項目
一般的には、次の項目で構成します。
- 試験の目的と範囲：どのシステム・連携を対象にするか。本番相当の環境か
- 壊れる状況の一覧：部品の故障（計算機、データベース、記憶領域）、相手システムの停止・遅延・誤った応答、通信の切断、処理の集中、時刻のずれ。構成図と脅威の整理から選ぶ
- 状況ごとの期待する振る舞い：止まらずに続くか、一部の機能だけ止まるか、安全に止まるか。利用者に何が見えるか。監視で何が検知されるか
- 起こし方：どうやって壊すか（部品を止める、通信を遮る、相手の模擬を遅らせる）。業務への影響を限る手段
- 測るもの：検知までの時間、自動で切り替わるまでの時間、人が気づくまでの時間、戻るまでの時間、失われた処理の有無
- 結果：状況ごとの実測と、期待との差。差の原因（設計、設定、手順、監視）
- 直したこと：差の原因ごとの対応と、再試験の結果
- 残っている弱さ：試験で明らかになったが、今は受け入れる弱さと、その理由
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 壊れる状況と結果の表
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
次の表は、計画と結果の書き方を学ぶための例です。数値・状況はすべて教材上の架空の例で、アステリア案件の記録ではありません。
| 状況（教材上の例） | 起こし方 | 期待する振る舞い | 測るもの |
|---|---|---|---|
| 業務アプリの計算機 1 台が停止 | 1 台を強制停止 | 利用者は気づかない。残りの台で処理が続く。監視が 1 分以内に検知 | 検知までの時間、処理の失敗件数 |
| 工数の外部サービスが 30 分応答しない | 連携の模擬で応答を止める | 取り込みは止まるが、新基幹の業務は続く。再開後に取り込みが自動で追いつく | 業務への影響、再開後の取り込みの遅れ |
| データベースの主系が停止 | 主系を強制停止 | 従系に自動で切り替わる。切り替え中の処理は再試行で成功する | 切り替えまでの時間、失われた処理の有無 |
| 連携基盤への処理が通常の 5 倍に集中 | 負荷の道具で集中させる | 受け付けを絞り、遅れても失わない。監視が警告を出す | 遅れの最大、失われた処理の有無 |
| 状況（教材上の例） | 結果 | 期待との差 | 原因 | 直したこと | 再試験 |
|---|---|---|---|---|---|
| 計算機 1 台が停止 | 処理は続いた。検知に 4 分 | 検知が 3 分遅い | 監視の間隔が 3 分 | 間隔を 30 秒に | 検知 45 秒。合格 |
| 外部サービスが 30 分応答しない | 業務は続いた。再開後の追いつきに 50 分 | 追いつきが遅い | 再送の間隔が固定で長い | 間隔を段階的に | 追いつき 12 分。合格 |
| データベースの主系が停止 | 切り替え 40 秒。処理が 3 件失われた | 失われた処理がある | 再試行が切り替え時間より短く打ち切り | 再試行の回数を増やす | 失われた処理 0。合格 |
| 処理が 5 倍に集中 | 受け付けを絞れず、連携基盤が停止 | 止まった | 受け付けの上限が未設定 | 上限と待ち行列を設定 | 遅れ最大 8 分、失われた処理 0。合格 |
読み方
- 壊れる状況が、構成図の部品と連携から網羅的に選ばれているか（都合の良い状況だけでないか）
- 状況ごとに「期待する振る舞い」が先に書かれているか（結果を見てから期待を書いていないか）
- 測るものに「失われた処理の有無」が入っているか（止まらなくても、処理が失われれば業務は壊れる）
- 期待との差に原因が書かれ、直して再試験しているか
- 残っている弱さが書かれ、受け入れの理由があるか
書き方
- 構成図（ARC-007 環境・配置構成図）の単一障害点の一覧と、連携の一覧から、壊れる状況を選ぶ
- 状況ごとに期待する振る舞いと測るものを先に書き、関係者で合意する
- 本番相当の環境で、業務への影響を限りながら起こす
- 結果と差を記録し、原因ごとに直して再試験する
- 残った弱さを運用の設計と障害対応の計画に引き継ぐ
何を書いてはいけないか
- 「問題なく動いた」だけの結果（何を測り、期待と比べてどうだったかを書く）
- 期待する振る舞いを結果に合わせて後から書くこと
- 本番で業務中に、影響を限る手段なしに壊すこと
- 実在の製品名を、案件の正式な採用として書くこと（正本に記載がない）
どこを見るか
- 壊れる状況の網羅
- 先に書かれた期待する振る舞い
- 失われた処理の有無
- 差の原因と再試験
- 残っている弱さ
赤信号
- 二重化しているはずの部品を、一度も止めて確かめたことがない
- 相手システムの停止を試しておらず、「相手が止まったら自分も止まる」ことを本番で知る
- 試験で見つかった差が直されず、「次の機会に」のまま稼働する
- 稼働後に構成が変わっても、再試験が行われない
よくある失敗
- 性能試験だけを行い、壊れ方の試験を行わないまま稼働し、最初の部品の故障で全体が止まる
- 都合の良い状況（軽い故障）だけを試し、相手の停止や処理の集中を試さない
- 「止まらなかった」ことだけを見て、失われた処理に気づかない
関係するUnit・成果物・危機演習
- Unit：10-08 壊して確かめるとはどういうことか、06-05 「絶対に止まらない」は要件になるのか、13-01 本番障害が起きたら最初に何をするか、07-04 相手システムが止まっていたらどうするか
- 成果物：TST-001 テスト戦略書、TST-005 性能試験結果報告書、ARC-007 環境・配置構成図、OPS-004 障害対応計画、OPS-008 災害復旧計画・訓練結果
- 危機演習：この成果物を直接の題材にする危機演習はありません
AI WORKFLOW
AIは、構成図の部品と連携の一覧から、壊れる状況の候補を網羅的に挙げ、計画の抜けを探す下書きに役立ちます。
「次の部品と連携の一覧から、部品ごと・連携ごとに起こりうる壊れ方（停止、遅延、誤った応答、切断、集中）を一覧にし、添付の試験計画にすでにある状況と、ない状況を分けて示してください。期待する振る舞いの提案や、優先順位の評価はしないでください。」
REVIEW
- AIが挙げた状況が、この構成で起こりうるか（一般論の候補をそのまま載せていないか）
- 「ない状況」について、意図して外したのか、見落としかを人が区別したか
- 構成の情報を AI に渡してよいか（構成情報の扱い）を事前に確かめたか
人間が判断すること
- どの状況を試験するか、本番相当の環境でどこまで壊すか
- 期待との差を直すか、残っている弱さとして受け入れるか
- 試験の結果を稼働判定にどう反映するか
Go / No-Go と重大障害判断は、AIへ最終委任しない事項です（正本の方針）。
いつ使うか
この教材では STAGE 10｜本当に動くことを証明する の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この計画と結果を読んだ運用の担当は、「どの部品が壊れたとき、システムがどう振る舞い、どれだけで戻り、どこは戻らなかったか」を、推測ではなく試験の記録で説明できますか？