障害試験の設計 — 本番前にどこまで壊して確かめるか

冗長化構成を組んだだけでは、本番環境が障害に耐えられる保証にはならない。障害試験とは「壊せるだけ壊す」作業ではなく、何を試験で確かめ、何を机上で済ませるかを設計段階で決める判断業務だ。復旧時間・データ欠損の合否基準を事前に設定し、稼働系への踏み込み範囲を明示することが設計の核心となる。どこまで壊して何を確かめるかを決めずに試験を始めると、試験が終わっても「本当に大丈夫か」という問いは解消されないまま本番を迎えることになる。

「冗長化したから大丈夫」を試さず本番へ出す構造

構成図と実動作のギャップが安心の幻想を生む

HA構成やRAID、ロードバランサーによる冗長化は、正しく設計されていても「切り替わるはず」という期待にとどまる面がある。構成図の上では二重化されていても、実際にフェイルオーバーが発動したときに切り替え先が正しく応答するか、セッションが引き継がれるか、監視アラートが想定どおりに上がるか——これらは動かして確かめない限り不明のままだ。現場では「構成図どおりに組んだのに、いざフェイルオーバーしたら監視通知が飛ばず、誰も気づかないまま30分以上経過した」という話をよく聞く。構成の正しさと動作の正しさは別の問いであり、後者は試験でしか答えが得られない。

試験をスキップする動機と組織的な構造

障害試験が省略される背景には、スケジュールの圧縮・環境コストの問題・「試験で何かが壊れることへの恐怖」という三つの動機が重なることが多い。特に本番同等環境を別途用意できないプロジェクトでは、「試験のために壊すリスクを取れない」という判断が下されやすい。しかし試験をスキップした結果、初回の本番障害が事実上の障害試験になるという構造が生まれる。これは試験コストを将来の障害対応コストに先送りしているだけであり、設計判断としては非常に脆弱だ。試験できない理由を整理し、代替手段（机上確認・段階的な試験）を選ぶことが、担当者に求められる判断となる。

本番初日が実質的な障害試験になるリスク

試験なしで本番へ出た場合、最初の実障害が試験の代わりになる。その際の問題は、試験と違って「止めてよい時間帯」「許容できる影響範囲」「中止判断のタイミング」が決まっていない点だ。試験であれば事前に合否基準と影響範囲を決めて臨めるが、本番の実障害では判断が後手に回る。中規模のWebシステムでも、初回フェイルオーバー時に担当者が手順を誤り、復旧に予定の3倍以上の時間を要した事例は珍しくない。障害試験の設計とは、こうしたリスクを本番前の制御された環境で踏んでおくための判断だ。

試験で確かめる故障と机上で済ませてよい故障の判断

実際に壊さなければ分からない障害の特徴

実際に障害を発生させなければ確認できないのは、主に「タイミング依存の挙動」「複数コンポーネントの連鎖反応」「監視・通知系の動作」の三つだ。たとえばアクティブ/スタンバイ構成でのフェイルオーバーは、切り替えタイミングでのセッション断・データの一貫性・ロードバランサーのヘルスチェック応答の順序関係が複雑に絡む。設計ドキュメントを読み込んでも「そうなるはず」という推測にとどまり、実際の切り替え試験で初めて想定外のタイムラグや接続エラーが露見することが多い。特に監視アラートの発報タイミングは、障害試験でしか正確に確認できない代表的な項目だ。

机上確認が有効な範囲とその限界

一方、机上確認（設計レビュー・構成確認・ログ解析）が有効なのは、「論理的な設定の整合性」「静的な設計ミス」を早期に発見する局面だ。VRRP優先度の設定値・フェイルオーバーグループの定義・バックアップスクリプトの対象パスの漏れといったものは、試験の前に机上で潰しておくべきだ。試験のたびに設定ミスが露見していては、障害試験の工数が増えるばかりで本来の確認に集中できない。机上確認と試験を組み合わせる設計では、机上で「設定の正しさ」を担保し、試験で「動作の正しさ」を確認する役割分担を明確にすることが効率化の鍵となる。

優先度マトリクスで試験対象を絞る

試験対象を絞るための判断軸は「発生確率」と「業務影響度」の二軸だ。発生確率が高く業務影響度も大きい故障（ディスク障害・ネットワーク断）は試験必須、発生確率が低く影響も限定的な故障（特定プロセスの一時停止・サブシステムのタイムアウト）は机上確認で済ませる、という整理ができる。試験対象を絞ることで、限られたスケジュールの中で本当に必要な確認に集中できる。10台構成のシステムでも、全障害パターンを試験しようとすれば数十のシナリオが出てくるため、絞り込みの設計判断は避けられない。絞り込んだ残りについては「対象外とした理由」を記録しておくと、後の検証工程での問い合わせに答えやすくなる。

机上確認・切替訓練・稼働系での故障注入の比較

3つのアプローチの特性整理

