# SRE Book - Chapter 14: Managing Incidents ## 要約 本章は Google におけるインシデント管理の原則と実践を体系的に解説する。まず「非管理型インシデント」の具体的シナリオを通じて、役割分担なき対応がいかに混乱を招くかを示す。技術的問題への過度な集中、コミュニケーション不足、独断的な変更（フリーランシング）が事態を悪化させる典型パターンを明らかにしたうえで、インシデントコマンドシステム（ICS）に基づく構造化された対応フレームワークを提示する。インシデントコマンダー、オペレーション担当、コミュニケーション担当、プランニング担当という4つの役割を軸に、指揮所の設置、ライブドキュメントの維持、明示的な引き継ぎといった具体的プラクティスを述べる。同じ障害シナリオに管理型の対応を適用した対照例で有効性を実証し、インシデント宣言の判断基準と日常的な訓練の重要性で締めくくる。 ## 主要概念 - **インシデントコマンドシステム（ICS）**: 消防など緊急対応組織に由来する指揮体系である。「責任の再帰的分離」を原則とし、役割の重複を排除して対応を構造化する。Google はこの手法をソフトウェアインシデントに適用している。 - **役割の分離**: インシデントコマンダー（全体統括・意思決定）、オペレーション担当（システム変更の実行）、コミュニケーション担当（利害関係者への情報発信）、プランニング担当（長期的懸念・バグ起票・ロールバック計画）の4役を明確に分ける。対応規模に応じて1人が複数役を兼ねてもよいが、責任の所在は常に明確にする。 - **フリーランシング**: 善意に基づく独断行動のことである。コマンダーの統制なく個人が独自に対処すると、変更が衝突し障害を拡大させる。インシデント中のシステム変更はオペレーション担当のみが行うべきである。 - **ライブインシデントドキュメント**: インシデントの現状・タイムライン・対応履歴をリアルタイムで記録する共有文書である。重要情報を先頭に配置し、ポストモーテム分析の基盤となる。Google Docs のような共同編集プラットフォームが推奨される。 - **明示的ハンドオフ**: 指揮権の引き継ぎは口頭で明確に確認する。「あなたが今からインシデントコマンダーです、よろしいですか」と伝え、相手の承認を待ってから離脱する。暗黙の引き継ぎは責任の空白を生む。 ## 実践的指針 - **インシデント宣言の基準**: (1) 2つ目のチームの関与が必要、(2) 顧客に影響が出ている、(3) 集中的な分析を1時間続けても未解決、のいずれかを満たせばインシデントを宣言する。宣言して不要だったとしても害は小さいが、宣言せずに混乱が広がる損失は大きい。 - **指揮所の確立**: 物理的な戦争部屋でもバーチャルな IRC チャンネルでもよいが、全員が参照する単一の調整拠点を設ける。IRC は信頼性が高く、対応ログとしても機能する。 - **優先順位付け**: サービスの復旧と証拠の保全を最優先する。根本原因の究明はポストモーテムに回す。 - **事前準備**: 手順書を事前に整備し、参加者の意見を取り入れておく。訓練なき手順書は実戦で機能しない。 - **信頼と委任**: 割り当てた役割には自律性を与える。マイクロマネジメントは対応速度を落とす。 - **内省**: 自身の感情状態を監視し、圧倒されたら交代を要請する。疲弊した判断は追加障害を招く。 - **定期訓練**: インシデント管理の習熟度は使わなければ急速に衰退する。変更管理や災害復旧テストの中で日常的にプロセスを実践し、役割をローテーションして全員の対応能力を育てる。 ## 関連 - [[@2016__OReilly__SRE Book - Chapter 1 Introduction]] - [[SRE Book]] - [[SRE]] ## 出典 Beyer, B., Jones, C., Petoff, J., Murphy, N.R. "Site Reliability Engineering: How Google Runs Production Systems," O'Reilly Media, 2016. Chapter 14: Managing Incidents (Written by Andrew Stribblehill, Edited by Kavita Guliani).