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

by konchanSS

Slide 1

Slide 1 text

鳴り止まないアラート対応の中で学んだ監視改善の進め方 CARTA HOLDINGS fluct 開発本部部長こんちゃん(konchanSS) PHPカンファレンス新潟 2025 2025.05.31

Slide 2

Slide 2 text

株式会社fluct 部長こんちゃん @konchanSS 略歴 ● 石川県金沢市出身 ● 新卒でCARTA HOLDINGS入社でCARTA MARKETING FIRMに配属される ● 1年目 ~ 6年目まで広告主向けの広告配信システム全体を担当 ● 7年目となる去年9月にfluctに異動 ● パブリッシャー向け広告配信設定システム/ツールの開発する役割/領域 management engineering Front Server Data Cloud Infra

Slide 3

Slide 3 text

はじめに今日話す監視について ● エラーログ監視 ○ アプリケーションログ、APMなどのプロファイリングツールを使ってアプリケーションを監視する ● リソース監視 ○ CPUやメモリ、ディスクを監視する ● プロセス監視 ○ 起動数やサービスの状態を監視する ● ネットワーク監視 ○ ネットワークやサーバーそのものを監視する etc….

Slide 4

Slide 4 text

はじめに今日話す監視について ● エラーログ監視 ○ アプリケーションログ、APMなどのプロファイリングツールを使ってアプリケーションを監視する ● リソース監視 ○ CPUやメモリ、ディスクを監視する ● プロセス監視 ○ 起動数やサービスの状態を監視する ● ネットワーク監視 ○ ネットワークやサーバーそのものを監視する今日話す監視は主にこれ

Slide 5

Slide 5 text

6年所属した部署からの異動で全く別のチームに配属された先では鳴り続けるアラートの日々が待っていました

Slide 6

Slide 6 text

ところで、みなさんもこんなアラートに出会ったことはないですか？

Slide 7

Slide 7 text

はじめに私が配属された当時のアラート ● チームメンバーから無視されているアラート ● どういうアクションを取ればいいのかわからないアラート ○ そのアラートを対応できるのは一部の人だけ ● アラート設定によくわからない閾値が設定されている

Slide 8

Slide 8 text

最初はただアラートを調整していけばいいと思っていました

Slide 9

Slide 9 text

はじめに最終的に目指したアラートの形 ● アラートがネクストアクションのトリガーになって誰もが対応できる ○ Github Issueの活用 ● アラートにシステムの歴史を語らせる ○ アラートを見ればわかるアプリケーションとアラートの設計 ● ビジネスの振る舞いや成長を理解してアラートを設定する ○ ビジネスとのコミュニケーションパス

Slide 10

Slide 10 text

理想の形にいくためには一筋縄ではいきませんでした

Slide 11

Slide 11 text

はじめに見えている課題は氷山の一角意味のないアラート改善ができないパターン改善ができない構造改善ができないメンタルモデル ● 見えていた課題は表層 ○ 意味のないアラート ● 本質的な問題は ○ チームの監視への知識量 ○ ビジネスへの理解度アラートの問題は結果であり、問題の原因は「知識量」

Slide 12

Slide 12 text

見えていない問題と如何に立ち向かうか

Slide 13

Slide 13 text

問題を解決するために必要な考え方と進め方

Slide 14

Slide 14 text

AGENDA 02 アラートの課題と解決までのプロセス 01 チームの分断 03 ビジネスの分断 04 まとめ

Slide 15

Slide 15 text

改めて監視とは？

Slide 16

Slide 16 text

改めて監視とは？監視とは様々な問題を俯瞰し予防と対応を体系化したもの

Slide 17

Slide 17 text

改めて監視とは？監視とは様々な問題を俯瞰し予防と対応を体系化したものここでいう問題とは何の問題？

Slide 18

Slide 18 text

サービス停止とか、セキュリティ異常とか要はシステムの問題

Slide 19

Slide 19 text

サービス停止とか、セキュリティ異常とか要はシステムの問題問題を放置してしまうとどういう不利益があるか？

Slide 20

Slide 20 text

障害の深刻化、利用者への影響、機会損失

Slide 21

Slide 21 text

障害の深刻化、利用者への影響、機会損失これらは何に繋がるか？

Slide 22

Slide 22 text

ビジネスの損失

Slide 23

Slide 23 text

