『SREの知識地図』の著者を招いてお送りするSREの旅〜 Road3 システムの状態を観測するを視聴して【イベント感想】

Dec 24, 2025· wan0ri· Category: Event

TL;DR

観測の目的は「ユーザー体験の保護」と「変更速度の維持」の両立。
会話の中心は SLI /SLO と Error Budget 。症状ベース監視へ寄せる。
メトリクス/ログ/トレースの役割分担と、cardinality 管理・サンプリング・PII 対策。
アラートは SLO 由来＋ Runbook 紐付け。ノイズは抑制/集約/遅延で削減。
ダッシュボードは監視盤と探索盤を分離し、リリースと観測を結合（Release Health ）。

参加イベント

2025 年 12 月 22 日（月）に開催された連続講義『SRE の知識地図』の著者を招いてお送りする SRE の旅〜 Road3 システムの状態を観測するを視聴しました。
視聴メモと、実務に転用できそうなポイントを残します。

『SREの知識地図』の著者を招いてお送りするSREの旅〜 Road3 システムの状態を観測する (2025/12/22 19:30〜)

── 『SREの知識地図』の著者を招いてお送りするSREの旅〜 Road3 システムの状態を観測する技術評論社から出版された『SREの知識地図』をテーマに、各章の執筆者と株式会社TopotalのCTOであるRyota Yoshikawaが対談形式で各章の内容についてディス …

topotal.connpass.com/event/377263/

アーカイブ（YouTube）は以下:

www.youtube.com

Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

www.youtube.com/watch?v=spz9aNZPV3I

備考: 前回参加した際の記事はこちら → 『SRE の知識地図』の著者を招いてお送りする SRE の旅〜 Road2: 信頼性を定義して組織で運用するを視聴して【イベント感想】

印象に残ったこと

1. 観測の出発点は「ユーザー症状」

ユーザーにとっての異常（失敗・遅延・不正確さ）を定義。
SLI は症状ベース、原因指標は補助に回すという整理が実務で効く。

2. SLO は“会話のハブ”

SLO/エラーバジェットを共通言語にすると、優先度調整と観測要件の合意が進むと感じました。

3. テレメトリの役割分担

メトリクス＝健康診断、ログ＝事実記録、トレース＝因果の紐解き。
トレースはクリティカルパスから段階導入、サンプリングは SLO 連動。

4. アラート疲れを防ぐ設計

「落ちたら困る」基準に限定し、抑制・集約・遅延でノイズを削減。
全アラートに責任者・優先度・TTR ・Runbook を紐付け。

5. コストとガバナンスの織り込み

高カーディナリティ抑制、保存期限・サンプリング方針、PII ガイドラインを最初に設計対象として明文化。

後に試してみたいこと（自分向け）

インフラ/SRE の日常運用に即して、

主要 SLI（成功率/遅延 P95/正確性）に暫定フォーカスし、SLO と Error Budget を設定。
Pager/On-call のアラート棚卸し。SLO 非連動は抑制/無効化し、Runbook を必ず紐付け。
Golden Signals の監視盤を 1 枚に統合。探索盤は分離して役割を明確化。
分散トレースはクリティカルパスから導入。遅延長いリクエストは必ず取得など SLO 連動サンプリング。
高カーディナリティ上位ラベルを洗い出し、削減・集約・TTL を適用してコスト管理。
リリース“完成定義”に観測タスク（メトリクス/ログ/トレース/ダッシュボード/アラート更新）を追加。
事後検証で SLO/アラート閾値を見直し、再発防止をタスク化。

まとめ（現時点の所感）

「観測なくして本番なし」。ユーザー症状起点の SLI/SLO と、SLO 由来アラート＋ Runbook の運用を軸に、まずノイズ削減とダッシュボード整理、クリティカルパスへのトレース導入から始めるのが自分の最短距離だと感じました。