# アラート管理 ## 定義 アラート管理(Alert Management)は、モニタリングシステムが生成した raw alert 群を解析・整理して、(1) 関連アラートを束ねて分析負荷を下げる **alert correlation**、(2) 1 オペレータが捌けない規模のアラート爆発に対処する **alert storm handling**、(3) 重要・真のアラートだけをチケット化対象として識別する **alert determination** の 3 プロセスに分割される、[[インシデント管理]]の上流工程である。Yu+ JNCA2024 はこの 3 プロセスを統一 AIM(Alert and Incident Management)アーキテクチャ Fig.5 の前半に据え、ITSM/ITIL の文脈で「event ⊃ alert、severe alert + user complaint → incident」という関係(Fig.3)で incident と区別する。(Source: [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]]) ## 横断的知見 - **alert と incident を別ライフサイクルとして扱う設計の利得**: Microsoft の慣行は「全アラートを incident として扱う」だが、Yu+ JNCA2024 は alert と incident を [[インシデント管理]] とは別の上流ライフサイクルとして明示的に分離する。これにより「alert で減らせる工数は incident に送らない」設計余地が生まれ、alert correlation で件数を縮約 → storm handling で異常事態を吸収 → determination で重大性を判定、と段階的に絞ったうえで incident management に渡す処理経路が成立する。同じ Tsinghua / Dan Pei 系統の [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]] が AlertGuardian で「denoise→summary→rule refinement」を一気通貫で実装した方向と一致する。(Source: [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - **alert determination は 3 種の直列統合で効く**: Yu+ JNCA2024 は alert distinguishing(真偽判定)・severe alert identification(重要度ランキング)・alert-based incident identification(アラート群→インシデント抽出)を独立に分類しつつ、Fig.7 で「distinguish で偽除去 → severe ranking と incident identification を並列適用」という統合パイプラインを将来方向として提示する。3 系統が直交であり個別研究で進化してきた事実が、3 段直列という結合余地を裏付ける。AlertRank(Zhao+ 2020c の XGBoost ranking)・eWarn(Zhao+ 2020b の multi-instance learning + LIME)・Warden(Li+ 2021a)など個別研究は既に高度化しており、未着手なのは結合のみ。(Source: [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]]) - **alert correlation 3 系統の使い分け(attribute / dependency / hybrid)**: attribute-based は意味類似度を捉え storm 時にも履歴照合に効くが解釈性に欠ける。dependency-based(PC・Granger・MIC・Bayesian network・トポロジ)は依存関係で直近の問題像を可視化するが類似アラート連結ができない。hybrid(深層学習で意味+挙動を統合する OAS by Chen+ 2022b: ASR+ABR+ACT)は両シナリオに効くが大量のラベル付きデータを要求する。「リアルタイム概況」と「履歴類似度」のどちらが要件かで選択が割れる。(Source: [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]]) - **alert storm は industrial alarm flood とは桁違いの規模で、独立の研究対象**: ISA 18.2・EEMUA 191 が定める industrial alarm flood の基準は "10 alerts/10 分/operator" だが、IT サービスの service alert storm はこれと桁が違う(Zhao+ AAAI2020)。industrial flood 向けの sequence mining(PrefixSpan・DTW・fault template)を IT に転用するだけでは不足し、Zhao+ 2020a は EVT(extreme value theory)で適応的検知 + 3 段要約を行い、Li+ FSE2022 は incident-as-storm として LiDAR + COT + DeepIP を併用する。「桁違いの規模 = 別問題」という前提を共有することが設計の出発点になる。(Source: [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]]) - **rule refinement(アラート生成ルール改善)は alert determination 解析結果の "逆流" として実装できる**: Yu+ JNCA2024 §7.3.1 は false/missed alert の発生をアラートルール不適合の現れとみなし、alert determination の結果(false 識別・incidental incident 判定・manual ticket 由来の missed alert)を上流のアラートルール最適化に逆流させる方向を提示する。これは [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]] が同じ Tsinghua-Tencent 連携で実装した「rule refinement を含むライフサイクル一括」という後継研究と対応する。Tang+ 2013c の自動規則学習や Tang+ 2012/2013b の text classification + 履歴解析が下地。(Source: [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - **Microsoft の "全アラートを incident として扱う" 設計は、後段に高精度の incidental 判定器を置くことで成立する**: Yu+ JNCA2024 Table 4 は「Microsoft は全アラートを incident として扱う」と指摘し Chen+ 2020a/c の incident 分析を実質的なアラート分析として位置づけた。実際 Chen+ 2020c に当たる [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]] は、報告された「incident」の 50.32% を後処理で incidental と判定する [[DeepIP]](attention 付き CNN・AUC 0.808)を組み込むことでこの設計を支えている。Tsinghua/Tencent 系統([[AlertGuardian]])が「上流の rule refinement」で 1,174 提案→375 受容(32%)とノイズ生成自体を抑えるのに対し、Microsoft 系統(Chen+ 2020c)は「下流の優先順位付け」で incidental 確率の昇順 ranking でノイズを後回しにする——同じ目的に対して上流アプローチと下流アプローチが並走する構図。Microsoft 系統は alert/incident を一本化する代償として後段の判定器に強い責任を課している。(Source: [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]], [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - **false alarm という独立カテゴリの存在は「モニタ自身の不具合」が独立の介入対象であることを示す**: [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]] の 6 カテゴリ taxonomy のうち false alarm(平均 7.05% — Table 1 から 11.11+3.75+6.22+5.55+8.84 を 5 で割った推定)は「monitor の閾値設定や検査周期の問題で本来鳴ってはいけない alert」を指し、本論文の Example 7 は「データは 3 分ごと更新だが monitor は 1 分ごとチェックしていた」典型例を示す。AlertGuardian の rule refinement(上流のルール改善)はまさにこの false alarm を上流で潰すフィードバックループであり、Chen+ 2020c が「下流で判別する」DeepIP を、AlertGuardian が「上流で発生抑止」する rule refinement を提案したのは、同じ問題(monitor 設定の不具合)に対する上流・下流の双対解。([[異常検知]] の偽陽性問題と接続)。(Source: [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - **静的閾値の脱却 + autonomous alert handlers という Google 流の 2 段アーキテクチャ**: Google SRE AI は (1) **異常検知**を時系列基盤モデル([[TimesFM]] が例示)に委ね、historical signals から「顧客指向 SLO」を予測する。(2) 検知された anomaly が alert を起こすと、**SRE AI alerting agent** が group / pre-process / enrich する。(3) enrich された alert は **autonomous AI alert handlers** に流れ、多くを自律処理・緩和する。この「動的閾値 + alerting agent + autonomous handler」の 3 段は、Tsinghua/Tencent 系統の denoise→summary→rule refinement([[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]])と方向は重なるが、**上流に検知層の基盤モデルを置く点**と**下流を autonomous handler に直結させる点**が新しい。両者を比較すると、AlertGuardian は alert 生成 rule 自体の改善で上流を狭くする方向、Google は anomaly detection を時系列基盤モデルに置き換えて上流の「閾値設計」自体を不要にする方向、と読める。(Source: [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]], [[TimesFM]]) - **「上流のルール改善」と「下流の対処」を橋渡しする中間層としての自動アンチパターン検知**: Yang+ DSN2022 は Huawei Cloud の 2 年・400 万件超アラートと 18 OCE 調査から、4 個別 + 2 集合のアラートアンチパターンを実証同定し、Avoidance(設計時の予防ガイドライン)と Reaction(運用時の対処)の中間に **自動アンチパターン検知**を置くフレームを Figure 6 で提示した。これは AlertGuardian の「上流 rule refinement」と Microsoft 系統の「下流 incidental 判定」のどちらにも還元しきれない第三の介入点で、QoA(Quality of Alerts: indicativeness・precision・handleability)による自動評価をその基盤に据える。Huawei Cloud(Yang+ 2022)の Repeating Alerts という新規集合アンチパターン同定は、Tsinghua/Tencent(Zhao+ 2020)の Cascading Alerts に並ぶ集合アンチパターンの輪郭を完成させた。([[Quality of Alerts]] へ昇格)(Source: [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]], [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]]) - **「現行 4 対処の有効性は OCE 評価で全員肯定、しかし設定にドメイン知識を要する」という共通の制約**: Yang+ DSN2022 の OCE 調査では Alert Blocking と Alert Correlation Analysis は全 18 名が Effective、Aggregation は 16 Effective + 2 Limited、Emerging Alert Detection は 13/3/2(Effective/Limited/Not Effective)。これは Yu+ JNCA2024 が指摘する「alert correlation 3 系統(attribute / dependency / hybrid)の使い分けは要件で割れる」という観察と同じ構造で、評価の高さは「対処自体の有効性」ではなく「設定が正しければ有効」を意味する。AlertGuardian の rule refinement や Google の autonomous handler は、この「設定にドメイン知識を要する」という共通制約を、それぞれ「ルール自動改善」「異常検知を基盤モデルに置換」で攻めている。(Source: [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]], [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]], [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]]) - **「アラートのみで RCA する」自己完結 alert-based RCA 系統の台頭**: [[@2024__CCGRID__AlertRCA - Causality Enhanced Graph Representation Learning for Alert-Based Root Cause Analysis|Yu+ CCGRID2024 (AlertRCA)]] はアラートイベントのみを入力とするエンドツーエンド RCA(top-1 83.9% / top-3 96.8%)を実現し、Groot(手作業ルールあり)を top-1 で上回った(§IV-B)。[[@2023__arXiv__ESRO - Experience Assisted Service Reliability against Outages|Chakraborty+ ESRO]] は過去の障害レポートとアラートデータから CK グラフを構築し、リアルタイムアラートのみで根本原因と緩和手順を推薦する経験ベース診断を提案(Rouge スコア +27.2% / +39.0%)。これらは Yu+ JNCA2024 の「alert-based incident identification」(Fig.7)系統の最新実装で、トレース・メトリクスなしでもアラート系列だけで RCA に十分な信号を取り出せることを示した。alert correlation が「ペア類似度」から「グラフ表現学習」へ世代交代した動きと並行する。(Source: [[@2024__CCGRID__AlertRCA - Causality Enhanced Graph Representation Learning for Alert-Based Root Cause Analysis]], [[@2023__arXiv__ESRO - Experience Assisted Service Reliability against Outages]], [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]] §3-7) - **HPC のアラート過負荷とクラウドのアラートストームは別問題で異なる集約戦略が必要**: [[@2024__ISSRE__Exploring Hierarchical Patterns for Alert Aggregation in Supercomputers|Yuan+ ISSRE2024 (SuperAgg)]] が定義した「アラート過負荷」(alert overload)は、断続的なアラートストームではなく**連続的なバーストの流れ**で 98 万〜211 万件/130 日が発生する。クラウド向け集約([[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems|Zhao+ 2020]] の EVT 検知 + DBSCAN 要約)は変化点検知前提のため HPC では機能せず、SuperAgg は Apriori によるシステム層主従関係と SOM ベースのセンサ層パターン抽出を組み合わせる 2 段階階層構造で対処する。Yu+ JNCA2024 の AIM 分類は IT サービス前提で組まれており、HPC ドメインの aggregate strategy は別カテゴリとして扱う必要がある。詳細は [[アラートストーム]] 参照。(Source: [[@2024__ISSRE__Exploring Hierarchical Patterns for Alert Aggregation in Supercomputers]] §I, §III-C) - **抑制(発火前)・フィルタリング(発火後の閾値)・集約(発火後のクラスタリング)・ランキング(発火後の順序付け)・RCA(発火後の原因)で介入点が分化**: [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps|Bhukar+ 2024]]([[アラート抑制]] 発火前)、[[@2023__JCC__Filtering Alerts on Cloud Monitoring Systems|Voutsas+ 2023]]([[アラートフィルタリング]] 発火後のクリック行動)、[[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems|Zhao+ 2020]] / [[@2023__ASE__Dynamic Graph Neural Networks-Based Alert Link Prediction for Online Service Systems|Chen+ 2023]] / [[@2024__ISSRE__Exploring Hierarchical Patterns for Alert Aggregation in Supercomputers|Yuan+ 2024]]([[アラート集約]] 発火後のクラスタリング)、[[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems|AlertRank]] / [[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems|TraceArk]]([[アクショナブルアラート]] 発火後のランキング)、[[@2024__CCGRID__AlertRCA - Causality Enhanced Graph Representation Learning for Alert-Based Root Cause Analysis|AlertRCA]] / [[@2023__arXiv__ESRO - Experience Assisted Service Reliability against Outages|ESRO]](発火後の RCA)と、5 つの介入点に細分化されてきた。Yu+ JNCA2024 の 3 プロセス(correlation / storm / determination)では捕捉しきれない解像度に到達しつつあり、AIM 分類の再整理が必要な段階にある。(Source: [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]], [[@2023__JCC__Filtering Alerts on Cloud Monitoring Systems]], [[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems]], [[@2023__ASE__Dynamic Graph Neural Networks-Based Alert Link Prediction for Online Service Systems]], [[@2024__ISSRE__Exploring Hierarchical Patterns for Alert Aggregation in Supercomputers]], [[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems]], [[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems]], [[@2024__CCGRID__AlertRCA - Causality Enhanced Graph Representation Learning for Alert-Based Root Cause Analysis]], [[@2023__arXiv__ESRO - Experience Assisted Service Reliability against Outages]]) - **「同事業者・同 SOP 資産・同研究グループ」での前後関係**: [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems|Yang+ DSN2022]] と [[@2024__ICSE-SEIP__Knowledge-aware Alert Aggregation in Large-scale Cloud Systems - a Hybrid Approach|Kuang+ ICSE-SEIP2024]] は同じ CUHK([[Michael R. Lyu]])+ Huawei Cloud([[Yongqiang Yang]]・[[Zengyin Yang]] 等)の連携で 2 年後に出された後続研究の関係にある。前者の調査では SOP の有用性が「Helpful 22.2% vs Limited Help 77.8%」と評価されており SOP の「呈示」は限界がある一方、後者では同じ SOP を LLM が要約・推論する材料として再利用し、Repeating/Cascading Alerts の集約(R2/R3)を F1 0.901-0.930 にまで引き上げた。Yang+ 2022 が SOP の限界を計測 → Kuang+ 2024 が LLM で SOP を再活用、という 2 年スパンの問題発見→解決の流れが同一事業者・同一研究系列で観察できる稀な事例。SOP は「OCE がそのまま読むには長すぎる」のであって「LLM が要約・推論する素材としては有効」という再定位が起きた。(Source: [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]], [[@2024__ICSE-SEIP__Knowledge-aware Alert Aggregation in Large-scale Cloud Systems - a Hybrid Approach]]) - **IBM 系研究 12 年の遷移 — 静的ルール最適化 → 動的オンライン抑制**: [[@2012__NOMS__Optimizing System Monitoring Configurations for Non-Actionable Alerts|Tang+ NOMS2012]](FIU + IBM Watson)はオフラインで「ルール条件 + 最適遅延時間」を月次バッチで決定する静的アプローチで、Tivoli 本番に conservative ルールを deploy し非アクション可能チケットを最大 75% 削減。これに対し 12 年後の [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps|Bhukar+ ICSE-SEIP2024]] は IBM Research(US/India 連携)が動的・オンラインの教師なし統計学習で抑制ポリシーを各メトリクス・サービスに個別学習し、教師あり上界に到達。同じ IBM 系の研究グループが「静的バッチ deploy → 動的 online learning」へ進化させた典型例で、`5 介入点(抑制/フィルタリング/集約/ランキング/RCA)`の最上流である**抑制**の自動化が手書きルールから ML へ転換した。Tang+ 2012 の「リアル見逃しゼロを Theorem 1 で数学保証」と Bhukar+ 2024 の「教師あり上界到達」を並べると、12 年で保証様式が「数学的存在保証」から「経験的近似保証」へ移ったことも観察できる。(Source: [[@2012__NOMS__Optimizing System Monitoring Configurations for Non-Actionable Alerts]], [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]]) - **アラートランキング系統 3 ルーツ — 教師なし不変条件 / 教師なし統一最適化 / 教師あり ML**: [[@2009__ICAC__Ranking the Importance of Alerts for Problem Determination in Large Computer Systems|Jiang+ ICAC2009]](NEC Labs)は不変条件ネットワーク + NTV(Number of Threshold Values)ピアレビューによる**教師なし**ランキングを最初に提案し、ARX モデルで等価閾値を計算してメトリクス横断比較を実現。[[@2018__CIKM__Collaborative Alert Ranking for Anomaly Detection|CAR(Lin+ CIKM2018)]] は同じ NEC Labs の系統で、Pitman-Yor 階層ベイズ(時間)+ エンティティ埋め込み(コンテンツ)を**統一凸最適化(NNLS)**で同時に解く**教師なし**手法。9 年後の [[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems|AlertRank(Zhao+ ISSRE2020)]] は Tsinghua + Tencent で XGBoost の**教師あり incremental learning**を採用し Resolution Record の TF-IDF + k-means でラベル自動付与、F1=0.89。3 ルーツは「教師あり vs 教師なし」「最適化 vs 探索」「単一ドメイン vs 汎用」軸で対照的に進化した。教師なし系(Jiang+/CAR)はラベル不要だが教師あり系(AlertRank)はソフトウェア変更への適応性で勝つ — どちらかを選ぶより**直列パイプライン(教師なしで候補を絞り教師ありで精選)**が未着手の組合せ。(Source: [[@2009__ICAC__Ranking the Importance of Alerts for Problem Determination in Large Computer Systems]], [[@2018__CIKM__Collaborative Alert Ranking for Anomaly Detection]], [[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems]]) - **「発火前精度向上」という第六の介入点 — DEAR の評価場所移動アプローチ**: 既存の 5 介入点(抑制/フィルタリング/集約/ランキング/RCA)はいずれも「アラートが発火するかしないか」を前提に介入する。これに対し [[@2020__CLOUD__DEAR - Distributed Evaluation of Alerting Rules|DEAR(Mormul+ CLOUD2020)]] は **BET(Binary Expression Tree)中間表現でアラートルールの評価場所を中央集約から VM 分散に移動させる**ことで、集約による精度劣化と分散化による管理複雑性の二重トレードオフを解消する**ルール評価インフラ層**の介入を提示。TTI を集約間隔依存(最大 27 秒)から定値 ~370ms に。これは Voutsas+/Bhukar+ の「発火後フィルタリング」とも Tang+/AlertGuardian の「rule refinement(発火条件改善)」とも独立した「**発火前のセンサ精度向上**」介入で、5 介入点に**「監視評価」という上流ゼロ番目の介入点**を追加すべき事例。AlertGuardian の rule refinement(ルールの内容を改善)と DEAR(ルールの実行場所を改善)を組み合わせれば、上流に二重の防御が成立する。(Source: [[@2020__CLOUD__DEAR - Distributed Evaluation of Alerting Rules]], [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]], [[@2023__JCC__Filtering Alerts on Cloud Monitoring Systems]]) - **低重要度アラートの「調査準備」は第七の介入点として見える**: 池田の [[prepalert]] 実践は、Warning アラートを抑制・フィルタリング・集約・ランキング・RCA する前に、判断材料をアラートメモへ自動添付する。これは「発火前精度向上」や「発火後ノイズ削減」と異なり、低重要度アラートを残したまま週次振り返りの入力品質を上げる介入である。[[AlertRCA]] や ESRO のような「アラートのみで RCA」系統が後段で原因を推定するのに対し、prepalert は CloudWatch Logs Insights、S3 select、Redshift data API などからログ・メトリクスを先に集め、人間が初期判断するための文脈を作る。実務分類としては alert enrichment / investigation preparation を独立層として扱う価値がある。(Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]], [[@2024__CCGRID__AlertRCA - Causality Enhanced Graph Representation Learning for Alert-Based Root Cause Analysis]], [[@2023__arXiv__ESRO - Experience Assisted Service Reliability against Outages]]) - **Zadka のコストモデルは介入点の経済的優先順位付けに使える**: [[@2022__SREcon22 Americas__Modeling Alert Quality|Zadka SREcon22]] は「アラーティングの総コスト + 非アラーティングの総コスト = アンチクオリティ」という枠組みを提示した。本 concept が整理した 7+ 介入点（抑制/フィルタリング/集約/ランキング/RCA/監視評価/調査準備/社会的設計）のそれぞれが「どのコスト構成要素を減らすか」でマッピングできる。偽アラーム削減は抑制・フィルタリングの ROI、確認→診断区間の短縮は Runbook・enrichment の ROI、欠落アラーム削減はルール追加の ROI に対応する。Zadka が「Goodhart の法則」を理由に品質指標を業績目標にしないよう警告した点は、Alert Management のライフサイクル運用設計にも示唆を持つ。(Source: [[@2022__SREcon22 Americas__Modeling Alert Quality]], [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]]) - **「発火前の社会的設計」という第七の介入点 — Runbook と通知チャンネルの合意形成**: 既存の介入点はルール評価、抑制、フィルタリング、集約、ランキング、RCA のように技術処理を中心に分化してきた。Iwahori の SRE NEXT 2023 事例は、アラートを追加する段階で「どの通知チャンネルを使うか」「いつ対応すべきか」「どの範囲へ適用するか」「対応 Runbook はあるか」を必須検討にすることで、発火前にアラートの受け手と期待行動を合意する。この介入は、機械的な rule refinement よりさらに上流にあり、アラート疲れを「鳴った後のノイズ処理」ではなく「そもそも曖昧なアラートを追加しにくくする」設計で抑える。(Source: [[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - **KEEP/TUNE/DELETE の定期的な集団判定は「人間側のアラート衛生」介入点である**: [[@2023__SREcon23 Americas__Cognitive Apprenticeship in Practice with Alert Triage Hour of Power|Cruz SREcon23]] の Alert Triage Hour of Power では、40 分のアラート調査後に Driver が KEEP / TUNE / DELETE を勧告する。この介入は rule refinement（上流の自動改善）でも alert suppression（発火前の機械的抑制）でもなく、**人間が定期的にアラートの要否を判断し続ける社会的プロセス**である。3 年間でスパムアラート削減率は 0% だった一方、オンコール訓練と組織的学習に効果があった。これは技術的介入（抑制/フィルタリング/集約/ランキング/RCA）と並行して「**人間のアラート判断能力の育成**」という直交する軸が存在することを示す。[[認知的徒弟制]]の 6 段階を通じてトリアージスキルが伝達されることで、個々のエンジニアが将来の TUNE/DELETE 判断をより適切に行えるようになる——つまりこの実践は、短期的な件数削減でなく長期的なアラート文化の形成に寄与する介入である。(Source: [[@2023__SREcon23 Americas__Cognitive Apprenticeship in Practice with Alert Triage Hour of Power]]) - **「通知先ルーティング」は件数を変えずに宛先を変える独立の介入点**: [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That|Mineiro SREcon19 EMEA]] の [[Adaptive Paging]] は、症状ベースアラーティングのアラート件数（1 件）を維持したまま、トレースの `error=true` パスを再帰的に辿り最深の障害サービスの運用チームへ通知先を動的に変更する。既存の 7+ 介入点（抑制/フィルタリング/集約/ランキング/RCA/監視評価/調査準備/社会的設計）がアラートの**件数・重要度・内容・発火条件**を操作するのに対し、Adaptive Paging はアラートの**宛先**を操作する。これは「dispatch routing」として独立した介入点であり、他の介入点と直交する。クリスマスツリー効果（全サービスがアラートを発火し全チームが呼び出される現象）と症状所有チームへのアラート爆撃の両方を回避する点で、件数削減とは異なる角度からオンコール負荷を解決する。FSF（IEEE CLOUD 2022）が同型のスパンツリー動的因果推論を学術的に形式化する 3 年前に、Zalando が実運用で先行実装した事例でもある。(Source: [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]], [[Adaptive Paging]], [[@2022__IEEE CLOUD__Localizing and Explaining Faults in Microservices Using Distributed Tracing]]) - **ビジネス KPI の優先度定義を CMDB で一元管理する「ビジネスモニタリング」アプローチ**: Alibaba の GOC は CMDB [[Hammurabi]] に各事業部のビジネス機能と KPI を登録し、P1〜P4 の優先度を「ビジネスメトリクスの偏差率」で数値定義する（例: Taobao 注文件数 15% 以上減少 = P1）。アラームと CMDB の自動マッピングにより、障害発生時に**ビジネス影響の定量評価とエスカレーション先の特定を同時に完了**する。これは Yu+ JNCA2024 の alert determination（真偽判定 + 重要度ランキング + incident 抽出）を CMDB 側の事前定義で前倒しする設計であり、AlertGuardian の rule refinement とは補完的——AlertGuardian がルール自体を自動改善するのに対し、Hammurabi はルールが参照する**ビジネス優先度の構造**を一元管理する。2018 年時点の実装であり、その後 Alibaba がどう進化させたかは未追跡。(Source: [[@2018__SREcon18 Asia__Introduction to Alibaba Monitoring System]], [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]]) - **[[Prometheusルールリント]] — ルール健全性保証という第零の介入点**: [[@2022__Cloudflare-Blog__Monitoring-our-Monitoring|Cloudflare Blog 2022]] は、Prometheus の alerting rule / recording rule が**有効な PromQL であっても静かに機能しなくなる**問題を体系化した。メトリクス名のタイポ・廃止・ラベル変更・`rate()` 時間範囲不足のいずれも、Prometheus はエラーを出さず空の結果を返すだけで、「アラートが来ない」は「正常」か「壊れている」かを区別しない。[[Cloudflare]] が開発した [[pint]] は CI モード(変更ルールのみ検証・劣化の「挿入」防止)とデーモンモード(漸進的劣化の常時検出)の組み合わせでライフサイクル全体を網羅する。既存の 7+ 介入点（抑制/フィルタリング/集約/ランキング/RCA/監視評価/調査準備/社会的設計）がいずれも「アラートが発火するかしないか」を前提に介入するのに対し、Prometheusルールリントは**そもそもルールが正しく発火できる状態にあるか**を保証する上流介入である。AlertGuardian の rule refinement(ルール内容の改善)、DEAR(評価場所の改善)と並び、「**ルールが参照するメトリクスが存在しているか**」という三番目の上流次元を担当する。(Source: [[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]]) - **「症状ベースアラーティング」の実践は 2017 年の Cloudflare 事例で既に組織的に推進されていた**: [[@2017__SREcon17 Europe__Monitoring Cloudflare's Planet-Scale Edge Network|Bostock SREcon17 Europe]] は、「原因でなく症状にアラートする」「マシンでなくサービスにアラートする」を Cloudflare の監視設計原則として掲げ、すぐに対応不要な問題は JIRA チケットに送信してバックログ管理する運用を報告した。これは [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That|Mineiro SREcon19 EMEA]] の [[Adaptive Paging]]（症状ベースアラートの通知先を動的に変更）の 2 年前に、症状ベースの考え方が実運用に根付いていた事例である。さらに 5 年後の [[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]] で Cloudflare は「そもそもアラートルールが正しく発火しているか」を [[pint]] で保証する上流介入へ進んだ。2017 年の「症状ベース設計」→ 2022 年の「ルール健全性保証」という同一事業者内での 5 年間の進化は、アラート管理の介入点が「発火後のノイズ削減」から「発火前の品質保証」へ上流シフトしていく実例である。(Source: [[@2017__SREcon17 Europe__Monitoring Cloudflare's Planet-Scale Edge Network]], [[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]], [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]]) - **「モニタリング増設 = 安全」という心理的結合がアラートポリューションの根本原因**: [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices|Smith SREcon22]] は、インシデント対応として「問題があった——モニタリングを増やした」と報告する慣行が、モニタリングと安全の心理的結合を形成し、不要なアラートの削減に対する組織的抵抗を生むと指摘した。光害運動で「屋外照明の削減 = 治安悪化」という誤った連想が繰り返し提起されるのと同じ構造である。この心理的バイアスは、Tang+ NOMS2012 / Bhukar+ ICSE-SEIP2024 の「抑制」や AlertGuardian の「rule refinement」といった技術的介入の**採用障壁**として作用する——ツールが存在しても「アラートを減らすことへの恐怖」が導入を阻む。Yang+ DSN2022 のアンチパターン分類は技術的特性に基づくが、Smith が指摘した心理的抵抗は分類外であり、アラート管理の組織的側面として独立に扱う必要がある。(Source: [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]], [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]]) - **Baidu Argus の 4 施策同時投入（2017）は「介入点の直列合成」最初期の産業事例**: [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue|Chen SREcon17 Asia]] は、[[Argus (Baidu)|Argus]] で 1 人 100 件超/日・有効率 15% 未満のアラート洪水に対し、(1) リンガバッファによるシンプルグルーピング + アソシエーションルールマイニングによるクロスモジュールパターン発見 + ネットワーク接続性検知の 3 層グルーピング（[[アラート集約]]）、(2) アテンション率に基づく重要度キャリブレーション（4 段階: Critical/Major/Warning/Notice）、(3) 段階的オンコールエスカレーション、(4) アラートトリガの自動修復（ログパージ・プロセス再起動）を同時投入し **85% 削減**を達成した。これは Yu+ JNCA2024 の AIM 分類における alert correlation（施策 1）・alert determination（施策 2）・incident mitigation（施策 4）を横断した初期の産業統合事例である。特に「アテンション率」——夜間のアラート確認行動（監視 UI アクセスログ・本番マシンログイン）を監視し重要度を校正する——は、AlertRank（Zhao+ ISSRE2020）の Resolution Record によるラベル付与と同じ「エンジニアの実際の行動を観測して重要度を調整する」着想を 3 年先行している。また、自動修復が成功したアラートを配信しない設計は、Bhukar+ ICSE-SEIP2024 の動的抑制と介入点は異なるが「アラートを鳴らさない」結果において等価である。(Source: [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]]) - **「アラートバジェットによるインセンティブ設計」は技術的介入と直交する組織的介入であり、既存の全介入点の採用障壁を構造的に除去できる**: [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives|Jalleda SREcon17 Europe]] は、[[Zynga]] で月間 10 万件超のアラートに対し NOC 増員（1→13 名）やカラーコーディング等のツール対策が失敗した後、**Clean Room イニシアティブ**として「アラートバジェット超過チームの SRE サポート停止、遵守チームへのワールドクラス SRE サポート提供」というインセンティブ設計を導入し、偽アラーム 90% 削減・応答時間 5 分を達成した。これは Smith SREcon22 が指摘した「モニタリング削減への心理的抵抗」を、コスト構造の反転（アラートを減らさないことの方がコストが高い）で無効化する介入である。技術的介入（抑制/フィルタリング/集約/ランキング/RCA/監視評価/調査準備）と社会的設計（Runbook 合意・KEEP/TUNE/DELETE 判定・認知的徒弟制）に加え、**インセンティブ設計**が第三の介入軸として成立する。[[エラーバジェット]]が信頼性とベロシティのトレードオフを数値化するのと同構造で、アラートバジェットは「ノイズ許容量」を数値化して開発チームに所有権を移転する。(Source: [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]], [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]]) - **「アラート追加前の問い」は Runbook 合意とインセンティブ設計の前史である**: [[@2016__SREcon16__Less Alarming Alerts|Treat SREcon16]] は、各アラートに対してビジネス影響・修復手順・通知先・予防可能性を説明させ、答えられないものを削除・通知化・修正の対象にする。これは [[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか|Iwahori SRE NEXT 2023]] の Runbook/通知チャンネル合意や、[[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives|Jalleda SREcon17 Europe]] のアラートバジェットより前に、発火前の社会的設計を明示した実践である。Treat の焦点は件数削減アルゴリズムではなく、**「そもそも人を起こす権利を持つ通知か」を追加時点で問うこと**にある。(Source: [[@2016__SREcon16__Less Alarming Alerts]], [[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか]], [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]]) - **「症状へページし、原因は調査・チケットへ逃がす」分離は Prometheus 初期事例で明示されていた**: [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise|Rabenstein SREcon16 Europe]] は、分散システムでは原因と症状が緩く結合しているため、単一マシン停止・ロードアベレージ高騰・リソース高使用率のような原因候補へページするとノイズ化しやすいとする。一方で原因情報は不要ではなく、チケット・情報通知・調査用グラニュラリティとして保持する。これは [[@2017__SREcon17 Europe__Monitoring Cloudflare's Planet-Scale Edge Network|Cloudflare 2017]] の「原因でなく症状にアラートする」原則より 1 年早く、Prometheus の時系列アラーティングを背景に症状ベース設計を運用原則として定式化した事例である。(Source: [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]], [[@2017__SREcon17 Europe__Monitoring Cloudflare's Planet-Scale Edge Network]]) - **ページ用異常検知の上限は「単純・堅牢」に置かれ、複雑な自動因果推定とは用途を分ける**: Rabenstein SREcon16 Europe は、ページを生成する監視ルールは単純に理解でき、明確な失敗を表すべきで、「しきい値や因果を自動学習する魔法のシステム」はページ経路に向かないとする。これは 2024-2026 年の AIOps が alert correlation / RCA / autonomous handler へ進む流れと矛盾しない。むしろ介入点の分離であり、複雑な推定は原因調査・集約・ランキングに使い、ページ発火条件は単純で監査可能に保つという設計原則として読める。(Source: [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]], [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]) - **症状ベースアラーティングの ML ドメインへの転用は「出力から逆順に優先する」フレームワークを生んだ**: [[@2023__SREcon23 EMEA__Symptom-based Alerting for Machine Learning|Weichbrodt SREcon23 EMEA]] は、Rabenstein 2016 / Wilkinson 2017 の「症状へページし原因は調査に残す」原則を ML サービスに転用し、ML リクエストシーケンスの出力側（ユーザー影響）から入力側（特徴量データ）へ逆順に 3 段階の監視優先度を割り当てた。従来の ML 監視文献が入力データドリフトに偏重していたのに対し、出力分布監視を「キャッチオール手法」として Priority 2 に位置づけ、入力監視は根本原因分析用の Priority 3 に下げた。SRE の症状ベース設計が ML ドメインで「何をどの順で監視するか」の具体的な優先順位フレームワークに翻訳された初期の産業事例である。(Source: [[@2023__SREcon23 EMEA__Symptom-based Alerting for Machine Learning]], [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]], [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]]) - **しきい値削減は「静的値を賢くする」より「人間の対応時間とサービス目標へ変換する」方向へ進む**: [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale|Wilkinson SREcon17 Americas]] は、ディスク 90% や残り 500MB のような静的しきい値が容量差・ワークロード差で偽陽性を生むことを示し、満杯までの時間と人間の修復時間の比較へ問題を移す。さらにページングするアラートは SLO 違反を示し、ディスク満杯・タスククラッシュ・バックエンド遅延などの原因候補は診断情報としてコンソールに置くとする。Rabenstein 2016 の「症状へページし、原因は調査に残す」原則を、Prometheus の時系列・分布・記録ルールで実装する実践編と読める。(Source: [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]], [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]]) - **「顧客観測ベースの安全網アラート」という独立の検知シグナル源 — Klaxon の事後判定アプローチ**: [[@2018__SREcon18Asia__You Can't Stop Fires with an Ambulance|Chamberlain SREcon18 Asia]] の [[Klaxon]] は、CPU credit burn やロードバランサー最小ホスト数割れのような通常の症状ベースアラート(Rabenstein 2016 europe / Bostock 2017 と同系統のシステムメトリクス症状)に加えて、顧客向けエラーページ・ステータスページ(status.xero.com)へのアクセスヒット率を検知シグナルとして使う。既存の症状ベースアラーティングが「システムメトリクスの異常」を症状とするのに対し、Klaxon は「顧客が実際に障害ページを踏んだ」という**顧客行動そのもの**を症状とする点で異なる。事前設定アラートが捕捉し損ねた未知の障害モードでも顧客影響を検知できる「安全網」として機能し、検知結果を SumoLogic → DataDog ワークフロー経由で Slack 通知と status.xero.com のメンテナンスモード更新に直結させる自己修復的設計も持つ。7+ 介入点(抑制/フィルタリング/集約/ランキング/RCA/監視評価/調査準備/社会的設計)のいずれにも収まらない、**顧客観測を一次シグナルとする検知**という独立した切り口。(Source: [[@2018__SREcon18Asia__You Can't Stop Fires with an Ambulance]]) - **症状ベースアラーティングの非公式な起源文献としての Rob Ewaschuk「philosophy on alerting」**: [[@2018__SREcon18Asia__You Can't Stop Fires with an Ambulance|Chamberlain SREcon18 Asia]] は、[[Xero]] がクラウド移行後にアラートを症状ベースへ簡素化する際の参考として、Google SRE Book に先駆けて非公式に業界で回覧されていた Rob Ewaschuk の "philosophy on alerting" 論文を口頭で言及した(スライド上に書誌情報なし、原論文は本 wiki 未収録)。[[Björn Rabenstein]](SREcon16 Europe)・Bostock(SREcon17 Europe)・Wilkinson(SREcon17 Americas)がいずれも症状ベース原則を実務的に定式化した 2016-2017 年と同時期に、この非公式文書が実務者の間で広く参照されていたことを示す傍証であり、症状ベースアラーティングの系譜が単一の学術的起源ではなく実務コミュニティ内の口伝的知識としても伝播していたことを示唆する。(Source: [[@2018__SREcon18Asia__You Can't Stop Fires with an Ambulance]]) ## 未解決の問い - LLM 時代の AIM 研究(FLASH・LLexus・StepFly・AlertGuardian など 2024-2026)は Yu+ JNCA2024 の 8 プロセス分類(alert: correlation/storm/determination、incident: representation/linking/triage/mitigation/resolution)をどこまで保ったか? 計画フェーズ前置(LLexus)や TSG オーケストレーション(StepFly)は既存分類のどのセルにも収まらないように見える。 - alert determination 3 種の直列統合(Yu+ 2024 Fig.7)は実装事例があるか? AlertRank・eWarn・Warden 個別研究はあるが、distinguish → ranking + incident identification の 3 段一括の本番運用報告は本サーベイ提示時点で未確認。 - "storm 検知 + 3 段要約"(Zhao+ AAAI2020)は streaming 解析と triggered 解析の併用というサーベイの将来方向に進んだか? AlertGuardian の denoise が streaming 寄りに見える一方、storm 専用の triggered パスは引き続き手薄。 - alert correlation の hybrid 系(OAS など)が要求する大量ラベル付きデータの取得問題は、LLM による weak supervision で緩和できるか? - alert と incident を分離する設計(Yu+ 2024)と Microsoft の合一設計(Chen+ 2020a-c など)の優劣を、同一データセット上で実証比較した研究はまだない。 - [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]] の 6 カテゴリ taxonomy(by design / customer error / won't fix / unable to reproduce / transient / false alarm)は「下流での判別」を前提に設計されている。同じカテゴリを「上流のルール設計」に翻訳すると(例: false alarm → monitor の閾値・周期見直し、transient → リトライ・自動回復許容窓設計、unable to reproduce → 観測解像度不足)、上流介入の設計指針として AlertGuardian の rule refinement に直接組み込めるか。 - Yang+ DSN2022 の 6 アンチパターン分類は Huawei Cloud のみで導出された。Microsoft 系・Google 系・AWS 系の本番運用に同じ分類を適用したとき、Repeating Alerts と Cascading Alerts の比率や、Misleading Severity の頻度は事業者ごとにどの程度変動するか? 経験的研究の事業者間比較が手薄。 - QoA(indicativeness・precision・handleability)を OCE のドメイン知識から機械学習でラベル化するというYang+ 2022 の将来像は、その後 LLM 系の AlertGuardian・LogPilot 等で部分的に実装されたか? 3 軸のうち「handleability」(目標と呈示の双方に依存する)は、ルールベース対処では捕捉しにくく LLM の出番が大きいはず。 - 5 介入点(抑制 / フィルタリング / 集約 / ランキング / RCA)を統合した本番システムは未報告。各介入点の研究は個別に高度化しているが、それらを直列に並べた end-to-end パイプラインで本番運用された事例の文献的痕跡が薄い。 - alert-based RCA(AlertRCA・ESRO)が「アラートだけで原因特定」を達成したことで、トレース・メトリクスを取り続ける必要性は減るか? それともむしろアラート品質の上流改善(rule refinement・抑制)の方が ROI が高いか? 両アプローチの経済性比較が未着手。 - Tang+ NOMS2012 の「チケット遅延 → 一過性自然消滅」と Bhukar+ ICSE-SEIP2024 の「動的抑制ポリシー」は同じ「発火を遅延・抑制」介入だが、Tang+ は SLA 上限を遵守する数学保証、Bhukar+ は経験的近似。両者を 6 介入点の最上流(発火前 = 抑制 / 評価場所移動)で組み合わせた本番システムは未報告。 - アラートランキング 3 ルーツ(Jiang+ ICAC2009 不変条件 / CAR CIKM2018 統一最適化 / AlertRank ISSRE2020 教師あり ML)を直列パイプラインで結合した本番運用事例の文献的痕跡が皆無。「教師なしで候補を絞り教師ありで精選」型の経済性測定は未着手。 - DEAR が示した「監視評価インフラ層」での介入は、AlertGuardian の rule refinement(ルール内容)と直交する。両者を上流に積層した「監視ルール × 評価場所 × 抑制」の 3 重防御は理論上可能だが、実装事例なし。各層の精度寄与の分解可能性も未検証。 - 低重要度アラートの調査準備を自動化する enrichment 層は、既存の AIM 分類でどの段に置くべきか。抑制・フィルタリング・集約のように件数を減らす介入ではなく、人間の判断材料を増やす介入として別カテゴリ化すべきか。 - Runbook と通知チャンネル選択のガイドラインをアラート管理ライフサイクルに入れる場合、これは alert determination の前処理なのか、rule refinement のさらに上流の governance なのか。アラート管理研究の taxonomy は、こうした組織的合意形成をまだ十分に分類できていない。 - Jalleda のアラートバジェット（2013 年頃、Zynga）と Google の[[エラーバジェット]]（2016 年 SRE Book）はバジェットメタファーの構造を共有するが、アラートバジェットの数値設定（シフトあたり何件が妥当か、バーンレートはどう定義するか）の設計パターンを体系化した後続研究は確認できていない。 - [[Klaxon]] のような「顧客向けページのアクセスヒット率を検知シグナルとする」安全網アラートは、他社でどの程度採用されているか。システムメトリクス症状ベースの実践報告(Rabenstein・Bostock・Wilkinson)に比べ、顧客観測を一次シグナルとする実践報告は本 wiki 内で他に確認できていない。 ## 関連 - 上流: [[テレメトリ]]・[[オブザーバビリティ]](monitoring system が生成) - 下流: [[インシデント管理]](severe alert + user complaint → incident) - 横並び: [[AIOps]](AIM は failure management のサブセット) - 自動評価軸: [[Quality of Alerts]](indicativeness・precision・handleability、Yang+ DSN2022 の将来方向) - ソース: [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]]、[[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]]、[[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]]、[[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]]、[[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]]、[[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか]] - 親サーベイ: [[@2021__TIST__A Survey of AIOps Methods for Failure Management]]