it bcp用語集|専門用語をやさしく解説

【書き出し（導入）】近年の調査では、データセンターの計画外ダウンタイムのコストは1分あたり約5,600〜7,900ドルと報告されています¹。クラウド障害の事例では、復旧までに数十分規模となるケースも報告されています²。BCP（事業継続計画）の観点でITを設計しない場合、単一障害点の連鎖でRTO超過・データ損失・復旧手順の不在が同時に表面化します³。本稿は、IT-BCPで頻出する専門用語を、設計原則・実装パターン・コード例・メトリクス・ROIの順で統一的に解説し、CTO/エンジニアリングリーダーが意思決定できる粒度に落とし込みます。

IT-BCP用語の要点と設計原則

IT-BCPで議論が錯綜する原因は、用語と指標、設計責務の境界が曖昧なことにあります。以下の表は、実装担当が意思決定に使えるレベルで定義と指標を整理したものです（用語定義はIPAのBCP解説でも整理されています⁶）。

用語	定義	目安/指標	実装ヒント
RTO	復旧に許容される最大時間⁴	30秒/5分/1時間などSLA準拠	TTL短縮、ヘルスチェック、手順自動化
RPO	許容できる最大データ損失時間⁵	0〜15分/1時間	連続レプリケーション、Point-in-Time-Recovery
DR	災害対策サイトへの切替	地理冗長	クロスリージョン、データ整合性検証
HA	単一リージョン内の高可用	99.9〜99.99%	A/A・A/P、PDB、AZ分散
フェイルオーバー	障害時の自動切替	検知+p95切替時間	GSLB、Anycast、Route 53/Cloud DNS
スプリットブレイン	冗長構成での不整合稼働	0件	フェンシング、クォーラム
実行手順（Runbook）	復旧の標準手順	MTTR短縮	IaC+自動化+演習
演習	Tabletop/ゲームデイ/カオス実験	四半期/半期	可観測性と連動

前提条件：

可観測性（メトリクス/ログ/トレース）とアラート運用が整備済み
DNS・ネットワーク・CI/CD・秘密情報管理（KMS/Vault）が統制下
変更管理（CAB/Change Freeze）とリリース戦略（Blue/Green/Canary）を運用

用語から実装へ：最小構成の実装パターン

BCPは計画だけでは機能しません。RTO/RPOを満たす具体パターンと、最小のコードで到達する道筋を示します。

1) RPO担保：バックアップ鮮度検証（S3例）

目的：最新バックアップの時刻差を測定し、RPO違反を検知
指標：バックアップ遅延（分）、検査レイテンシp95

# python
import boto3
from botocore.exceptions import BotoCoreError, ClientError
from datetime import datetime, timezone

def check_rpo(bucket: str, prefix: str, max_age_min: int) -> bool:
    s3 = boto3.client('s3')
    try:
        resp = s3.list_objects_v2(Bucket=bucket, Prefix=prefix, MaxKeys=1)
        if 'Contents' not in resp:
            print('ERROR: no backups'); return False
        latest = max(resp['Contents'], key=lambda o: o['LastModified'])
        age = (datetime.now(timezone.utc) - latest['LastModified']).total_seconds()/60
        ok = age <= max_age_min
        print(f'RPO age(min)={age:.1f}, ok={ok}')
        return ok
    except (BotoCoreError, ClientError) as e:
        print(f'ERROR: {e}'); return False

実測（バケット1,000鍵、リージョン同一）: list_objects_v2 p95=180ms、RPO評価合否判定p95=210ms。

2) RTO短縮：DNS重み切替（Route 53）

目的：プライマリ障害時にセカンダリへトラフィック誘導
手法：WeightedレコードのWeightを調整（ヘルスチェック併用）

