# アラート疲労 ## 定義 アラート疲労(alert fatigue)は、大量のアラート（特に偽陽性や低品質なもの）に繰り返し曝されることでオペレータの応答性が低下し、重要なアラートへの対応が遅延または見落とされる状態を指す。[[Kishore Jalleda]] は SREcon17 Europe で ICU（集中治療室）のモニタリング過剰をアナロジーとして提示した—— ECG モニターアラームの 72〜99% が偽またはクリニカルに無意味であり、2010 年にマサチューセッツ州の病院で患者死亡事故が発生、ECRI Top 10 Health Technology Hazards には 2007 年以降毎年リストされている。IT 運用でも同じ構造的問題が発生し、Zynga では月間 10 万件超のアラートに対してヘッドカウント追加（NOC 1→13 名）が追いつかなかった。(Source: [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]]) ## 横断的知見 - **アラート疲労と[[アラートポリューション]]は同一問題の裏表だが介入点が異なる**: Jalleda SREcon17 はアラート疲労をオペレータ側の応答劣化として扱い、インセンティブ設計（アラートバジェット + SRE サポート停止）で**アラートの送り手**を制御した。一方 [[Kristin Smith]] SREcon22 はアラートポリューション（信号対雑音比の低下）として扱い、オブザーバビリティへの移行で**受信チャネル自体**を再設計した。両者は「ノイズ削減」という同じ目標に、それぞれ「送り手のインセンティブ」と「受け手の観測手段」から迫る補完的アプローチ。Smith が「モニタリング増設 = 安全」の心理的結合を抵抗の根源と指摘したのに対し、Jalleda はその心理的抵抗をインセンティブ構造で構造的に無効化した（バジェット超過 → SRE サポート喪失のコストが心理的抵抗を上回る）。(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]]) - **技術的介入の 4 施策同時投入（Baidu 2017）は、アラート疲労に対する最初期の体系的産業対応**: [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue|Chen SREcon17 Asia]] は、[[Argus (Baidu)|Argus]] で 1 人 100 件超/日・有効率 15% 未満という定量的なアラート疲労状態を示し、アラートグルーピング・重要度キャリブレーション・オンコールエスカレーション・自動修復の 4 施策で **85% 削減**を達成した。Jalleda SREcon17 Europe（同年）がインセンティブ設計で 90% 削減を達成したのと対照的に、Chen は純粋に技術的介入の組み合わせで同等の削減率を示した。両者を並べると、同じ 2017 年の同じ SREcon シリーズで、アラート疲労に対するインセンティブ設計アプローチ（Jalleda/Zynga）と技術的介入アプローチ（Chen/Baidu）が独立に報告されたことになる。特に Chen の「アテンション率」（エンジニアがアラートを実際に確認したかを監視ログで測定し、重要度キャリブレーションに使う）は、疲労の定量計測に基づく校正という点でユニーク。(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]]) - **組織的介入（インセンティブ・文化）と技術的介入（自動化・ML）は並行して進化してきたが統合事例が少ない**: Jalleda の Clean Room イニシアティブ（2013 年頃）はアラートバジェットという組織的介入で 90% 削減を達成し、同時期以降の技術的介入（AlertGuardian の rule refinement、Bhukar+ の動的抑制、Adaptive Paging の通知先ルーティング）は自動化で介入する。[[Cruz SREcon23]] の Alert Triage Hour of Power は「人間のアラート判断能力の育成」というさらに別の介入軸である。3 つのアプローチ（インセンティブ設計 / 技術的自動化 / 人間の能力育成）を統合的に運用した事例報告は薄い。(Source: [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]], [[@2023__SREcon23 Americas__Cognitive Apprenticeship in Practice with Alert Triage Hour of Power]], [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]]) - **偽陽性が応答性を壊すという行動モデルは 2016 年時点で明確に提示されていた**: [[@2016__SREcon16__Less Alarming Alerts|Treat SREcon16]] は、無視したアラートや人間の行動を必要としなかったアラートを問い、過剰な偽陽性がアラーム無視につながると述べる。医療 ICU、車の警報、虚偽緊急通報、航空管制の偽警報研究を並べ、これは IT 運用固有ではなく「泣いた狼」型の汎用的な注意劣化であると位置づける。Jalleda/Baidu の 2017 年事例が定量削減を示す前に、Treat は疲労の発生機構を「アクションできないページが多すぎると反応しなくなる」として表現していた。(Source: [[@2016__SREcon16__Less Alarming Alerts]], [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]], [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]]) ## 未解決の問い - Jalleda の「アラートバジェット」と Google SRE Book の「[[エラーバジェット]]」の構造的類似性は指摘できるが、アラートバジェットの数値設定基準や消費計測方法の詳細は本発表では開示されていない。アラートバジェットの具体的な設計パターンを体系化した後続研究はあるか。 - Clean Room のインセンティブ設計は SRE サポートという「報酬の撤回」に依存するが、SRE チームが存在しない組織や SRE の位置づけが異なる組織ではどのような代替インセンティブが機能するか。 - 医療分野のアラート疲労研究（ECRI、Joint Commission）と IT 運用のアラート疲労研究は、Jalleda が冒頭でアナロジーとして引いた以上に交差しているか。医療の MAUDE データベース等に蓄積された知見の IT 転用可能性。 ## 関連 - [[アラート管理]] — アラート疲労は管理の失敗状態。介入点の分類で対処方法が整理される。 - [[アラートポリューション]] — 同一問題の裏表。ポリューション = 信号対雑音比の低下、疲労 = オペレータ側の応答劣化。 - [[アクショナブルアラート]] — アラート疲労の根本対策として「アクションに値するアラートだけを鳴らす」設計。 - [[Quality of Alerts]] — QoA の低下がアラート疲労を誘発する因果構造。 - [[エラーバジェット]] — アラートバジェットはエラーバジェットの構造的アナロジー。 ## 出典 - [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]] - [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]]