通知再考 ~ 最高のアラート通知を今改めて考える ~

https://event.cloudnativedays.jp/cnk/talks/2893
https://x.com/r_takaishi

Transcript

1. 通知再考 ~ 最高のアラート通知を今改めて考える ~ 髙石諒 / @r_takaishi 2026-05-15 クラウドネイティブ会議
2. 髙石 諒 / @r_takaishi • ソフトウェアエンジニア ◦ 株式会社フライル • OSS開発 ◦ https://github.com/takaishi/tfclean ◦ apply済みのimport/moved/removed blockを一掃できます • 過去登壇 ◦ SRE Kaigi 2025 / どうやればインシデント対応能力を鍛えられ るのか？
3. 株式会社フライル • 膨大なフィードバックを分類・要約しプロダクト・サー ビスの改善へ繋げるSaaSの開発 ◦ データウェアハウス・BI・データ加工ワークフロー
4. スポンサーセッションもあるので見てください • https://event.cloudnativedays.jp/cnk/talks/3048 • まだ見ていなければ是非アーカイブ視聴を！
5. 本題
6. みなさん
7. こんな経験はありますか 🖐
8. アラートで夜中起こさ れた、と思ったらたま たまその一瞬だけ閾値 を越えただけで、起き る必要がなかった
9. 私はあります 🫠
10. とにかく大量のアラー ト通知・エラー通知が 届いて疲れてしまった
11. 私はあります 🫠
12. 疲れたくないでござる
13. 今日はアラート通知を改 めて考える話をします
14. アジェンダ 1. 通知の3タイプ と メソッドの歴史 2. 通知の難しさ — flyle の現場から 3. 通知を改善する スピーカーの経験をベースに調べた・考えたことを話し ます
15. 1. 通知の3タイプ と メソッドの歴史
16. 通知には3タイプありそう • Event-based ◦ 例外・スタックトレース・ログ。1 イベント単位 ◦ コードの異常に気づきたい • Metric-based ◦ 時系列の数値が閾値超え。CPU / Memory / Error 率 ◦ リソース・サービスの異常に気づきたい • Symptom-based ◦ ユーザーが体験する 症状 で発火。SLO バーンレート ◦ ユーザーの困りごとに気づきたい
17. メソッドの系譜 • 〜2010 OK / WARNING / CRITICAL — 外形監視・死活・メトリクス • 2012 USE Method（Brendan Gregg）— リソース指向 (Utilization / Saturation / Errors) • 2016 Four Golden Signals（Google SRE Book）— Latency / Traffic / Errors / Saturation • 2018 RED Method（Tom Wilkie）— サービス指向 (Rate / Errors / Duration) • 2018 SLO バーンレート（SRE Workbook）— どう判定するか：時間軸を加 味した許容量の消費速度 • 2022〜 Beyond SLO — Desai 2σ / Rethinking SLOs
18. 通知先も変遷がありそう • Email / ポケベル / 任意のスクリプト • オンコール SaaS（2009〜）— PagerDuty ◦ Severity・ローテーション・エスカレーションを SaaS 化 ◦ SMSや電話、スマホアプリのプッシュ通知 • 業務チャット（2010s〜）— IRC → 中略 → Slack/Teams ◦ Hubot (2011) で「ChatOps」が定着 ◦ スマホアプリでプッシュ通知 • AIOps / LLM トリアージ（2023〜）— 通知そのものではないが通知前 後で活用 → 通知は「届ける手段」だけでなく「誰がいつ受け取るか」の設計対象に
19. 積み重ねの歴史 • 新しい手法は古い手法を完全には置き換えないと考える • ただし役割は絞られる ◦ 全てにCPU利用率80%のアラートを設定、というのは今はあまりや らないだろう • 自分のシステムで何を使うかは文脈次第 → 各プラクティス・メソッドが何を目的とするかを理解する
20. 2. 通知の難しさ — flyle の現場から
21. flyleの通知史 • 2020 創業 — 素朴なエラー通知 (CloudWatch → Slack) • 2023 SLO 導入を検討したが中止 • 2024 Datadog導入、監視対象のメトリクス増加 • 2024 コンポーネント毎の通知チャンネル整備 • 2025 マルチプロダクト化、緊急度毎のチャンネル整備 • 未来 AIOpsやオンコールSaaSの導入？
22. 複雑になっていく構造 • コンポーネントが増える → 通知先も増える • 組織拡大 → 通知先の増加・分割 • 新しいメソッドを採用 → 既存のしきい値モニタと並走
23. SLO を導入しなかった理由 • プロダクトと組織の流動性を考慮すると人間が判断する 方が当時はよかった ◦ SLOベースで判断するコストが大きい • メンテナンスの余裕がなかった ◦ 組織規模 ◦ 優先順位 ◦ 結果として監視・通知が後回しになりがちだったので妥当だったと 思う
24. 本当に必要だったもの • アプリエラー発生時の判断高速化 ◦ 当時はアプリエラーの方が圧倒的に発生が多かった • 全体のどこで、どんな問題が起きているのか把握したい • スタックトレースをパッと見たい • 通知先の分割 ◦ コンポーネント毎にSlackチャンネルを準備
25. アプリエラー通知、難しい • 「正常」「異常」の境界が曖昧 ◦ 例：404 Not Found は単発なら正常、特定 URL で頻発なら異常 • コンテキスト依存性が高い ◦ 同じ TimeoutError でも、情報取得 API なら軽い、決済 API なら重い • 新種が常に現れる ◦ リリースごとに新しい例外型 • あまり把握していない領域からのエラーは調査自体が難し い
26. どのメソッドを使うか • USEメソッド？ • REDメソッド？ • SLO? 対象/組織規模/組織成熟度で使い分けるのがよさそう フライルでも今後SLOや別手法の導入はありえる
27. 3. 通知を改善する
28. いい通知とは？
29. 動ける通知がいい通知 • 通知の周辺を育てる ◦ Runbook/ダッシュボード/オブザーバビリティ • 通知を受ける人がそれを活用できるか？ ◦ 啓蒙、足並みを揃える • 顧客が本当に必要だった物 • 監視・通知も一つのプロダクトとして捉えられそう
30. 監視・通知を育てる
31. 監視・通知を育てる
32. 監視・通知を育てる ここに目が行きがちだが…
33. 監視・通知を育てる ここが重要
34. 学習・改善の駆動エンジン2つ 育てる運用 • 起点：発火履歴 • トリガー：定期 • ノイズをキャッチ ポストモーテム改善ループ • 起点：個別インシデント • トリガー：インシデント 発生時 • 検知漏れをキャッチ
35. 監視・通知は育てるもの 監視は一度設定して終わりではなく、運用しながらより適切な状 態に近づけていく — Mackerel ブログ
36. 銀の弾丸も金の弾丸も ない
37. 時間をかける • 通知改善に特効薬はない • むしろ一気にやりすぎるのは逆効果ではないか ◦ 足並みを揃える • 時間をかけて変化を加え続けることが大事そう
38. まとめ • 通知の3タイプ ◦ Event-based/Metrics-based/Symptom-based • メソッド採用時の考慮 ◦ 対象/組織規模/成熟度 • 3つの指針 ◦ 動ける通知がいい通知/監視・通知を育てる/時間をかける
39. We are hiring! • フライルはSRE/SWE採用中！ • https://recruit.flyle.io/
40. スポンサーセッションもあるので見てください • https://event.cloudnativedays.jp/cnk/talks/3048 • まだ見ていなければ是非アーカイブ視聴を！
41. Thank you ! おいしいビールの店を探しています ご存じの方はask the speakerコーナーで教えてください セッションについても話しましょう
42. 参考文献 (1/2) • Rob Ewaschuk「My Philosophy on Alerting」(2013) ◦ https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zz An0YfcApr8Q/edit • Google『Site Reliability Engineering / The Site Reliability Workbook』(2016 / 2018) ◦ https://sre.google/ • Brendan Gregg「The USE Method」(2012) ◦ https://www.brendangregg.com/usemethod.html • Tom Wilkie「The RED Method」(Grafana, 2018) ◦ https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-yo ur-services/
43. 参考文献 (2/2) • Narayan Desai「Principled Performance Analytics」(SREcon22 Americas) ◦ https://www.usenix.org/conference/srecon22americas/presentation/desai • Google SRE Prodcast「Rethinking SLOs」(S1E4, 2022) ◦ https://sre.google/prodcast/transcripts/sre-prodcast-01-04/ • iwamot「SLOベースの監視は廃れるのか」(SRE Magazine 12号, 2026) ◦ https://sre-magazine.net/articles/12/iwamot/ • jacopen「間違いだらけのポストモーテム」（CloudNative Days Winter 2024） • https://speakerdeck.com/jacopen/jian-wei-itarakenohosutomotemu-hontoniyi-li-turehiyuhakouta • Mackerel ブログ ◦ https://mackerel.io/ja/blog/