「落ちないシステム」より「戻せるシステム」を：一人情シスが可用性（SLA 99.99%）を捨てて復旧訓練に走るべき理由

「システムは止まってはならない」「サーバーは二重化（冗長化）が常識」

IT業界に長くいると、この教義が骨の髄まで染み込みます。 SLA（サービス品質保証）99.99%。これは年間ダウンタイムを52分以内に抑えるという数字ですが、クラウドベンダーや大手SIerは、これを金科玉条のように掲げ、ロードバランサー、マルチAZ、Active-Active構成といった「高可用性（High Availability: HA）構成」を提案してきます。

しかし、私は断言します。 社員数100〜300人規模、かつ情シスが少人数の企業において、この「高可用性神話」は百害あって一利なしです。

あなたが目指すべきは、絶対に止まらないシステム（Availability）ではなく、**「止まっても確実に、しかも単純な手順で元に戻せるシステム（Recoverability）」**です。

本稿では、なぜ中小企業の情シスが「可用性」を捨てて「復旧能力」に全振りすべきなのか、その現実的な解法を論じます。

なぜ「可用性」は危険なのか

1. 複雑さは脆弱さを生む

サーバーを1台で動かすより、2台でクラスタリングし、ロードバランサーを挟み、自動フェイルオーバーを組む方が、システム構成は圧倒的に複雑になります。複雑なシステムは、複雑な壊れ方をします。

単一構成の場合：「サーバーが落ちた」→「再起動する」。これだけです。
冗長構成の場合：「プライマリが落ちたが、なぜかセカンダリに切り替わらず、両系とも中途半端に生きている（スプリットブレイン）状態で、データ不整合が起きた」。

この状況を、夜中の3時に一人でトラブルシューティングできますか？「可用性を高めるための仕掛け」自体が新たな障害ポイントとなり、復旧を困難にする。これがHA構成の最大のパラドックスです。

2. 「誤操作」は冗長化できない

障害の原因の多くは、ハードウェア故障ではなく、オペレーションミス（設定変更ミス、誤ってデータを削除、ランサムウェア感染）です。これらは、どれだけ高可用な構成を組んでいても防げません。むしろ、リアルタイム同期されているがゆえに、「誤って消した」という操作も瞬時に全サーバーに同期され、全てのデータが同時に消失します。

「MTBF（壊れにくさ）」より「MTTR（直りやすさ）」

では、どう考えるべきか。指標を変えましょう。平均故障間隔（MTBF）を伸ばす努力をやめ、平均復旧時間（MTTR）を短くすることにリソースを集中します。

「5年に1回しか落ちないが、落ちたら復旧に3日かかり、その間データがどうなっているか分からないシステム」と、「半年に1回落ちるが、誰でもボタン一つで、必ず1時間前の状態に30分で戻せるシステム」。

一人情シスの現場で安心できるのは、圧倒的に後者です。

具体的な「復旧ファースト」設計

1. 「スナップショット」こそ最強の盾

RAIDを組む予算があるなら、その金でバックアップストレージを買いましょう。そして、OS丸ごとのスナップショット（AWSならAMIやEBSスナップショット）を、毎日、あるいは数時間おきに自動取得します。

何かあれば、トラブルシューティングなどしません。 「昨日の時点にロールバックする」。これが最強かつ最速の復旧手順です。原因究明は、復旧して業務が回った後に、壊れた方のイメージで行えばいいのです。

2. リストア訓練をしていないバックアップは「ゴミ」

「バックアップは取っています」と胸を張る情シス担当者に、「最後にそのバックアップから戻すテストをしたのはいつですか？」と聞くと、大抵黙り込みます。リストア手順書がない、あるいは手順書が古くて動かないバックアップは、保存容量の無駄遣いです。

四半期に一度、実際にバックアップから別環境に復元し、アプリが起動することを確認する。 この「避難訓練」こそが、あなたの安眠を保証します。

3. ステークホルダーとの合意形成

技術的な準備と同じくらい重要なのが、経営層や現場との「期待値調整」です。

「止まることはある」と宣言する

「うちはGoogleではありません。コストとの兼ね合いで、年に数回は止まる可能性があります」「その代わり、万が一止まっても、最大4時間以内には業務を再開できる体制を組んでいます」

このように宣言し、SLA（サービスレベル合意）のハードルを現実的なラインまで下げておきます。事前に言っておけば、4時間の停止は「想定内」ですが、言わずに止まれば「事故」です。

「データロス」の許容範囲（RPO）を握る

「サーバーが壊れた時、直近1時間分の入力データが消えることは許容できますか？それとも数千万円かけてリアルタイム同期しますか？」と聞けば、多くの中小企業は「1時間なら紙の伝票から打ち直すよ」と答えます。これで、高価なレプリケーションソフトは不要になり、1時間ごとのスナップショットで済むようになります。

結論：シンプルさは力なり

一人情シスが戦う相手は、未知のウイルスやハードウェア故障だけではありません。「複雑すぎて自分でも制御不能になったシステム」こそが、最大の敵です。

可用性を追求すればするほど、システムはブラックボックス化し、あなたの首を絞めます。逆に、復旧能力（Recoverability）を追求すれば、システムはシンプルになり、手順は明確化され、誰がやっても同じ結果が出せるようになります。

「落ちても、戻せばいい」 この開き直りにも似たタフな精神性と、それを裏付ける**「検証済みのリストア手順」**。これさえあれば、どれほどカオスな障害の中でも、あなたは冷静にコーヒーを飲みながら復旧コマンドを叩けるはずです。

理想の99.99%を追い求めるのはやめましょう。現実的な「落ちてから30分での確実な復帰」こそが、あなたの会社のビジネスを守る、最も堅実な防衛線なのです。

AIに相談するためのプロンプト（テンプレート）

高可用性（HA）の泥沼から抜け出し、シンプルな「復旧（リストア）」戦略へ移行するための設計プロンプトです。

あなたはBCP（事業継続計画）とシステム運用の専門家です。
現在、社内システムの更改において、ベンダーから「冗長化構成（HA）」を提案されていますが、運用が複雑になることを懸念しています。
記事にある「可用性より復旧性」の思想に基づき、よりシンプルで堅牢な「バックアップ＆リストア」戦略を設計してください。

# 対象システム
*   システム種別: [例: ファイルサーバー（全社員が利用）]
*   現在の提案: [例: AWS上でMulti-AZ構成、ロードバランサーあり]

# 自社の許容度（RPO/RTO）
*   データロス: [例: 1日分なら諦められる（前日夜のバックアップでOK）]
*   停止時間: [例: 半日以内なら業務は回る]

# 出力してほしい内容
1.  **構成の簡素化**: 冗長化を廃止し、シングル構成＋強力なバックアップにする場合の推奨アーキテクチャ。
2.  **SLAの定義**: ユーザー部門に対して宣言すべき、「サービス品質保証（止まる頻度）と復旧目標時間」の合意文書案。
3.  **復旧手順の要点**: 「障害発生から3時間以内に戻す」ための、具体的なバックアップ取得・リストア運用（スナップショット活用など）のポイント。