鳴り止まないアラート対応の中で学んだ 監視改善の進め方 / team-based-monitoring-improvement-from-alert

PHP Conference niigata 2025 プロポーザル通過 @konchanSS

本人資料から転載: https://speakerdeck.com/konchanss/team-based-monitoring-improvement-from-alert

Transcript

1. 鳴り止まないアラート対応の中で学んだ 監視改善の進め方 CARTA HOLDINGS fluct 開発本部 部長 こんちゃん(konchanSS) PHPカンファレンス新潟 2025 2025.05.31
2. 株式会社fluct 部長 こんちゃん @konchanSS 略歴 • 石川県金沢市出身 • 新卒でCARTA HOLDINGS入社でCARTA MARKETING FIRMに配 属される • 1年目 ~ 6年目まで広告主向けの広告配信システム全体を担当 • 7年目となる去年9月にfluctに異動 • パブリッシャー向け広告配信設定システム/ツールの開発する 役割/領域 management engineering Front Server Data Cloud Infra
3. はじめに 今日話す監視について • エラーログ監視 ◦ アプリケーションログ、APMなどのプロファイリングツールを 使ってアプリケーションを監視する • リソース監視 ◦ CPUやメモリ、ディスクを監視する • プロセス監視 ◦ 起動数やサービスの状態を監視する • ネットワーク監視 ◦ ネットワークやサーバーそのものを監視する etc….
4. はじめに 今日話す監視について • エラーログ監視 ◦ アプリケーションログ、APMなどのプロファイリングツールを 使ってアプリケーションを監視する • リソース監視 ◦ CPUやメモリ、ディスクを監視する • プロセス監視 ◦ 起動数やサービスの状態を監視する • ネットワーク監視 ◦ ネットワークやサーバーそのものを監視する 今日話す監視は主にこれ
5. 6年所属した部署からの異動で全く別のチームに配属された 先では鳴り続けるアラートの日々が待っていました
6. ところで、みなさんもこんなアラートに 出会ったことはないですか？
7. はじめに 私が配属された当時のアラート • チームメンバーから無視されているアラート • どういうアクションを取ればいいのかわからないアラート ◦ そのアラートを対応できるのは一部の人だけ • アラート設定によくわからない閾値が設定されている
8. 最初はただアラートを 調整していけばいいと思っていました
9. はじめに 最終的に目指したアラートの形 • アラートがネクストアクションのトリガーになって誰もが対応できる ◦ Github Issueの活用 • アラートにシステムの歴史を語らせる ◦ アラートを見ればわかるアプリケーションとアラートの設計 • ビジネスの振る舞いや成長を理解してアラートを設定する ◦ ビジネスとのコミュニケーションパス
10. 理想の形にいくためには 一筋縄ではいきませんでした
11. はじめに 見えている課題は氷山の一角 意味のないアラート 改善ができないパターン 改善ができない構造 改善ができないメンタルモデル • 見えていた課題は表層 ◦ 意味のないアラート • 本質的な問題は ◦ チームの監視への知識量 ◦ ビジネスへの理解度 アラートの問題は結果であり、 問題の原因は「知識量」
12. 見えていない問題と如何に立ち向かうか
13. 問題を解決するために 必要な考え方と進め方
14. AGENDA 02 アラートの課題と解決までのプロセス 01 チームの分断 03 ビジネスの分断 04 まとめ
15. 改めて監視とは？
16. 改めて監視とは？ 監視とは様々な問題を俯瞰し 予防と対応を体系化したもの
17. 改めて監視とは？ 監視とは様々な問題を俯瞰し 予防と対応を体系化したもの ここでいう問題とは何の問題？
18. サービス停止とか、セキュリティ異常とか 要はシステムの問題
19. サービス停止とか、セキュリティ異常とか 要はシステムの問題 問題を放置してしまうと どういう不利益があるか？
20. 障害の深刻化、利用者への影響、機会損失
21. 障害の深刻化、利用者への影響、機会損失 これらは何に繋がるか？
22. ビジネスの損失
23. アラートの課題と解決までのプロセス ビジネスと監視は切っても切り離せない 私たちはビジネスの損失の予防と対応のために監視をしている 監視がちゃんとできているかを判断する上で、私たちもビジネ スについて多少知っておく必要がある 私たちがやることはビジネス指標と技術指標の橋渡し をしてあげること
24. ただ、システムを長く運用していくと アラートにも課題が出てくる
25. アラートの課題と解決までのプロセス アラートの課題 • システムの運用歴が長くなるにつれて、 システムと周辺技術の変更と共にアラートの定義も変化する • 変化にアラートが対応しないと意味のないアラートや本当に アラートだったものに反応できなくなることが増えていく • アラートではないものが通知され続けることでチームが アラート疲れを起こしてしまうという二次的な被害が起こる ※ アラート疲れとは絶え間のないアラートや通知を大量に受け取ると、その膨大な量に 圧倒されて結果としてアラートの見逃し、無視や対応の遅れを生んでしまうこと
26. 実際に私がジョインした当時の状況
27. アラートの課題と解決までのプロセス 無視されているアラート • 飛んでいるけど1日以上無視され ている
28. アラートの課題と解決までのプロセス 同じ人が一生対応しているアラート アラート(1回目) 僕対応します Aさん アラート(N回目) 僕対応します Aさん 基本同じ人が見てる • アラート対応できる人が一部 のみ 他のメンバーにはどう対応するの かわからない人もいた かつ、情報も残してないのでわか らない
29. アラートの課題と解決までのプロセス 閾値の理由がよくわからないアラート • 5回以上はアラートにすると なっているが、4回以下までは 良いという根拠は一体どこに ある？ 実は根拠はなく 最初作った人の感覚だった 3回まではWarning 5回目以降はAlert
30. アラートの課題と解決までのプロセス 調査するのが時間がかかるアラート • アラート自体に情報はなくて 詳細のログを見ないと問題な いかを判断できない • 調査にそれなりに時間持って かれることもある アラートの中身が空 すいません具が入ってません
31. アラート改善していくなら 設定を直せばゴール
32. アラートの課題と解決までのプロセス アラートをただ直すだけでは、意味がない なぜ変化に追従できなかったか？ より深くにある構造とメンタルモデル を知らないまま改善してもいずれまた 同じ状況になる 意味のないアラート 改善ができないパターン 改善ができない構造 改善ができないメンタルモデル 構造＝ルールや仕組み メンタルモデル＝意識・無意識の前提
33. アラートの課題と解決までのプロセス 本来あるべきアラート対応のチームの形 アラート(1回目) 対応します チームメンバー誰でも アラート(N回目) 僕対応します 新卒 • 誰もがアラートに対応できる • 新卒採用文化なので、すぐ新 卒に対応してもらう 具体的に実施した改善策は後述します チームメンバー
34. AGENDA 02 アラートの課題と解決までのプロセス 01 チームの分断 03 ビジネスの分断 04 まとめ
35. チームの分断 アラート改善ができない問題にはチームの問題が潜んでいる • アラート設定をしているのはチーム • 改善していくのもチーム • それができていないということは、 チームがアラート改善ができる状況 ではない チームを否定するのではなく チームの状況を聞いて対話をして いきましょう 意味のないアラート 改善ができないパターン 改善ができない構造 改善ができないメンタルモデル
36. チームの分断 具体例(私が入ったタイミングでのチームの状況) 10年以上の運用歴のある管理画面 チーム 芸歴4年ほどの若手メンバーだけで 構成されているチーム 監視するシステム
37. チームの分断 具体例(私が入ったタイミングでのチームの状況) 10年以上の運用歴のある管理画面 監視するシステム チーム 芸歴4年ほどの若手メンバーだけで 構成されているチーム 監視についての基礎的な知識があるのみ 今ある監視の意図は分かっていない
38. チームの分断 具体例(私が入ったタイミングでのチームの状況) 10年以上の運用歴のある管理画面 監視するシステム チーム 芸歴4年ほどの若手メンバーだけで 構成されているチーム 監視についての基礎的な知識があるのみ 今ある監視の意図は分かっていない 最初にシステム設計、監視をした人は チームにもういない
39. チームの監視に対する知識量が足りてない システムの理解が追いついていない
40. チームの分断 このような状況でチームに起きていること • アラートの認識がチームの中で揃っていない • 情報の断裂が起きている • アラートやアプリケーションのログに調査、対応に必要な情報が 残されていない • 監視を設定する人がシステムの動作を理解できていない
41. チームの分断 このような状況でチームに起きていること • アラートの認識がチームの中で揃っていない • 情報の断裂が起きている • アラートやアプリケーションのログに調査、対応に必要な情報が 残されていない • 監視を設定する人がシステムの動作を理解できていない アラートが来てからチームの次の対応が バラバラになっている
42. チームの分断 このような状況でチームに起きていること • アラートの認識がチームの中で揃っていない • 情報の断裂が起きている • アラートやアプリケーションのログに調査、対応に必要な情報が 残されていない • 監視を設定する人がシステムの動作を理解できていない 前任者はアラートが来てから次の対応を 手順書に残さなかった 知っている情報がメンバー同士で差がある
43. チームの分断 このような状況でチームに起きていること • アラートの認識がチームの中で揃っていない • 情報の断裂が起きている • アラートやアプリケーションのログに調査、対応に必要な情報が 残されていない • 監視を設定する人がシステムの動作を理解できていない アラートが来てから何を調査する必要があるのか わからない
44. チームの分断 このような状況でチームに起きていること • アラートの認識がチームの中で揃っていない • 情報の断裂が起きている • アラートやアプリケーションのログに調査、対応に必要な情報が 残されていない • 監視を設定する人がシステムの動作を理解できていない わからないのでとりあえずCPUやメモリなど 表層的な指標をアラートしてしまう
45. 解決するためにやったこと
46. チームの分断 これらを解決するには • アラートの認識がチームの中で揃っていない • 情報の断裂が起きている • アラートやアプリケーションのログに調査、対応に必要な情報が残 されていない • 監視を設定する人がシステムの動作を理解できていない
47. チームの分断 これらを解決するには • アラートの認識がチームの中で揃っていない • 情報の断裂が起きている • アラートやアプリケーションのログに調査、対応に必要な情報が残 されていない • 監視を設定する人がシステムの動作を理解できていない 監視をチームのスキルとしていく
48. チームの分断 これらを解決するには • アラートの認識がチームの中で揃っていない • 情報の断裂が起きている • アラートやアプリケーションのログに調査、対応に必要な情報が残 されていない • 監視を設定する人がシステムの動作を理解できていない 情報を残す、繋ぐ手段を確立する
49. チームの分断 これらを解決するには • アラートの認識がチームの中で揃っていない • 情報の断裂が起きている • アラートやアプリケーションのログに調査、対応に必要な情報が残 されていない • 監視を設定する人がシステムの動作を理解できていない ドメインを理解できる手段を確立し 監視と結び付ける
50. チームの分断 監視をチームのスキルとしていく • アラートの定義をチームの中で決める ◦ アラートがきたときにチームが取りたいアクション を決めること ◦ そうすることでチームの中で同じ認識でアラート を見ることができる • チームの中で議論して決めるには同じ情報量で話が できる必要がある ◦ (具体例) チーム全員で『入門監視』を読んでくる • 定義が決まったら習慣的にアラートを見直してみる ◦ 持ち回りでファシリテーターを決めて監視設定を 見直してみる
51. チームの分断 情報を残す、繋ぐ手段を確立する • アラートが来たときに必ず手順書やログ を残すというチームの手続きを決める ◦ (具体例) Github Issueに調査から対応までの 流れを記録として残す ◦ 見返すことで誰でも後からできるようにな る • アラートのメッセージに過去の対応した 記録を貼っておく ◦ (具体例) Github Issueのリンクを貼っておく ◦ いちいち記録を探しに行かなくてよくなっ た
52. チームの分断 私たちのチームでやるようになった結果 • アラートの通知数が極端に減った • チームメンバーがどのアラートでも対応ができる状態になった • アラートについてのチーム内の議論が活発になった • 自主的にアラートの見直しができるようになった
53. チームの分断 私たちのチームでやるようになった結果 • アラートの通知数が極端に減った • チームメンバーがどのアラートでも対応ができる状態になった • アラートについてのチーム内の議論が活発になった • 自主的にアラートの見直しができるようになった 多い日は1日8件ぐらい来てたアラートが週に1回 来るかどうかの状態になった ※ 後述する施策の影響もある
54. アラート通知量の減少 毎日7~8件 x 5日 || 35 ~ 40件 週1件 アラート定義に基づいて 週1回の見直しを繰り返していった
55. チームの分断 私たちのチームでやるようになった結果 • アラートの通知数が極端に減った • チームメンバーがどのアラートでも対応ができる状態になった • アラートについてのチーム内の議論が活発になった • 自主的にアラートの見直しができるようになった 特定の人しか見れないというアラートはなくなった
56. チームの分断 私たちのチームでやるようになった結果 • アラートの通知数が極端に減った • チームメンバーがどのアラートでも対応ができる状態になった • アラートについてのチーム内の議論が活発になった • 自主的にアラートの見直しができるようになった 調査をしやすくするにはこういう情報がログに欲しい アラートに関する議論をするようになった
57. チームの分断 私たちのチームでやるようになった結果 • アラートの通知数が極端に減った • チームメンバーがどのアラートでも対応ができる状態になった • アラートについてのチーム内の議論が活発になった • 自主的にアラートの見直しができるようになった 私はもう定期アラート見直し会に参加してないが 自主的にチームの中でまわっている
58. これでチームでアラートを改善できる！
59. AGENDA 02 アラートの課題と解決までのプロセス 01 チームの分断 03 ビジネスの分断 04 まとめ
60. ビジネスの分断 ここまでのまとめ • ここまでアラート改善ができない構 造にはチームの問題が潜んでいてそ れを解決していく話をした • では、改善ができないメンタルモ デルには何が潜んでいるのか 意味のないアラート 改善ができないパターン 改善ができない構造 改善ができないメンタルモデル
61. ビジネスの分断 メンタルモデルとは、私たちが監視をする理由の中にある 私たちが監視をするのはなぜだろう？
62. ビジネスの分断 メンタルモデルとは、私たちが監視をする理由の中にある 私たちが監視をするのはなぜだろう？ 業務上決められているのもあるが、問題に気づけないと 失われてしまうビジネス上の損失があるから 1
63. ビジネスの分断 メンタルモデルとは、私たちが監視をする理由の中にある 私たちが監視をするのはなぜだろう？ 業務上決められているのもあるが、問題に気づけないと 失われてしまうビジネス上の損失があるから 1 2 では、私たちはビジネスのことをどれぐらい知っている？ ビジネスの損失に気づけるように監視が設定されている？
64. ビジネスの分断 メンタルモデルとは、私たちが監視をする理由の中にある 私たちが監視をするのはなぜだろう？ 業務上決められているのもあるが、問題に気づけないと 失われてしまうビジネス上の損失があるから メンタルモデル 1 2 では、私たちはビジネスのことをどれぐらい知っている？ ビジネスの損失に気づけるように監視が設定されている？
65. ビジネスの分断 メンタルモデルの具体例 • 餅は餅屋なので、ビジネスのことはビジネス職に任せよう • 私たちがアラート対応するのだから、私たちの基準で アラートを決めよう
66. ビジネス理解の分断が起きている
67. ビジネスの分断 ビジネスと監視は切っても切り離せない 私たちはビジネスの損失の予防と対応のために監視をしている 監視がちゃんとできているかを判断する上で、私たちもビジネ スについて多少知っておく必要がある 私たちがやることはビジネス指標と技術指標の橋渡し をしてあげること
68. ビジネスの分断 どうビジネスについて知るか？ ビジネスについて詳細に理解することは難しいし、理解でき ている必要も極論ない まずは自分自身が詳しくならなくても プロダクトマネージャーやプロジェクトマネージャーに 聞きにいけばいい 話の中でビジネス指標を見つけていく
69. ビジネスを理解したからこそ、出来た改善例
70. ビジネスの分断 実際にビジネス指標を見つけたら • 実際に話をして見つけたらそれ を技術指標と絡めて見てみる ◦ 右の図が私が運用してたシステ ムと絡めて見た様子 ビジネスを通してシステムと 監視の勘所を理解できるように なる ビジネス指 標 技術指標 影響 案件の登録 案件、在庫 データの登 録失敗 登録数のメ トリクス 案件に登録されたデー タの売上のN%が我々 の売上になっているの でクリティカルになる 急激に減ったら何かビ ジネスに影響のある技 術的課題があるかもし れない
71. ビジネスの分断 実際に私たちのチームでは • アプリケーション側が改善される機会が増えた • アラートが来たときの判断はより明確になった • アラート通知数が減った
72. ビジネスの分断 実際に私たちのチームでは • アプリケーション側が改善される機会が増えた • アラートが来たときの判断はより明確になった • アラート通知数が減った ログレベルの調整 気づきやすいアプリケーション設計を意識するようになった アラート通知する実装部分が改善された
73. ビジネスの分断 実際に私たちのチームでは • アプリケーション側が改善される機会が増えた • アラートが来たときの判断はより明確になった • アラート通知数が減った ビジネス上の損失が起きるかどうかを軸に ネクストアクションを決めやすくなった
74. ビジネスの分断 実際に私たちのチームでは • アプリケーション側が改善される機会が増えた • アラートが来たときの判断はより明確になった • アラート通知数が減った 7~8件/日から0~1件/週に 意味のないアラートだという判断がしやすくなった
75. ビジネスの分断 ビジネスに与えた変化 • 売上を上げるための機能開発に集中できるようになった • ビジネスに影響のある障害が起きづらくなった • ビジネスの損失つながるバグは1時間以内に気づいて復旧までするよ うになった
76. ビジネスの分断 ビジネスに与えた変化 • 売上を上げるための機能開発に集中できるようになった • ビジネスに影響のある障害が起きづらくなった • ビジネスの損失つながるバグは1時間以内に気づいて復旧までするよ うになった アラートの調査でチームで毎日3時間ぐらい 使っていたのが週1時間ぐらいになった その時間を機能開発あてれるようになった
77. アラート対応の時間の削減 毎日3時間 x 5日 || 15時間 週1時間 チームの人数の掛け算も考えるともっと 全体的にはコスト削減になっている
78. ビジネスの分断 ビジネスに与えた変化 • 売上を上げるための機能開発に集中できるようになった • ビジネスに影響のある障害が起きづらくなった • ビジネスの損失つながるバグは1時間以内に気づいて復旧までするよ うになった 以前は半日ぐらい気づかないこともあった 2回ほどビジネスの損失につながる事態が発生したが どちらも1時間以内に復旧することができた これによって新卒も安心してリリースできようになった より安心してリリースできるためのテストも増やすようになった
79. 障害検知から復旧までのトータル時間の削減 1時間 4時間程度 復旧作業 復旧作業 トータルの時間で考えても 改善前の障害検知よりも短くなった
80. AGENDA 02 アラートの課題と解決までのプロセス 01 チームの分断 03 ビジネスの分断 04 まとめ
81. まとめ 最後に • アラートの問題というの結果であり、原因には『チームの 知識の分断とビジネス理解の不足』がある • 表層の課題を解決しようとするのではなく、原因の解決を 目指すこと • 最初から技術で解決しなくていい、必要な人と必要な対話 をすることからはじめよう
82. ご清聴ありがとうございました 中途エンジニア 採用中!!