監視とアラート設計｜クラウドインフラ

🎓 レベル：標準　|　重要度：A（必須）

📎 前提：メトリクス・ログ・トレース（3本柱）　|　関連：SREとは・SLI/SLO/エラーバジェット・インシデント対応とポストモーテム

要点（BLUF）

良いアラートは「人が今すぐ行動すべきことだけを鳴らす」。鳴ったら必ず対応が要る状態にする。情報共有はダッシュボード、行動要求はアラート、と分ける。
**原因ベース（CPUが高い）より症状ベース（ユーザーが遅い/エラー）**で鳴らす。ユーザー影響に直結する指標が主役。
SLOバーンレートで鳴らすと、エラーバジェット（SREとは・SLI/SLO/エラーバジェット）の消費速度に応じて緊急度を調整でき、ノイズが激減する。

概念 ── アラートは「行動要求」

アラートが多すぎると人は鈍ります（アラート疲れ／alert fatigue）。すべてに反応できず、本当に重要な1件を見逃す。だから原則は「鳴ったら必ず人の行動が要る」ものだけを鳴らす。「知っておきたい」程度はダッシュボード（メトリクス・ログ・トレース（3本柱））で見る。

flowchart TB
    signal["信号（メトリクス）"] --> q{"人が今すぐ動く必要があるか"}
    q -->|"はい"| page["アラート（呼び出し・page）"]
    q -->|"いいえ・参考情報"| dash["ダッシュボードに表示のみ"]
    page --> runbook["ランブックに沿って対応"]

仕組み ── 症状ベースと SLO バーン

原因ベース（CPU 80%超で警告）の問題は、(1) CPUが高くてもユーザーが困っていないことがある（誤報）、(2) CPUは正常でもユーザーが困っていることがある（見逃し）。

**症状ベース（symptom-based）**は「ユーザーが体感する悪さ」で鳴らす——エラー率の上昇、レイテンシの悪化、可用性の低下。これらは SLI（SREとは・SLI/SLO/エラーバジェット）そのもの。

さらに SLOバーンレート：エラーバジェットをどれだけ速く食っているかで緊急度を分けます。

速い消費（数時間で全部使う勢い）→ 即ページ（夜でも起こす）
遅い消費（数日かけて）→ 翌営業日のチケットでよい

flowchart LR
    budget["エラーバジェット（SLOの余裕）"] --> rate{"消費速度（バーンレート）"}
    rate -->|"高い：急速に枯渇"| urgent["即ページ（緊急）"]
    rate -->|"低い：ゆっくり"| ticket["チケット（非緊急）"]

これにより「一時的なスパイクでは鳴らず、本当に予算を脅かす異常でだけ鳴る」アラートになります。

仕組み ── ランブックと多段階

鳴らすアラートには必ず**ランブック（対応手順書）**を紐づけます。「このアラートが鳴ったら何を見て、何をするか」が書いてあれば、誰でも・夜中でも対応できる。深夜の判断を属人化させない。

通知も多段階に：緊急は呼び出し（オンコール）、非緊急はチャット/チケット、参考はダッシュボードのみ。重大度（severity）でルーティングします。

なぜこう設計するのか

見逃しを防ぐため：ノイズを減らすほど、本物の1件に集中できる。アラート疲れは可用性の敵。
ユーザー視点に揃えるため：症状ベースは「困っているのは誰か＝ユーザーか」を基準にする。内部指標の上下に振り回されない。
持続可能な運用のため：SLOバーンとランブックで、緊急度の判断と対応手順を仕組み化。オンコール担当の負担（toil）を抑える（インシデント対応とポストモーテム）。

⚠️ よくある誤解・落とし穴

「とりあえず全部アラート」→ アラート疲れで重要な1件を見逃す。行動が要る物だけ。
「CPU・メモリのしきい値だけで監視」→ ユーザー影響と無関係に鳴る/鳴らない。症状ベースを主に。
「ランブックの無いアラート」→ 鳴っても何をすべきか分からず対応が属人化。必ず手順を添付。
「静的しきい値を全環境一律」→ トラフィックの波で誤報。時間帯・季節性を考慮、または SLOバーンで相対化。
「アラートを鳴らしっぱなしで振り返らない」→ 誤報・無対応アラートは定期的に棚卸しして削る。アラートも保守対象。

対応ラボ

なし（設計トピック）。鳴らす元のメトリクスはメトリクス・ログ・トレース（3本柱）の Prometheus ラボで収集できる。Prometheus の alerting rule／Alertmanager は同ラボを拡張して実装（要最新確認）。