「監視しているのになぜ気づかない」を解消した3つの施策
「監視ツールは入れています。アラートも設定しています。でも障害は、ユーザーから教えてもらっています」
これを、複数の組織で聞いた。そのたびに少し複雑な気持ちになる。問題はツールではないからだ。
「入れているのに気づかない」の原因は、たいてい同じ3つの場所にある。複数の組織で同じパターンを見ていると、それが確信に変わった。設定の問題というより問いの立て方の問題だ。
「監視できている」の定義が、ずれていた
監視の目的を「インフラが正常かどうか確認すること」だと定義すると、多くの組織では「監視できている」になる。CPUは正常、メモリは正常、エラーレートも閾値内。それを見て「問題ない」と判断する。
ところがその間に、ユーザーは「画面が真っ白」「ボタンが押せない」という体験をしている。
あるチームの支援に入ったとき、まさにその状況だった。監視ダッシュボードはすべてグリーンだ。それでも「ユーザーから使えないという声がある」と言われた。調べると、特定のブラウザでJavaScriptのエラーが大量に出ていた。サーバーサイドには何も出ていない。インフラは正常で、アプリは壊れていた。
「監視できている」と思っていたのは、インフラのことだけだったとわかった瞬間だった。
ユーザー体験の計測：「見えていない」に気づく難しさ
サーバーサイドの監視には限界がある。フロントエンドで何が起きているか——JavaScriptのエラー、描画速度、セッションの中断——これらはサーバーのログには出ない。計測の仕組みを入れない限り、誰にも見えていない。
ただし「入れればいい」と最初は思っていた。RUM（Real User Monitoring）とは、実際のユーザーのブラウザ上でJavaScriptを動かし、描画速度やエラー、セッションの流れをリアルタイムに収集する仕組みだ。Datadog RUMやSentryなど各種ツールが対応しており、SDKを数行追加するだけで計装できる。実際に入れてみると、最初に出てきたのは把握していなかったエラーの一覧だった。件数が予想より多かった。「これ全部直すんですか」と聞かれたとき、正直答えられなかった。
見えるようになっても、「どれが重要か」「どこから手をつけるか」の判断基準がないと、ダッシュボードが埋まるだけで終わる。導入の技術的なハードルより、「フロントエンドの健全性をどう定義するか」を決めることの方がずっと難しかった。
実際に効いたのは、エラーをユーザーへの影響度で並べ直したことだ。「エラーが出ている」ではなく「この画面でセッションが途中で終わっている」という形で状況を把握できると、開発チームの優先度の判断が変わった。見えるだけでは不十分で、見えた後に「何を優先するか」を決める場を作ることが本当の仕事だった。
ログ整理：「捨てる」の合意が一番時間がかかった
「ログはしっかり取っています」という組織の多くで、実際は「多すぎて調査に使えていない」状態にある。
ログを削減する話をすると、最初は必ず抵抗される。「後で必要になるかもしれない」と言われる。その感覚はわかる。私も最初はそう思っていた。
ただ、実際の障害調査を一緒に振り返ると、変わることがある。「直近の調査で、DEBUGレベルのログを使いましたか」と聞くと、「使っていない」という答えが多い。ヘルスチェックのアクセスログも、定期バッチの正常完了ログも、「念のため残している」ものが大半だった。
ここで選択したのは「捨てる」ではなく「分ける」だった。
具体的には、ERRORとWARNのログを専用のインデックスに分離し、DEBUGやINFOは保持期間を短くするか取り込まない設定にした。DatadogにはLog Indexesという機能があり、ログをフィルタリング条件ごとに別インデックスに振り分けられる。ELKスタックであればインデックスを分けるか、OpenSearch/Elasticsearchのデータストリームで同様の整理ができる。「エラーだけを見に行く場所」を作ることで、障害調査の最初の一手が変わった。
ただ、この設定は1日で変えられる。「このログは調査に使わない」と組織として合意するまでの方が、はるかに時間がかかった。
アラート設計：信頼を失ったアラートは音と同じになる
毎日30件以上のアラートが届いていたチームがいた。Slackに流れてくるが、誰も見ていない。正確には、「重要かどうかわからないから全部流している」状態だった。
アラートが機能していない状態を「設定の問題」と見ると、解決策を間違える。あのチームに足りていなかったのは設定ではなく、「このアラートが鳴ったら対応する」という前提だった。アラートが信頼されていなかった。
信頼が失われる理由は2つある。鳴りすぎること、と、鳴っても何もしなくていいことがあること。この2つが重なると、人はアラートを「音」として処理するようになる。見ない、消す、慣れる。
件数を減らすと言うと「安全性が下がる」という反論が出る。その反論は理解できる。ただ、毎日30件届いて誰も見ていない状態は、すでに安全ではない。
取り組んだのは、まず「このアラートが鳴ったとき、誰が何をするか」を全部書き出すことだった。答えられないものは一度止めた。残ったものについて、閾値の根拠を聞いた。「なんとなくこの値にした」が多かった。インフラの数値に基づく閾値を、ユーザー体験に影響が出ているかどうかという観点に置き換えていった。
整理後にアラート数は半分以下になった。件数が減ったことより印象的だったのは、「アラートが来たら見る」という空気が戻ってきたことだ。信頼は、数が減ることで回復した。
3つに共通していたこと
振り返ると、3つの変化に共通していた。設定を変えることより、判断の基準を変えることの方が時間がかかった。
フロントエンドのどのエラーが重要か。どのログを捨てていいか。どのアラートを信頼するか。これらはツールの問題ではなく、チームが「何を監視に値する状態と定義するか」の問題だ。ツールを変えてもこの問いは消えない。
「監視しているのに気づかない」の多くは、問いの方を変える必要があった。
そして1チームで定着した「監視に値する状態の定義」は、別チームのオンコール基準を見直す呼び水になりやすい。組織全体の監視文化は、こういう個別チームの判断基準が横に伝染することで動き始める。
監視を見直そうとしている人がいたら、直近1週間で起きた障害を1件選び、「その障害に監視で気づけたか／気づけなかったとしたら何が見えていなかったか」を振り返るところから始めるとよい。3つの施策のうち、何から手をつけるべきかが自然に見えてくる。
この記事は、複数の組織でSREとして働いてきた筆者の経験をもとにしています。一部、経験から推測される行動・思考パターンを含む記述があります。
Discussion