このユニットの結論
正しい入力で正しく動くことを確かめるテストだけでは、本番は守れません。
部品を止め、相手を止め、通信を遅らせ、処理を集中させて、「壊れたときに設計どおり振る舞い、戻るか」を本番の前に確かめる。壊れないことは約束できないので、壊れ方を約束し、それを試験で証明します。
1. 何の話か
このユニットは、システムを意図的に壊して、耐え方と戻り方を確かめる試験の話です。
06-05 「絶対に止まらない」は要件になるのか で、「止まらない」ではなく「止まったら何分で、誰が、どう戻すか」を要件にすることを学びました。要件にしたなら、確かめる必要があります。それがこの試験です。世界で共有されている考え方では「レジリエンス試験」「カオスエンジニアリング」などと呼ばれます。
2. なぜ必要か
壊して確かめないと、
- 二重化しているはずの部品が、実際には切り替わらないことを本番の故障で知る
- 相手システムが止まると自分も止まる設計になっていることを、相手の障害で知る
- 処理が集中したときに受け付けを絞る仕組みがなく、連携の基盤ごと倒れる
- 監視が故障を検知せず、利用者からの連絡で気づく
ということが起きます。どれも、本番の前に壊してみれば分かったことです。
3. このユニットで分かること
- 壊れる状況の選び方
- 「期待する振る舞い」を先に書く理由
- 試験の結果を設計と運用に戻す方法
4. 壊れる状況を選ぶ
状況は、構成図と連携の一覧から選びます。思いつきで選ぶと、都合の良い（軽い）状況だけになります。
| 種類 | 状況（一般的な例） | 確かめること |
|---|---|---|
| 部品の故障 | 計算機 1 台の停止、データベースの主系の停止、記憶領域の満杯 | 自動で切り替わるか。切り替え中の処理は失われないか |
| 相手の停止・遅延 | 連携先のシステムが応答しない、30 秒遅れる、誤った応答を返す | 自分の業務は続くか。再開後に追いつくか |
| 通信の問題 | 一部の経路の切断、断続的な失敗 | 再試行で成功するか。二重に処理されないか |
| 処理の集中 | 通常の 5 倍の要求、一斉のログイン | 受け付けを絞って遅れても失わないか。監視が警告するか |
| 時刻と順序 | 時刻のずれ、順序の入れ替わり | 日付の境目の処理が正しいか。順序に依存していないか |
5. 期待を先に書き、結果を戻す
期待する振る舞いを先に書きます。 「利用者は気づかない」「取り込みは止まるが業務は続く」「安全に止まって知らせる」のどれかを、状況ごとに決めてから壊します。結果を見てから期待を書くと、何が起きても「想定どおり」になります。
測るものは、検知までの時間、自動で切り替わるまでの時間、人が気づくまでの時間、戻るまでの時間、失われた処理の有無です。特に「失われた処理」は見落とされます。止まらなくても処理が失われれば、業務は壊れています。
結果は設計と運用に戻します。 期待との差の原因（設計、設定、手順、監視）を書き、直して再試験します。直しきれない弱さは「残っている弱さ」として、障害対応の計画（OPS-004 障害対応計画）に引き継ぎます。計画と結果は TST-008 レジリエンス試験計画・結果 に残します。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の壊れ方に関する記載
- 約36本のシステム連携。連携の経路に SYS-06 システム連携基盤を通るものと、直接つなぐものがある。外部サービスとして SYS-03 勤怠・工数管理SaaS がある
- システムに SYS-11 監視・ログ基盤 がある。Vendor B クラウドブリッジの担当範囲に クラウド基盤、ネットワーク、連携、監視 が含まれる
- 成果物に TST-008 レジリエンス試験計画・結果、OPS-004 障害対応計画 がある
- P-010 宮田 直人 — テスト・品質管理リーダー、P-011 山下 恵 — 本番移行・運用リーダー
アステリア案件でどの状況が試され、システムがどう振る舞ったかは、正本に記録がありません。記録なし
6. THINK — 「二重化してあるので試験は不要」
テスト計画のレビューで、基盤の担当者が次のように言いました。
「データベースは二重化してあり、自動で切り替わる設計です。わざわざ止めて試験する必要はありません。」
問題
この説明で、試験を省いてよいでしょうか。
判断例を開く
判断
「設計」は、動くことの証明ではありません。
確認すること:
- 切り替えの設定が、本番相当の環境で実際に動くことを一度でも見たか
- 切り替えにかかる時間は何秒か。その間の処理は再試行で成功するか、失われるか
- 切り替わったことを監視が検知し、人に知らせるか
- 切り替わったあと、元に戻す手順はあるか。それも試したか
- 業務アプリの側が、切り替えで接続が切れたときに正しく再接続するか（データベースだけの問題ではない）
二重化は「切り替わるはず」の仕組みです。「切り替わった」を試験の記録で示して初めて、要件を満たしたと言えます。
7. よくある失敗
- 性能の試験だけを行い、壊れ方の試験を行わないまま稼働する
- 軽い故障だけを試し、相手の停止や処理の集中を試さない
- 「止まらなかった」だけを見て、失われた処理に気づかない
- 試験で見つかった差を直さず、「次の機会に」のまま稼働する
8. 成果物との接続
- TST-008 レジリエンス試験計画・結果：壊れる状況、期待する振る舞い、測るもの、結果と直したこと、残っている弱さ
- OPS-004 障害対応計画：試験で分かった壊れ方と残っている弱さを、障害のときの初動に引き継ぐ
9. AI WORKFLOW — 壊れる状況の候補を網羅させる
AIは、部品と連携の一覧から、壊れ方の候補を網羅的に挙げ、計画の抜けを探す下書きに役立ちます。
指示例:
「次の部品と連携の一覧から、部品ごと・連携ごとに起こりうる壊れ方（停止、遅延、誤った応答、切断、集中）を一覧にし、添付の試験計画にある状況と、ない状況を分けて示してください。期待する振る舞いの提案や、優先順位の評価はしないでください。」
10. REVIEW — AIの候補を確認する
- AIが挙げた壊れ方が、この構成で起こりうるか（一般論をそのまま載せていないか）
- 「ない状況」について、意図して外したのか、見落としかを人が区別したか
- 構成の情報を AI に渡してよいか（構成情報の扱い）を事前に確かめたか
11. 人間が判断すること
- どの状況を、どこまで本番相当の環境で壊すか
- 期待との差を直すか、残っている弱さとして受け入れるか
- 試験の結果を稼働判定にどう反映するか
Go / No-Go と重大障害判断は、AIへ最終委任しない事項です（正本の方針）。
12. 判断演習
「夜間に工数を取り込み、翌朝までに原価を集計する」処理について、壊れる状況を 3 つ選んでください（部品の故障、相手の停止、処理の集中から 1 つずつ）。
それぞれについて、「期待する振る舞い」を 1 文で書き、「測るもの」を 2 つ挙げてください。そのうえで、期待どおりにならなかった場合に、翌朝の業務がどうなるかを書いてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
壊れ方は試験で証明する。構成から状況を選び、期待する振る舞いを先に書き、壊して測り、差の原因で設計と運用を直す。失われた処理を見落とさない。