Slide 1
Slide 1 text
ja.mackerel.io
2025-08-07 id:onk
オブザーバビリティ文化を
組織に浸透させるには
国産サービスで実践するオブザーバビリティ入門
Slide 2
Slide 2 text
自己紹介
● 大仲 能史 a.k.a. id:onk
● 芸歴20年
○ バックエンド〜インフラが主戦場
● 株式会社はてな チーフエンジニア
● Mackerel開発チーム エンジニアリングマネージャー
2
Slide 3
Slide 3 text
力作の完成、
おめでとうございます
3
Slide 4
Slide 4 text
今日の話
4
Slide 5
Slide 5 text
オブザーバビリティ文化を
組織に浸透させるには
5
Slide 6
Slide 6 text
6
Slide 7
Slide 7 text
よろしくお願いします
7
Slide 8
Slide 8 text
アジェンダ
● Mackerelという国産可観測性プラットフォーム
● 定点観測の取り組み
○ SRE
○ PWG
● オブザーバビリティを組織に浸透させるには
8
Slide 9
Slide 9 text
9
Slide 10
Slide 10 text
“Mackerel” as an Observability Platform
10
Slide 11
Slide 11 text
サーバー監視サービスとして生まれたMackerel
11
Slide 12
Slide 12 text
ラベル付きメトリック機能のリリース
12
Slide 13
Slide 13 text
ラベル付きメトリック機能のリリース
● 入力が多次元に
○ 今までのメトリックは、横軸に時間、縦軸に値のみ
○ 値にAttributeが付いているので、任意に絞り込める
13
Slide 14
Slide 14 text
APM機能のリリース
14
Slide 15
Slide 15 text
APM機能のリリース
15
● ボトルネックを見つける
○ HTTPエンドポイントごと、DBクエリごとに集計
○ エラーの発生箇所ごとに集計
● アプリケーションの中の処理を追跡する
○ トランザクション単位で処理の流れと時間を可視化
Slide 16
Slide 16 text
最近のMackerel
● 誰でも簡単に始めやすく奥深い可観測性プラットフォーム
○ サーバー監視はすぐに始められる
○ ダッシュボードも一瞬で作れる
● チームみんなで育てる監視
○ Slack上でグラフを見て、そのままコミュニケーション
● アプリケーションの振る舞いを監視するAPM
○ なんとなくの不調を、中を見通せる事実に変える
16
Slide 17
Slide 17 text
定点観測
1
7
Slide 18
Slide 18 text
SLO Monitoring
● SLO
○ SREの代表的なプラクティス
● プロダクトチーム、プロダクトオーナーの意思決定
○ エラーバジェットポリシー ＝ SLOを満たせなかったら、
機能開発を緩めて信頼性の改善に取り組む
● SLI/SLOを改善するフィードバックループ
○ Revisit Date
18
Slide 19
Slide 19 text
● SLOを割っているか、割っていたか
○ バーンレートアラートもあるが
この場でも会話している
● 対応したがSLOに影響が無いもの
○ 対応必要ならSLOが足りない
● SLO緩める？厳しくする？
SLO Monitoring
19
Slide 20
Slide 20 text
PWG (Performance Working Group)
● サービスの運用状況をチームで見直す月次定例会
● はてなで2009年ぐらいから開催している
● SRE本31章と酷似
20
Slide 21
Slide 21 text
SRE本31章
21
Slide 22
Slide 22 text
SRE本31章
22
私たちが行うミーティングの中で、平均以上
に有益なものが一つあります。それはプロダ
クションミーティングと呼ばれるもので、
SREチームが自分たちと他の参加者に対し、
担当するサービスの状況について十分に注意
を払って明確に説明をすることによって、す
べての関係者の全般的な認識を高め、サービ
スの運用を改善するために行われます。
Slide 23
Slide 23 text
SRE本31章
23
定期的なミーティングにおいて設計上の判断
をサービスのパフォーマンスと合わせて考え
てみることは、きわめて強力なフィードバッ
クループになります。
Slide 24
Slide 24 text
SRE本31章
24
● プロダクション環境において予定されてい
る変更
● メトリクス
● 障害
● ページされたイベント
● ページされなかったイベント
● これまでのアクションアイテム
Slide 25
Slide 25 text
PWG (Performance Working Group)
● 直近の障害ふりかえり: 対応状況や再発防止策の確認
● 作業ログ: 手作業や臨時作業をふりかえって、根本原因や自動化の機会を探る
● アラート: 発火傾向の分析、閾値の見直し、不要なアラートの削除
● ダッシュボード: サービス状態を俯瞰し、変化を見つける。SLOも確認
● 今日話したいこと: 自由トピック
● 今後の変化共有: アクセス傾向が変わるイベント、リリースや構成変更などの予
告
● 出たTODOのIssue化: 話した内容をその場でNext Actionに繋げる
● 感想/雑談: ちょっとした気づきやモヤモヤの解消。このアジェンダ自体の見直
しとかも
25
Slide 26
Slide 26 text
アラート一覧眺めるコーナー
26
● Mackerelのアラート一覧とその傾向を眺める
○ それぞれがなぜ発生しているのかを話す
● 対応していないアラートがあったら
○ そもそも不要なアラートじゃないか会話する
○ その場で閾値を変えたり、監視ごと消したり
● 頻出しているアラートがあったら
○ 必要なアラートなら根本対応を検討する
Slide 27
Slide 27 text
● 議事録を取りつつその場で調べる
● 調べきれないならオブザーバビリ
ティが足りない
○ 引き続き調査したり
○ 計装するIssueを入れたり
ダッシュボード
27
Slide 28
Slide 28 text
● 未来の見通しを議論できる
○ 利用状況のトレンドや今後の開発予定の共有
○ キャパシティプランニング判断
● SREsのソフトスキル向上
○ Devに対してタスクを振る機会
● システム構成オンボーディング
○ アーキテクチャや特性、コンポーネントのオーナーに対する
解像度が上がる
PWGの効能
28
Slide 29
Slide 29 text
PWGの効能
● チームみんなで育てる監視
○ その場で会話して編集できる
○ オオカミ少年アラートの抑制
○ ダッシュボードの改善
● 「情報」は意思決定と行動を促すものである
○ これで意思決定できますか、行動できますか
○ runbookを書けない監視は存在すべきではない
29
Slide 30
Slide 30 text
オブザーバビリティ文化を
組織に浸透させるには
3
0
Slide 31
Slide 31 text
● ツールの効果的な導入
● 開発者も巻き込む
● 運用プロセスに組み込む
オブザーバビリティ文化を組織に浸透させるには
31
Slide 32
Slide 32 text
ツールを導入して全体感を見る
● Mackerel Agent
● クラウドインテグレーション
● 外形監視
● 自動計装
● O11yが足りないところを追加で計装する
32
Slide 33
Slide 33 text
● アプリケーションの中の処理を見る
○ リソースの監視ではなくAPMならDevの興味範囲
○ オブザーバビリティの向上からスタートすると巻き込みやすい
■ トレース
■ エラー
● 特にエラーは分かりやすく開発者の領域
○ 負荷ではなくバグ
開発者も巻き込む
33
Slide 34
Slide 34 text
開発者も巻き込む
34
● ダッシュボードを利用した定点観測会
○ 全員がシステムの「普段の状態」を共通認識として持てる
■ SLO、各コンポーネントの強弱、最近の傾向、限界値
○ 何かが起きたときに「異常な状態」に気づきやすくなる
■ 勘と経験に頼った探索にものすごく役に立つ
■ オブザーバビリティがある状態でも更に爆速に
● 自分の守備範囲と思わせる
○ 知識が無い→学習している、に変えたい
Slide 35
Slide 35 text
認知負荷
35
● 課題内在性負荷
○ 学習対象そのものの複雑さによる負荷
○ 専門用語が多い、概念が抽象的である
● 課題外在性負荷
○ 学習内容とは直接関係のない負荷
○ 分かりにくい説明、不要な情報過多
● 学習関連負荷
○ 知識を定着させるために必要な負荷
○ 問題を解く、他の人と議論する
Slide 36
Slide 36 text
● 使い道に合わせて情報量を減らす
● 上から下に流れていくよう構成する
○ 外側のコンポーネントを上に、内側のコンポーネントは下に
● グラフに補助線を入れる
○ 普段0.1〜0.2で、危険域が90.0、というメトリックもある
○ 10.0程度の揺らぎは普段の100倍だけど、ただのノイズ
● Markdownウィジェットを使って適宜説明を入れる
負荷をできる限り下げるダッシュボードの構築
36
Slide 37
Slide 37 text
運用プロセスに組み込む
● リリース前後でAPMの画面を確認する
○ 指標が悪化したらロールバックや、機能トグルをオフに
● アラートを設定し、普段のチャットに通知が来るように
○ インフラチャンネルではなく、開発チャンネルに通知すると
Critical通知が来たら全員で対応するプロセスになりやすい
● 障害時に見るダッシュボード
○ 初動フローに「ダッシュボードを確認する」と明記しておく
○ ポストモーテムにもスクショやリンクを沢山貼って見慣れる
37
Slide 38
Slide 38 text
運用プロセスに組み込む
38
● 障害対応演習を定期的に行う
○ 学習関連負荷をかける
わかばちゃんと学ぶ サーバー監視 湊川あい 粕谷大輔 C&R研究所
Slide 39
Slide 39 text
まとめ
3
9
Slide 40
Slide 40 text
● Mackerelは可観測性プラットフォームです
○ 最近はアプリケーションの中も見られるようになっています
● 定点観測を義務づける＝運用プロセスに組み込むと良い
○ SLOをRevisit Date通りに運用する
○ チームを徐々に育成していく
● オブザーバビリティ文化を組織に浸透させるには
○ 組織の運用プロセスに組み込む
○ 認知負荷をできる限り下げながら、組織に対してパッチを当てる
まとめ
40