# Warningアラート ## 定義 Warning アラートとは、Severity が Warning に設定されたアラートであり、即座に人間が対応する Critical アラートよりも低い重要度として扱われるが、重大事故の前兆を含む可能性がある警告である。池田将士の SRE NEXT 2023 発表では、リクエスト 5xx エラー 1 件や平均レスポンスタイム 500 ms などが例として挙げられ、Mackerel では Slack メンションなしで通知される一方、Critical アラートは channel メンションやオンコール付きで扱われる。([[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]]) ## 横断的知見 - **Warning アラートは alert determination の前段にある調査準備問題を露出させる**: [[アラート管理]] 研究は抑制・フィルタリング・集約・ランキング・RCA に介入点を分けてきたが、池田の実践は「発火した低重要度アラートに対し、判断材料を先に集める」層を明示する。これはアラートをすぐ消す/束ねるのではなく、週次振り返りで重大化の可能性を判断するための文脈を自動的に添える介入であり、alert determination の入力品質改善として読める。(Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]], [[アラート管理]]) - **SLO・エラーバジェット運用では低重要度アラートでも予算消費を起こしうる**: FCKeditor 向け攻撃事例では、アプリケーションに有効な攻撃でなくても 5xx を返すことで [[エラーバジェット]] が削れる。Warning アラートの扱いは「オンコールすべきか」だけでなく、[[サービスレベル目標]] の良いイベント比率を守るために、どこで遮断・分類・放念するかの判断に接続する。(Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]], [[エラーバジェット]], [[サービスレベル目標]]) ## 未解決の問い - Warning アラートの調査準備を自動化する層は、既存のアラート管理分類では抑制・フィルタリング・集約・ランキング・RCA のどこに置くべきか。独立した「エンリッチメント」層として扱う方が実務には近いか。 - Warning アラートを「低重要度だが予算消費につながるもの」として扱う場合、SLO バーン率アラートやエラーバジェットポリシーとのしきい値設計はどう調整すべきか。 - アラートメモへの自動収集結果が増え続けると、判断材料の過剰化や誤った安心につながらないか。必要な情報量をどう制御するか。 ## 関連 - 実践: [[prepalert]] - ソース: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]] - 既存概念: [[アラート管理]] / [[エラーバジェット]] / [[サービスレベル目標]] ## 出典 - [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]]