# アラート疲労 ## 定義 アラート疲労(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]]) - **ML 監視における入力データドリフトアラートは IT 運用のアラート疲労と同一構造の問題を再現する**: [[@2023__SREcon23 EMEA__Symptom-based Alerting for Machine Learning|Weichbrodt SREcon23 EMEA]] は、ある金融会社のデータサイエンティストが ML オブザーバビリティツール導入後「入力フィールドの分布変化アラートが週に複数届くが、上流のビジネス変更か自然変動か分からず一切対処しなかった」と報告した事例を紹介する。これは Jalleda/Zynga の IT 運用アラート疲労（月間 10 万件超、有効率不明）と構造が同一——大量の低信頼アラートに曝され応答性が低下する——だが、ML 固有の要因として (a) 入力データの自然変動が大きく偽陽性率が高い、(b) データサイエンティストがオンコール文化を持たない、(c) データ品質問題の修正責任がデータ所有チームにあり優先順位が低い、という 3 点が重なる。Weichbrodt の対処方針は「入力監視を Priority 3 に下げ、出力分布監視を優先する」ことで実質的にアラート総数を絞るもので、Chen/Baidu の技術的削減ともJalleda のインセンティブ設計とも異なる「**監視対象の優先順位付けによるノイズ回避**」という第四の介入軸を示す。(Source: [[@2023__SREcon23 EMEA__Symptom-based Alerting for Machine Learning]], [[@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]]) - **2026 年時点の産業統計はアラート疲労が「AI 統合後も改善していない」ことを示す**: [[Eddie Redick]] が SREcon26 Americas（2026-03-25）で引用した産業調査(AI SOC Market 2025, Ponemon/Databahn)によると、組織平均アラート数は **960+/日**、大企業では **3,000+/日**、**30% が未調査のまま消える**。さらに 2026 SRE Report では Toil が 5 年ぶりに増加し、中央値 34% の業務時間が Toil に費やされ、70% がオンコールストレスによる燃え尽きを経験している。重要な視点は Redick が「アラート疲労は**アラート量を減らす**のではなく、**入力（シグナル品質）を修正する**システム問題」と再フレーミングした点で、Jalleda/Baidu の「削減」アプローチに対する質的な転換を提示する。AI が増やすのはアラート判断のスループットではなく、未調査のまま消えるアラートの「許容度」かもしれないという懸念が背景にある。(Source: [[@2026__SREcon26Americas__Human Factors in the Age of AI Ops]]) - **アラーム疲労は 2,600 年前のイソップ寓話に起源を持つ汎用問題であり、ユーザー視点の単一 SLI への集約が IT 運用での解法となった**: [[Alex Hidalgo]] は SREcon19 EMEA で「None of this is new」として歴史的文脈を示した——アラーム疲労はヘルスケア・鉱業・建設・原子力産業で研究が蓄積され、イソップ寓話「嘘をついた少年」（約 2,600 年前）にも見出せる「泣いた狼」問題だと述べる。Squarespace ELK スタックでは Logstash プロセス・Logstash-to-Kafka 接続・Logstash-to-Elasticsearch 接続・スループット・Elasticsearch プロセス・Elasticsearch クラスタブロックの 6 種アラートが「ノイジー・既知の未知だけ・ユーザー視点なし」という 3 欠点を持っていた。これを「Kafka 積み残し数 ÷ Logstash 処理レート = エンドツーエンドレイテンシ（秒）」という単一 SLI に集約することで、ユーザー体験の悪化を直接捉える 1 つのアラートに置き換えた。Jalleda SREcon17 のインセンティブ設計・Chen SREcon17 の技術的削減と並ぶ第三の軸として「**多数コンポーネント監視→単一ユーザー体験 SLI への置換**」を示す事例。(Source: [[@2019__SREcon19EMEA__How to SRE When Everything is Already on Fire]]) - **オンプレ由来アラートルールのクラウド流用がアラート疲労の定番構造的原因である**: [[Sohei Iwahori]] SRE NEXT 2020 は、[[GREE, Inc]] が 2015 年のオンプレ→AWS 移行時にアラートルールをそのまま踏襲した結果、2018/09 に月 300 件超のオンコールアラートがピークに達した事例を示す。根本原因はオートスケーリングによる台数調整の激しさ・スケールイン/アウト時の一時的事象であり、オンプレ環境では想定外だった「一時的なしきい値超過」が高頻度で発生した。この結果「静観」（復旧アクション不要で事象が収まる）対応が主流になり、ページャーへの応答が形骸化した。SRE Book Chapter 6 の「Every time the pager goes off, I should be able to react with a sense of urgency. I can only react with a sense of urgency a few times a day before I become fatigued.」という引用がこの問題意識の動機として示される。クラウドへの移行が大規模アラート疲労を誘発することは Baidu（技術的介入、Chen SREcon17 Asia）でも報告されており、移行期のアラートルール見直しが必要であることが独立に確認される。(Source: [[@2020__SRENext2020__Practices for Making Alerts Actionable]], [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]]) - **マルチウィンドウ・マルチバーンレートアラートは非同期パイプラインにおけるアラート疲労の実践的な解法として提示された**: [[Gabriela Medvetska]] は SREcon25 Americas で自身の受信箱（Metric Alerts 1936 件・Maintenance Alerts 13,108 件）を示し、eBay での過剰アラートを実例化した。対処として Google SRE Workbook のマルチウィンドウアラート設計を非同期パイプラインに適用し、Critical（1h+5m/6h+30m）と Warning（1d+2h/3d+6h）の 4 レベルでバーンレートとウィンドウを明確に分離することで「過剰アラートと検知漏れのバランス」を取った。これは Jalleda の「インセンティブでアラートバジェットを設定する」という組織的アプローチとは異なり、**アラート条件自体を時間ウィンドウ対比で精密設計する**技術的アプローチとして分類できる。(Source: [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]], [[@2018__Google SRE Workbook__Alerting on SLOs]]) - **「オオカミ少年アラート問題」は SRE の実践者が工学的未解決課題として明示的に位置づけた**: [[Yuuki Tsubouchi]] は SRE NEXT 2024「工学としての SRE 再訪」において、アラート疲労の典型症状である「誤検知が多く対応者がアラートを無視するようになる現象」を**6 つの SRE オープンチャレンジの 1 つ**として提示した。SREcon コミュニティが 2016〜2026 年にわたって多様な技術・組織的解決策を報告してきた一方で、SRE の実践コミュニティでは 2024 年時点でも「解決済み」とは認識されていないことを意味する。学術的・産業的な知識が蓄積されているにもかかわらず、個々の組織内での適用・定着が依然として難題であることが示唆される。(Source: [[@2024__yuuk.io__SRE-NEXT-2024]], [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]], [[@2026__SREcon26Americas__Human Factors in the Age of AI Ops]]) - **最小限の技術変更+コミュニケーション過剰投資+定量的バイイン可視化の組み合わせは、「統合事例が薄い」という既存の観察に対する具体的な反例を提供する**: [[Tony Lykke]] (Hudson River Trading) はSREcon19 Americasで、高urgencyページを6年間の71,317件から4か月で1,015件へ削減した事例を報告した。技術的変更はMaster NagiosとPagerDutyの間にdrop/downgrade/groupフィルタ層を追加するだけに留め、「9 Really Hard Steps」の大半をオーディエンス理解・許可取得・コミュニケーションという組織的プロセスに割いた。さらに`git shortlog`によるコミット貢献の推移(懐疑的だった同僚が5コミットから765コミットへ転じた)を提示し、心理的バイインの変化を定量指標で裏付けた。インセンティブ設計([[Kishore Jalleda]])と技術的介入([[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue|Chen]])が「統合事例が薄い」と評されていたのに対し、Lykkeの事例は両者を意図的に組み合わせ、かつ組織的バイインを可視化した点で独自である。(Source: [[@2019__SREcon19 Americas__Fixing On-Call When Nobody Thinks It's (Too) Broken]], [[@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]]) - **アラート削減自体が「沈黙への不安」という新たな心理的抵抗を生むことがあり、これは Smith の「モニタリング増設 = 安全」の心理的結合と対をなす**: [[@2019__SREcon19 Americas__Fixing On-Call When Nobody Thinks It's (Too) Broken|Lykke]] は、ページ数を一晩でほぼ半減させた際、チームが安堵するのではなく不安になったと報告する。理由は「ページャーからの沈黙は歴史的に監視スタック自体が壊れている兆候だった」という連想であり、単なる「モニタリングを増やすほど安全」という信念の裏返しとして、モニタリングを減らすと「壊れているのに気づけていない」という不安を生む。Lykkeはこれを、サイレンス・ダウングレード処理を自動投稿するミュート可能なSlackログチャンネルで緩和した——鳴らないことと「何も起きていないこと」を区別できる受動的可視性を提供する解決策であり、[[Kristin Smith]] のオブザーバビリティ再設計([[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]])とは異なる角度から同じ心理的抵抗に対処した事例と言える。(Source: [[@2019__SREcon19 Americas__Fixing On-Call When Nobody Thinks It's (Too) Broken]], [[@2022__SREcon22 Americas__Dark Sky Camping - Reducing Alert Pollution with Modern Observability Practices]]) - **[[Mark Burgess]] の「タイムスケール分離」原則は、アラート疲労の産業的解決策群がすべて共有する暗黙の前提——「アラート量を絞れば解決する」——のさらに一段上流にある構造的原因を指摘する**: 本 concept に蓄積された事例(Jalleda/Zynga のインセンティブ設計、Chen/Baidu の技術的削減、Hidalgo の単一SLI集約等)は、いずれも「大量の低品質アラートを人間が処理しきれない」という現象への対処に焦点を当てる。一方 Burgess は「マイクロ秒スケールで発生するエラーを分〜時間スケールで応答する人間にそのまま渡すこと自体が構造的に誤りであり、アラート量を絞ってもこのタイムスケールの不一致自体は解消されない」と、より根源的な設計原則を提示する([[タイムスケール分離と監視粒度]])。この観点では、[[アラートポリューション]] の「監視対象の優先順位付け」や Hidalgo の「単一ユーザー体験 SLI への集約」は、結果的にタイムスケールの一致に近づく設計変更として再解釈できる。(Source: [[@2014__markburgess.org__Infrastructure Management Timescales]]) - **教科書レベルの言説でも「業界は機能不全を AIOps 製品として商品化した」という批判が明示されるようになった**: *Observability Engineering* 第 2 版第 11 章は、閾値ベースアラートへの対症療法として AIOps 製品(グルーピング・抑制などのアラート処理レイヤー)が市場に溢れる現状を、「逸脱の正常化を業界が製品化しただけ」と評する([[逸脱の正常化]])。これは Redick(SREcon26 Americas)が「AI 統合後もアラート量は改善していない」と統計で示した観察と方向は一致するが、本章は数値的実証ではなく理論的批判として、AIOps レイヤーの追加自体が「複雑性と誤検知源をさらに積み増す」と論じる点で異なる角度から同じ懸念を補強する。両ソースを合わせると、2026 年時点でアラート疲労への「AI で処理を肩代わりする」路線への懐疑が、実務者の統計(Redick)と教科書の理論(本章)の双方で独立に表明されていることになる (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]], [[@2026__SREcon26Americas__Human Factors in the Age of AI Ops]])。 - **分散システムの「未知の未知」支配という論点は、Jalleda・Chen・Hidalgo らの個別施策(インセンティブ設計・技術的削減・単一 SLI 集約)がなぜ根治にならないかを説明する理論的補助線になる**: 本 concept のこれまでの横断的知見は、アラート疲労への具体的な対処法(アラートバジェット、自動修復、単一ユーザー体験 SLI への集約等)を蓄積してきたが、いずれも「なぜ閾値アラートがそもそもノイズを生みやすいのか」という機序には立ち入っていなかった。本章は、モノリスでは網羅可能だった「既知の未知」が、分散システムではサービス間相互作用の組み合わせ爆発により「未知の未知」に主役を譲ると論じ、閾値アラートの限界を構造的に説明する。この視点に立つと、Hidalgo の「単一ユーザー体験 SLI への集約」は個別コンポーネントの既知の未知を捨象して症状(未知の未知の帰結)だけを見る設計として、他の技術的削減策より本質的に整合していると読める (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]], [[@2019__SREcon19EMEA__How to SRE When Everything is Already on Fire]])。 - **「オオカミ少年」化と過剰通知の害は、2011年の実務エッセイと2019年の学術的な歴史的位置づけの双方で独立に確認できる**: [[@2019__SREcon19EMEA__How to SRE When Everything is Already on Fire|Hidalgo SREcon19 EMEA]] は「アラーム疲労はイソップ寓話『嘘をついた少年』(約2,600年前)にも見出せる汎用問題」だと歴史的文脈から位置づけたが、これは学術的講演での引用にとどまる。[[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視|『ウェブオペレーション』6章]]は、放送局ポータルサイトの夜間障害対応で「1つの問題に対して25通ものアラートが届き、担当者がアラートを止めてしまった」という実例を挙げたうえで、本文中で明示的に「アラートが多すぎると『オオカミ少年』になる」と表現している(ch.6 §6.3)。同一のことわざが、学術的講演(2019年、歴史的教訓としての引用)と実務書の一次資料(2011年、実際に起きたインシデントの説明原理)の双方で独立に持ち出されていることは、この比喩が SRE コミュニティ固有の発明ではなく、監視実務者が世代・組織を問わず自然に到達する説明図式であることを示す。さらに本書の事例は「アラートの回数を無制限にしていたこと」「同一原因への重複アラート」という具体的な技術的原因まで踏み込んでおり、Jalleda(SREcon17 Europe)・Chen(SREcon17 Asia)の技術的介入が対処する問題状況を、8年以上早い時点で実務者が個人の経験として記録していたことになる。(Source: [[@2019__SREcon19EMEA__How to SRE When Everything is Already on Fire]], [[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視]] §6.3) - **『SREの探求』30章は、アラート疲労を技術的に解決すべき問題ではなく、オンコールという慣行そのものの正当性を疑う証拠として引用する**: 本ページの既存知見はいずれも「ノイズをどう減らすか」(インセンティブ設計・技術的削減・単一SLI集約・監視対象の優先順位付け等)という技術的・組織的介入に焦点を当てる。30章は同じ現象——「ノイズの多いアラートに悩まされる」「アラートはほとんど、または全く対応できないものばかり」「モニタリングは実際のサービス障害を捕捉せず、実際のユーザーが気付いて発覚する」——を、オンコールを担当する人間が支払う具体的なコストの一項目として列挙し、この状態を改善しようとするのではなく、そもそも人間をこの慣行に配置し続けるべきかを問う論拠に転用する。本ページに蓄積された技術的解決策の集積は「アラート疲労は解決可能な工学課題である」という前提を共有するが、30章はこの前提の外側から、アラート疲労が解消されない現実そのものをオンコール廃止論の証拠として使う点で異なる層に位置する。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 30 オンコール反対論]] §30.2) - **アラート疲労は IT 運用に固有の現象ではなく、物理警備・電子戦を含む閾値検知システム一般に現れる構造的性質であり、かつ攻撃者がそれを意図的に悪用する対抗的(adversarial)な側面を持つ**: Ross Anderson『Security Engineering』第13章は、侵入警報の誤報が警備員の応答性を劣化させる現象を、電子戦のレーダー操作員データ(誤報率15%超で性能劣化)・警察の出動停止方針(年間3〜5件の誤報で対象施設への出動を停止)・TSA 手荷物検査のテスト頻度統計(複数回テストで脅威の20%しかすり抜けないが、1回のみでは60〜75%がすり抜ける)という3つの独立した定量データで裏付ける。これは [[@2016__SREcon16__Less Alarming Alerts|Treat SREcon16]] が医療 ICU・車の警報・航空管制の偽警報研究を並べて示した「IT 運用固有ではない汎用的な注意劣化」という主張と方向は一致するが、Treat が講演内での歴史的引用にとどまるのに対し、Anderson は物理警備の実務データで劣化の閾値を定量化している点で補強する。さらに Anderson は本ページのこれまでの蓄積(いずれも設定不備・環境変動・移行期のしきい値不整合など**偶発的**なノイズ過多を扱う)にない角度として、攻撃者が実際の侵入に先立って**意図的に**誤報を誘発し、警備員の反応が鈍った頃合いを見計らって侵入するという対抗的な悪用パターンを描く(絵画泥棒シナリオ)。これは警報応答網に対する能動的なサービス拒否攻撃であり、IT運用のアラート疲労文献が主に扱う「事故的なノイズ」とは異なる次元を示す(詳細は [[誤報率と検知率のトレードオフ]] concept に分離)。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 13 Locks and Alarms]], [[@2016__SREcon16__Less Alarming Alerts]]) - CloudflareのMatt Bostockは、全世界115拠点以上のエッジPoPから集まる監視において、アラート疲労を抑制するため「過去データによるクエリ発火シミュレーション」「RunbookとGrafanaダッシュボードリンクの義務化」「原因ではなく症状に対するアラート命名（例: RAIDではなくRAID_Health_Degraded）」「通知先タグによるJira起票とオンコールページングの分離」を徹底した。(Source: [[@2017__PromCon__Monitoring Cloudflare's Planet-Scale Edge Network with Prometheus]]) ## 未解決の問い - IT・SRE の現場で、攻撃者が実際の侵害に先立って意図的にアラート/ページングシステムを飽和させ、オンコール担当者を疲弊させてから本命の攻撃を仕掛けた事例(物理警備におけるBrunoの誤報誘発の情報セキュリティ版)は報告されているか。 - Jalleda の「アラートバジェット」と Google SRE Book の「[[エラーバジェット]]」の構造的類似性は指摘できるが、アラートバジェットの数値設定基準や消費計測方法の詳細は本発表では開示されていない。アラートバジェットの具体的な設計パターンを体系化した後続研究はあるか。 - Clean Room のインセンティブ設計は SRE サポートという「報酬の撤回」に依存するが、SRE チームが存在しない組織や SRE の位置づけが異なる組織ではどのような代替インセンティブが機能するか。 - 医療分野のアラート疲労研究（ECRI、Joint Commission）と IT 運用のアラート疲労研究は、Jalleda が冒頭でアナロジーとして引いた以上に交差しているか。医療の MAUDE データベース等に蓄積された知見の IT 転用可能性。 - Lykke の `git shortlog` コミット数はあくまで代理指標であり、コミット数の増加が実際の心理的バイイン(懐疑から信頼への転換)とどの程度相関するかは検証されていない。組織的信頼の変化を定量化する、より妥当性の高い指標はあるか。 - 「沈黙への不安」の緩和策(ミュート可能なSlackログチャンネルによる受動的可視性)は、HRTのような少人数(~300名)のエンジニア組織に特有の解決策か、それとも大規模組織でも同様に機能するか。 ## 関連 - [[アラート管理]] — アラート疲労は管理の失敗状態。介入点の分類で対処方法が整理される。 - [[アラートポリューション]] — 同一問題の裏表。ポリューション = 信号対雑音比の低下、疲労 = オペレータ側の応答劣化。 - [[アクショナブルアラート]] — アラート疲労の根本対策として「アクションに値するアラートだけを鳴らす」設計。 - [[Quality of Alerts]] — QoA の低下がアラート疲労を誘発する因果構造。 - [[エラーバジェット]] — アラートバジェットはエラーバジェットの構造的アナロジー。 - [[逸脱の正常化]] — アラート疲労下でのアラーム無視・抑制の常態化は逸脱の正常化の典型例。 - [[サービスレベル目標]] — SLO ベースアラートは「潜在原因/症状」を分離することでアラート疲労の構造的原因(既知の未知/未知の未知の非対応)に対処する。 - [[オンコール]] — アラート疲労を含むオンコールの人的コストを、慣行そのものの存廃論の論拠とする上位概念 - [[@2021__OReillyJapan__SREの探求 - Chapter 30 オンコール反対論]] — アラート疲労を技術的解決対象でなくオンコール廃止論の論拠として引用するソース - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視]] — 「オオカミ少年」比喩を実際のインシデント経験から独立に用いる2011年の一次資料 - [[誤報率と検知率のトレードオフ]] — アラート疲労の一般形(信号検出理論としてのROC)と、意図的な誤報誘発という対抗的次元を扱う姉妹 concept - [[@2020__Wiley__Security Engineering 3e - Chapter 13 Locks and Alarms]] — 物理警備・電子戦の定量データでアラート疲労の汎用性を裏付け、意図的な誤報誘発という対抗的次元を追加するソース - ソース: [[@2017__PromCon__Monitoring Cloudflare's Planet-Scale Edge Network with Prometheus]] ## 出典 - [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]] - [[@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]] - [[@2019__SREcon19 Americas__Fixing On-Call When Nobody Thinks It's (Too) Broken]] - [[@2021__OReillyJapan__SREの探求 - Chapter 30 オンコール反対論]](Niall Richard Murphy, 『SREの探求』, オライリー・ジャパン, 2021, 30章。§30.2) - パトリック・デボイス, 「6章 監視」, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, §6.3. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 13, §13.3.2, §13.3.5.