LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

運用設計とは何か——監視・障害対応・定常作業の体系化

運用設計とは、システムを本番稼働後に安定して維持するために必要な「監視・バックアップ・インシデント対応・エスカレーション・定常作業」を体系化し、手順・責任・判断基準をあらかじめ定める設計工程を指します。

開発フェーズではアーキテクチャや機能実装に注力しますが、リリース後の安定稼働は「誰が・いつ・何をするか」を事前に決めておかなければ維持できません。運用設計はその土台を作る工程です。

具体的には、以下の5つの領域を網羅して設計します。

• 監視設計：死活監視・メトリクス監視・ログ収集の対象と閾値を定め、アラートの通知先・通知方法を決定します
• バックアップ設計：取得スケジュール・保管場所・世代管理・リストア手順と復旧時間目標（RTO）を定めます
• インシデント対応設計：障害の重大度（Severity）分類基準とエスカレーション経路、役割（インシデント司令官・通信リード・運用リード）を定めます
• 定常作業設計：日次・週次・月次の定期作業（パッチ適用・ログローテーション・キャパシティ確認）を洗い出し、担当と実施タイミングを明確にします
• エスカレーション設計：対応不能・判断権限超過・関係者への報告タイミングを規定し、連絡先一覧（エスカレーションマトリクス）として整備します

運用設計を怠った場合、障害発生時に担当者が手順を都度考えながら対応することになります。その結果、平均復旧時間（MTTR：Mean Time To Recovery）が延び、ビジネスへの影響が拡大するリスクがあります。

SRE（Site Reliability Engineering）の観点では、Google社が公開する「SRE Book」において、監視の出力はアラート・チケット・ロギングの3種類に分類し、それぞれ対応優先度を設けることが推奨されています^*1。運用設計はこの分類を自社システムに当てはめる作業でもあります。

Runbook（手順書）の作り方と属人化を防ぐ粒度設計

Runbookとプレイブックの違い

Runbook（ランブック）とは、特定の運用作業や障害対応を繰り返し実行するための詳細な手順書です。「誰が読んでも同じ結果を再現できる」粒度で記述することが基本原則となります。

一方、Playbook（プレイブック）はアラートや障害タイプごとに「対応アプローチ・診断手順・緩和策・エスカレーション判断基準」を集約した判断の手引きです。Google SRE Workbookでは、プレイブックには「重大度と影響の説明、デバッグの提案、緩和策」が含まれると定義されており、「ストレス軽減・MTTR低減・ヒューマンエラーリスク低減」に貢献すると記されています^*2。

実務上は、Runbookが「手順の詳細」、Playbookが「判断の手引き」として機能し、両者を組み合わせて運用します。

属人化を防ぐRunbookの粒度設計

Runbookで最も失敗しやすいポイントは「粒度の設計」です。抽象的すぎると担当者が都度解釈し直す必要が生まれ、詳細すぎると作成・更新コストが膨大になります。

実務上の目安として、次の基準が有効です。

• 初期対応手順（First Response）：アラート受信から5分以内に実行する確認コマンドと判断分岐を記載します。コマンドは実行例をそのまま記述し、コピー＆ペーストで実行できる形にします
• 診断手順（Diagnosis）：ログの確認箇所・確認コマンド・正常値との比較方法を記載します。「〜の場合はAへ、〜の場合はBへ」のフロー形式が可読性を高めます
• 緩和・復旧手順（Mitigation）：サービスを早期復旧させるための手順（再起動・フェイルオーバー・ロールバック）を、前提条件・手順・確認方法の順で記述します
• エスカレーション判断：自己解決できない条件（〇分経過・重大度Highへの格上げ・データ損失の可能性など）を明記し、エスカレーション先と連絡手段を記載します

Runbookは「本番環境の変化と同速で情報が陳腐化する」という性質があります^*2。そのためシステム変更時にRunbookの更新を必須とする「変更管理との連動」が重要です。更新漏れが発生すると、記載内容と実際の環境が乖離し、かえって対応ミスを引き起こします。

属人化排除のための整備チェックポイント

以下のチェックリストを使うと、作成したRunbookの属人化リスクを評価できます。

オンコール体制・インシデント対応フロー・ポストモーテムの設計

オンコール体制：Google SREが示す基準