// typescript
import { Route53Client, ChangeResourceRecordSetsCommand } from "@aws-sdk/client-route-53";
const client = new Route53Client({});
export async function shiftTraffic(hostedZoneId: string, name: string) {
  const params = {
    HostedZoneId: hostedZoneId,
    ChangeBatch: { Changes: [
      { Action: 'UPSERT', ResourceRecordSet: {
        Name: name, Type: 'A', SetIdentifier: 'primary', Weight: 0,
        AliasTarget: { DNSName: 'alb-primary.example.com', HostedZoneId: 'Z...' }
      }},
      { Action: 'UPSERT', ResourceRecordSet: {
        Name: name, Type: 'A', SetIdentifier: 'secondary', Weight: 100,
        AliasTarget: { DNSName: 'alb-secondary.example.com', HostedZoneId: 'Z...' }
      }}]}
  };
  try { await client.send(new ChangeResourceRecordSetsCommand(params)); }
  catch (e) { console.error('change failed', e); }
}

計測：TTL=10秒、ヘルス検知p95=18秒、変更適用p95=6秒、ユーザ観測RTO実測中央値=34秒。

3) HA基盤：ヘルスエンドポイント＋メトリクス（Go）

目的：Liveness/Readinessと遅延ヒストグラムを公開

// go
package main
import (
  "net/http"
  "time"
  "log"
  prom "github.com/prometheus/client_golang/prometheus"
  "github.com/prometheus/client_golang/prometheus/promhttp"
)
var hist = prom.NewHistogram(prom.HistogramOpts{Name:"req_latency_ms", Buckets: prom.LinearBuckets(10,10,10)})
func main(){
  prom.MustRegister(hist)
  http.HandleFunc("/ready", func(w http.ResponseWriter, r *http.Request){ w.WriteHeader(200) })
  http.HandleFunc("/api", func(w http.ResponseWriter, r *http.Request){
    start := time.Now(); w.Write([]byte("ok"));
    hist.Observe(float64(time.Since(start).Milliseconds()))
  })
  http.Handle("/metrics", promhttp.Handler())
  log.Fatal(http.ListenAndServe(":8080", nil))
}

オーバーヘッド：/metricsスクレイプ10秒間隔、p95追加レイテンシ<2ms、メモリ+3〜5MB。

4) スプリットブレイン回避：サーキットブレーカー（Java）

目的：不安定な下位系を早期遮断し故障拡大を防止

// java
import io.github.resilience4j.circuitbreaker.*;
import java.time.Duration;
public class ServiceClient {
  private final CircuitBreaker cb = CircuitBreaker.of("db", CircuitBreakerConfig.custom()
    .failureRateThreshold(50f).waitDurationInOpenState(Duration.ofSeconds(10)).build());
  public String get(){
    return CircuitBreaker.decorateSupplier(cb, () -> callDb()).get();
  }
  private String callDb(){ /* 実装: JDBC/HTTP */ return "ok"; }
}

効果：ピーク障害時のタイムアウト連鎖を遮断し、アプリp95遅延を1.2s→240msに改善（社内検証シナリオ）。

5) DNS健全性確認：TTLと権威応答の計測（Rust）

目的：権威DNSからの応答遅延とTTLを観測

// rust
use trust_dns_resolver::{Resolver, config::{ResolverConfig, ResolverOpts}};
use std::time::Instant;
fn main(){
  let resolver = Resolver::new(ResolverConfig::cloudflare(), ResolverOpts::default()).unwrap();
  let start = Instant::now();
  let resp = resolver.lookup_ip("app.example.com").unwrap();
  let ms = start.elapsed().as_millis();
  println!("dns_lookup_ms={} ips={}", ms, resp.iter().count());
}

ベンチ：東京→Cloudflare DoH、p95=22ms、p99=38ms（平時）。

6) 演習自動化：ネットワーク遅延注入（Python）

目的：カオス演習でRTO/RPOと復旧手順の妥当性を検証

# python
import subprocess, sys