アラートの課題と解決までのプロセスビジネスと監視は切っても切り離せない私たちはビジネスの損失の予防と対応のために監視をしている監視がちゃんとできているかを判断する上で、私たちもビジネスについて多少知っておく必要がある私たちがやることはビジネス指標と技術指標の橋渡しをしてあげること

Slide 24

Slide 24 text

ただ、システムを長く運用していくとアラートにも課題が出てくる

Slide 25

Slide 25 text

アラートの課題と解決までのプロセスアラートの課題 ● システムの運用歴が長くなるにつれて、システムと周辺技術の変更と共にアラートの定義も変化する ● 変化にアラートが対応しないと意味のないアラートや本当にアラートだったものに反応できなくなることが増えていく ● アラートではないものが通知され続けることでチームがアラート疲れを起こしてしまうという二次的な被害が起こる ※ アラート疲れとは絶え間のないアラートや通知を大量に受け取ると、その膨大な量に圧倒されて結果としてアラートの見逃し、無視や対応の遅れを生んでしまうこと

Slide 26

Slide 26 text

実際に私がジョインした当時の状況

Slide 27

Slide 27 text

アラートの課題と解決までのプロセス無視されているアラート ● 飛んでいるけど1日以上無視されている

Slide 28

Slide 28 text

アラートの課題と解決までのプロセス同じ人が一生対応しているアラートアラート(1回目) 僕対応します Aさんアラート(N回目) 僕対応します Aさん基本同じ人が見てる ● アラート対応できる人が一部のみ他のメンバーにはどう対応するのかわからない人もいたかつ、情報も残してないのでわからない

Slide 29

Slide 29 text

アラートの課題と解決までのプロセス閾値の理由がよくわからないアラート ● 5回以上はアラートにするとなっているが、4回以下までは良いという根拠は一体どこにある？実は根拠はなく最初作った人の感覚だった 3回まではWarning 5回目以降はAlert

Slide 30

Slide 30 text

アラートの課題と解決までのプロセス調査するのが時間がかかるアラート ● アラート自体に情報はなくて詳細のログを見ないと問題ないかを判断できない ● 調査にそれなりに時間持ってかれることもあるアラートの中身が空すいません具が入ってません

Slide 31

Slide 31 text

アラート改善していくなら設定を直せばゴール

Slide 32

Slide 32 text

アラートの課題と解決までのプロセスアラートをただ直すだけでは、意味がないなぜ変化に追従できなかったか？より深くにある構造とメンタルモデルを知らないまま改善してもいずれまた同じ状況になる意味のないアラート改善ができないパターン改善ができない構造改善ができないメンタルモデル構造＝ルールや仕組みメンタルモデル＝意識・無意識の前提

Slide 33

Slide 33 text

アラートの課題と解決までのプロセス本来あるべきアラート対応のチームの形アラート(1回目) 対応しますチームメンバー誰でもアラート(N回目) 僕対応します新卒 ● 誰もがアラートに対応できる ● 新卒採用文化なので、すぐ新卒に対応してもらう具体的に実施した改善策は後述しますチームメンバー

Slide 34

Slide 34 text

AGENDA 02 アラートの課題と解決までのプロセス 01 チームの分断 03 ビジネスの分断 04 まとめ

Slide 35

Slide 35 text

チームの分断アラート改善ができない問題にはチームの問題が潜んでいる ● アラート設定をしているのはチーム ● 改善していくのもチーム ● それができていないということは、チームがアラート改善ができる状況ではないチームを否定するのではなくチームの状況を聞いて対話をしていきましょう意味のないアラート改善ができないパターン改善ができない構造改善ができないメンタルモデル

Slide 36

Slide 36 text

チームの分断具体例(私が入ったタイミングでのチームの状況) 10年以上の運用歴のある管理画面チーム芸歴4年ほどの若手メンバーだけで構成されているチーム監視するシステム

Slide 37

Slide 37 text

チームの分断具体例(私が入ったタイミングでのチームの状況) 10年以上の運用歴のある管理画面監視するシステムチーム芸歴4年ほどの若手メンバーだけで構成されているチーム監視についての基礎的な知識があるのみ今ある監視の意図は分かっていない

Slide 38

Slide 38 text

チームの分断具体例(私が入ったタイミングでのチームの状況) 10年以上の運用歴のある管理画面監視するシステムチーム芸歴4年ほどの若手メンバーだけで構成されているチーム監視についての基礎的な知識があるのみ今ある監視の意図は分かっていない最初にシステム設計、監視をした人はチームにもういない