障害試験のアプローチは大きく「机上確認」「切替訓練（非稼働系）」「稼働系での故障注入」の三つに分類できる。それぞれのコスト・リスク・確認精度は大きく異なり、どれか一つで完結するものではない。以下の比較表を試験設計の組み合わせ判断に活用してほしい。

アプローチ	確認精度	環境コスト	業務リスク	主な適用場面
机上確認（設計レビュー・ログ解析）	低〜中（静的ミスのみ）	なし	なし	試験前の設定整合性チェック・低影響故障の確認
切替訓練（非稼働系・ステージング）	中〜高（動的挙動を確認）	中（環境複製コスト）	低（本番無影響）	フェイルオーバー・バックアップ復元・プロセス再起動
稼働系での故障注入（カオスエンジニアリング的手法）	最高（本番同等の挙動）	低（追加環境不要）	高（業務影響が発生しうる）	本番同等確認が必須・ステージングで再現不可な事象

環境コストとリスクのトレードオフ

切替訓練に使う非稼働系（ステージング・検証環境）は、本番と同等のハードウェア構成・ネットワーク構成を持つほど試験精度が上がるが、そのぶん環境複製コストがかかる。規模の大きいオンプレミス環境では、本番同等の試験環境を用意するだけで本番構築費の30〜50%程度のコストが発生することもある。一方、クラウド環境であれば試験期間だけインスタンスを立ち上げ、終わったら削除するという使い方で環境コストを抑えられる。稼働系での故障注入は環境コストがかからない反面、業務影響が直接発生しうるため、後述する境界設定が不可欠だ。三つのアプローチを組み合わせ、試験フェーズごとにどれを使うかを設計書に明記することで、関係者間の認識ずれを防ぎやすくなる。

電源・NIC・ディスク・プロセス — どの層から抜くか

物理層（電源・NIC）の試験と観察ポイント

物理層の故障試験は、論理的な冗長設定が本当に機能するかを確かめる最も直接的な手段だ。電源の片系を抜く試験では、UPS切り替えの応答時間・PDUの系統切り替えログ・サーバーのIPMIイベントログを同時に記録することが重要だ。NICの抜線試験では、ボンディング（bonding/teaming）の切り替え時間・ARP更新のタイミング・ロードバランサーのヘルスチェック応答がどの順序で変化するかを観察する。物理層の試験では「抜いた瞬間から監視アラートが上がるまでの時間」を計測しておくと、後の合否基準設定に使える具体的な数値が得られる。試験環境によっては、抜線からアラートまで15〜30秒のラグが発生することも珍しくなく、この数値を把握していないと合否基準の設定ができない。

ディスク・ストレージ層での試験設計

ディスク層の試験では、RAIDの縮退動作・ホットスペアへの自動再構築・ストレージのパス切り替えが主な確認対象になる。RAIDの縮退試験では、ディスクを1本抜いた状態でのI/Oパフォーマンス劣化幅を実測しておくことが重要だ。縮退時のスループットが通常時の60%以下まで落ちる構成では、業務システムへの影響が顕在化しやすく、アプリケーション側のタイムアウト設定との整合性を確かめる必要がある。マルチパス構成のストレージでは、パス切り替え時にI/Oが一時中断するタイミングがあり、その中断時間がアプリケーションのリトライ許容範囲に収まるかどうかが試験の判断ポイントになる。ディスク系の試験は物理的な操作が必要なケースが多く、遠隔での実施手順も含めた試験設計が求められる。

プロセス・サービス層での故障注入

プロセス層の故障注入は、物理操作なしにソフトウェア的に実施できるため、試験の反復がしやすい。Webサーバー・アプリケーションサーバー・データベースの各プロセスを強制停止し、自動再起動や系切り替えが規定時間内に完了するかを確認する。この層での設計判断ポイントは「どのプロセスをsystemd/supervisorで管理し、どれをクラスタウェアで管理するか」という役割分担の妥当性だ。試験でプロセス停止後の自動再起動が30秒以上かかるケースでは、ヘルスチェック間隔や再起動回数制限の設定を見直す契機になる。プロセス層の試験は比較的低リスクで繰り返せるため、試験の序盤に組み込み、手順・計測方法の習熟を兼ねる構成にするのが効率的だ。

合否基準（復旧時間・データ欠損）をどう置くか

RTO/RPOを試験の合否基準に落とし込む

障害試験の合否基準は、システムのRTO（目標復旧時間）とRPO（目標復旧時点）から逆算して設計する。「フェイルオーバー完了まで60秒以内」「最大データ欠損5分以内」という形で数値を定めておかなければ、試験結果の評価が「なんとなく動いた」で終わってしまう。RTO/RPOは要件定義で記述されていることが多いが、それが試験の合否基準として計測手順に落とし込まれていないプロジェクトは意外に多い。要件定義上の「30分以内に復旧」という記述を、「切り替え操作開始から業務アプリケーションが正常応答を返すまでの秒数」という計測可能な基準に変換する作業が、試験設計の前提となる。

測定ポイントと計測方法の設計

