# インシデント優先順位付け ## 定義 インシデント優先順位付け(Incident Prioritization)は、オンラインサービスシステムで自動報告される大量のインシデントを「対処すべき essential incidents」と「対処不要な incidental incidents」に分類し、後者を後回しにすることで OCE(On-Call Engineer)の有限な工数を essential に集中させるタスクである。[[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]] が初めて定式化し、incidental incidents を **by design / customer error / won't fix / unable to reproduce / transient / false alarm** の 6 カテゴリで分類した。bug severity prediction(bug 報告の重大度予測)とは似て非なる問題で、incident は monitor の自動報告かつ時間相関を持つため、bug 系の手法をそのまま流用すると AUC が 0.6 前後にとどまる。 ## 横断的知見 - 現時点では [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]] が唯一の取り込み済みソース。複数ソースの突き合わせによる横断的知見は今後蓄積予定。 - **DeepIP の「対処不要(incidental)」判定と、BSRS 17章の「バグは通常インシデント対応を要しない」という原則は、どちらも「大量のシグナルの中から本当に組織的対応を要するものだけを残す」という同じ目的を、全く異なる粒度で実装している**: DeepIP はオンラインサービスの自動報告インシデントを by design / customer error / won't fix / unable to reproduce / transient / false alarm の6カテゴリに分類し、essential incidents だけに OCE(On-Call Engineer)の工数を割り当てる統計的分類問題として優先順位付けを扱う。一方 [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] は、多層防御が適切に機能していればソフトウェアバグ(脆弱性)の是正は通常インシデント対応プロセスに乗せる必要がないと述べつつ、影響が極めて大きい脆弱性(Spectre/Meltdown等)は侵害の有無を問わずインシデントとして扱うべきだとする、質的で組織文脈依存の判断基準を示す。DeepIP が「過去の類似インシデントとの統計的パターン」で自動判定するのに対し、BSRS の基準は「その脆弱性が悪用された場合の潜在的影響の大きさ」という将来リスクの見積もりに基づく点で、両者は優先順位付けの根拠(過去のパターン vs 将来リスクの見積もり)が異なる。(Source: [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]] §3, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]] §Compromises Versus Bugs) ## 未解決の問い - DeepIP の統計的パターン分類(過去の類似インシデント)と BSRS 17章の将来リスク見積もり(悪用された場合の影響)という2つの異なる優先順位付けの根拠は、単一のパイプラインに統合できるか。既知の脆弱性データベース(CVEの深刻度スコア等)を DeepIP のような分類器の特徴量に組み込む設計は存在するか。 - incidental incidents の 6 カテゴリ(by design / customer error / won't fix / unable to reproduce / transient / false alarm)は他社のオンラインサービス([[Amazon Web Services|AWS]]・[[Google Cloud]]・[[Tencent]]・[[Alibaba Cloud]] 等)でも再現するか。Microsoft の運用文化(monitor 中心の自動報告)に強く依存していないか。 - 「2 クラス分類(incidental vs essential)」の粒度は運用上十分か。false alarm は「monitor 再設計」、won't fix は「コード削除」、transient は「リトライ抑止」など、カテゴリごとに介入が異なるはずで、multi-class 分類 / カテゴリ条件付き出力の方が運用効率を上げる可能性がある(DeepIP の Conclusion でも future work として明記)。 - DeepIP のオフライン訓練時間は最大 19 時間(S10)。新サービス導入時のコールドスタート、訓練データの陳腐化([[インシデントTTM予測]] で TTMPred も同じ課題を持つ)に対応する継続学習・転移学習はどう設計すべきか。 - 現行 severity 割当(潜在影響顧客数ベースの 0〜4 段階)と、DeepIP の incidental 確率 ranking をどう統合するか。両者の組み合わせは本論文の射程外で、severity 0 でも incidental が 57.96% という構造的逆転をどう運用フローに翻訳するかは未解明。 - LLM エージェント時代の incident prioritization——RCA エージェントや自動緩和エージェントが介入する環境では、incidental か否かの判定基準そのものが変わる(自動修復可能なものは even further deprioritize できる)。[[OpsAgent]]・[[FLASH]] らの自動化エージェントと DeepIP 型の優先度判定を組み合わせる設計は未着手。 - [[アラート管理]] の Yu+ JNCA2024 が示す「alert と incident を別ライフサイクルとして扱う」設計と DeepIP の「全アラートを incident として扱う Microsoft 慣行 + 後処理での優先順位付け」設計はどちらが運用効率が高いか。両者を同一データセット上で比較した研究はない。 ## 関連 - ソース: [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]] / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 17 Crisis Management]](将来リスク見積もりに基づく質的な優先順位付けの対概念) - 概念: [[インシデント管理]](上位概念・ライフサイクル全体) / [[アラート管理]](上流ライフサイクル) / [[インシデントTTM予測]](緩和時間予測。Chen+ チームの後続研究) / [[異常検知]](false alarm はモニタ側の問題) / [[インシデントトリアージ]](並列研究系譜。同じ「トリアージ」語の別文脈での使われ方) - エンティティ: [[Microsoft]] / [[DeepIP]] / [[Junjie Chen]] / [[Qingwei Lin]] - 関連 MOC: [[AIOps - Failure Detection - MOC]] / [[SRE - MOC]] ## 出典 - [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]](§3 実証研究 RQ1〜4・§4 DeepIP アーキテクチャ・§5 評価 RQ5〜6) - Matt Linton (with Nick Soda and Gary O'Connor), "Crisis Management", in Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 17, §Compromises Versus Bugs.