第3章：リアルタイムである必要はあるか

この章で分かること

  • リアルタイム／オンデマンド／定期の分け方
  • 「行動できるか？」という判断基準
  • アラート疲れの仕組みと対策
  • SLO・エラーバジェットとの関係
  • Golden Signals と「症状優先」の考え方
  • 通知ルール棚卸しの進め方
たとえ話

スマホ通知と同じです。「今すぐ返信」と「週末に読むレポート」を同じバイブにすると、大事な連絡が埋もれます [S11][S14]。

判断基準: 今この情報が届いたとき、具体的なアクションを起こせるか？
タイミング分類図 · ソース: ../diagrams/monitoring_timing_matrix.mmd
%% タイミング分類図
flowchart LR
  Q{"今この情報が届いたとき\n具体的なアクションを起こせるか?"}

  Q -->|今すぐ行動| RT["リアルタイム\nサービス停止 / 注文失敗急増\n認証障害 / コスト暴走\nSNMP Trap重大障害"]
  Q -->|調査依頼を受けて| OD["オンデマンド\n特定ユーザー失敗\nCI失敗調査\nデプロイ前後差分\n監査調査"]
  Q -->|傾向・予測で改善| REG["定期"]

  REG --> D["日次\n重大エラー集計\nLLMコスト"]
  REG --> W["週次\n再発傾向\nアラートノイズ"]
  REG --> M["月次\n容量予測\nMTTR推移\nインシデント件数"]

  style RT fill:#7f1d1d,stroke:#fca5a5,color:#fff
  style OD fill:#1e3a5f,stroke:#7dd3fc,color:#fff
  style REG fill:#14532d,stroke:#86efac,color:#fff
図が見えないときのテキスト版 
行動できる？ → リアルタイム / オンデマンド / 定期(日次・週次・月次)

1. 三つの箱（詳細）

箱条件例通知AIの使い方
リアルタイム今、人が動く／守る停止、認証障害、重大Trap、コスト暴走ページ等検知後の初動パック
オンデマンド依頼があってから特定ユーザー、CI失敗、監査依頼時検索・相関
定期傾向・予測・改善再発、容量、費用、MTTR日次〜月次要約と優先草案

2. SLO・エラーバジェット

SLO＝目標水準。エラーバジェット≒100%−SLO [S12][S13]。枯渇時の扱い（リリース方針など）は政策として事前合意します [S18]。
全部をリアルタイムにすると、「変更を進めるか信頼性作業に寄せるか」の会話も濁ります。

2b. Golden Signals と症状優先

SREの監視では、ユーザーに近い症状（symptoms）をページの主対象とし、 原因ヒューリスティック（CPU単体など）は補助に回すのが定石です [S11]。
典型の観測軸は Golden Signals（latency / traffic / errors / saturation）です。 「ディスク90%」単体より、「エラー率上昇＋レイテンシ悪化」の方が行動につながりやすい、という判断材料になります。

3. 棚卸しワーク（30分）

  1. 直近の通知を20件書き出す
  2. 各行に「届いた瞬間に取った行動」を書く（無ければ定期候補）
  3. 重要度と頻度で四象限に置く
  4. 行動不能な高頻度を抑制・集約・定期へ移す
行動できない情報をリアルタイム通知し続けるとアラート疲れになります [S11]。
運用担当者通知ルールを行動有無で棚卸しする
PGログ量が増える変更はseverityとevent_codeを添えて相談する
SE通知設計を行動可能性で分類し、集約・抑制方針を決める
PM日次・週次の受け手とアクションを決める
経営層「リアルタイム＝先進」ではないと理解する

4. 現場適用：振り分けシート

通知名 | 届いたときの行動 | 箱 | 変更案
------|------------------|----|--------
disk90 | なし（見るだけ） | 月次 | ページ解除
auth_down | 全員召集 | リアルタイム | 維持
ci_flake | 翌朝確認 | 日次/週次 | 抑制

ふりかえり

  • 自チーム通知を三箱に振り分けたか
  • 振り分け不能な通知をやめる／定期化する候補にしたか