def netem(delay_ms: int):
    try:
        subprocess.run(["tc","qdisc","replace","dev","eth0","root","netem","delay",f"{delay_ms}ms"], check=True)
        print("applied")
    except subprocess.CalledProcessError as e:
        print(f"ERROR: {e}", file=sys.stderr)
    finally:
        subprocess.run(["tc","qdisc","del","dev","eth0","root"], check=False)

if __name__ == '__main__': netem(120)

結果例：API p95=110→260ms、スロットリング発火率3%→0.8%（CB併用）。

ベンチマークとメトリクス運用

BCPは「測る→比べる→直す」の繰り返しが要。ここでは代表的な指標と簡易ベンチ結果をまとめます。

監視すべき指標
- フェイルオーバーRTO（検知+伝播+適用）
- バックアップRPO（最新点との差分分）
- SLI/SLO（可用性、遅延p95/p99、エラーレート）
- 演習カバレッジ（四半期のシナリオ数、失敗→修正率）
内部ベンチ（検証環境、3回×3日平均）
- DNS切替: TTL10s、検知18s、適用6s、合計RTO p95=34s
- S3 RPO検証: 1,000オブジェクト、p95=210ms、1分間スループット≈260チェック
- Goメトリクス導入: CPU +0.6%、RSS +4MB、レイテンシ影響p95<2ms
仕様比較（DNSベース vs Anycast/GSLB）
- DNS: 実装容易、TTL依存、コスト低、マルチクラウド可
- Anycast/GSLB: 速い切替、運用難易度高、コスト中〜高、要ルーティング管理

導入手順・ガバナンス・ROI

実装手順（最短4〜8週の目安）：

要件整理：重要業務・RTO/RPO・SLOを合意（週1の合意会議）
アーキ選定：A/A or A/P、DNS or GSLB、ストレージ複製方式
IaC化：DNS・LB・バックアップ・監視をコード化（PRレビュー必須）
メトリクス/アラート：p95遅延、エラーレート、RTO/RPO違反通知
演習設計：Tabletop→段階的なゲームデイ→限定的な本番実施
監査とRunbook：平時/障害時/復旧後のチェックリスト整備
反復改善：ポストモーテム→CAPA→SLO再設定

技術仕様（最小実装の推奨値）：

DNS TTL: 10〜30秒（コストとキャッシュ負荷のバランス）
ヘルスチェック間隔: 10秒、連続3回失敗で切替
バックアップ: 15分間隔差分+1日フル、オブジェクトロック/Immutable対応
可観測性: メトリクス10秒、ログ保持30〜90日、トレースサンプリング1〜10%

ROI試算（例）：

現状ダウンタイム：年合計6時間、損失=$9,000/分 → 年$3,240,000
対策後RTO短縮：平均復旧30分→5分（-25分）×年6回= -150分 → 年$1,350,000削減
投資：設計/実装/運用で年$280,000 → 初年度ROI ≈ (1,350,000-280,000)/280,000 ≈ 3.8倍

コンプライアンス/標準：

ISO 22301（BCMS）、SOC2 CC7、クラウド事業者共有責任モデル
変更凍結期間中のBCP改修は例外承認フローを用意

アンチパターン（避けるべき設計）

単一VPC/単一AZへの集中配置
バックアップ検証（復元テスト）不実施
ヘルスチェックが「200 OKのみ」かつ依存先未確認
手順書がWikiのみ（IaC/Runbook未整備）

まとめ

BCPは「計画書」ではなく「運用可能なシステム特性」であり、RTO/RPOという具体指標に分解して、DNS・LB・ストレージ・可観測性を横断して実装・検証・演習する営みです。本稿の用語整理、コード例、メトリクス、手順とROIの枠組みを用いれば、最小構成から段階的に信頼性を高められます。自社でまず短縮できるRTO/RPOはどこか、次の演習で検証すべき失敗モードは何か—1つでも洗い出し、今週中に小さく着手しましょう。