障害試験の設計 — 本番前にどこまで壊して確かめるか
冗長化構成の正しさと実際の動作の正しさは別の問いだ。障害試験とは「壊せるだけ壊す」作業ではなく、何を試験で確かめ何を机上で済ませるかを設計段階で決める判断業務。復旧時間・データ欠損の合否基準と稼働系への踏み込み境界を事前に設定することが設計の核心となる。
冗長化構成の正しさと実際の動作の正しさは別の問いだ。障害試験とは「壊せるだけ壊す」作業ではなく、何を試験で確かめ何を机上で済ませるかを設計段階で決める判断業務。復旧時間・データ欠損の合否基準と稼働系への踏み込み境界を事前に設定することが設計の核心となる。
本番への変更を誰が承認するかは、チームの規模や変更頻度によって設計が変わる。変更の分類基準・三つの承認モデルの比較・緊急変更の取り扱い・記録の置き場所・形骸化しきい値を整理し、変更管理フローの設計判断軸を示す。
データベースへの接続数上限とプール設計は、アプリ水平スケール時に最初の障壁になる。アプリ内プール・中間プーラー・直接接続の使い分け基準と、参照系・更新系の分離判断、プール過多による逆効果を整理する。
保存データの暗号化は「対策済み」とされやすいが、実装層・脅威モデル・鍵管理の設計が噛み合っていなければインシデント時に機能しない。どの層で何を守るかの判断軸、鍵管理の分離設計、多層化が招く復旧不能リスクの境界線を整理した設計判断ガイド。
Terraformなどインフラコードのapply実行主体は、変更追跡・権限管理・緊急対応の設計と直結する。手元実行・CI実行・マネージド実行基盤の特性を比較し、環境数・チーム規模・リスク許容度を軸に実行主体の設計判断を整理する。
Terraformのプロバイダ・モジュール・CLI本体のバージョンを固定するか追従するかは、構築の再現性と長期保守性を左右する設計判断。固定なしで起きる「planの破壊」の構造、lockファイルの正しい扱い、定期更新の組み込み方、EOL境界の見極め方を体系化する。
検証環境を「共有型」で運用するか「使い捨て型」で配るかは、チームの規模とインフラの成熟度によって答えが変わる。競合・汚染・廃棄の失敗を防ぐ設計の判断軸と、払い出し後の管理を破綻させないチェックポイントを整理した。
カットオーバー方式の選定を当日まで先送りにすると、時間と判断根拠の両方を失う。一斉切替・段階移行・並行稼働の選択は、データ整合性要件・トラフィック特性・ロールバック許容時間という三軸で決まる。設計フェーズで方針を固める論点を整理。
データ保管設計の失敗パターンと、高速・低頻度・アーカイブ各層の判断軸を解説。削除・降格タイミングの明文化、自動ライフサイクルと申請制の使い分け、階層を刻みすぎる落とし穴まで、設計判断に直結する視点をまとめる。
メール送信基盤の選択は到達率問題が出てから考えでは遅い。自前MTA・リレー中継・マネージドサービスの判断軸と、SPF/DKIM/DMARC認証の詰め方、経路分離の設計方針を構築フェーズで確定させるための設計判断を解説。