合否判定に使う計測は、「何を起点とし」「何を終点とするか」を事前に決めておく必要がある。起点を「障害発生時刻（ログ上）」とするか「担当者が気づいた時刻」とするかで計測値が大きく変わる。終点も「プロセスが起動した時刻」と「サービスが正常応答を返した時刻」では差が出る。試験では少なくとも3〜5回の繰り返しで平均値と最大値を記録し、最大値が基準内に収まることを確認するのが望ましい。1回だけ試験して「OK」とするのは、たまたま短時間で切り替わっただけの可能性を排除できないため、統計的な根拠に欠ける判断となる。

段階的な基準設定と反復試験の組み方

試験の初期段階では、厳密な合否基準より「現状の復旧時間を計測する」フェーズとして設計するのが実際的だ。初回試験でRTOが大幅に超過しても、それは設計の改善情報として使える。試験→設定修正→再試験のサイクルを2〜3回回すことを前提に、試験日程を組む必要がある。構成変更を伴う修正が入る場合、再試験の工数として1〜2日分を追加で確保しておくことが設計判断として現実的だ。試験を1回で終わらせようとするほど、「動いたから合格」という曖昧な評価に流れやすく、後の本番障害で真価が問われることになる。

稼働中の系に踏み込んで被害を出す境界

本番同等環境と本番環境の線引き

稼働系への故障注入が必要になるのは、ステージング環境では再現できない条件——本番固有のデータ量・接続数・外部サービスとの連携——が試験に影響するケースだ。しかしこれは例外的な判断であり、原則は「本番同等環境で試験を完結させる」ことだ。本番同等環境が用意できない理由として挙げられるのは「コスト」「ライセンス」「外部連携の模擬困難」の三つが多い。コストについては試験期間限定の環境構築で対応できる場合も多く、安易に「本番でやるしかない」という判断に流れないための検討が求められる。「本番でしか確認できない理由」を列挙し、代替手段を検討したうえで残るものだけを稼働系試験の対象とする、という設計の流れが適切だ。

許容できる影響範囲の事前定義

稼働系で故障注入を実施する場合は、「許容できる影響範囲」を書面で事前に定義し、関係者が合意した状態で実施することが不可欠だ。たとえば「読み取り系のAPIは5秒以内の応答遅延まで許容」「書き込み系は試験中は完全に停止する」という粒度で定める。この定義がない状態で試験を始めると、想定外の範囲まで影響が広がったときに中止判断が遅れ、被害が拡大する。現場では、境界の定義なしに稼働系試験を始め、想定外のリードレプリカへの影響が発生したにもかかわらず試験を継続してしまい、後処理に大きな工数を要した事例が報告されている。

試験の中止判断基準

試験を途中で止める判断基準も設計の一部だ。「このラインを超えたら即座に中止する」という基準を事前に設定しておかなければ、試験中の判断が感情的・場当たり的になりやすい。中止基準の例としては「監視アラートが想定外のシステムまで波及した」「データ欠損が事前定義の上限値を超えた」「復旧手順を開始してから15分経過しても復旧の見通しが立たない」といったものが挙げられる。中止判断の権限者を事前に指名しておくことも重要で、試験中に権限者が不在では判断が遅れる。試験設計書に「中止基準」「中止判断者」「中止後の復旧手順」を明記する習慣が、稼働系試験のリスクを制御する上で欠かせない。

障害試験設計チェックリスト

以下のチェックリストを試験設計フェーズで確認することで、見落としがちな判断項目を事前に潰せる。すべての項目を一度に満たす必要はなく、未対応の項目は「机上確認で代替する」「次フェーズで実施する」という形で明示的に残す判断も設計の一部だ。手を動かす手順の詳細は本体の構築ガイドやセミナーに委ねるとして、ここでは「何を決めたか・何を保留にしたか」を記録することを目的とする。

1. 試験対象の故障を「発生確率×業務影響度」のマトリクスで整理し、試験必須・机上確認・対象外を区分けしているか
2. 合否基準（復旧時間・データ欠損の上限）を計測可能な形で定義し、計測の起点・終点を明記しているか
3. 試験環境が本番と異なる点（ハードウェア台数・データ量・外部連携）を列挙し、差分の影響を評価しているか
4. 物理層（電源・NIC）・ディスク層・プロセス層それぞれで実施する試験シナリオを定義しているか
5. 監視・アラートの発報が試験シナリオの中に含まれており、アラート未発報も「不合格」と定義しているか
6. 試験は最低2〜3回の繰り返しを計画に組み込み、最大値が合否基準内に収まることを確認する設計になっているか
7. 試験→設定修正→再試験のサイクルを前提に日程を組み、再試験工数（1〜2日分）を確保しているか
8. 稼働系試験の場合、許容できる影響範囲・中止基準・中止判断者を書面で定義し、関係者の合意を得ているか
9. 試験結果の記録方式（ログの取得方法・タイムスタンプの統一基準）を事前に決めているか
10. 試験後の復旧手順と確認項目を定め、試験によって本番相当の状態に戻せることを確認しているか