Slide 39

Slide 39 text

チームの監視に対する知識量が足りてないシステムの理解が追いついていない

Slide 40

Slide 40 text

チームの分断このような状況でチームに起きていること ● アラートの認識がチームの中で揃っていない ● 情報の断裂が起きている ● アラートやアプリケーションのログに調査、対応に必要な情報が残されていない ● 監視を設定する人がシステムの動作を理解できていない

Slide 41

Slide 41 text

チームの分断このような状況でチームに起きていること ● アラートの認識がチームの中で揃っていない ● 情報の断裂が起きている ● アラートやアプリケーションのログに調査、対応に必要な情報が残されていない ● 監視を設定する人がシステムの動作を理解できていないアラートが来てからチームの次の対応がバラバラになっている

Slide 42

Slide 42 text

チームの分断このような状況でチームに起きていること ● アラートの認識がチームの中で揃っていない ● 情報の断裂が起きている ● アラートやアプリケーションのログに調査、対応に必要な情報が残されていない ● 監視を設定する人がシステムの動作を理解できていない前任者はアラートが来てから次の対応を手順書に残さなかった知っている情報がメンバー同士で差がある

Slide 43

Slide 43 text

チームの分断このような状況でチームに起きていること ● アラートの認識がチームの中で揃っていない ● 情報の断裂が起きている ● アラートやアプリケーションのログに調査、対応に必要な情報が残されていない ● 監視を設定する人がシステムの動作を理解できていないアラートが来てから何を調査する必要があるのかわからない

Slide 44

Slide 44 text

チームの分断このような状況でチームに起きていること ● アラートの認識がチームの中で揃っていない ● 情報の断裂が起きている ● アラートやアプリケーションのログに調査、対応に必要な情報が残されていない ● 監視を設定する人がシステムの動作を理解できていないわからないのでとりあえずCPUやメモリなど表層的な指標をアラートしてしまう

Slide 45

Slide 45 text

解決するためにやったこと

Slide 46

Slide 46 text

チームの分断これらを解決するには ● アラートの認識がチームの中で揃っていない ● 情報の断裂が起きている ● アラートやアプリケーションのログに調査、対応に必要な情報が残されていない ● 監視を設定する人がシステムの動作を理解できていない

Slide 47

Slide 47 text

チームの分断これらを解決するには ● アラートの認識がチームの中で揃っていない ● 情報の断裂が起きている ● アラートやアプリケーションのログに調査、対応に必要な情報が残されていない ● 監視を設定する人がシステムの動作を理解できていない監視をチームのスキルとしていく

Slide 48

Slide 48 text

チームの分断これらを解決するには ● アラートの認識がチームの中で揃っていない ● 情報の断裂が起きている ● アラートやアプリケーションのログに調査、対応に必要な情報が残されていない ● 監視を設定する人がシステムの動作を理解できていない情報を残す、繋ぐ手段を確立する

Slide 49

Slide 49 text

チームの分断これらを解決するには ● アラートの認識がチームの中で揃っていない ● 情報の断裂が起きている ● アラートやアプリケーションのログに調査、対応に必要な情報が残されていない ● 監視を設定する人がシステムの動作を理解できていないドメインを理解できる手段を確立し監視と結び付ける

Slide 50

Slide 50 text

チームの分断監視をチームのスキルとしていく ● アラートの定義をチームの中で決める ○ アラートがきたときにチームが取りたいアクションを決めること ○ そうすることでチームの中で同じ認識でアラートを見ることができる ● チームの中で議論して決めるには同じ情報量で話ができる必要がある ○ (具体例) チーム全員で『入門監視』を読んでくる ● 定義が決まったら習慣的にアラートを見直してみる ○ 持ち回りでファシリテーターを決めて監視設定を見直してみる

Slide 51

Slide 51 text

チームの分断情報を残す、繋ぐ手段を確立する ● アラートが来たときに必ず手順書やログを残すというチームの手続きを決める ○ (具体例) Github Issueに調査から対応までの流れを記録として残す ○ 見返すことで誰でも後からできるようになる ● アラートのメッセージに過去の対応した記録を貼っておく ○ (具体例) Github Issueのリンクを貼っておく ○ いちいち記録を探しに行かなくてよくなった