オンコール（On-Call）とは、業務時間外を含む一定期間、本番インシデントへの緊急対応ができる状態を維持する体制です。Google SRE Workbookでは「オンコール状態とは、一定期間利用可能であり、本番インシデントに適切な緊急度で対応する準備ができていること」と定義されています^*2。

同資料では、オンコール担当者の健康を維持するための推奨基準として「1回の12時間シフトあたりインシデントは2件まで」「総労働時間の最低50%をプロジェクト作業に充てる」が示されています^*2。この基準を超える運用が続くと、担当者の疲弊とインシデント対応品質の低下が連鎖します。

体制設計では以下の要素を決定します。

• シフト設計：平日夜間・休日をカバーするローテーションと、プライマリ担当者・バックアップ担当者の二重化
• 通知経路：PagerDuty・OpsGenieなどのアラートルーティングツールの設定と通知先の優先順位
• エスカレーション経路：対応限界時間と上位担当者・ベンダーへのエスカレーション基準

インシデント対応フロー：3つのロールと4段階プロセス

Google SRE Workbookが示すインシデント対応では、3つの基本ロールが定義されています^*2。

• インシデント司令官（IC：Incident Commander）：対応全体を指揮・調整し、意思決定の司令塔を担います
• 通信リード（CL：Communication Lead）：経営層・ステークホルダー・エンドユーザーへの情報提供を管理します
• 運用リード（OL：Operations Lead）：実際の緩和・復旧作業を指揮します

対応フローは「影響評価→緩和策実施→根本原因分析→事後対応」の4段階で進みます。重要な原則は「根本原因が完全に解明される前に、影響を軽減する緩和策を優先する」ことです^*2。原因究明に時間をかける間もサービスは停止しているため、まず影響範囲を限定することが優先されます。

ポストモーテム：学習文化の仕組み化

ポストモーテム（Postmortem）とは、インシデント発生後に「影響・実施した対策・根本原因・再発防止策」を文書化する事後分析です。Google SRE Bookでは「ポストモーテムの主な目標は、インシデントを文書化し、根本原因を十分に理解し、再発の可能性と影響を低減する有効な予防措置を講じること」と定義されています^*1。

ポストモーテム文化において最も重要な原則は「責任追及なし（Blameless）」です^*1。担当者を罰する文化では、エンジニアが問題を隠蔽するようになり、組織全体の学習機会が失われます。「誰が悪いか」ではなく「なぜこの状況が起きたか」を問い、プロセスや設計の改善へ向かうことが再発防止に直結します。

実施タイミングとしては、インシデント発生後1週間以内の完成が推奨されています^*2。記録が新鮮なうちに関係者の記憶を文書化することで、原因分析の精度が高まります。

ポストモーテムのトリガー基準（実施を義務付ける条件）を以下のように設定することが一般的です。

• ユーザーに見えるダウンタイムまたは機能低下が発生した場合
• データ損失が発生した場合
• オンコール担当者が手動介入を行った場合
• インシデント解決時間が事前に定めた閾値を超えた場合
• 監視システム自体が機能しなかった場合

外注で進める際の委託範囲の切り方と発注側の準備

設計フェーズと定常運用フェーズで委託範囲を分ける

運用設計とRunbook整備を外注で進める場合、まず「設計フェーズ」と「定常運用フェーズ」で委託範囲を明確に分けることが重要です。

設計フェーズの委託対象は「運用設計書の作成・Runbook初版の整備・監視設定・アラートルール定義・オンコール体制設計」です。このフェーズは知識集約型であり、SRE経験・インフラ知識・業務フロー理解を持つ専門家への委託が効果的です。

定常運用フェーズの委託対象は「アラート対応・定期作業実施・Runbook更新・インシデント対応一次受け」です。設計フェーズで整備した手順書に基づいて実行するため、委託先の習熟コストを抑えられます。

発注側が事前に準備すべき5つの情報

外注で運用設計を進める際、発注側の準備不足が大きなリスクになります。委託先がシステムの実態を把握できなければ、設計品質は低下します。

