Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Avatar for konchanSS konchanSS
May 29, 2025
3.3k

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

Avatar for konchanSS

konchanSS

May 29, 2025
Tweet

Transcript

  1. 株式会社fluct 部長 こんちゃん @konchanSS 略歴 • 石川県金沢市出身 • 新卒でCARTA HOLDINGS入社でCARTA

    MARKETING FIRMに配 属される • 1年目 ~ 6年目まで広告主向けの広告配信システム全体を担当 • 7年目となる去年9月にfluctに異動 • パブリッシャー向け広告配信設定システム/ツールの開発する 役割/領域 management engineering Front Server Data Cloud Infra
  2. はじめに 今日話す監視について • エラーログ監視 ◦ アプリケーションログ、APMなどのプロファイリングツールを 使ってアプリケーションを監視する • リソース監視 ◦

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

    CPUやメモリ、ディスクを監視する • プロセス監視 ◦ 起動数やサービスの状態を監視する • ネットワーク監視 ◦ ネットワークやサーバーそのものを監視する 今日話す監視は主にこれ
  4. はじめに 最終的に目指したアラートの形 • アラートがネクストアクションのトリガーになって誰もが対応できる ◦ Github Issueの活用 • アラートにシステムの歴史を語らせる ◦

    アラートを見ればわかるアプリケーションとアラートの設計 • ビジネスの振る舞いや成長を理解してアラートを設定する ◦ ビジネスとのコミュニケーションパス
  5. はじめに 見えている課題は氷山の一角 意味のないアラート 改善ができないパターン 改善ができない構造 改善ができないメンタルモデル • 見えていた課題は表層 ◦ 意味のないアラート

    • 本質的な問題は ◦ チームの監視への知識量 ◦ ビジネスへの理解度 アラートの問題は結果であり、 問題の原因は「知識量」
  6. アラートの課題と解決までのプロセス アラートの課題 • システムの運用歴が長くなるにつれて、 システムと周辺技術の変更と共にアラートの定義も変化する • 変化にアラートが対応しないと意味のないアラートや本当に アラートだったものに反応できなくなることが増えていく • アラートではないものが通知され続けることでチームが

    アラート疲れを起こしてしまうという二次的な被害が起こる ※ アラート疲れとは絶え間のないアラートや通知を大量に受け取ると、その膨大な量に 圧倒されて結果としてアラートの見逃し、無視や対応の遅れを生んでしまうこと
  7. アラートの課題と解決までのプロセス 同じ人が一生対応しているアラート アラート(1回目) 僕対応します Aさん アラート(N回目) 僕対応します Aさん 基本同じ人が見てる •

    アラート対応できる人が一部 のみ 他のメンバーにはどう対応するの かわからない人もいた かつ、情報も残してないのでわか らない
  8. チームの分断 アラート改善ができない問題にはチームの問題が潜んでいる • アラート設定をしているのはチーム • 改善していくのもチーム • それができていないということは、 チームがアラート改善ができる状況 ではない

    チームを否定するのではなく チームの状況を聞いて対話をして いきましょう 意味のないアラート 改善ができないパターン 改善ができない構造 改善ができないメンタルモデル
  9. チームの分断 このような状況でチームに起きていること • アラートの認識がチームの中で揃っていない • 情報の断裂が起きている • アラートやアプリケーションのログに調査、対応に必要な情報が 残されていない •

    監視を設定する人がシステムの動作を理解できていない 前任者はアラートが来てから次の対応を 手順書に残さなかった 知っている情報がメンバー同士で差がある
  10. チームの分断 監視をチームのスキルとしていく • アラートの定義をチームの中で決める ◦ アラートがきたときにチームが取りたいアクション を決めること ◦ そうすることでチームの中で同じ認識でアラート を見ることができる

    • チームの中で議論して決めるには同じ情報量で話が できる必要がある ◦ (具体例) チーム全員で『入門監視』を読んでくる • 定義が決まったら習慣的にアラートを見直してみる ◦ 持ち回りでファシリテーターを決めて監視設定を 見直してみる
  11. チームの分断 情報を残す、繋ぐ手段を確立する • アラートが来たときに必ず手順書やログ を残すというチームの手続きを決める ◦ (具体例) Github Issueに調査から対応までの 流れを記録として残す

    ◦ 見返すことで誰でも後からできるようにな る • アラートのメッセージに過去の対応した 記録を貼っておく ◦ (具体例) Github Issueのリンクを貼っておく ◦ いちいち記録を探しに行かなくてよくなっ た
  12. ビジネスの分断 実際にビジネス指標を見つけたら • 実際に話をして見つけたらそれ を技術指標と絡めて見てみる ◦ 右の図が私が運用してたシステ ムと絡めて見た様子 ビジネスを通してシステムと 監視の勘所を理解できるように

    なる ビジネス指 標 技術指標 影響 案件の登録 案件、在庫 データの登 録失敗 登録数のメ トリクス 案件に登録されたデー タの売上のN%が我々 の売上になっているの でクリティカルになる 急激に減ったら何かビ ジネスに影響のある技 術的課題があるかもし れない
  13. ビジネスの分断 ビジネスに与えた変化 • 売上を上げるための機能開発に集中できるようになった • ビジネスに影響のある障害が起きづらくなった • ビジネスの損失つながるバグは1時間以内に気づいて復旧までするよ うになった 以前は半日ぐらい気づかないこともあった

    2回ほどビジネスの損失につながる事態が発生したが どちらも1時間以内に復旧することができた これによって新卒も安心してリリースできようになった より安心してリリースできるためのテストも増やすようになった