# Less Alarming Alerts! Navigation: [[アラート管理]] | [[アクショナブルアラート]] | [[アラート疲労]] ## 概要 [[Robert Treat]]（[[OmniTI]] CEO）による SREcon16 発表資料。オンコールをより人間的で合理的にするため、アラートを「人を起こすページ」に限定し、ビジネス影響・修復手順・通知先・予防可能性を説明できないものを悪いアラートとして削除・通知化・修正する考え方を提示する。 本資料の特徴は、後続のアラート管理研究が扱う「発火後の削減・集約・ランキング」よりさらに上流に、**アラートを追加してよいかを事前に問うガバナンス**を置く点にある。2017 年以降のアラートバジェット、Runbook 合意、アラートトリアージ実践の前史として読める。 ## 主要メッセージ ### アラートを他の観測手段と区別する（p.18–p.22） ![[_attachments/srecon16_slides_treat/page-022.png]] Treat は用語を段階的に整理し、メトリクスは「測定できるもの」、グラフは「傾向を見るシステム」、通知は「イベント通知（メール）」、アラートは「人を起こすページ」と定義する。ここでの重要点は、すべての異常通知をページにしないことだ。 ### アラートはシステム理解の外側にある証拠である（p.23–p.25） アラート改善にはシステム思考が必要であり、アラートは「既存の理解の外側でシステムが振る舞っている証拠」として扱う。さらに、改善は事業側が合意できる語彙、つまりビジネス影響で説明されなければならない。 ### 各アラートが答えるべき問い（p.26–p.31） ![[_attachments/srecon16_slides_treat/page-028.png]] 各アラートについて、ビジネス影響、修復手順、誰に通知したか、予防可能性を記録する。回答は毎回チーム全員へ共有し、アラートシステムからその文書へリンクする。これは知識移転、ギャップ露出、パターン発見を生む。 ### 悪いアラートの判定基準（p.32–p.38） ![[_attachments/srecon16_slides_treat/page-032.png]] 悪いアラートの条件は、ビジネス影響を判断できない、修復が不要、誰にも知らせる必要がない、回避策がある、の 4 点である。修復できないなら起こす必要はなく、朝まで待てるなら起こす必要もない。悪いアラートは削除する、通知へ変換する、または修正を実装する。 ### 組織問題としてのアラート（p.39–p.43） 新しいウェブサイトを立ち上げるなら本当に必要なアラームは 1 つだけ、という思考実験を置き、サーバが燃えていても売上が続くなら気にしないという顧客発言を引用する。多くの SA/SRE は先行指標でプロアクティブに起こしたがるが、偽陽性が増えれば反応性は下がる。 ### OOM 事例と自動修復への接続（p.44–p.51） ![[_attachments/srecon16_slides_treat/page-050.png]] サイト停止時に監視が 200 応答コードだけを確認し、応答コードが存在しない状態を見落とした事例を示す。OOM は根本原因になり得るが、常に停止を引き起こすわけではないため、単純に OOM でページすれば偽陽性が増える。代替として、OOM 検知、アプリサーバ再起動、問題プロセス終了、新ノード起動と旧ノード停止を自動化し、すべて失敗した場合だけアラートする設計を提示する。 ### 結論（p.52–p.54） ![[_attachments/srecon16_slides_treat/page-052.png]] 24x7 稼働するソフトウェアが必要なら、人間介入ではなくソフトウェア側にレジリエンスを設計すべきである。2AM に思考へ依存する運用はスケールしない。 ## 視覚的に重要な図表 **p.22 用語定義** ![[_attachments/srecon16_slides_treat/page-022.png]] メトリクス・グラフ・通知・アラートを区別し、アラートだけを人を起こすページに限定する。 **p.28 修復手順の記録** ![[_attachments/srecon16_slides_treat/page-028.png]] 問題要約、解決行動、通知先、予防可能性を毎回文書化する。 **p.47 誤警報の外部例** ![[_attachments/srecon16_slides_treat/page-047.png]] 医療 ICU、車の警報、虚偽緊急通報、航空管制の偽警報研究を並べ、偽陽性が応答を鈍らせる構造が IT 運用に限らないことを示す。 **p.50 OOM の自動修復案** ![[_attachments/srecon16_slides_treat/page-050.png]] OOM をページ条件にする代わりに、検知・再起動・プロセス終了・ノード交換を自動化し、失敗時だけページする。 ## 口頭説明・補足 公式ページには音声と動画が提供されている。音声ファイルは `.raw/slides/srecon16_slides_treat/media/treat.mp3` に保存した。文字起こしは長時間完了しなかったため未生成であり、本ページの中心主張はスライド画像と公式ページのメタデータに基づく。 ## 概念・実体への接続 - [[アラート管理]] — アラート追加前にビジネス影響と修復手順を問う、発火前ガバナンスの初期実践。 - [[アクショナブルアラート]] — アクション可能性を「ビジネス影響 + 修復手順 + 通知先 + 予防可能性」で評価する運用者視点の定義。 - [[アラート疲労]] — 偽陽性が多すぎるとアラートを無視するようになる、という疲労の行動モデル。 - [[OmniTI]] — OmniTI の複数サイト・24x7 運用経験が背景。 ## 限界・不確実点 - `date_published` は USENIX 公式ページの BibTeX（2016 年 4 月）とスライド下部の日付（2016-04-09）から 2016-04 とした。 - transcript は未生成。口頭 Q&A やスライド外の補足は未確認。 - p.47 の外部研究リンクはスライド上で確認したが、各研究本文の再検証はしていない。 - p.40–p.41 の「新しいウェブサイトなら本当に必要なアラームは 1 つだけ」は思考実験であり、一般的な監視設計規則としてそのまま適用する主張ではない。