# Draining the Flood — A Combat against Alert Fatigue Navigation: [[アラート管理]] | [[アラート疲労]] | [[アラート集約]] ## 概要 [[Yu Chen (Baidu)]]（[[Baidu]] SRE チームデータアーキテクト）が SREcon17 Asia（2017 年 6 月、シンガポール）で発表したスライド資料。Baidu の監視システム [[Argus (Baidu)|Argus]] が生成する大量のアラート——1 人あたり 1 日 100 件超、有効率 15% 未満——に対し、アラートグルーピング・重要度キャリブレーション・オンコールエスカレーション・自動修復の 4 施策を組み合わせて **85% 削減**を達成した実践報告である。 ## 主要メッセージ ### 問題の定量的把握（p.2） - 1 人 1 日あたり 100 件超のアラート SMS（日中 75%/17 時間、夜間 25%/7 時間） - 有効アラート率: `#effective alerts / #alert SMS < 0.15`（85% 以上が冗長） - 重大障害時にアラートが殺到し、エンジニアの問題特定を妨げる ### 観察と対策の対応（p.3） ![[_attachments/srecon17asia-chen-draining-the-flood/page-003.png]] 4 つの観察と対応する施策を整理した表。重複率 58%・夜間アテンション率 25%・受信者平均 3 名・単一インスタンスアラート 88% の 4 指標から、アラートグルーピング・重要度キャリブレーション・オンコールエスカレーション・自動修復の 4 施策を導出。 | 観察 | 数値 | 原因 | 施策 | |---|---|---|---| | 重複率 | 58% | 持続的・相関アラート | アラートグルーピング | | アテンション率 | 25%（夜間） | 重要度設定の過剰 | 重要度キャリブレーション | | 受信者数 | 3 名/アラート | 非効率なオンコール手順 | オンコールエスカレーション | | 単一インスタンスアラート | 88% | 40% 超は単純操作で復旧可 | 自動修復 | ### アラートグルーピング（p.4–p.9） 3 層のグルーピング戦略: **1. シンプルグルーピング**（p.5–p.7）: デプロイ構造の自然な次元（アラートルール名・プロダクト・モジュール・クラスタ・インスタンス・データセンター・マシン）でグルーピング。**リンガバッファ**を介して同一ルールのアラートを集約し、設定可能なリンガタイムで一括配信する。 ![[_attachments/srecon17asia-chen-draining-the-flood/page-007.png]] リンガバッファの動作: Alert Source からアラートが到着すると、同一ルール・同一モジュールのアラートをリンガタイム内でバッファリングし、まとめて 1 通として配信する。 **2. クロスモジュールパターン**（p.8）: 呼び出し元/呼び出し先の関係を利用し、アソシエーションルールマイニングでモジュール間の相関パターン（`M:ruleX → N:ruleY`）を発見する。各アラートを起点にトランザクションウィンドウを切り、頻出パターンを抽出。 ![[_attachments/srecon17asia-chen-draining-the-flood/page-008.png]] Caller/Callee 関係に基づくアソシエーションルールマイニング。時間ウィンドウ内のアラート共起からクロスモジュールルールを学習する。 **3. ネットワーク接続性検知**（p.9）: ネットワークデバイス障害は大量のアラートを発生させる。ヒューリスティックルールとして $\text{score} = \sqrt{\frac{\text{alerting rules}}{\text{total rules}} \times \frac{\text{alerting products}}{\text{total products}}}$ で異常スコアを計算し、閾値超過時にアラートサージを抑制する。 ![[_attachments/srecon17asia-chen-draining-the-flood/page-009.png]] ネットワーク接続性スコアの時系列グラフ。スパイクがデータセンターレベルの障害を示す。 ### 重要度キャリブレーション（p.11–p.12） **アテンション率**の概念を導入: アラート送信後の時間区間 $[t_{\text{alert}}, t_{\text{alert}} + t_{\Delta}]$ 内に監視システムのアクセスログ（アラート詳細閲覧・関連グラフ閲覧）や本番マシンのログインログが存在すれば「確認済み」、存在しなければ「無視」と判定する。夜間のみ適用。 4 段階の重要度レベル: - **Critical**: SMS + 全受信者への電話 - **Major**: SMS + エスカレーション - **Warning**: SMS（エスカレーションなし） - **Notice**: メールのみ アテンション率が重要度レベルと整合しない場合はレベルを引き下げ、マネジメント層からの圧力でキャリブレーションを推進する。 ### オンコールエスカレーション（p.13–p.15） 一般的な受信者構成（プライマリ・セカンダリ・リード・シニアエンジニア・マネージャ）に対し、段階的エスカレーションを導入。固定ステージ（プライマリ/セカンダリ）→ 一定時間未対応で次のエスカレーションステージへ移行する。未確認時間・未解決時間・電話有無をステージごとに設定。 ### 自動修復（p.16） 単一インスタンスアラートの 40% 超が単純操作で復旧可能であるため、アラートトリガで自動修復を実行する: - **Lazy ログパージ**: ディスク空き容量アラートでログを自動削除 - **インスタンスレベル**: `bin_control restart` - **モジュール/クラスタレベル**: `curl master.a.com` 自動修復が実行されたアラートは配信されず、アラートログでのみ確認可能。JSON 設定で `cb_action`（実行スクリプト）と `callback`（結果通知先）を定義する。 ### マネジメントサポート（p.17） 技術的施策だけでなく、マネジメント層の支援が不可欠: - 重要度レベルの引き下げを推進 - アテンション率をオンコール業務評価に組み込む ## 視覚的に重要な図表 **p.18 アラート量の推移グラフ** ![[_attachments/srecon17asia-chen-draining-the-flood/page-018.png]] 2015 年 1 月〜2016 年 11 月の週次アラート数（Total/DayTime/Night の 3 線）。2015 年 5〜7 月頃（グレー帯）の施策投入でアラート量が急減し、以降 **85% 削減**を維持。夜間アラートは特に低水準を保つ。 ## 概念・実体への接続 - [[アラート疲労]] — 1 人 100 件超/日が本発表の出発点。85% 削減は組織的な疲労軽減の定量事例。 - [[アラート集約]] — リンガバッファによるシンプルグルーピングは、後続研究（COLA・DyAlert・ProAlert）が自動化するものの最も原始的な産業実装。 - [[アラート相関]] — クロスモジュールパターンのアソシエーションルールマイニングは attribute-based correlation の初期事例。 - [[アラート管理]] — 4 施策の組み合わせが Yu+ JNCA2024 の AIM アーキテクチャの各段に対応する。 - [[自動修復]] — アラートトリガの自動修復で配信自体を抑制する設計。 - [[Argus (Baidu)]] — Baidu の内製監視システム。 ## 限界・不確実点 - `date_published` は SREcon17 Asia の開催時期から 2017-06 と推定。USENIX 公式ページの日付表示と会議命名に不整合があり、正確な開催日は未確定（`confidence: high` はスライド内容に対して）。 - transcript なし。口頭説明・デモ・質疑の内容は未取得。 - p.3 の表中の数値（重複率 58%・アテンション率 25%・受信者 3 名・単一インスタンス 88%）はスライド画像で確認済みだが、測定期間・対象サービス範囲の詳細はスライドに記載なし。 - p.8 のアソシエーションルールマイニングの具体的パラメータ（最小支持度・信頼度閾値）は不明。 - p.9 のネットワーク接続性スコアの閾値設定方法は不明。 - p.18 のグラフのグレー帯の正確な施策投入タイミング・順序は不明。 - 85% 削減の内訳（4 施策それぞれの寄与率）は開示されていない。