はじめに
当時の状況
とある現場でNew Relicを導入して、監視やアラートの整備を進める機会がありました。
監視自体は元々存在していました。
- CloudWatchのメトリクス
- ログ
- 各種アラート
- etc
という感じで何かしらの異常があれば通知される状態ではありました。
課題
しかし実際に運用していると、次のような課題がありました。
- アラートは鳴るが、本当に対応すべきものか分かりづらい
- 重要度の低い通知が多く、重要な通知が埋もれる
- アラートが鳴っても、すぐに見られないことがある
- 障害時に「どこを見ればよいか」が人によって違う
- ユーザー影響や事業影響とアラートが紐づいていない
いわゆる、アラートのオオカミ少年化というやつですね。
本記事ではNew Relicの導入をきっかけに、アラートや監視の考え方を見直し
「鳴るけど見られないアラート」から「鳴ったらちゃんと見られるアラート」へ変えていった話を書いていこうと思います。
見られないアラートとはどういうことか？
監視ツールやアラートが存在していることと、
監視できていることは別だと思っています。
アラートの中には、
- すぐ対応しなくても問題ないもの
- 原因が分かっていて放置されているもの
- 一時的なスパイクで毎回鳴るもの
- 誰が見るべきか決まっていないもの
- ユーザー影響があるのか判断しづらいもの
が混ざっていました。
その結果、アラートが鳴っても、
また何か鳴っているな
くらいの扱いにしかならず・・・
これでは本当に重要な障害が起きたときにも、
普段のノイズに埋もれてしまいますね。
Before / After
今回やったことをざっくり図にすると、以下のようなイメージです。
Before
After
方針
アラートの目的を見直した
そこでまず、アラートの目的を見直しました。
アラートは、単に異常値を通知するためのものではありません。
重要なのは、チームが次の行動を取れることです。
アラートが鳴った時は
- 何が起きているのか
- ユーザー影響があるのか
- どのサービス・機能に影響しているのか
- 誰が見るべきなのか
- どのダッシュボードを確認すればよいのか
- すぐ対応すべきなのか、経過観察でよいのか
この辺りが判断できる必要があります。
逆に言えば、これらが判断できないアラートは、
鳴っていても運用上はあまり役に立ちません。
そこで、アラートを増やすのではなく、
アラートへの信頼を取り戻すことを重視しました。
ユーザー影響を起点に考えた
重要な導線というのはユーザーやサービスによって変わってきます。
- お金が関わる処理（支払い・決済機能）
- 求人の応募
- サイト内の検索（旅行サイトなら旅館など）
といった導線です。
これ以外にも色々ありますが、事業の影響やユーザー体験の直結する
など重要度はサービスやチームによって変わるかと思います！
そのため、単にCPU使用率やメモリ使用率を見るだけではなく、
- ユーザーが見れるべき内容を見られているか
- 検索できているか
- 重要なAPIが遅くなっていないか
- エラーが増えていないか
などの観点で監視を整理しました。
インフラが正常に見えていても、ユーザーが困っているケースはあります。
そのため、監視の中心を
インフラの状態から、ユーザー影響・事業影響へ寄せていきました。
実際にやったこと
ノイズになっているアラートの見直し
まずは、既存アラートの棚卸しです。。
以下観点で、今出ているアラートについて調査していきました
- このアラートは今も必要か
- 鳴ったときに誰かが見ているか
- 鳴ったときに取るべきアクションが明確か
- ユーザー影響に紐づいているか
- 閾値は適切か
- 一時的なスパイクで頻繁に鳴っていないか
- 似たようなアラートが重複していないか
この時点で下記のような不要に思えるアラートが見えてきました！
- 鳴っているけど誰も見ていない
- 鳴っても対応しない
- 毎回同じ理由で鳴っている
アラートは多ければ安心、というものではありません。
むしろ多すぎると、重要なものが見えなくなります。
重要なアラートを絞った
次に重要なアラートの整理です！
特に優先したのは、ユーザー影響が大きいものです。
このときに意識したのは、技術的に異常かどうかだけではなく
ユーザーや事業に影響があるかです。
同じエラーでも、
- 社内向けの低頻度な処理で起きているのか、
- ユーザー影響が大きい重要APIで起きているのか
では優先度は大きく変わってきます！
アラートの重要度を、サービスの重要導線と紐づけて整理しました。
ダッシュボードを用意
アラートが鳴ったときに、
「何を見ればいいんだっけ？」となると初動が遅れます。
そこでNew Relic上に、確認用のダッシュボードを整備しました。
ダッシュボードでは、以下のような情報を見られるようにしました。
- 主要APIのレスポンスタイム
- エラーレート
- 重要機能ごとの状態
- BFF/APIの状態
- フロントエンド側のエラー
- 可用性やSLOに近い指標
これにより、アラートが鳴ったときに、
まず同じ画面を見て状況を確認できるようになりました。
エンジニア以外にも見える形にした
監視はエンジニアだけのものではないと思っています。
特に、ユーザー影響や事業影響がある場合は、
PM・セールス・CSなども状況を把握できる必要があります。
そこでNew Relicのダッシュボードは、
エンジニアだけが見るものではなく、
社内のステークホルダーも確認できるようにしました。
これにより、障害時の会話が少し変わりました！
Before
APIでエラーが出ています
ログを見るとこのサービスが怪しいです
という技術寄りの説明・・・
After
〇〇閲覧は生きています
〇〇導線でエラーが増えています
検索APIのレスポンスタイムが悪化しています
ユーザー影響があるため優先度が高いです
というように、
事業側にも伝わりやすい言葉で状況を共有しやすくなりました。
これは、New Relicを入れたこと以上に大きな変化だったと思います。
やってみて分かったこと
監視を強化しようとすると、ついアラートを増やしたくなります。
しかし、アラートが多すぎると見られません。
見られないアラートは、存在していても意味が薄くなります。
大事なのは、
このアラートが鳴ったら、見る必要がある
とチームが思える状態にすることです。
そのためには、アラートの数よりも、
アラートの意味や対応方針を整理することが重要でした。
まとめ
今回の取り組みを通じて感じたのは、監視とは単にメトリクスを見ることではなく
異常に気づき、影響を判断し、チームが動ける状態を作ることだということです。
実施したことや課題がとても多いので1つ1つのTODOは
ざっくりした内容ですが、それぞれの詳細についても今後まとめていけたらと思ってます！