# Dashboards and Runbooks: Scrapbooking for Engineers Navigation: [[index]] | [[overview]] ## 概要 [[Colin Douch]]([[Cloudflare]] Observability Platform Team Tech Lead)による USENIX SREcon22 Asia/Pacific(2022-12-07、シドニー)での講演。ダッシュボードとランブックを「エンジニアのスクラップブッキング」と呼び、これらのドキュメントが体系的な設計原則なしに場当たり的に積み上がっていく病理を分析し、composability・SLO・discoverability/explorability への移行を提案する。動画は USENIX 会員限定のため、YouTube 上の同一講演動画(`llDMcZLTPSc`)から自動字幕 transcript と代表フレームを取得した。 ## 主要メッセージ - ダッシュボードもランブックも、汎用化(over-templating・変数の組み合わせ爆発)と過度な特化(インシデントごとの使い捨てダッシュボード)という対称的な失敗様式を持ち、いずれも discoverability を損なう。(映像 + 口頭説明) - ランブックには自動化可能(automatable)・自由記述(freeform)・無価値(useless)の3クラスがあり、良いランブックは自動化への一時的な踏み石にすぎず、長期に存続すること自体が「自動化文化の不在」を示す症状である。(映像 + 口頭説明) - ダッシュボードとランブックが増殖する動機として、可視的フィードバックが与える心理的満足(「lizard brainy」な快感)と、業界慣習への cargo culting(儀式的模倣)を挙げる。(口頭説明) - 障害モードの事前想定(pre-instrumented telemetry)がダッシュボード・ランブックの内容を規定し、それが「自分はシステムを理解している」という安心感を生む一方、複雑系では必ず想定外の失敗が起きてこの安心感は崩れる。(口頭説明) - 解決の方向性として、(1) 作成・保守・削除を明示するライフサイクル管理、(2) ドキュメントとしての正式な位置づけ、(3) 全員向けの汎用ツールでなく composability(JSonnet・Pulumi 等)、(4) SLI/SLO による「何が成功か」の定義、(5) メトリクス/ログ中心から イベント・トレーシングへの移行による discoverability/explorability 重視、を提示する。(映像 + 口頭説明) ## 映像で確認できる重要点 - ![[_attachments/srecon22apac-douch-dashboards-runbooks/frame-003-3am-questions.jpg]] frame-003: オンコール中3amに投げかけられる典型的な質問「Have you checked the dashboard?」「What does the runbook say?」「Have you tried giving up on your hopes and dreams?」を戯画的に示すスライド。講演の導入エピソード(3amのインシデント対応で開口一番これを聞かれた不満)に対応する。 - ![[_attachments/srecon22apac-douch-dashboards-runbooks/frame-004-doc-cycle.jpg]] frame-004: 「New incident → New Documentation → New Distractions → New incident」という悪循環を示す円環図。インシデント対応の都度ドキュメントが増殖し、それが次のインシデント対応時のノイズ(distraction)になるという構造的問題を視覚化している。 - ![[_attachments/srecon22apac-douch-dashboards-runbooks/frame-008-variables-panel.jpg]] frame-008: Grafana ダッシュボードの `General / Service Resources` に `Service: wshim` という変数(variable)を差し込む実例のスクリーンショット。汎用ダッシュボードに変数を持たせて任意サービスに適用しようとする典型パターンを示す。 - ![[_attachments/srecon22apac-douch-dashboards-runbooks/frame-010-incident-dashboards.jpg]] frame-010: `incident-1883 adhoc`〜`incident-2044` まで連番で並ぶインシデント専用ダッシュボードの一覧。使い捨てダッシュボードが削除されずに蓄積し続ける実例として提示される。 - ![[_attachments/srecon22apac-douch-dashboards-runbooks/frame-013-remediation-runbook.jpg]] frame-013: 「Suggested Remediation: Check the consul logs (`journalctl -u consul`) for one of the following issues:」という実際のランブック抜粋。特定のコマンド・特定のログを指示する具体的な自動化候補ランブックの例。 - ![[_attachments/srecon22apac-douch-dashboards-runbooks/frame-014-three-classes.jpg]] frame-014: ランブックを「Automatable Runbooks(自動化可能)」「Freeform Runbooks(自由記述)」「Useless Runbooks(無価値)」の3クラスに分類するスライド。講演の中心分類枠組み。 - ![[_attachments/srecon22apac-douch-dashboards-runbooks/frame-018-lifecycle.jpg]] frame-018: 「Establish Clear Lifecycles: Creation → Maintenance → Deletion」という円環図。ダッシュボード・ランブックにも通常のソフトウェア成果物と同じライフサイクル管理を適用すべきという提言に対応する。 - ![[_attachments/srecon22apac-douch-dashboards-runbooks/frame-020-discoverability.jpg]] frame-020: 「Discoverability and Explorability over pre-prepared monitoring」という結論スライド。事前準備された監視(ダッシュボード・ランブック)よりも、探索可能性を重視すべきという講演全体の帰結を示す。 ## 口頭説明・補足 - 講演者は Cloudflare の Observability チームを率いる Tech Lead で、鉱業(mining)出身、Observability 分野で約10年の経験を持つ([[Colin Douch]] 参照)。冒頭の自己紹介で「ニュージーランド出身でイギリス人ではない」と繰り返し訂正するジョークを交えている。 - 導入エピソード: 約1年前のオンコールシフトで午前3時にインシデントが発生し、参加した際に最初に聞かれたのが「dashboard は確認したか」「runbook には何と書いてあるか」だったことに苛立ちを覚えたことが、本講演の出発点になっている。 - ダッシュボード・ランブックを「インシデントを悪魔に見立て、その名前を知れば制御できるという迷信的行為」に例え、これが体系性のない場当たり的な文書の蓄積を招くと指摘する。 - ダッシュボードの失敗様式を2つに分解する: (1) 汎用化しすぎ(over-templating)で変数の組み合わせが爆発し discoverability を失う、(2) 特化しすぎ(インシデントごとの使い捨てダッシュボード)で「削除していいか誰も判断できず」蓄積し続ける。両者が組み合わさると「クローンされたダッシュボードが増殖し続けるチェーンメールの転送」のような状態になると表現している。 - ランブックについても同様に「自動化可能」「自由記述(人間の目によるパターンマッチングが必要)」「無価値(マネジメント上のチェックボックス消化のためだけに存在)」の3クラスに分類し、良いランブックは本来「一時的(transient)」であるべきで、インシデント対応から自動化までの踏み石にすぎないと述べる。長期間存続するランブックは「自動化文化の不在」の症状であり、マネージャー向けに「どれだけ長く存続しているランブックがあるかを調べれば、チームの燃え尽きの兆候が分かる」と助言している。 - ダッシュボード・ランブックが増殖し続ける理由として、(1) 視覚的フィードバックが与える心理的満足("lizard brainy" な快感、フロントエンドエンジニアの職務満足度が高いことへの類推)、(2) 業界の慣習への cargo culting(何十年も前のメインフレーム時代からダッシュボード・ランブックが存在し、新人が「そういうものだ」と教えられて疑問を持たずに作り続ける)を挙げる。 - 障害モード分析(failure mode analysis、D&D のダイスに例えて形式的・非形式的いずれの実施も推奨)の結果が、メトリクス・ログの計装(テレメトリ)を規定し、それがダッシュボード・ランブックの内容を規定するという因果連鎖を説明する。この「事前に想定した障害モードに基づく計装」が、複雑系で必ず起きる想定外の失敗に対してトンネルビジョンを生む、という論点を提示している。 - 改善提案として、(1) 作成・保守・削除を明示したライフサイクル管理の確立、(2) ダッシュボード・ランブックを他のドキュメンテーションと同列に扱う(現状は「奇妙な運用系の別物」として孤立して管理されがちだと指摘)、(3) 全員の問題を1つのツールで解決しようとするのではなく Jsonnet・Pulumi のような composability を提供する building block 志向、(4) SLI/SLO のような「何が成功か」を先に定義するフレームワークでインシデント追跡から脱却する、(5) メトリクス・ログに固定化されたテレメトリからイベント・トレーシングへ移行し、outside-the-box に集約することで discoverability・explorability を実現する、という5つの方向性を提示する。 - 結論として Grafana の Explore view を discoverability の基準例として挙げつつ、多くの Observability SaaS がすでに OpenTelemetry spans を自由に投げ込んで探索できる方向に進んでいることに言及し、業界がこの方向へ向かうことへの期待を述べて締めくくっている。 ## 概念・実体への接続 - [[Colin Douch]] — 本講演の登壇者。[[Cloudflare]] Observability Platform Team Tech Lead。 - [[Cloudflare]] — 登壇者の所属組織。 - [[ダッシュボードとランブックの運用]] — 本講演の中心概念を集約した新規 concept。 ## 限界・不確実点 - USENIX 公式ページの動画は会員ログインが必要で直接取得できず、YouTube 上の同一動画(`https://www.youtube.com/watch?v=llDMcZLTPSc`、USENIX 公式チャンネル掲載)から音声・低解像度動画・代表フレームを取得した。 - transcript は YouTube 自動生成英語字幕(auto-caption)であり、人手による正式な transcript ではない。固有名詞・数値の一部(コマンド名 `journalctl -u consul` 等)は映像フレームで裏取り済みだが、口頭のみの主張は自動字幕由来であることに留意する。 - 動画全体(20分29秒)から60秒間隔で20枚の代表フレームを抽出し全て目視確認したが、フレーム間の細部(スライド遷移の全て)は捕捉していない。 - 登壇者の詳細な経歴(鉱業からの転身時期等)は USENIX 公式ページのバイオ記述のみに基づき、他ソースでの裏取りはしていない。