# ダッシュボードとランブックの運用 インシデント対応のためのダッシュボードとランブックが、明示的なライフサイクル管理なしに場当たり的に作成され続け、汎用化しすぎ(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]]) ## 未解決の問い - 「良いランブックは本質的に一時的であるべき」という原則を、実際の組織でどう運用上のメトリクス(例: ランブックの平均寿命)として計測・強制できるか。 - ダッシュボードの discoverability を定量的に評価する方法(利用頻度・クローン数・最終更新日以外の指標)は何か。 - composability(Jsonnet・Pulumi 等)へ移行するコストと、既存の汎用ダッシュボード資産を段階的に置き換える現実的な移行パスはどのようなものか。 - 「共同作業として書かれたランブック」と「個人が単独で書いたランブック」で、前提の洗い出し効果や実運用時の有効性に差があるかを検証した研究・事例はあるか。 ## 関連 - [[Colin Douch]] — 「エンジニアのスクラップブッキング」概念の提唱者 - [[Thai Wood]] — 「ランブックは安全を買えない」という認識論的批判 ## 出典 - [[@2022__SREcon22APAC__Dashboards and Runbooks - Scrapbooking for Engineers]] - [[@2023__SREcon23Americas__If I Can Do It on an Ambulance - Scalable Incident Response Using ICS]]