# Quality of Alerts ## 定義 Quality of Alerts(QoA)は、アラートが診断・修復作業に与える有用性を 3 軸で評価する自動評価枠組みである。[[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems|Yang+ DSN2022]] が [[アラートアンチパターン]] の自動検知を支える将来方向として提案した。3 軸は以下: - **Indicativeness(指示性)**: アラートが「エンドユーザの体験に影響する障害」を実際に指し示しているか。下層インフラの指標(CPU・ディスク等)はサービス品質に直結しないことがあり、indicativeness の低いアラートを大量に生成する典型源になる。 - **Precision(精度)**: アラートが異常の重大度を正しく反映しているか。Misleading Severity アンチパターン(過剰高 severity が時間を浪費し、過低 severity が重要アラートを見逃す)を評価する軸。 - **Handleability(処理容易性)**: アラートを迅速に処理できるか。target(何を監視するか)と presentation(どう呈示するか)に依存し、これらが不適切だと低下する。 (Source: [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]]) ## 横断的知見 - **TraceArk の 2 軸(impact + interpretability)は QoA 3 軸の再分節化と読める**: [[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems|Zeng+ ICSE-SEIP2023]] は「アクショナブルアラート」を impact(ユーザー影響の大きさ)と interpretability(次のアクションを誘導できる)の 2 軸で定義した(§II-B)。これを QoA 3 軸に重ねると、impact ≒ indicativeness + precision(影響評価 + 重大度の正しさ)、interpretability ≒ handleability(target + presentation)と対応する。TraceArk は handleability 軸を「ExL(排他的レイテンシ)」と「パス粒度のトレース集約」で具体的に計算可能な指標に落とした(§III-A)点で、Yang+ 2022 が「target と presentation の複合だから捉えにくい」と将来課題に挙げた handleability の機械的測定の最初の具体例と言える。(Source: [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]] §IV, [[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems]] §II-B, §III-A) - **precision 軸の自動最適化(severity ランキング)を支えるラベル源は事業者で異なる**: [[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems|Zhao+ ISSRE2020 (AlertRank)]] は Resolution Record(解決記録)の TF-IDF + k-means クラスタリングで severity の連続スコアを自動付与する(§III.A2)。手動ラベル付け不要で precision 軸を最適化できる重要な実装パターンだが、解決記録が整備されていないと機能しない。[[@2023__arXiv__ESRO - Experience Assisted Service Reliability against Outages|Chakraborty+ ESRO]] が過去の障害レポート + アラートデータで CK グラフを構築するアプローチも同質で、ラベル源が「ポストモーテム的文書」に偏る前提を共有する。Yang+ DSN2022 が QoA の自動ラベル化を将来課題に挙げたとき、解決記録という暗黙のラベル源が事業者によって整備度に大きな差があることは明示されていなかった。(Source: [[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems]] §III.A2, [[@2023__arXiv__ESRO - Experience Assisted Service Reliability against Outages]] §IV, [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]] §IV) - **handleability の機械化は「フィードバックループ前提」の継続学習系で達成される**: [[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems|TraceArk]] が 10〜30 件のエンジニア評価で F1 を 0.74 まで向上させる半教師あり XGBoost フィードバック機構を持つ(§IV-C、図10)のと、[[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems|AlertRank]] がソフトウェア変更後の F1 劣化(0.68)をインクリメンタル学習で F1 0.88 まで回復させる(§IV.C4)のは、いずれも「初期モデル + 運用中フィードバック」の学習系。Yang+ 2022 が QoA の handleability を「OCE のドメイン知識から ML でラベル化」と将来方向に挙げた理由は、静的分類器では本質的に到達できない領域があるから。詳細は [[アクショナブルアラート]] 参照。(Source: [[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems]] §IV-C, [[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems]] §IV.C4) ## 未解決の問い - QoA の 3 軸はそれぞれどのようにラベル付け・学習されるべきか。論文は「OCE が処理中に high/low precision/handleability/indicativeness のラベルを与え、ML モデルが継続学習する」枠組みを示すが、具体的アルゴリズムは提示されていない。 - handleability は target と presentation の双方に依存する複合軸であり、ルールベースでは捕捉しにくい。LLM(LogPilot・AlertGuardian など)で評価する場合、target と presentation を別々に評価するべきか、複合スコアとして扱うべきか。 - 3 軸のうち precision は SLO/SLA との関係付けが自然だが、indicativeness と handleability は SLO 文脈での標準化指標が未確立。 - 後続研究([[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems|AlertGuardian]]・[[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems|LogPilot]] など)が QoA の 3 軸を明示的に評価指標として採用したか、独自の評価軸を立てたか。 - TraceArk の 2 軸(impact + interpretability)と QoA の 3 軸の対応付けは未検証。impact = indicativeness + precision、interpretability = handleability という直感的な対応は妥当か? - 解決記録(Resolution Record)に依存しない precision 自動学習の代替シグナルとして何が機能するか? チケットのクローズログ・KPI 復旧時刻・SLO 違反履歴などが候補。 ## 関連 - 親概念: [[アラート管理]]・[[アラートアンチパターン]] - 関連: [[サービスレベル目標]](precision 軸が SLO と接続)、[[アクショナブルアラート]](impact + interpretability の機械化) - ソース: [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]]、[[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems]]、[[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems]] ## 出典 - [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]] §IV(Future Directions)。 - [[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems]] §II-B(actionable 2 軸定義)、§III-A(ExL とパス粒度集約による handleability の機械化)。 - [[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems]] §III.A2(severity 自動ラベル付け)、§IV.C4(インクリメンタル学習による継続最適化)。