Slide 52

Slide 52 text

チームの分断私たちのチームでやるようになった結果 ● アラートの通知数が極端に減った ● チームメンバーがどのアラートでも対応ができる状態になった ● アラートについてのチーム内の議論が活発になった ● 自主的にアラートの見直しができるようになった

Slide 53

Slide 53 text

チームの分断私たちのチームでやるようになった結果 ● アラートの通知数が極端に減った ● チームメンバーがどのアラートでも対応ができる状態になった ● アラートについてのチーム内の議論が活発になった ● 自主的にアラートの見直しができるようになった多い日は1日8件ぐらい来てたアラートが週に1回来るかどうかの状態になった ※ 後述する施策の影響もある

Slide 54

Slide 54 text

アラート通知量の減少毎日7~8件 x 5日 || 35 ~ 40件週1件アラート定義に基づいて週1回の見直しを繰り返していった

Slide 55

Slide 55 text

チームの分断私たちのチームでやるようになった結果 ● アラートの通知数が極端に減った ● チームメンバーがどのアラートでも対応ができる状態になった ● アラートについてのチーム内の議論が活発になった ● 自主的にアラートの見直しができるようになった特定の人しか見れないというアラートはなくなった

Slide 56

Slide 56 text

チームの分断私たちのチームでやるようになった結果 ● アラートの通知数が極端に減った ● チームメンバーがどのアラートでも対応ができる状態になった ● アラートについてのチーム内の議論が活発になった ● 自主的にアラートの見直しができるようになった調査をしやすくするにはこういう情報がログに欲しいアラートに関する議論をするようになった

Slide 57

Slide 57 text

チームの分断私たちのチームでやるようになった結果 ● アラートの通知数が極端に減った ● チームメンバーがどのアラートでも対応ができる状態になった ● アラートについてのチーム内の議論が活発になった ● 自主的にアラートの見直しができるようになった私はもう定期アラート見直し会に参加してないが自主的にチームの中でまわっている

Slide 58

Slide 58 text

これでチームでアラートを改善できる！

Slide 59

Slide 59 text

AGENDA 02 アラートの課題と解決までのプロセス 01 チームの分断 03 ビジネスの分断 04 まとめ

Slide 60

Slide 60 text

ビジネスの分断ここまでのまとめ ● ここまでアラート改善ができない構造にはチームの問題が潜んでいてそれを解決していく話をした ● では、改善ができないメンタルモデルには何が潜んでいるのか意味のないアラート改善ができないパターン改善ができない構造改善ができないメンタルモデル

Slide 61

Slide 61 text

ビジネスの分断メンタルモデルとは、私たちが監視をする理由の中にある私たちが監視をするのはなぜだろう？

Slide 62

Slide 62 text

ビジネスの分断メンタルモデルとは、私たちが監視をする理由の中にある私たちが監視をするのはなぜだろう？業務上決められているのもあるが、問題に気づけないと失われてしまうビジネス上の損失があるから 1

Slide 63

Slide 63 text

ビジネスの分断メンタルモデルとは、私たちが監視をする理由の中にある私たちが監視をするのはなぜだろう？業務上決められているのもあるが、問題に気づけないと失われてしまうビジネス上の損失があるから 1 2 では、私たちはビジネスのことをどれぐらい知っている？ビジネスの損失に気づけるように監視が設定されている？

Slide 64

Slide 64 text

ビジネスの分断メンタルモデルとは、私たちが監視をする理由の中にある私たちが監視をするのはなぜだろう？業務上決められているのもあるが、問題に気づけないと失われてしまうビジネス上の損失があるからメンタルモデル 1 2 では、私たちはビジネスのことをどれぐらい知っている？ビジネスの損失に気づけるように監視が設定されている？

Slide 65

Slide 65 text

ビジネスの分断メンタルモデルの具体例 ● 餅は餅屋なので、ビジネスのことはビジネス職に任せよう ● 私たちがアラート対応するのだから、私たちの基準でアラートを決めよう

Slide 66

Slide 66 text

ビジネス理解の分断が起きている

Slide 67

Slide 67 text

ビジネスの分断ビジネスと監視は切っても切り離せない私たちはビジネスの損失の予防と対応のために監視をしている監視がちゃんとできているかを判断する上で、私たちもビジネスについて多少知っておく必要がある私たちがやることはビジネス指標と技術指標の橋渡しをしてあげること

