# ダッシュボードとランブックの運用 インシデント対応のためのダッシュボードとランブックが、明示的なライフサイクル管理なしに場当たり的に作成され続け、汎用化しすぎ(over-templating)または特化しすぎ(使い捨てダッシュボード)という対称的な失敗様式に陥り、最終的に discoverability を損なって新規インシデント対応の調査時間を増加させる構造的問題。[[Colin Douch]]([[Cloudflare]])は、この病理を「エンジニアのスクラップブッキング」と呼んだ。(Source: [[@2022__SREcon22APAC__Dashboards and Runbooks - Scrapbooking for Engineers]]) ## 失敗様式 - **ダッシュボードの二極化**: 変数(variable)を多用して汎用化しすぎると、変数の組み合わせ爆発(combinatorics)により discoverability を失う。逆にインシデントごとに使い捨てダッシュボードを作ると、削除判断がつかず永続的に蓄積する。 - **ランブックの3クラス**: 自動化可能(automatable)・自由記述(freeform、人間のパターンマッチングが必要)・無価値(useless、マネジメント上のチェックボックス消化のためだけに存在)。 - **良いランブックの本質的な一時性(transience)**: 自動化可能なランブックは本来、インシデント対応から自動化への「踏み石」として一時的に存在すべきものであり、長期間存続すること自体が組織に自動化文化が根付いていない症状である。 ## 増殖の動機 - 可視的フィードバックが与える心理的満足(ログの1行より視覚的な成果物を作ることの快感)。 - 業界慣習への cargo culting(何十年も前から存在する慣習を、疑問を持たずに新人に継承させる)。 - 障害モードの事前想定(failure mode analysis)がテレメトリの計装内容を規定し、それがダッシュボード・ランブックの内容を規定するという因果連鎖。この「事前計装されたテレメトリ(pre-instrumented telemetry)」が、複雑系で必然的に起きる想定外の失敗に対してトンネルビジョンを生む。 ## 改善の方向性 - 作成・保守・削除を明示したライフサイクル管理の確立。 - ダッシュボード・ランブックを「奇妙な運用系の別物」ではなく他の正式なドキュメンテーションと同列に扱う。 - 全チームの問題を1つの汎用ツールで解決しようとするのではなく、Jsonnet・Pulumi のような composability(building block志向)を提供する。 - SLI/SLO のような「何が成功か」を先に定義するフレームワークにより、インシデントを後追いで追跡するマインドセットから脱却する。 - メトリクス・ログに固定化されたテレメトリからイベント・トレーシングへ移行し、事前に定義した「興味深いもの」の枠を超えて discoverability・explorability を重視する。 ## 横断的知見 - 本概念が指摘する「事前計装されたテレメトリによるトンネルビジョン」は、[[アクショナブルアラート]]が扱う「症状ベースアラーティング」の議論と表裏一体である。いずれも「あらかじめ想定した障害モードに基づく計装・ドキュメント」が、想定外の障害への対応力を損なうという同型の構造を指摘している。 - ランブックの「本質的な一時性」という主張は、[[インシデント調査戦略]]における体系的調査と日和見的調査の対比とも接続する。自動化可能なランブックへの依存は「体系的調査の代替物」として機能しうるが、それが恒久化すると調査能力そのものの成長を止めるという緊張関係がある。 - **「ランブックは本質的に一時的」(Douch)と「ランブックは安全を買えない」(Wood)は、異なる次元からランブックの限界を補い合う**: Douch（[[@2022__SREcon22APAC__Dashboards and Runbooks - Scrapbooking for Engineers]]）は自動化可能なランブックが自動化への「踏み石」として一時的に存在すべきと、ライフサイクル管理・composability という運用面の処方箋を提示する。一方 [[Thai Wood]]（[[@2023__SREcon23Americas__If I Can Do It on an Ambulance - Scalable Incident Response Using ICS]]）は「You cannot document your way to safety」と述べ、ランブックが「書かれた時点で想定した未来」であり実際のインシデントとは乖離しやすいという、より根本的な認識論的限界を指摘する。Douch の処方箋（一時性の運用管理）は Wood の指摘（文書と実際の乖離は原理的に埋まらない）を前提とすれば、「ランブックを恒久資産として扱わない」という結論で収束する。(Source: [[@2022__SREcon22APAC__Dashboards and Runbooks - Scrapbooking for Engineers]], [[@2023__SREcon23Americas__If I Can Do It on an Ambulance - Scalable Incident Response Using ICS]]) - **ランブック作成という「活動」自体の価値は Wood が明示的に肯定する**: Wood はランブックが緊急時にそのまま機能することは保証しないとしつつ、チームで一緒にランブックを書く活動自体は「暗黙の前提を洗い出す」価値があると述べる（例: 「SSH してよいと思っていなかった」という気づき）。これは Douch のランブック3クラス(自動化可能/自由記述/無価値)のうち、無価値クラスとの境界線を引く材料になる——チェックボックス消化のためだけに書かれたランブックにはこの「前提の洗い出し」効果がなく、共同作業として書かれたものにのみ効果がある可能性を示唆する。(Source: [[@2023__SREcon23Americas__If I Can Do It on an Ambulance - Scalable Incident Response Using ICS]]) - **『SLO サービスレベル目標』15章のSLOダッシュボードは、「二極化」失敗を回避する固定テンプレートの具体例として読める**: Douch が指摘するダッシュボードの二極化(変数を多用した汎用化のしすぎによる discoverability 喪失 対 インシデントごとの使い捨てダッシュボードの永続的蓄積)に対し、Hidalgo が15章で示すSLOダッシュボードは、現在の状態(バイナリ)・SLO違反グラフ・バーンダウングラフ・定義ドキュメントへのリンクという4要素の固定テンプレートを、対象システムが何であれ同一の構成で全SLOに適用する設計である。変数の組み合わせ爆発を許す汎用ダッシュボードでもなく、インシデントごとの使い捨てでもない「SLO単位で1枚、要素は固定」という第三の型は、本概念が「改善の方向性」で示唆する「SLI/SLOのような『何が成功か』を先に定義するフレームワークによる後追い追跡からの脱却」を、ダッシュボード設計そのものに具体化した一例といえる。さらに「定義ドキュメントへのリンク」を必須要素に含める点は、ダッシュボード単体の discoverability だけでなく、Douch が重視する情報同士の発見可能性(ダッシュボードから文書へ、文書からダッシュボードへ)を双方向に担保する設計とも読める。(Source: [[@2022__SREcon22APAC__Dashboards and Runbooks - Scrapbooking for Engineers]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 15 発見可能で理解可能なSLO]] §15.2.4) - **固定テンプレートによる手順書の完全性保証は、Douchが指摘する「無価値なランブック」との境界線を、内容の網羅性という別の軸から引く**: Douch([[@2022__SREcon22APAC__Dashboards and Runbooks - Scrapbooking for Engineers]])のランブック3クラス(自動化可能/自由記述/無価値)は、無価値クラスを「マネジメント上のチェックボックス消化のためだけに存在する」ものとして機能面から定義するが、何が「無価値」を生むかという作成プロセス側の要因には立ち入らない。『SREの探求』19章は、タイトル・概要・重大度・検証・トラブルシューティング・解決策・エスカレーション・関連リンクという固定セクションを持つ手順書テンプレートを提示し、特定の情報が未確定でも"TBD"/"N/A"を明記しどのセクションも空欄のままにしないことを求める。これは、Douchが名指しした「無価値なランブック」(内容が伴わないまま存在するランブック)が生まれる経路の一つ——セクションの欠落や記入漏れ——を、テンプレートの構造的強制によって事前に塞ぐ予防策として読める。ただしテンプレートは記入の完全性を保証しても、Wood(既出)が指摘する「文書と実際の乖離」という認識論的限界そのものは解消しない。(Source: [[@2022__SREcon22APAC__Dashboards and Runbooks - Scrapbooking for Engineers]], [[@2021__OReillyJapan__SREの探求 - Chapter 19 ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合]] §19.3.1) - **EngPlayの「アラート-手順書エントリの自動照合」は、Douchが求めるライフサイクル管理を、削除ではなく欠落検知の方向で自動化した実例である**: Douchの「改善の方向性」は作成・保守・削除を明示したライフサイクル管理の確立を求めるが、具体的な自動化の実装例までは示さない。19章のEngPlay(Google社内の手順書専用ホスティング基盤)は、モニタリング設定から生成されたアラートをツールが自動的に手順書エントリと比較し、アラートが文書化されていない、またはドキュメンテーションはあるが対応するアラートが欠落している場合に警告を出す機能を持つ。これはランブックの「作成漏れ」を運用時に自動検知する具体的な実装であり、Douchが理念として掲げるライフサイクル管理の一部(保守フェーズの欠落検知)を先取りする実例と言える。(Source: [[@2022__SREcon22APAC__Dashboards and Runbooks - Scrapbooking for Engineers]], [[@2021__OReillyJapan__SREの探求 - Chapter 19 ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合]] §19.2.1) ## 未解決の問い - 「良いランブックは本質的に一時的であるべき」という原則を、実際の組織でどう運用上のメトリクス(例: ランブックの平均寿命)として計測・強制できるか。 - ダッシュボードの discoverability を定量的に評価する方法(利用頻度・クローン数・最終更新日以外の指標)は何か。 - composability(Jsonnet・Pulumi 等)へ移行するコストと、既存の汎用ダッシュボード資産を段階的に置き換える現実的な移行パスはどのようなものか。 - 「共同作業として書かれたランブック」と「個人が単独で書いたランブック」で、前提の洗い出し効果や実運用時の有効性に差があるかを検証した研究・事例はあるか。 ## 関連 - [[Colin Douch]] — 「エンジニアのスクラップブッキング」概念の提唱者 - [[Thai Wood]] — 「ランブックは安全を買えない」という認識論的批判 - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 15 発見可能で理解可能なSLO]] — 固定テンプレート型SLOダッシュボードの具体例 - [[@2021__OReillyJapan__SREの探求 - Chapter 19 ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合]] — 固定テンプレートによる手順書の完全性保証、EngPlayによるアラート-手順書エントリの自動照合 - [[EngPlay]] — アラート-手順書エントリ自動照合の実装 - [[ドキュメンテーションのワークフロー統合]] — ドキュメンテーション一般の統合原則との接続 ## 出典 - [[@2022__SREcon22APAC__Dashboards and Runbooks - Scrapbooking for Engineers]] - [[@2023__SREcon23Americas__If I Can Do It on an Ambulance - Scalable Incident Response Using ICS]] - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 15 発見可能で理解可能なSLO]]（SLOダッシュボードの4要素固定テンプレート） - [[@2021__OReillyJapan__SREの探求 - Chapter 19 ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合]]（§19.3.1: 手順書テンプレートによる完全性保証、§19.2.1: EngPlayのアラート-手順書エントリ自動照合)