# QoA 3 軸の詳細解説 ## 問い Yang+ DSN2022 が提案した QoA(Quality of Alerts)の 3 軸について詳しく解説せよ。 ## 回答 [[Quality of Alerts]](QoA)は、アラートが診断・修復作業に与える有用性を 3 軸で評価する自動評価枠組みである。[[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems|Yang+ DSN2022]] が [[アラートアンチパターン]] の自動検知を支える将来方向として §IV で提案した。 --- ### 1. Indicativeness(指示性) **「このアラートはエンドユーザ体験に影響する障害を本当に指し示しているか」** CPU 使用率・ディスク I/O などの下層インフラ指標は、フォールトトレランス(fault tolerance)の進化で顧客側の品質に必ずしも直結しなくなっている。Indicativeness が低いアラートの典型源は A3 アンチパターン(不適切で時代遅れの生成ルール)で、「数値は閾値を超えているがサービスは正常」という偽陽性を大量に生成する。 --- ### 2. Precision(精度) **「このアラートの severity 設定は異常の重大度を正しく反映しているか」** A2 アンチパターン(Misleading Severity)と直接対応する軸。 - 過剰に高い severity → OCE の時間を浪費 - 過低な severity → 重要アラートが埋もれて見逃す 後続研究 AlertRank([[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems|Zhao+ ISSRE2020]])は解決記録(Resolution Record)の TF-IDF + k-means で連続重要度スコアを自動付与することでこの軸の機械化に踏み込んだが、解決記録が整備されていない組織では機能しないという制約が残る。 --- ### 3. Handleability(処理容易性) **「このアラートを OCE が迅速に処理できるか」** target(何を監視するか)と presentation(どう呈示するか)の双方に依存する複合軸で、ルールベースで捕捉しにくいと論文は認めている。A1 アンチパターン(Unclear Name or Description)や target の選択ミスが handleability を下げる。 TraceArk([[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems|Zeng+ ICSE-SEIP2023]])が「排他的レイテンシ(ExL)」とパス粒度のトレース集約で handleability の機械的測定の最初の具体例を与えた。Yang+ 2022 が「将来課題」に挙げた時点では具体アルゴリズムは未提示のままだった。 --- ### アンチパターンとの対応関係 | アンチパターン | 下がる QoA 軸 | |---|---| | A1 Unclear Name/Description | Handleability | | A2 Misleading Severity | Precision | | A3 Improper/Outdated Generation Rule | Indicativeness | | A4 Transient/Toggling Alerts | Precision / Handleability | | A5 Repeating Alerts | Indicativeness | | A6 Cascading Alerts | Indicativeness / Precision | --- ### 横断的知見 **TraceArk の 2 軸との対応**: impact(ユーザ影響の大きさ)≒ indicativeness + precision、interpretability(次のアクションへの誘導)≒ handleability と読める。QoA 3 軸の再分節化と位置づけられる。 **Zadka のコストモデル(SREcon22)との補完**: [[Quality of Alerts]] の QoA が「何が品質を構成するか」を軸立てし、[[@2022__SREcon22 Americas__Modeling Alert Quality|Zadka]] が「それぞれにどんなコストが対応するか」を分解した関係。 | QoA 軸 | Zadka モデルでの読み替え | |---|---| | indicativeness | 偽アラーム・useless alarm の削減 → アラーティングコスト低減 | | precision | 真アラームの発生→検知区間の短縮(正確な閾値) | | handleability | 確認→診断→復旧の各区間短縮(Runbook・診断情報の付与) | --- ### 未解決の問い - QoA の 3 軸をどのようにラベル付け・学習するか。OCE が処理中に高低ラベルを付与し機械学習が継続学習する枠組みは示したが具体アルゴリズムは未提示 - handleability は target と presentation の複合軸であり、LLM(LogPilot・AlertGuardian)で評価する場合に別々に評価すべきか複合スコアとして扱うべきか - precision は SLO/SLA との関係付けが自然だが、indicativeness と handleability は SLO 文脈での標準化指標が未確立 ## 出典 - [[@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, §III-A - [[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems]] §III.A2 - [[@2022__SREcon22 Americas__Modeling Alert Quality]]