ITエンジニアにとってのBCPとは
BCP（Business Continuity Plan：事業継続計画）とは、地震・洪水・大規模障害・サイバー攻撃など不測の事態が発生した際に、事業への影響を最小限に抑えながら、重要業務を継続または迅速に再開するための計画です。
「BCPは経営層や総務部門の仕事」と思っているエンジニアも多いですが、実際にはシステムの可用性設計・バックアップ戦略・クラウドアーキテクチャ・障害対応手順の整備など、技術的な実装を担うのはエンジニアです。計画を絵に描いた餅で終わらせないために、エンジニアがBCPの考え方を深く理解しておくことは不可欠です。
近年、日本企業のBCP策定を後押しする出来事が相次いでいます。2024年1月の能登半島地震、そして国内外でのサイバー攻撃による病院・製造業・自治体のシステム停止。「うちは大丈夫」という過信を捨て、具体的な対策に落とし込む時期に来ています。BCPは策定すること自体が目的ではなく、実際に機能することが求められます。その実行力を支えるのは、現場エンジニアの技術と準備です。
BCPの根幹を支える2つの指標
ITシステムのBCPを設計するうえで、最初に理解しなければならない指標が RTO と RPO です。この2つを定義せずにBCPを語ることはできません。
| 指標 | 正式名称 | 意味 | 設計への影響 |
|---|---|---|---|
| RTO | Recovery Time Objective（目標復旧時間） | 障害発生から業務を再開するまでの許容時間 | 短いほどコストが上がる。スタンバイ構成の種類を左右する |
| RPO | Recovery Point Objective（目標復旧時点） | 障害発生時にどの時点のデータまで失ってよいか | バックアップ頻度・レプリケーション方式を決める |
たとえばRTOが「4時間以内」でRPOが「1時間以内」のシステムと、RTOが「72時間以内」でRPOが「24時間以内」のシステムでは、必要なインフラ構成とコストが大きく異なります。すべてのシステムを最高水準の可用性で設計することは現実的ではないため、システムの重要度に応じてRTO・RPOを段階的に設定することが重要です。
重要なのは、この数値をエンジニアだけで決めないことです。「このシステムが何時間止まったら事業にどれだけの損失が出るか」は経営判断であり、ビジネス部門と合意したうえで技術的な実装方針を決定します。この合意プロセスを経ることで、エンジニアは「なぜそのコストをかけるのか」を根拠を持って説明できるようになります。
システム可用性の設計パターン
RTOの短さに応じて、代表的な3つのスタンバイ構成があります。それぞれの特性を正確に理解することで、システムの重要度に合った設計を選べるようになります。
コールドスタンバイ
待機系サーバーは普段は停止しており、障害時に起動してシステムを復元します。コストは最も安いですが、RTOは長くなります（数時間〜数日）。重要度の低い社内システムや開発環境では現実的な選択肢です。バックアップメディアから手動でリストアする手順を整備しておくことが前提になります。クラウド環境であれば、AMI（マシンイメージ）やスナップショットから新しいインスタンスを起動する運用がこれに相当します。
ウォームスタンバイ
待機系は起動済みで最低限のリソースで動いており、本番系の障害時にスケールアップして引き継ぎます。RTOは数十分〜数時間程度で、コストとRTOのバランスが取りやすいため、多くの業務システムで採用されます。クラウドであれば、小さいインスタンスで待機系を常時稼働させておき、フェイルオーバー時に大きいインスタンスタイプに切り替える設計が典型的です。データベースはリードレプリカを昇格させてプライマリに切り替える操作がこれにあたります。
ホットスタンバイ（アクティブ-アクティブ）
本番系と同等の構成の待機系が常時稼働しており、リアルタイムで同期しています。フェイルオーバーは自動で完結し、RTOは数秒〜数分です。ECサイトや金融システムなど、1分の停止も許容できないシステムに適用されます。コストは最も高く、データ同期の整合性管理が技術的に複雑になります。複数のAZにまたがるロードバランサー構成や、Aurora Global Databaseのようなマルチリージョン対応のマネージドDBがこれを支えます。
クラウド時代のBCP実装
オンプレミスだけの時代と異なり、クラウドはBCPに必要な技術コンポーネントをマネージドサービスとして提供しています。自前で冗長構成を一から構築する必要がなく、適切なサービスを組み合わせることで、以前より低コストかつ短期間で高い可用性を実現できます。
マルチリージョン構成
AWSやGCPでは、異なる地理的リージョンにシステムを複製することで、データセンター規模の障害（自然災害・電力障害）に備えられます。AWSのRoute 53ヘルスチェック＋フェイルオーバールーティングを使えば、プライマリリージョンが応答しなくなった際に自動でセカンダリリージョンへ切り替えるDNSフェイルオーバーを実装できます。
ただし、マルチリージョンはデータの同期遅延（レプリケーションラグ）という課題を持ちます。RDSのクロスリージョンリードレプリカはレプリケーションラグが発生するため、フェイルオーバー後にラグ分のデータが失われる可能性があります。RPOの要件と照らし合わせて許容できるかを事前に確認しておく必要があります。
インフラのコード化（IaC）
BCPにおいてしばしば見落とされるのが「インフラの再現性」です。障害時に新しい環境を立ち上げようとしても、構成がドキュメントだけで管理されていると、手作業での再構築に時間がかかり、設定ミスのリスクも高まります。
TerraformやAWS CloudFormationでインフラをコード化しておけば、必要なリソースを短時間で正確に再構築できます。IaCのコードはGitで管理し、本番環境と同等の構成を任意のリージョンにデプロイできる状態を維持することが、現代のBCP設計の基本です。「コードがあれば環境は何度でも再現できる」という状態こそ、真の意味でのBCP準備と言えます。
BCP計画書に盛り込むべき技術的要素
計画書を作成する際、エンジニア観点で明記しておくべき項目は次のとおりです。
- システム優先度マップ ：業務への影響度に基づいてシステムをA・B・Cなどに分類し、RTO・RPOを明示する
- 連絡体制と権限委譲 ：誰が何を判断してよいか、深夜・休日でも動ける体制を定義する
- フェイルオーバー手順書 ：コマンド・コンソール操作レベルまで落とし込んだ手順を整備する
- 依存サービスの把握 ：SaaS・外部API・CDNなど、自社でコントロールできない依存先を洗い出す
- テスト実施スケジュール ：机上訓練・実機切り替えテストをいつ・どの頻度で行うかを決める
特に「テスト」は計画の品質を保つうえで欠かせません。「計画は作ったがテストしたことがない」というのは、最悪のケースです。本番を止めずに障害訓練を行うカオスエンジニアリング（NetflixのChaos Monkeyが有名）の考え方を取り入れ、定期的に復旧手順の有効性を検証することが重要です。AWSにはFault Injection Simulator（FIS）というカオスエンジニアリング専用のマネージドサービスもあり、実際に特定のAZをシャットダウンしたシナリオを安全にテストできます。
よくある落とし穴
BCPを整備した組織でも、実際の障害時に機能しないケースがあります。よくある原因をまとめます。
| 落とし穴 | 具体的な問題 | 対策 |
|---|---|---|
| バックアップが使えない | 暗号化・破損を未検証。リストア手順が誰も知らない | 定期的なリストア訓練の実施 |
| 連絡が取れない | 緊急時の連絡先がSlackだけ。Slack自体が落ちている | SMS・電話・紙の連絡網を並列で用意 |
| 手順書が古い | クラウド移行後に手順書を更新していない | 変更管理と手順書更新をセットで運用 |
| 復旧担当者が一人 | 特定の社員しかわからない属人化 | 手順書の整備と複数人へのトレーニング |
| コストを理由に先送り | 「優先度が低い」と言い続けて対策ゼロ | 障害時のコストと対策コストを経営に提示 |
バックアップのリストア訓練は、多くの組織で後回しにされがちです。「バックアップは取っている」と「バックアップから復元できる」はまったく別の話です。半年に一度でも実際にリストアを試みることで、手順書の抜けや依存関係の見落としが浮き彫りになります。
まとめ
BCP対策は「万が一のための準備」ではなく、「確実に来る障害への備え」です。クラウドが当たり前になった今、技術的な実装コストは以前より大幅に下がっており、マルチリージョン構成やIaCによる再現性確保は現実的な選択肢です。
まず自社・自チームのシステムを棚卸しし、RTO・RPOを経営部門と合意するところから始めましょう。計画が紙の上に留まらないよう、テスト・訓練の文化をチームに根付かせることが、エンジニアとしての最大の貢献になります。障害が起きてから「あのとき準備しておけば」と後悔しないために、今日から一つ行動してみてください。