前回は、運用の真の目的が「MTTD（検出）とMTTR（復旧）の短縮」にあることをお伝えしました。では、具体的に「何」を「どう」監視すれば、この目的を達成できるのでしょうか。とりあえずCPUやメモリの負荷を眺めているだけでは、ユーザーが体験している「重い」「使えない」という不満には気づけません。　第2回では、モダンな監視を設計するための3つの強力なフレームワークと、運用を崩壊させる「監視の罠」について解説します。

連載：モダンなシステム運用への道標

第1回なぜ今、「監視」を見直す必要があるのか？～DevOpsと運用の真の目的～
第2回ユーザー視点で考える！モダンな監視デザインパターンとアンチパターン <=ココ

視点を整理する3つのフレームワーク

監視の項目を闇雲に増やす前に、まずは「誰のための、何の指標か」を整理しましょう。モダンな運用現場では、以下の3つのメソッドを組み合わせて活用します。
1.USEメソッド（インフラの健康診断）
主にサーバーやネットワークなどのリソースを対象にします。

Utilization（利用率）：リソースをどれくらい使い切っているか？
Saturation（飽和度）：処理待ち（キュー）が発生していないか？
Errors（エラー）：ハードウェアやOSレベルでエラーが出ていないか？

2.REDメソッド（サービスの健康診断）
マイクロサービスなど、リクエストベースのサービスの状態を測るのに適しています。

Rate（リクエスト数）：秒間あたりのリクエストは？
Errors（エラー数）：失敗しているリクエストは？
Duration（所要時間）：処理にどれくらい時間がかかっているか？

3.Four Golden Signals（Google SRE流）
GoogleのSREチームが提唱する、ユーザー体験に直結する4つの基本シグナルです。

Latency（遅延）：成功した（および失敗した）リクエストの速度。
Traffic（トラフィック）：システムの需要量。
Errors（エラー）：リクエストの失敗率。
Saturation（飽和）：システムがどれくらい「いっぱいいっぱい」か。

「外側」から監視を設計する

多くのエンジニアは「内側（サーバー内部）」から監視を組みがちですが、モダンな設計の鉄則は 「外側（ユーザーに近い場所）」 から始めることです。

外形監視（Synthetics）とRUM

サーバーのCPUが100%でも、ユーザーが快適に買い物できているなら、それは「緊急事態」ではないかもしれません。逆に、CPUが1%でも、ネットワーク経路の不調で決済ができないなら、それは「大惨事」です。

外形監視：外部の拠点から定期的に「ログイン→商品検索→決済」というシナリオを自動実行し、成功率を測る。
RUM（Real User Monitoring）：実際のユーザーのブラウザから「画面が表示されるまでの時間」を収集する。

これらを監視の 「最優先（Tier 1）アラート」 に据えることで、ビジネスへの影響をダイレクトに察知できるようになります。

運用を壊す「監視のアンチパターン」

「監視を強化したつもりが、運用チームが疲弊してしまった」——そんな悲劇を防ぐために、避けるべき3つのアンチパターンを紹介します。

アンチパターン①：とりあえず全部アラート

「何かあったら怖いから、CPU 80%で通知しよう」という考えは危険です。

結果：重要度の低い通知がSlackに溢れ（アラートノイズ）、本当に重要な「サービス停止」の通知が埋もれてしまいます。

アンチパターン②：深夜の「おやすみ」コール

対応が不要なアラート（例：一時的な負荷増大ですぐ収まったもの）で担当者を叩き起こすのは、QOL（生活の質）を著しく低下させます。

改善策：即時対応が必要なものは「電話/通知」、明日対応すればいいものは「チケット作成」というように、通知先と経路を峻別しましょう。

アンチパターン③：ダッシュボードを作って満足

豪華なグラフを作っても、誰も見ていなければ意味がありません。

改善策：ダッシュボードは「異常に気づくため」ではなく、 「異常に気づいた後に、原因を特定するため」 に使うものです。

監視を「継続的な改善」のサイクルに組み込む

監視設定は一度作ったら終わりではありません。障害が起きるたびに、以下の問いを繰り返す必要があります。

この障害は、既存のアラートで検知できたか？（MTTDはどうだったか？）
検知できなかったなら、どの指標を見ていれば防げたか？
通知は適切だったか？（ノイズではなかったか？）

この「振り返り（ポストモーテム）」を繰り返すことで、監視は研ぎ澄まされ、チームの信頼（安心感）へとつながっていきます。

次回予告：なぜ「監視」だけでは足りないのか？

「エラーが出ているのは分かった。でも、なぜ起きているのかが分からない……」

分散システムやクラウドネイティブな環境では、監視だけではこの「なぜ」に答えられません。次回、その壁を突破する概念 「オブザーバビリティ（可観測性）」 について深掘りします。

今回のまとめ：

リソースならUSE、サービスならRED/Golden Signalsを使う。
ユーザー視点の「シナリオ監視」を最優先にする。
アラートノイズを減らし、人間を大切にする運用を設計する。

その他

New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています！

無料でアカウント作成も可能なのでぜひお試しください！

New Relic株式会社のX(旧Twitter) や Qiita OrganizationOrganizationでは、

新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。

無料のアカウントで試してみよう！

New Relic フリープランで始めるオブザーバビリティ！