# SRE Book - Chapter 13: Emergency Response ## 要約 本章は Google における緊急対応の原則と実践を、テスト起因・変更起因・プロセス起因の 3 つの実際のインシデント事例を通じて解説する。いずれの事例にも共通する教訓として、パニックにならないこと、必要に応じてエスカレーションすること、過去の障害から学ぶこと、能動的にシステムをテストすること、文書化を徹底すること、そして改善のサイクルを継続することが挙げられる。著者は「すべての問題には解決策がある」という信念のもと、障害履歴の蓄積、仮説的シナリオの検討、能動的テストの奨励という 3 つの学習メカニズムを提示し、組織の規模を問わず適用可能な緊急対応の枠組みを示している。 ## 主要概念 - **パニック回避の原則**: 緊急事態において最も重要なのは冷静さを保つことである。SRE は訓練を受けており、物理的な危険はほとんどない。感情ではなく手順に従うことが事態の収束を早める。 - **エスカレーションの文化**: 問題の解決に行き詰まった場合、追加の人員やチーム全体、さらには組織全体を巻き込むことを躊躇すべきではない。より広い範囲の専門知識を集めることで解決が加速する。 - **ポストモーテムの徹底**: すべての障害を正直かつ詳細に文書化し、戦術的・戦略的な再発防止策を特定する。ポストモーテムを全社的に公開・整理し、フォローアップの実行に対する説明責任を持つ。 - **能動的テスト**: 理論と現実は大きく異なるため、最善のスタッフが揃った条件下で意図的にシステムを壊すテストを実施する。深夜の障害で初めて問題に気づくよりも、管理された環境でのテストのほうが安全である。 - **ロールバック手順の事前検証**: ロールバック手順が本番環境で機能する保証はない。大規模テストの前にステージング環境でロールバックを検証する必要がある。 - **カナリアデプロイの重要性**: 設定変更のカナリアが特定のキーワードや機能の組み合わせを網羅していない場合、本番環境での障害を防げない。カナリアプロセスの改善と自動化が不可欠である。 - **帯域外通信の確保**: 本番システムの障害時に通常のコミュニケーションツールが使えなくなる可能性がある。帯域外の通信手段を事前に確保し、維持する必要がある。 - **自動化の安全策（サニティチェック）**: 自動化システムは空の応答を「全件」と解釈するような危険な動作を防ぐサニティチェックを備えるべきである。空のデータベース応答を「対象なし」ではなく「全マシン」と解釈したことが壊滅的な障害を引き起こした事例がある。 ## 実践的指針 - 緊急事態が発生したら、まずパニックにならず、確立されたインシデント対応プロセスに従う - 問題が解決しない場合は速やかにエスカレーションし、追加の人員を巻き込む - 障害の原因となった行動を取った人物を情報源として活用する（非難ではなく） - すべての障害をポストモーテムとして文書化し、戦術的（短期）と戦略的（長期）の両方の再発防止策を策定する - ポストモーテムを全社的に公開し、フォローアップの完了を追跡する - ロールバック手順はステージング環境で事前に検証する - カナリアデプロイでは、稀な設定や機能の組み合わせも含めて網羅的にテストする - 帯域外の通信手段とコマンドラインによる代替アクセス手段を確保する - 自動化にはサニティチェックを組み込み、異常な入力に対するガードレールを設ける - 「もし〜が起きたら」という仮説的シナリオを定期的に検討し、対応計画を策定する - 最善のスタッフが揃った条件下で能動的にシステムテストを実施する ## 事例の要約 ### テスト起因のインシデント MySQL クラスタ内の 1 つのデータベースへのアクセスを意図的にブロックするテストが、想定外のカスケード障害を引き起こし、複数の依存サービスに影響した。1 時間以内に完全復旧したが、システム間の相互依存関係の理解不足、インシデント対応プロセスの周知不足、ロールバック手順の未検証が明らかになった。 ### 変更起因のインシデント 不正利用防止インフラへのグローバルな設定変更が、クラッシュループのバグを誘発し、外部サービス群と内部アプリケーションに同時に影響した。モニタリングが数秒で異常を検知し、プッシュエンジニアが 5 分以内にロールバックを実施した。カナリアが稀な設定キーワードの組み合わせを網羅していなかったことが根本原因であった。 ### プロセス起因のインシデント 廃止予定のサーバ群に対する 2 件のターンダウンリクエストが、自動化のバグによりグローバルな全マシンのディスク消去キューへの送信を引き起こした。自動化サーバがデータベースからの空の応答を「全マシン」と解釈したことが根本原因である。1 時間で障害は終息したが、容量の大部分を復旧するまでに 3 日を要した。 ## 関連 - [[@2016__OReilly__SRE Book - Chapter 1 Introduction]] - [[SRE Book]] - [[SRE]] - [[インシデント管理]] - [[ポストモーテム]] ## 出典 Beyer, B., Jones, C., Petoff, J., Murphy, N. R. (Eds.). "Site Reliability Engineering: How Google Runs Production Systems," O'Reilly Media, 2016. Chapter 13: Emergency Response (Written by Corey Adam Baye, Edited by Diane Bates).