サービス継続計画（BCP）実践

復旧目標と優先順位を数値で固める

BCPは「止めないための願望」ではなく「止まっても戻せる設計」を数字で合意するところから始まります。まずは業務単位でRTO（どれだけで復旧させるか）とRPO（どこまでデータを戻せるか）を決めます。決め方はシンプルで、1時間の停止コストを見積もり、冗長化・自動化コストと比較することです。「1時間の停止コスト ＞ 冗長化の月額×2」なら即実施、のように判断基準を作ると迷いが減ります。

次に、復旧順序を「画面」ではなく「機能」で決めます。例：認証→在庫参照→決済→通知。依存関係（DNS、IdP、支払いゲートウェイ、メール/SMS、CDN）まで含めたトポロジー図を作成し、各ノードにRTO/RPOを貼ります。決めたRPOはバックアップ方式（スナップショット、PITR、ストリーミング）に、RTOはフェイルオーバー単位（AZ/リージョン/コンテナ）に落とし込みます。

現実的なRTO/RPOの線引き

RTO 15分を目指すなら「自動フェイルオーバー＋無人実行のランブック（IaC）」「監視からの一発切替」を必須にします。RPO 5分以内なら「WAL送信やbinlogレプリケーション＋遅延監視＋定期リカバリ検証」が現実解です。逆に社内ポータルのRPOが24時間でも事業影響が小さいなら夜間バッチ復元で十分、など“使い分け”をはっきりさせます。

劣化運転の設計

完全停止か稼働かの二択にしないこともBCPです。決済が落ちたら「カートは開くが予約注文に切り替える」、在庫が怪しいときは「在庫−2の安全在庫で販売」、レコメンドが不調なら「固定ランキングで代替」など、機能ごとのデグレードモードをフラグで制御します。

監視設計をBCP視点で作り替える

監視の主語を「ミドルウェアのメトリクス」から「ユーザー体験のSLO」に切り替えます。主指標は可用性（成功率）、レイテンシ（P95/P99）、エラー率、デプロイ直後の変化です。外形監視（シンセティック）で支払い・検索・ログインなどの重要シナリオを数分間隔で実行し、リアルユーザーとは独立に可用性を測ります。内部のメトリクスは「SLO逸脱を説明するための証拠」として紐づけます。

アラートは「ページャに上げるもの」と「日中に見るもの」を分け、ページャは3条件に限定します。1) SLO逸脱が進行中、2) 自動修復が失敗、3) セキュリティ/データ喪失の兆候。逆に“沈黙”も監視対象です。エージェントのハートビート、バックアップの完了通知、ログ収集の遅延など、来るべき信号が来ないことを検知します。

ダッシュボードとランブックの一体化

ダッシュボードの各ウィジェットから該当ランブックへ1クリックで飛べるようリンクします。ランブックは「状況判定→初動（5分）→切替/巻き戻し（10分）→連絡」のタイムラインで書き、最後に「誰がやっても辿り着ける確認観点」を箇条書きにします。夜間当番はペア当番＋エスカレーション3段（アプリ/インフラ/経営）の連絡網を用意し、連絡手段も冗長化（チャット、電話、SMS、メール）します。

データ保護と復元訓練を習慣化する

バックアップは3-2-1（3世代、2媒体、1つはオフサイト/イミュータブル）を原則に、毎月「実復元」を行いRTO実績を計測します。PITRは障害だけでなく論理削除にも効くため、本番と同じバージョンのエンジンで時点復元→リードオンリー検証→整合性チェックまでを自動化します。証明書更新、DNSのTTL、APIキー失効、監視のAPIクォータなど“運用起因の障害”もチェックリスト化し、卓上演習（tabletop）で定期訓練します。

生成AIも現場の速度を上げます。ChatGPTやClaudeでランブックのドラフトやコミュニケーション文面（お客様・社内向け）を短時間で用意し、Copilotで復旧スクリプト/IaCの静的チェック、Geminiで障害シナリオのバリエーション出しや依存関係の洗い出しを行う、といった役割分担が現実的です。AI提案は必ず検証環境で再現し、最終手順はGitで版管理、レビュワーと最終更新日を明記します。

身近な企業活用例：小売ECの失敗からのBCP刷新

夏のセール初日に「DNSのTTL長すぎ＋DBインデックス欠落」でサイトが断続的に落ち、在庫数の不整合も発生。バックアップは毎日深夜のスナップショットのみで、RPOは最大24時間。連絡網は担当者個人依存、決済ゲートウェイ障害時の代替手段もありませんでした。結果、4時間の停止と大量のカスタマー対応で翌週まで影響が残りました。

改善では、RTOを「支払い系15分、閲覧系30分」、RPOを「支払い・受注5分、その他1時間」に設定。DBはPITR＋リードレプリカをマルチAZ化、検索はキャッシュヒット率のSLOを定義。CDNとDNSにヘルスチェック付きのフェイルオーバーを設定し、在庫は安全在庫−2の劣化運転を導入。外形監視で「トップ→検索→商品→カート→決済」を3分間隔で実行、失敗時は自動で閲覧専用モードに切替。ランブックはChatGPTでたたき台を作り、Claudeで抜け漏れレビュー、Copilotで切替スクリプトを整備、Geminiで障害シナリオを10パターン用意して卓上演習を月1で実施しました。

結果、次回の障害ではMTTRが180分→35分、受注データの欠損はゼロ（RPO 5分内）、売上影響は前回比で80％削減。経営は「止めない投資」を数字で評価できるようになり、監視とBCPが日常業務に溶け込みました。

サーバ監視運用事業の視点では、BCPは別冊ではなく運用そのものです。SLOを軸に監視を再設計し、アラートとランブックを結線し、復元訓練でRTO/RPOを実測する。日々の当番、ダッシュボード、自動化の一手が、そのまま事業継続の強度になります。