Runbookを2層に分ける理由
Runbookは障害の正解集ではありません。予期しないDependency、配布変更、データ状態、Trafficが重なり、同じ症状でも原因は違います。固定すべきは原因より対応方法です。誰がIncidentを判断し、何でSeverityを決め、誰が指揮し、どう被害を減らし、いつ復旧を宣言し、何を記録・通知・引き継ぐかを合意します。
NISTの最新指針も、全状況の詳細手順を事前作成するのは非現実的としています。[6] 役割と権限を定め、反復的・重要・時間に敏感な活動へ実行可能な手順を用意します。Runbookは障害を予言するのでなく、障害中も同じ運用規則を使うためのものです。
全Commandと障害種類を一文書へ入れるとすぐ古くなります。共通のDetection、Triage、Severity、指揮、Communication、Handoff、Closure、ReviewはCoordination Runbookへ置きます。DB Failover、Queue処理、外部API迂回、Cache停止、Service再起動、配布Rollbackなどは、システム別Technical Runbookへ分けます。
一Incidentで複数のTechnical Runbookを使えても、誰がどの状態で何を実行し、どう結果を確認するかは一つのCoordination Runbookが統制します。技術Stackが変わっても、対応管理全体の再設計を減らせます。
対応状態を先に合意する
一人は復旧済みと考え、別の人は原因調査中というように、現在状態の理解もずれます。次のモデルが共通言語になります。
Detected → Triaged → Declared → Mitigating → Recovering → Monitoring → Resolved → Reviewed
これは唯一の標準ではなく運用例です。名前より各状態の目標が重要です。Mitigatingは完璧な修正より被害拡大の停止、Recoveringは一時措置に頼らない意図した状態への復帰、Monitoringはユーザー結果とデータの確認です。悪化時には前段へ戻れる必要があります。
監視から復旧・改善までつながる運用 — サービス指標とアラートを基準に対応し、変更履歴と事後報告を次の改善につなげます。
Detection：発見した事実を記録する
始まりは監視Alertだけではありません。ユーザーの報告、Supportの反復問い合わせ、Providerの障害通知、配布担当者の異常発見もあります。
原因の推測より初期事実を残します。検知時刻と経路、失敗する操作、影響しそうなユーザー・地域・機能、最初の症状、根拠のDashboard・Log・Trace・Request IDです。
Alert受信とIncident判断は別です。Page・Ticket・Dashboardへの振り分けは別問題で、この記事は観測した事象をIncident Responseへ移した後を扱います。
Triage：原因より影響範囲を先に把握する
直前の配布やDB CPU上昇から原因を早く断定するのは危険です。仮説は必要でも事実と混ぜません。初期目的はRoot Cause Analysisではなく、現在の運用状況の共通理解です。
実ユーザー影響、失敗する主要Journey、拡大またはRegion・Tenant・機能・Versionへの限定、直前変更、Dependency状態、書込み・整合性リスク、Security・Privacy事故の可能性、Workaroundを確認します。
Infrastructure Metricは原因の重要な信号ですが、それだけで影響を判定しません。復旧も同じ理由でユーザージャーニーの結果に結びます。
Severity：数字より判断根拠を残す
Severityは人員、意思決定参加者、連絡経路、中断する他作業を決めるためです。ただし10分ならSEV-1、30分ならSEV-2という全組織共通表は作れません。NISTもScope、Impact、Time-critical Nature、Recoverabilityなどで優先順位を評価します。[6] 少なくとも表の軸を確認します。
各組織でLabelと結び、初期宣言後も固定しません。影響拡大やデータリスク発見で上げ、範囲限定が確認されれば調整できます。何が変わり、なぜ変更したかをTimelineに残します。
判断軸 | 質問 |
|---|---|
| ユーザー影響 | 主要Journeyが止まったか。一部機能か全体か。 |
| 影響範囲 | 一部ユーザー・Region・Tenantか、急拡大中か。 |
| データ | 損失・重複・汚染・整合性破損の可能性はあるか。 |
| Security・Safety | 侵害や個人情報露出の可能性はあるか。 |
| 時間敏感性 | 時間とともに損害が累積し、復旧が難しくなるか。 |
| 迂回可能性 | 安全なWorkaroundがあるか。 |
| 復旧可能性 | 既知の緩和・復旧経路か、不確実か。 |
| 調整の複雑さ | 一チームか、複数チームやProviderが必要か。 |
| 不確実性 | 原因だけでなく影響範囲自体も不明か。 |
Incident Commanderが自分ですべて直さない理由
大きな障害ほど技術以上にCoordinationが問題になります。多数が同じLogや設定を操作し、別Slack Threadで違う仮説を話すと、人数が増えるほど把握しにくくなります。
Google SREはIC、Communications Lead、Operations Leadを分けます。[1] ICは全体と優先順位、Operationsは実作業、Communicationは情報流を担います。小規模なら兼任できますが、最終調整責任者とProduction変更権限者は曖昧にしません。
ICは最優秀Debuggerでなくて構いません。全Commandを実行すると全体・優先順位・連絡を見失います。必要なのは全正解でなく、既知・未知と次の意思決定を維持する権限と責任です。
Mitigation：原因修正より被害を減らす
MitigationとRecoveryを同義にすると対応が揺れます。Mitigationは現在の影響と追加損害を抑えるもので、一時状態でも構いません。機能停止、Traffic迂回、書込み制限、過負荷要求の削減が原因調査より先になる場合があります。
配布が原因候補ならRollbackも選択肢ですが、可否はCodeだけでなく設定・Schema・データ・Feature Exposure・Trafficの互換性で決まります。仕組み自体は別のRollback設計です。
特定手段を正解に固定せず、各行動に表の記録を求めます。実行したことと効果があったことを区別します。
項目 | 記録内容 |
|---|---|
| Action | 何を変更するか |
| Owner | 誰が実行するか |
| Objective | どの影響を減らすか |
| Expected Signal | 有効ならどの信号が変わるか |
| Risk | 追加リスク |
| Safety Control | 失敗時の停止・復旧方法 |
| Result | 実際の結果 |
| Evidence | 判断根拠 |
Evidence：緩和中に何を残すか
緊急時は記録を後回しにしがちですが、再構成には変更前と対応過程が必要です。可能なら破壊的変更前に稼働Version、設定とFlag、Dashboard・Query基準時刻、Log・Trace・Request IDを残します。Queue・DB状態、Dependency、誰が何をなぜ変えたか、結果の変化も加えます。
NISTはデータとMetadataの整合性・由来を保つよう勧めますが、すべてに法的なChain of Custodyが必要とはしていません。[6] 通常障害の基本目標は後から再構成できる記録です。
侵害や個人情報流出の疑いならSecurity・Legal ProcedureとEvidence Handlingへ移ります。ただし証拠保存のため被害を放置しません。拡大中ならICがContainmentと保存の優先順位を明示します。
Recovery：一時状態から正常運用へ
緩和でError Rateが下がっても終わりではありません。重要機能を止めて利用可能にした状態はMitigatedでも、完全Recoveryではない場合があります。
合意したTarget Stateへ戻します。一時変更解除、正常Traffic、整合性処理、Backlog解消、Dependency正常化が含まれ、必要ならRollback・Roll-forward・Failover・Restoreを使います。復旧作業完了とService復旧確認を再び分けます。
復旧確認：Serverが緑なら終わりか
宣言は早まりがちです。CPU低下、Pod Running、Log減少は良い信号でも、正常利用を意味しません。
NIST Rev. 3も重要Serviceの実復元、整合性と正常動作の検証、その後の監視、終了基準に沿ったRecovery終了を求めます。[6] 最初に影響したユーザー結果へ戻って確認します。
失敗Journeyの再成功、残る遅延、欠損・重複・不整合、Queue蓄積、特定Region・Tenant・Segmentの失敗、Dependencyの正常経路、MonitoringとAlert、一時迂回の新リスクを確認します。
観察時間はTraffic、失敗周期、処理方式によります。15分正常なら完了という汎用基準でなく、Service別Acceptance CriteriaとObservation Conditionを定めます。
Communicationは独立したWorkstream
後で告知するだけではありません。Responder間の調整、経営・Support・営業などへの影響共有、ユーザーや外部機関への連絡が同時に存在し得ます。
NISTは調整、通知、公的連絡、情報共有を別活動とします。[6] Google SREも技術緩和と並び、現在の影響と対応状態の明確な伝達を重視します。[1]
更新にはIncident、現在状態・Severity、ユーザー影響、範囲、前回からの変化が必要です。進行中の緩和・復旧、Workaround、未知事項、次の判断点、次回更新も記します。
Next Updateは根拠のない復旧ETAではありません。復旧時刻が不明なら30分以内と推測せず、次の手順完了時や合意したCadenceで更新します。
Handoff：メッセージを残すだけでは終わらない
長期障害では一人の継続対応自体がリスクです。交代の要否より、状態が損失なく移るかが問題です。Google SREもIncoming ICへ説明した後、明示的に指揮権を引き受けさせます。[1]
現在の影響・Severityと根拠、ICと役割、確認事実と仮説、実行済み緩和と結果、進行中作業、失敗・再実行禁止の作業、次の判断点を渡します。内外の連絡状況、証拠場所、残るリスクも必要です。
Outgoingが文書を残すだけでは完了しません。Incomingが理解して責任を明示的に受けた時刻を記録します。
いつIncidentを終了するか
原因を完全に知るまで開き続ける必要はありませんが、Error Rateの一時低下で閉じてもいけません。Resolved条件を事前合意します。
被害停止、Journey基準達成、データ・Queue・非同期残問題の許容性、Dependency確認、監視正常、一時措置の記録と未解除措置のOwner、残存リスクの記録と認識、必要連絡の更新、Review Owner指定が条件です。
NISTも終了を技術作業完了だけでなく、復旧確認、終了基準、文書化を含む過程として扱います。[6]
振り返り：原因一行で終わらせない
原因は必要な問いですが、それだけでは同じ障害の再発をかろうじて防ぐ程度です。対応自体の改善には広い検討が必要です。
Detectionではユーザーより早く気付いたか、信号不足はないか。Triageでは範囲把握と誤仮説による浪費。Severityでは必要人員の早期参加。Coordinationでは指揮と変更権限。Mitigationでは被害削減の優先。Recoveryでは一時緩和との区別。Verificationではユーザー結果とデータ。Communicationでは必要な人への適時共有。HandoffではContext損失を確認します。
Google SREも原因分析だけでなく検出・緩和・調整・連絡を改善対象にします。[5] Actionは実Backlogへつなぎます。Blamelessは責任不要ではありません。個人を責めず、システムが行動を許容・要求した理由を調べ、修正にはOwnerを付けます。
Follow-up：文書を書けば改善したのか
Postmortemが文書庫で終わると次回の行動は変わりません。各Follow-upには表の最低情報が必要です。
緊急に入れたFlag、Firewall Rule、Traffic迂回、手動Cronは別Cleanup Itemにします。最後の段階は会議ではなく、発見したGapがBacklogのOwnershipを持つ瞬間です。
Field | 内容 |
|---|---|
| Gap | 発見した失敗可能性 |
| Action | 具体的な変更 |
| Owner | 完了まで責任を持つ人・チーム |
| Priority | 他運用作業との優先順位 |
| Target | 合意した完了目標 |
| Acceptance Evidence | 完了を判断する証拠 |
| Tracking ID | Issue・Ticketなど追跡先 |
| Status | 現在状態 |
Runbook Templateに何を含めるか
これは特定原因のTechnical Runbookではありません。Service別Commandと復旧手順は別に結び、共通状態と責任を管理します。MetadataからImprovementまで17ブロックで、検知、分類、Severity、緩和、Evidence、復旧、連絡、引き継ぎ、終了、Reviewを追います。
Roles & Authorityでは6役割の担当者と責任を記します。兼任しても指揮権と変更権限は明示します。Severity変更は上書きせず、時刻、Previous、New、理由、決定者を追加します。
Status Updateは連絡項目を様式化します。HandoffはOutgoing説明、Incoming質問時間、進行中変更確認、次判断点の合意、明示的受入、他Responderへの指揮交代通知の6項目です。配布Rollbackの詳細は別Runbookを使います。
- Incident Commander
- 全体状態・優先順位・Decisionを管理します。最優秀Debuggerである必要はありません。
- Operations / Technical Lead
- 緩和と復旧を実行します。
- Communications Owner
- 現在状態を内外へ伝えます。
- Scribe / Timeline Owner
- Timeline・判断・Evidenceを記録します。
- SME
- 特定システムを分析する専門家です。
- Production Change Authority
- 本番変更を承認・実行する権限を持ちます。
ブロック | 記録フィールド | 確認項目 |
|---|---|---|
| Runbook Metadata | runbook_name · service · runbook_owner · last_reviewed_at · review_due_at · critical_user_journeys · related_alerts · technical_runbooks · recovery_procedures · rollback_guide · escalation_path · communication_channels | リンクを定期確認。 |
| Detection | incident_id · detected_at · detected_by · detection_source(alert, user_report, support, operator, dependency, other) · observed_symptom · suspected_user_impact · affected_journey · affected_scope · initial_confidence · initial_evidence(dashboards, logs, traces, request_ids, external_status) | 推測より最初の事実を記録。 |
| Triage & Incident Declaration | declared(true, false) · declared_at · declaration_owner · current_state · initial_severity · severity_rationale · known_facts · hypotheses · unknowns | 実影響、主要Journey、Scopeと拡大、直前の配布・設定・Feature、Dependency、整合性リスク、Security/Privacy、Workaround、宣言の要否。 |
| Roles & Authority | Incident Commander · Operations / Technical Lead · Communications Owner · Scribe / Timeline Owner · SME · Production Change Authority：役割別の担当者と責任 | 小チームは兼任可能。現在の指揮とProduction変更権限者を明記。 |
| Severity Assessment | current_severity · assessed_at · assessed_by · user_impact · scope · data_risk · security_or_safety_risk · time_criticality · workaround · recoverability · coordination_complexity · uncertainty · rationale | Severity変更は上書きせず、時刻・Previous・New・理由・決定者を追加。 |
| Current Incident State | state(DETECTED, TRIAGED, DECLARED, MITIGATING, RECOVERING, MONITORING, RESOLVED) · current_objective · current_user_impact · current_scope · latest_decision · next_decision_point | 状態ごとに現在目標を一行で記録。 |
| Mitigation Log | Action · Owner · Objective · Expected Signal · Risk / Safety Control · Status · Result · Evidence | 一行動一行。実行と効果を区別。 |
| Evidence Preservation | evidence_location · retention_requirement · sensitive_data_present · security_or_legal_escalation | 配布・Artifact版、Configuration・Flag、Dashboard・Query基準時刻、Log・Trace・Request ID、Stateful SystemとDependency、実変更者・理由・結果。Security/Privacyは別Evidence手順。 |
| Recovery Plan | target_state · recovery_owner · prerequisites · technical_runbooks · recovery_actions · temporary_controls_to_remove · known_residual_risk | 配布Rollbackの詳細は別Runbook。 |
| Recovery Verification | verification_started_at · verification_owner · journey_evidence · data_evidence · dependency_evidence · monitoring_evidence · observation_condition · verification_result | Journey再成功、遅延許容、欠損・重複・整合性、Queue・非同期Backlog、Region・Tenant・Segment、Dependency正常経路、監視CoverageとAlert、一時措置の残存Risk、Service別観察条件。 |
| Communication | Audience(Incident Responders · Internal Stakeholders · Users / Customers · External Provider · Legal / Security / Regulatory) · Owner · 伝達内容 · Last Update · Next Update Trigger | 受信者ごとに一行。 |
| Status Update Template | Incident · Current State · Severity · User Impact · Affected Scope · Changes Since Previous Update · Mitigation / Recovery in Progress · Available Workaround · Known Unknowns · Next Decision Point · Next Update | Next Updateは根拠のない復旧ETAではなく次の更新点。 |
| Handoff | handoff_at · outgoing_owner · incoming_owner · current_user_impact · current_severity · severity_rationale · current_state · confirmed_facts · active_hypotheses · unknowns · completed_actions · actions_in_progress · failed_or_unsafe_actions · pending_actions · next_decision_point · communication_status · evidence_location · guardrails · incoming_owner_accepted_at | Outgoing説明、Incoming質問時間、進行中本番変更確認、次判断点合意、明示的受入、他Responderへの指揮交代通知。 |
| Closure | resolved_at · resolved_by · closure_rationale · remaining_risks · temporary_controls · post_incident_owner | 被害停止、復旧検証合格、データ・Queue・Dependency・監視確認、一時変更全記録、未解除ControlのOwner、残Risk、連絡完了、Review Owner。 |
| Post-incident Review | review_owner · review_date · incident_summary · timeline · user_impact · technical_factors · contributing_factors · detection_review · triage_review · severity_review · coordination_review · mitigation_review · recovery_review · verification_review · communication_review · handoff_review · what_worked · what_did_not_work · remaining_unknowns | Root Cause一行で終えない。 |
| Follow-up Ownership | ID · Gap · Action · Owner · Priority · Target · Acceptance Evidence · Tracking ID · Status | 一項目一行。緊急の一時措置は別Cleanup Item。 |
| Runbook Improvement | runbook_gap_found · runbook_change_required · change_owner · technical_runbook_change_required · alerting_change_required · observability_change_required · deployment_change_required · next_review_or_drill | 実IncidentごとにRunbook自体を修正。 |
Runbookの完成度はいつ分かるか
障害時に初めて読む文書にしてはいけません。平時にService・On-call担当者のSeverity理解、IC権限、連絡経路、技術リンク、引き継ぎ可能性を確認します。
実IncidentのたびにRunbook自体も更新します。NIST Rev. 3はLessons Learnedを復旧後の一回だけでなく、対応全体の改善へ還元します。[6]
よいRunbookでも障害はなくなりませんが、ばらばらな対応が生む二次障害を減らします。最初から原因を知らなくても、判断者、今守るもの、行った変更、復旧を示す証拠、次へ渡すものが分かれば、対応は反復可能な運用になります。
