前回は、運用の真の目的が「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では、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
無料のアカウントで試してみよう！
