「落ちないシステム」より「戻せるシステム」を：一人情シスが可用性を捨てて復旧訓練に走るべき理由
目次
「システムは絶対に止めてはならない」 「サーバーは二重化（冗長化）するのが常識だ」
インフラ設計の議論において、この原則は疑う余地のない正論として語られます。 SLA（稼働率）99.99%。年間ダウンタイムを52分以内に抑えるこの指標を掲げ、クラウド事業者や大手SIerはロードバランサー、マルチAZ、Active-Activeクラスタといった高可用性（High Availability: HA）構成を提案します。
しかし、社員数100〜300人規模で専任の情シスが1〜2名の企業において、高可用性の過剰な追求は逆効果を生みます。
目指すべきは「絶対に停止しないシステム（Availability）」ではなく、「停止しても確実かつ単純な手順で元の状態へ戻せるシステム（Recoverability）」です。可用性の呪縛を解き、復旧能力へリソースを全振りすべき理由と設計方針を整理します。
高可用性構成が内包する構造リスク
構成の複雑化がトラブルシューティングを困難にする
単一サーバー構成に比べ、複数ノードをクラスタリングし、ロードバランサーを挟んで自動フェイルオーバーを組む構成は、アーキテクチャが格段に複雑化します。 複雑なシステムは、障害の発生パターンも複雑化します。
- 単一構成の場合: サーバーダウンを検知し、再起動またはインスタンス再作成を行う。判断導線は極めて明確です。
- 冗長構成の場合: プライマリがダウンしたにもかかわらずセカンダリへの昇格が中途半端に失敗し、両系が不整合なデータを書き込み続ける（スプリットブレイン現象）。
この状態に陥った際、深夜にたった一人でネットワークパケットを解析し、データベースのトランザクションログを手動修復できるでしょうか。 「可用性を高めるための機構」そのものが新たな単一障害点となり、平均復旧時間を大幅に悪化させる。これがHA構成が抱える典型的なパラドックスです。
オペレーションミスとランサムウェアは冗長化できない
インシデントの主因は、ハードウェアの物理故障よりも、設定変更ミスやデータの誤削除、ランサムウェア感染といった人的・論理的要因が大半を占めます。 これらは高可用性構成では防げません。リアルタイムでデータ同期を行っている場合、「誤った削除操作」や「ファイルの暗号化」も瞬時に全ノードへ同期され、バックアップごと共倒れになります。
MTBF（故障間隔）よりMTTR（復旧時間）を優先する
追うべき指標を根本から切り替えます。平均故障間隔（MTBF: Mean Time Between Failures）を伸ばす努力をやめ、平均復旧時間（MTTR: Mean Time To Recovery）を最短化することへ工数を集中させます。
- 5年に1度しか停止しないが、障害発生時の復旧に3営業日を要し、データ整合性の確認が難航するシステム
- 年に1〜2回停止するものの、誰でも標準化された手順で、確実に30分前のスナップショットから即座に立ち上げ直せるシステム
少人数の情シス現場において、事業の継続性を真に担保できるのは後者の設計です。
復旧ファーストの具現化
スナップショットを軸としたロールバック設計
複雑なレプリケーションソフトに予算を割く前に、イミュータブル（改変不可）なバックアップストレージを確保します。 OSおよびデータボリューム全体のスナップショット（AWSであればAMIやEBSスナップショット、オンプレミスならVMスナップショット）を日次および数時間単位で自動取得します。
障害発生時、原因追及で時間を空費しません。 「直前の正常なスナップショットへロールバックする」。 この単一の手順で業務を再開させます。根本原因の究明は、障害インスタンスを隔離して別環境で検証すれば十分です。
検証されていないバックアップは存在しないに等しい
「バックアップは自動で取得している」と回答する担当者に対し、「直近でそのバックアップデータから別サーバーを起動し、業務疎通テストを実施したのはいつか」と問うと、多くの現場で言葉が詰まります。 リストア手順書が存在しない、あるいは手順が古くて動作しないバックアップは、ストレージを消費しているだけのデータです。
四半期に一度、ステージング環境へバックアップを復元し、アプリケーションが正常起動することを確認する「リストア避難訓練」。この実証プロセスの反復こそが、有事の際の初動を支えます。
ステークホルダーとの合意形成
技術的な対策と同等に重要なのが、経営陣および業務部門との期待値調整です。
停止の可能性を事前に明文化する
「自社のシステム規模とIT投資額では、年数回の突発停止をゼロにはできません。ただし、停止した場合でも最大4時間以内に業務を復旧できる手順と体制を担保しています」
SLAのハードルを現実的な水準へ引き下げ、経営陣と合意を交わしておきます。事前の合意があれば数時間の停止は「想定内の運用計画」として処理できますが、合意がなければ数分の停止でも「重大なIT事故」として責任追及に発展します。
データ損失許容期間（RPO）の現実的合意
「サーバーが全損した際、直近2時間分の入力データの消失は許容できますか。それとも数千万円を投資してリアルタイム完全同期を目指しますか」
現実的なコスト感を提示すれば、大半の中小企業は「2時間分なら業務伝票から再入力してリカバリーする」と判断します。これにより高額なレプリケーション設計を回避し、シンプルな定期スナップショット運用へ落とし込むことが可能になります。
単純さこそが最大の耐障害性である
一人情シスが対峙すべき最大の脅威は、ハードウェアの故障ではありません。「複雑化しすぎて自ら制御不能に陥ったシステムアーキテクチャ」です。
可用性を追い求めるほどシステムはブラックボックス化し、運用の属人化を加速させます。対照的に、復旧能力（Recoverability）を突き詰めたシステムは構成が単純化され、手順が標準化され、誰が対応しても再現性のある結果を導き出せます。
「システムはいつか停止する。しかし確実に元の状態へ戻せる」。この割り切りと、検証済みのリストア手順書を整備すること。それこそが、限られた体制で事業のITインフラを守り抜く最も確実な防衛戦術です。