# 現代の理想的なアラーティング-判断モデル ## 結論 現代の理想的なアラーティングとは、単に「人へ通知する仕組み」ではなく、**顧客影響・緊急性・対応主体・自動処理可能性・欠落リスクを評価し、ページ、チケット、自律処理、診断情報、または削除へ振り分ける信頼性制御ループ**である。 この判断モデルの中心には、「人間を起こす権利は高価である」という前提を置く。したがってページは、サービスレベル目標(SLO)に関わる影響があり、即時対応が必要で、かつ人間の判断が価値を持つ場合に限る。それ以外は、チケット、自動修復、エージェント型ハンドラ、ダッシュボード、監視ルール改善、または削除へ送る。 --- ## 1. 語彙を分ける アラーティングを再設計する最初の仕事は、「鳴ったもの」をすべて同じ名前で呼ばないことである。理想的な設計では、以下を分離する。 | 名称 | 意味 | 主な受け手 | |---|---|---| | イベント | システム内で起きた観測可能な事実 | ログ・監視基盤 | | シグナル | SLI、メトリクス、ログ、トレース、プローブなどの観測値 | 監視ルール・分析基盤 | | アラート | 何らかの条件により注意喚起された状態 | 管理基盤・集約器 | | ページ | 人間の即時対応を要求する通知 | オンコール担当者 | | チケット | 後で処理できる作業項目 | 所有チーム | | インシデント | 顧客影響または重大な運用影響を持つ事象 | インシデント対応体制 | | 自律ハンドラ入力 | 自動緩和・調査・復旧の対象 | エージェントまたは自動化基盤 | | 診断情報 | ページ条件ではないが調査に役立つ文脈 | ダッシュボード・Runbook | この分離により、「検知したので人を起こす」という短絡を避けられる。[[アラート管理]] が alert と incident を別ライフサイクルとして分けるのと同様に、ページもアラートの一形態にすぎない。 --- ## 2. 中心原則 ### 人間を呼ぶ権利は高価である ページは人間の注意、睡眠、判断能力、将来の応答性を消費する。したがって、ページの条件は通常の通知より厳しくなければならない。[[アクショナブルアラート]] の最小条件は、「即時対応が必要であり、かつ人間の知性を要する」ことである。自動修復できるなら人間を呼ばない。朝まで待てるならページしない。修復手順が存在しないなら、ページではなく設計不備として扱う。 ### 症状へページし、原因は診断情報に残す ページ条件は、CPU 使用率やディスク使用率のような原因候補ではなく、顧客影響や SLO 違反の予兆に置く。一方で原因情報を捨ててはいけない。原因候補、関連メトリクス、直近変更、依存関係、過去事例は、ページ本文、Runbook、ダッシュボード、自動添付情報として残す。これは「鳴る条件」と「調べる材料」を分離する設計である。 ### 欠落アラームも品質問題である ノイズ削減だけを目的にすると、鳴るべきアラートまで削る危険がある。理想的な判断モデルは、偽陽性コストだけでなく、欠落アラームの損害を同じ品質モデルに入れる。[[Quality of Alerts]] と Zadka のコストモデルは、この点で相補的である。 ### 自律処理と人間対応の境界を明示する エージェント型 SRE の時代には、アラートは人間だけでなく自律ハンドラの入力にもなる。ただし、すべてを自律処理に送るべきではない。重大障害、広域障害、未知の影響範囲を持つ事象、不可逆操作を伴う緩和は、人間判断を残すべき領域である。 --- ## 3. ライフサイクルモデル 理想的なアラーティングは、次の 7 段の閉ループとして扱う。 | 段 | 問い | 代表的な介入 | |---|---|---| | 1. 影響定義 | 何が顧客影響なのか | SLI/SLO、ビジネス KPI、ゴールデンシグナル | | 2. 監視存在保証 | 鳴るべき対象を監視しているか | 監視不在検知、SLO カバレッジ確認 | | 3. ルール健全性保証 | ルールは正しく動くか | [[Prometheusルールリント]]、CI、常時検証 | | 4. 発火前制御 | 鳴らす前に抑えられるか | 抑制、遅延、X-out-of-Y、予測的条件 | | 5. 発火後整理 | 鳴ったものをどう減らすか | 集約、相関、重複排除、ランキング | | 6. 対応先決定 | 誰または何が処理するか | [[Adaptive Paging]]、チケット化、自律ハンドラ | | 7. 学習と改善 | 結果をどう戻すか | QoA、アラートバジェット、KEEP/TUNE/DELETE | 重要なのは、すべての段を一度に高度化することではない。自組織で最も高いコストを生んでいる段を特定し、そこから改善する。 --- ## 4. ページ判定表 以下は、アラート候補を処理先へ振り分けるための最小判断表である。 | 条件 | 処理 | 理由 | |---|---|---| | SLO 違反中、または短時間で違反見込み。即時対応が必要。人間判断が必要。 | ページ | 顧客影響と人間判断の価値がそろっている | | SLO 影響があり、自動緩和手順が安全に定義済み。 | 自律ハンドラ | 人間を呼ぶ前に機械が処理できる | | SLO 影響はないが、放置すると将来のリスクが上がる。 | チケット | 即時性はないが改善対象である | | 原因候補だが、顧客影響を直接示さない。 | 診断情報 | ページ条件ではなく調査材料である | | 低重要度だが、発生時点の文脈を残す価値がある。 | 証拠自動収集 | Warning アラートを調査可能な状態にする | | 同一根本原因から大量発火している。 | 集約・相関 | 人間に渡す単位を縮約する | | 受け手が曖昧で、誰も行動できない。 | Runbook 合意へ戻す | アクショナブル性が未成立である | | ルールが壊れている、または参照メトリクスが存在しない。 | 監視の監視 | 正常沈黙と故障沈黙を区別する | | 頻繁に無視され、対処も記録されない。 | 削除・通知化・チケット化 | ページとしての資格がない | | 重大障害で、影響範囲が大きく自律処理の安全境界を超える。 | 人間主導のインシデント対応 | 自律処理の失敗コストが高い | この表の狙いは、アラートを「鳴らすか消すか」の二択から外すことである。多くの候補は、ページではなくチケット、診断情報、自律処理、またはルール改善に送るべきである。 --- ## 5. 品質モデル 理想的なアラーティングは、品質を主観ではなく測定対象として扱う。基本軸は [[Quality of Alerts]] の 3 軸である。 | 軸 | 問い | 低い場合に起きること | |---|---|---| | 指示性 | 顧客影響を本当に指しているか | 低層メトリクスのノイズで人が呼ばれる | | 精度 | 重大度は正しいか | 重要でないものが高重要度になり、重要なものが埋もれる | | 処理容易性 | 誰が何をすべきか分かるか | 確認・診断・復旧が遅れる | ただし、この 3 軸だけでは欠落アラームを表しにくい。したがって実務上は、以下の 4 番目の問いを加える。 | 軸 | 問い | 低い場合に起きること | |---|---|---| | 欠落耐性 | 鳴るべき事象を見逃していないか | 「静かな失敗」が顧客影響として発覚する | この 4 軸は、Zadka のコスト分解と対応させると使いやすい。 | コスト区間 | 主に効く品質軸 | |---|---| | 発生から検知まで | 指示性、精度、欠落耐性 | | 検知から確認まで | 精度、処理容易性 | | 確認から診断まで | 処理容易性、診断情報の質 | | 診断から復旧まで | Runbook、自動緩和、安全な実行権限 | 品質改善とは、単にアラート件数を減らすことではない。偽陽性、真陽性処理時間、欠落損害の合計コストを下げることである。 --- ## 6. 組織モデル 技術的に正しいアラーティングでも、組織的な所有権がなければ劣化する。理想的な運用では、以下を制度として持つ。 ### アラート追加前レビュー 新しいページ条件を追加する前に、次を確認する。 - 顧客影響または SLO への接続があるか - 即時対応が必要か - 人間判断が必要か - 通知先は明確か - Runbook は存在するか - 自動修復またはチケットで足りない理由は何か - 削除条件または見直し期限はあるか ### アラートバジェット アラート件数、夜間ページ数、偽陽性率、未対応アラート数をチームごとに可視化する。これは罰則のためではなく、アラートを増やすことのコストを明示し、所有権をサービスチームへ戻すためである。 ### KEEP / TUNE / DELETE 定期レビューでは、各アラートを以下に分類する。 | 判定 | 意味 | |---|---| | KEEP | 現状維持。顧客影響・対応手順・通知先が妥当である | | TUNE | 条件、重要度、通知先、Runbook、添付情報を直す | | DELETE | ページとしての資格がない。削除、通知化、チケット化、自動化へ移す | ### 認知的徒弟制 アラートトリアージは暗黙知にしない。クエリを声に出して読み、タイトルと条件の一致を確認し、なぜ KEEP/TUNE/DELETE にしたかを共有する。これにより、アラーティングの品質判断が個人技から組織能力へ移る。 --- ## 7. 成熟度モデル | 段階 | 状態 | 主な改善目標 | |---|---|---| | L0 | 静的しきい値が直接ページする | 原因指標と症状を分ける | | L1 | SLO または顧客影響でページする | ページ条件を症状起点へ寄せる | | L2 | Runbook、通知先、対応タイミングが合意済み | アクショナブル性を発火前に作る | | L3 | ルール健全性、抑制、集約、ランキングがある | ノイズと静かな故障を制御する | | L4 | QoA とコストで継続改善する | 削減ではなく総コスト最小化へ移る | | L5 | 自律ハンドラと人間ページの境界を管理する | 人間判断を高価値領域へ集中させる | 成熟度は直線的な達成リストではない。組織によっては、L1 の SLO 化より先に L2 の Runbook 合意が効く場合もある。重要なのは、自分たちの最大コストがどこにあるかを測って改善順序を決めることである。 --- ## 8. 監査チェックリスト 既存アラートを棚卸しするときは、各アラートについて次を確認する。 - このアラートは SLO、顧客影響、ビジネス KPI のどれに接続しているか。 - ページ、チケット、診断情報、自律処理のどれに送るべきか。 - 人間が 15 分以内に判断または操作する価値があるか。 - 通知先は、原因または所有責任に最も近いか。 - Runbook は「手順」だけでなく、背景、判断材料、撤退条件を含むか。 - 発火条件は単純で監査可能か。 - ルールが静かに壊れた場合に検出できるか。 - 同一原因の重複発火を集約できているか。 - 過去 30 日で無視、即 close、未対応が続いていないか。 - 自動修復、自律調査、証拠収集に移せる部分はないか。 - 削除した場合の欠落コストを説明できるか。 --- ## 9. 未解決の論点 - 人間通知用アラートと自律ハンドラ入力は、同じスキーマで扱えるか。それとも別の設計原則が必要か。 - QoA の指示性・精度・処理容易性・欠落耐性を、どこまで自動採点できるか。 - アラートバジェットを業績目標にした場合、Goodhart の法則をどう避けるか。 - 複数の介入点、すなわち抑制、集約、ランキング、RCA、自律ハンドラを直列に並べたとき、各層の寄与をどう分解するか。 - Runbook の鮮度、通知先の正しさ、所有権の曖昧さを自動検知できるか。 - 重大障害では、どこまでエージェントに調査・緩和を委ね、どこから人間主導へ切り替えるべきか。 --- ## 関連 - 元ノート: [[現代の理想的なアラーティング]] - 進化史: [[アラーティングの進歩-年代別]] - 技術的介入点: [[アラート管理]] / [[Prometheusルールリント]] / [[アラート集約]] / [[アラート抑制]] - 品質評価: [[Quality of Alerts]] / [[アクショナブルアラート]] - 組織的条件: [[アラート疲労]] / [[アラートポリューション]] / [[認知的徒弟制]] - 将来方向: [[agentic SRE]] ## 出典 本ノートは [[現代の理想的なアラーティング]] を判断モデル型に再構成した派生ノートである。個別の根拠は元ノート、[[アラーティングの進歩-年代別]]、および関連 concept ページに従う。