# ランブック ## 定義 ランブック(runbook、手順書)は、アラートが来たときに対応者がすばやく進むべき方向を知るための、サービスごとの文書である。何のサービスで何をするか、誰が責任者か、どんな依存を持つか、インフラ構成はどうか、どんなメトリクスとログを送りそれが何を意味するか、どんなアラートがなぜ設定されているかに答える形で書き、各アラートから該当サービスのランブックへリンクする。チーム全員が全システムを知っているわけではない複雑な環境では、知識を広める手段にもなる。一方、修復手順がコピーアンドペーストで済むほど単純ならランブックのあり方がおかしい兆候であり、修復を自動化してアラートを削除すべきで、ランブックは人間の判断と診断が必要な場面のためにある(Source: [[@2019__OReillyJapan__入門 監視 - Chapter 3 アラート、オンコール、インシデント管理]] §3.1.2)。具体的な雛形はメタデータ・エスカレーション手順・外部/内部依存・技術スタック・メトリクスとログ・アラート(閾値と疑うべき原因)の各項目から成る(Source: [[@2019__OReillyJapan__入門 監視 - Appendix A 手順書の例 Demo App]])。 ## 未解決の問い - 「人間の判断と診断が必要な場面」と「自動化してアラートを消すべき定型手順」の境界を、誰がどの基準で判定し、ランブックの棚卸しに組み込むのか。 - ランブックの保守責任(サービスオーナか、オンコール対応者か)と陳腐化の検知方法はどう設計するのがよいか。 - LLM エージェントがトラブルシューティングガイドを解釈・実行する([[TSG自動化]])とき、「人間の判断のための文書」という位置づけはどう変わるか。人間向けの書き方と機械実行向けの書き方は両立するか。 ## 未編纂の観察 - 「定型コマンドで済むなら自動化せよ」という線引きは 3 ソースで一致する。Julian はコピーアンドペーストで済む修復手順をランブックの誤用の兆候とし、Iwahori は定型コマンドで解決できるものを人間を起こす対象でなく自動化対象とし、Douch は自動化可能なランブックを自動化への踏み石として一時的に存在すべきものと位置づける(Source: [[@2019__OReillyJapan__入門 監視 - Chapter 3 アラート、オンコール、インシデント管理]], [[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか]], [[@2022__SREcon22APAC__Dashboards and Runbooks - Scrapbooking for Engineers]]) - 手順書に「なぜそのアラートがあるのか」を残す点でも一致する。Julian の雛形はアラートごとに発報条件と疑うべき原因を書かせ、良い手順書の問いに「アラートの理由」を含める。Iwahori は How だけの旧手順書ではアラートの背景が失われたと指摘し、背景・判断材料・ヒントを残す設計に改めた(Source: [[@2019__OReillyJapan__入門 監視 - Appendix A 手順書の例 Demo App]], [[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか]]) ## 関連 - [[ダッシュボードとランブックの運用]](ランブックの 3 クラスと一時性、ライフサイクル管理) - [[TSG自動化]] / [[アクショナブルアラート]] / [[オンコール]] / [[インシデント管理]] - [[@2019__OReillyJapan__入門 監視 - Chapter 11 監視アセスメントの実行]](監視アセスメントの成果を手順書へ書く) ## 出典 - [[@2019__OReillyJapan__入門 監視 - Chapter 3 アラート、オンコール、インシデント管理]](§3.1.2 手順書を書こう) - [[@2019__OReillyJapan__入門 監視 - Appendix A 手順書の例 Demo App]] - [[@2019__OReillyJapan__入門 監視 - Chapter 11 監視アセスメントの実行]](§11.5) - [[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか]] - [[@2022__SREcon22APAC__Dashboards and Runbooks - Scrapbooking for Engineers]]