1. システム構成図と依存関係：サーバー・ネットワーク・外部サービス・バッチ処理の依存関係図。「どこかが落ちると何に影響するか」が分かるレベルで整備します
2. 過去のインシデント記録：発生日時・内容・影響範囲・対応時間の一覧。過去事例がRunbook設計の出発点になります
3. SLA・SLO（サービス水準目標）：ユーザーやビジネスサイドと合意した可用性目標と、それを達成するための許容停止時間（エラーバジェット）。SRE Bookでは「SLOは製品レベルの問題」と位置づけており^*1、発注側が主体的に決定する必要があります
4. エスカレーション先の連絡先一覧：社内の担当者・役割・連絡先と、利用ベンダーのサポート連絡先を整備します
5. 定常作業の現状把握：現時点で誰がどのような定期作業を行っているかの一覧。暗黙知になっている作業を洗い出すことが属人化排除の第一歩です

これらを発注前に整備できていない場合、委託先との認識齟齬が生まれ、設計の手戻りコストが発生します。準備段階を「外注の前提条件」として社内で位置づけることが大切です。

契約形態と外注費用の考え方

運用設計・Runbook整備の外注では、フェーズに応じた契約形態の使い分けが有効です。

設計フェーズは成果物（運用設計書・Runbook）の品質が明確に評価できるため、準委任契約または請負契約で対応します。定常運用フェーズはアラート対応・定期作業という継続的なサービスのため、保守運用契約（月次固定費＋工数従量）が一般的です。

費用の見積もり根拠として、外注先に求める明示的な確認事項は「担当者のスキルセット（インフラ構築経験・監視ツール経験・SRE知識）・Runbook作成の実績・対応可能なシステム規模・緊急時の対応時間（応答時間SLA）」です。これらを確認せずに価格だけで選定すると、緊急対応時の対応品質が期待を下回るリスクがあります。

内製と外注の比較——スキル・工数・リスクの違い

内製に必要なスキルと工数の実態

運用設計とRunbook整備を内製で完結させるには、以下のスキルセットを持つ人材が必要です。

• インフラ設計・構築経験（Linux・ネットワーク・クラウドサービス）
• 監視ツール（Prometheus・Datadog・CloudWatch等）の設定経験
• インシデント対応の実務経験と記録・分析の習慣
• ドキュメント整備・更新を継続できる体制

これらを兼ね備えた人材を確保・維持するには、採用コスト・教育コスト・離職リスクを考慮する必要があります。特に中小規模の開発チームでは、開発業務と運用業務を同じ人員で担う「開発者運用」が発生しやすく、Runbook整備のような非緊急タスクが後回しになる傾向があります。

Runbook整備を後回しにした結果、障害発生時に担当者が手順を都度思い出しながら対応することになります。これがMTTRを延ばし、ビジネスへの影響を広げる原因になります。

外注のメリットと委託先選定の視点

外注の主なメリットは「専門知識の即時調達」と「属人化リスクの外部化」です。設計フェーズに限定した外注でも、運用経験を持つ専門家が整備した設計書とRunbookは、内製チームの対応品質を底上げします。

委託先を選定する際の評価軸として以下を確認します。

外注委託において特に注意すべきリスクは「設計書・Runbookが委託先の知識として閉じてしまうこと」です。成果物の所有権・共有形式・更新プロセスを契約段階で明確にしなければ、委託先を切り替えた際に運用知識がゼロリセットされます。

まとめ：運用設計とRunbook整備外注を成功させる3つの判断軸

本稿では、運用設計とRunbook整備を外注で進める方法について、設計工程・Runbook粒度・オンコール体制・発注側準備・内外製比較の順に整理しました。要点を3つに集約すると次の通りです。

第一に、運用設計は「監視・バックアップ・インシデント対応・エスカレーション・定常作業」の5領域を体系化する工程であり、システム稼働前に完了させることが障害対応品質の前提条件になります。設計を後回しにした場合、担当者がMTTRを延ばしながら属人的に対応を続けることになります。

第二に、Runbookは「コピー＆ペーストで実行できるコマンド例・判断分岐・エスカレーション基準」を明記した粒度で整備することが属人化排除の核心です。システム変更時の更新を変更管理プロセスに組み込まなければ、Runbookは急速に陳腐化します。

第三に、外注で進める場合は「設計フェーズ」と「定常運用フェーズ」で委託範囲を分け、システム構成図・過去インシデント記録・SLO・エスカレーション連絡先の4点を発注前に整備することが成否を分けます。成果物の所有権と更新プロセスを契約段階で確定させることも欠かせません。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Google「Site Reliability Engineering（SRE Book）」（2016年）
2. *2　出典：Google「The Site Reliability Workbook（SRE Workbook）」（2018年）

Tweet