Slide 68

Slide 68 text

ビジネスの分断どうビジネスについて知るか？ビジネスについて詳細に理解することは難しいし、理解できている必要も極論ないまずは自分自身が詳しくならなくてもプロダクトマネージャーやプロジェクトマネージャーに聞きにいけばいい話の中でビジネス指標を見つけていく

Slide 69

Slide 69 text

ビジネスを理解したからこそ、出来た改善例

Slide 70

Slide 70 text

ビジネスの分断実際にビジネス指標を見つけたら ● 実際に話をして見つけたらそれを技術指標と絡めて見てみる ○ 右の図が私が運用してたシステムと絡めて見た様子ビジネスを通してシステムと監視の勘所を理解できるようになるビジネス指標技術指標影響案件の登録案件、在庫データの登録失敗登録数のメトリクス案件に登録されたデータの売上のN%が我々の売上になっているのでクリティカルになる急激に減ったら何かビジネスに影響のある技術的課題があるかもしれない

Slide 71

Slide 71 text

ビジネスの分断実際に私たちのチームでは ● アプリケーション側が改善される機会が増えた ● アラートが来たときの判断はより明確になった ● アラート通知数が減った

Slide 72

Slide 72 text

ビジネスの分断実際に私たちのチームでは ● アプリケーション側が改善される機会が増えた ● アラートが来たときの判断はより明確になった ● アラート通知数が減ったログレベルの調整気づきやすいアプリケーション設計を意識するようになったアラート通知する実装部分が改善された

Slide 73

Slide 73 text

ビジネスの分断実際に私たちのチームでは ● アプリケーション側が改善される機会が増えた ● アラートが来たときの判断はより明確になった ● アラート通知数が減ったビジネス上の損失が起きるかどうかを軸にネクストアクションを決めやすくなった

Slide 74

Slide 74 text

ビジネスの分断実際に私たちのチームでは ● アプリケーション側が改善される機会が増えた ● アラートが来たときの判断はより明確になった ● アラート通知数が減った 7~8件/日から0~1件/週に意味のないアラートだという判断がしやすくなった

Slide 75

Slide 75 text

ビジネスの分断ビジネスに与えた変化 ● 売上を上げるための機能開発に集中できるようになった ● ビジネスに影響のある障害が起きづらくなった ● ビジネスの損失つながるバグは1時間以内に気づいて復旧までするようになった

Slide 76

Slide 76 text

ビジネスの分断ビジネスに与えた変化 ● 売上を上げるための機能開発に集中できるようになった ● ビジネスに影響のある障害が起きづらくなった ● ビジネスの損失つながるバグは1時間以内に気づいて復旧までするようになったアラートの調査でチームで毎日3時間ぐらい使っていたのが週1時間ぐらいになったその時間を機能開発あてれるようになった

Slide 77

Slide 77 text

アラート対応の時間の削減毎日3時間 x 5日 || 15時間週1時間チームの人数の掛け算も考えるともっと全体的にはコスト削減になっている

Slide 78

Slide 78 text

ビジネスの分断ビジネスに与えた変化 ● 売上を上げるための機能開発に集中できるようになった ● ビジネスに影響のある障害が起きづらくなった ● ビジネスの損失つながるバグは1時間以内に気づいて復旧までするようになった以前は半日ぐらい気づかないこともあった 2回ほどビジネスの損失につながる事態が発生したがどちらも1時間以内に復旧することができたこれによって新卒も安心してリリースできようになったより安心してリリースできるためのテストも増やすようになった

Slide 79

Slide 79 text

障害検知から復旧までのトータル時間の削減 1時間 4時間程度復旧作業復旧作業トータルの時間で考えても改善前の障害検知よりも短くなった

Slide 80

Slide 80 text

AGENDA 02 アラートの課題と解決までのプロセス 01 チームの分断 03 ビジネスの分断 04 まとめ

Slide 81

Slide 81 text

まとめ最後に ● アラートの問題というの結果であり、原因には『チームの知識の分断とビジネス理解の不足』がある ● 表層の課題を解決しようとするのではなく、原因の解決を目指すこと ● 最初から技術で解決しなくていい、必要な人と必要な対話をすることからはじめよう

Slide 82

Slide 82 text

ご清聴ありがとうございました中途エンジニア採用中!!