# アラート抑制 ## 定義 アラート抑制(Alert Suppression)は、生成されたアラートのうち SRE/OCE が確認する前に「ノイズ」と判定して通知から除外する機構。代表形式は **X-out-of-Y ポリシー**(直近 Y サンプル中 X 個が閾値超過したらアラート発火)で、X・Y を静的に固定する静的版と、メトリクス・マイクロサービスごとに適応的に学習する動的版がある([[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps|Bhukar+ ICSE-SEIP2024]] §1, §2)。 抑制はアラート管理の上流(発火前)で働き、[[アラートフィルタリング]](発火後にユーザー反応で取捨選択)、[[アラート集約]](発火後に複数アラートをクラスタリング)とは介入点が異なる。([[アラート管理]] の rule refinement の一形態)。 ## 横断的知見 - **「静的ポリシーはドメインをまたいで汎化しない」が共通観察**: [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps|Bhukar+ 2024]] は、メトリクスデータ(平均 21 イベント/持続領域)に最適化された Static-X-Y(X=2, Y=5)が、ログデータ(平均 2691 イベント/持続領域)では No-Suppression と同等に劣化したと報告(§4.1)。逆も同様で、ログ最適 X=6 はメトリクスで誤抑制を生む。動的学習(Dynamic-X-Y)が必要なのは「単一ドメインの最適値が他ドメインで通用しない」という構造的事実に根差している。[[@2023__JCC__Filtering Alerts on Cloud Monitoring Systems|Voutsas+ 2023]] が示した「クラウドモニタリング(Netdata)では 4,000 メトリクス・80〜100 種アラートが日常で、本番では 10,000〜20,000 メトリクス・数百種に達する」という事業者間の規模差(§I)は、Bhukar+ 2024 の知見を強化する: 単一ハイパーパラメータの転移可能性は元から低い。(Source: [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]] §4.1, [[@2023__JCC__Filtering Alerts on Cloud Monitoring Systems]] §I) - **教師なし設定で「上界(教師あり最適)」に到達できるという反直感的発見**: [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps|Bhukar+ 2024]] は、教師なし統計手法(移動平均エンベロープ)で学習した X・Y が、教師あり設定(ブルートフォース最適探索)の最適値とほぼ一致したと報告(§4.2)。これは [[@2023__JCC__Filtering Alerts on Cloud Monitoring Systems|Voutsas+ 2023]] が「ユーザーのクリック行動を弱教師信号として使う」という別系統の弱教師アプローチと対比できる: Bhukar は教師信号を一切使わず統計構造のみで上界に達したのに対し、Voutsas は OCE のクリックを暗黙ラベルとして使う。両者は「ラベルなし/弱ラベル運用」という制約下で抑制ポリシーをどう確定するかという同じ問題に対して、統計ベース vs インタラクションベースという別系統の解を提示している。(Source: [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]] §4.2, [[@2023__JCC__Filtering Alerts on Cloud Monitoring Systems]] §III) - **アラートアンチパターン A4 Transient Alerts の直接対処として位置付くこと**: [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems|Yang+ DSN2022]] が A4 Transient and Toggling Alerts(短時間で自動解除される/振動する)を集合アンチパターンの 1 つとして挙げ、Avoidance ガイドラインに「適切な resolve 時間と通知遅延を設定」と書いた。[[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps|Bhukar+ 2024]] の Dynamic-X-Y はこの「通知遅延」を自動最適化する具体実装で、Industrial case study(TcpRetrans メトリクス)で No-Suppression 比 61.53% のノイズ削減を達成(§5.2)。「アンチパターンの自動緩和」の代表事例として QoA(Quality of Alerts)の precision 軸を直接改善する。(Source: [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]] A4, [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]] §5.2) - **IBM 系研究 12 年の遷移**: [[@2012__NOMS__Optimizing System Monitoring Configurations for Non-Actionable Alerts|Tang+ NOMS2012]] は IBM Tivoli 本番でオフライン静的「ルール条件 + 最適遅延時間」を月次バッチ deploy し、リアルチケット見逃しゼロ(Theorem 1)を数学保証しつつ非アクション可能を最大 75% 削減。12 年後の [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps|Bhukar+ ICSE-SEIP2024]] は同 IBM Research が動的オンライン教師なし統計学習で抑制ポリシーを各メトリクス・サービスに個別学習。保証様式が「数学的存在保証」から「経験的近似保証」へ、deploy 周期がバッチから online へ進化した。(Source: [[@2012__NOMS__Optimizing System Monitoring Configurations for Non-Actionable Alerts]] Theorem 1, [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]] §4) - **「チケット遅延 → 一過性アラート自然消滅」設計は SLA 上限制約付きの新パラダイム**: Tang+ NOMS2012 は「アラートを真偽分類するのではなく SLA の許す範囲で遅延 → 一過性は自然消滅、リアルは通常通り発火」という設計転換を行った。SLA 上限を遵守する数学保証(Theorem 1: P(損失) → 0)は Bhukar+ 2024 の経験的近似抑制とは別系統の保証アプローチ。(Source: [[@2012__NOMS__Optimizing System Monitoring Configurations for Non-Actionable Alerts]] §3, [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]] §2) ## 未解決の問い - 抑制の評価は通常「ノイズ削減率」だが、見逃しアラート(false negative)の評価が薄い。[[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps|Bhukar+ 2024]] は industrial case study で「OCE が確認すべきイベント数も削減した」と定性報告するが、見逃した真のインシデントの数値は提示されていない。 - 動的ポリシー学習は「正常状態のデータだけで」走るが、低頻度・高重大度のアラート(例: SSD voltage 低下、年に数回)に対しては学習データそのものが少ない。希少アラートを抑制対象に含めると見逃しリスクが高くなる。Bhukar+ 2024 は希少クラスへの対応を明示していない。 - [[@2023__JCC__Filtering Alerts on Cloud Monitoring Systems|Voutsas+ 2023]] のクリック行動ベースフィルタは、OCE が「クリックする」=「重要」と仮定するが、現場では誤クリック・アラート疲れによる無視・別タブで開きっぱなしなど、クリック信号のノイズが大きい。教師なし統計(Bhukar)と弱教師インタラクション(Voutsas)を組み合わせるアーキテクチャは未提案。 - 抑制は発火前介入で、[[アラート集約]] は発火後介入。両者を同時に適用するときの順序や重み付けの設計指針は未確立。 - Tang+ 2012 の SLA 制約付き遅延と Bhukar+ 2024 の動的抑制ポリシーを直列化した本番運用報告がない。両者の保証様式(数学保証 vs 経験近似)を組み合わせた多層抑制設計の研究余地。 ## 関連 - 親概念: [[アラート管理]](alert correlation と独立の上流介入) - 兄弟: [[アラートフィルタリング]](発火後にユーザー反応で取捨選択)、[[アラート集約]](発火後にクラスタリング) - 関連アンチパターン: [[アラートアンチパターン]] の A4 Transient and Toggling Alerts - 評価軸: [[Quality of Alerts]] の precision(誤発火を減らす) - ソース: [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]]、[[@2023__JCC__Filtering Alerts on Cloud Monitoring Systems]] ## 出典 - [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]] §2(ASP 定義)、§4(教師なし学習)、§5(industrial case) - [[@2023__JCC__Filtering Alerts on Cloud Monitoring Systems]] §I(クラウドモニタリング規模)、§III(クリックベースフィルタ)