# アラート管理の教科書 本ページは、wiki に蓄積した 105 本のソースを横断し、アラート管理という営みの設計空間を年代順に編纂したものである。 扱うのは、何を鳴らすかという生成の設計から、鳴りすぎたものをどう減らすか、誰にどう届けるか、鳴った後どう応答するか、そして良いアラートをどう測るかまでである。 全主張には出典を付けた。本文中の `Source:` に続くリンクをたどれば、その主張がどのソースページの記述に対応するかを 1 対 1 で確認できる。数値には評価条件を併記した。条件が原典に書かれていないものは、その旨を本文に明記している。 **読み方の指針**。全体像を最短で得たいなら第 2 章の座標系だけを読む。設計の選択肢を知りたいなら第 II 部と第 III 部。手法の系譜を追いたいなら第 IV 部と第 V 部。運用の組み立てに関心があるなら第 VI 部と第 VII 部。現在地を知りたいなら第 VIII 部。何が分かっていないかだけを持ち帰りたいなら第 X 部。 **姉妹ページとの分担**。SLI の設計と SLO 目標値の決め方は [[SLI-SLO教科書]] が扱う。本ページは SLO をアラートの発火条件へ接地する側だけを書く。アラートが鳴った後の指揮、役割分担、収束の判断は [[インシデント対応の教科書]] が扱う。事後の学習とポストモーテムの運営は [[ポストモーテムの教科書]] が扱う。いずれも本ページでは繰り返さない。 --- ## 第 1 章　アラート管理という問題 ![[Attachments/アラート管理の教科書/chapter-01.png]] アラートとは、監視システムが「何かが期待どおりに振る舞っていない」ことを検知したときに送るシグナルである (Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 1 Introduction]])。 この定義自体は素朴だが、そこから先に少なくとも 5 つの独立した設計問題が派生する。 何を鳴らすかを決める問題がある。 鳴りすぎたものをどう減らすかという問題がある。 残ったものを誰にどう届けるかという問題がある。 届いた後に人間または機械がどう応答するかという問題がある。 そして、その一連の仕組みが良いかどうかをどう測るかという問題がある。 これらは互いに独立に解ける。 検知ルールを精緻にしても、届け先が間違っていればアラートは処理されない。 集約で件数を 2 桁減らしても、受け取る人間の側の制度が変わらなければ負荷は残る。 逆に、アラートの中身を一切変えずに通知先だけを変えることでも運用は改善する (Source: [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]])。 この独立性が、アラート管理を単一の技術課題として語れなくしている。 さらに、この 5 つの問題はそれぞれ別の共同体が別の言語で扱ってきた。 SRE 実務の共同体は、カンファレンス発表と書籍を通じて「何を鳴らすか」の原則を積み上げてきた。 学術 AIOps の共同体は、査読論文を通じて「どう減らすか」の手法を積み上げてきた。 両者は同じ現象を扱いながら、互いの文献をほとんど引用しない。 この断絶は今に始まったものではなく、本ページが第 I 部で扱う前史の時点ですでに存在していた (Source: [[@2000__arXiv__On the theory of system administration]], [[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視]])。 本ページは、この断絶した文献群を 1 つの年表の上へ並べ直すことを目的とする。 --- ## 第 2 章　座標系 ![[Attachments/アラート管理の教科書/chapter-02.png]] 以降の各部を読むための座標系を、4 つの軸で定義する。 読者は各文献を、この 4 軸上の 1 点として配置できる。 ### 軸 A　ライフサイクル段階 アラートが生まれてから評価されるまでの 5 段階である。第 1 章で挙げた 5 つの設計問題に対応する。 | 値 | 内容 | この教科書での主な扱い | |---|---|---| | 生成 | 何を鳴らすかを決める。信号の選定、閾値、SLO への接地 | 第 I 部、第 II 部、第 III 部 | | 削減 | 鳴ったものを減らす。抑制、フィルタリング、相関、集約、要約、ランキング | 第 IV 部、第 V 部 | | 配送 | 誰にどう届けるか。緊急度による経路分岐、動的ルーティング、Runbook | 第 VI 部 | | 応答 | 受け取った後どう動くか。トリアージ、診断、自動修復 | 第 VII 部、第 VIII 部 | | 評価 | 仕組みの良し悪しを測る。アラート品質、コストモデル、ルール自体の検査 | 第 III 部、第 VII 部 | ### 軸 B　介入層 同じ「アラートを減らす」でも、手を入れる層が違えば別の技術になる。 | 値 | 内容 | 代表的な例 | |---|---|---| | 信号設計 | そもそも何を測り何を指標にするか | ゴールデンシグナル、症状ベースアラーティング | | ルール | 発火条件の式そのもの、およびその式の健全性 | バーンレートアラート、二項分布による動的しきい値、PromQL のリント | | 後処理パイプライン | 発火したアラートを受けて選別、集約、要約する層 | 抑制ポリシー、グラフ集約、LLM による要約 | | 人間と組織 | オンコール制度、インセンティブ、訓練 | アラートバジェット、認知的徒弟制 | 層が違う介入は互いに直交する。 発火条件をいくら精緻にしても、そのルールが静かに壊れていれば何も鳴らない (Source: [[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]])。 後処理でいくら束ねても、そもそも鳴らすべきでない信号を選んでいれば束の中身は変わらない (Source: [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]])。 ### 軸 C　知識の出自 | 値 | 内容 | 本ページでの主な所在 | |---|---|---| | SRE 実務 | カンファレンス発表、実務書、事例報告。定量評価を持たないことが多い | 第 II 部、第 VI 部、第 VII 部 | | 学術 AIOps | 査読論文。指標と比較対象を持つが、単一事業者の非公開データで評価されることが多い | 第 IV 部、第 V 部 | | LLM エージェント | 2024 年以降の系譜。学術と産業デプロイ報告が混在する | 第 VIII 部 | ### 軸 D　評価データの出自 主張の重みを判断するための軸である。本ページで最も頻繁に参照する。 | 値 | 内容 | 注意点 | | -------- | ----------------- | ---------------------- | | 本番テレメトリ | 事業者の実運用データ。多くは非公開 | 再現できない。単一事業者の運用文化に依存する | | 公開ベンチマーク | Zenodo 公開データセットなど | 本ページの母集団ではきわめて少数である | | 研究室構築と合成 | テストベッド、障害注入、合成データ | 本番規模との乖離を確認する必要がある | | 事例報告のみ | 定量評価を伴わない経験の記述 | 数値が示されても分母と計測期間の確認が要る | この軸を立てる理由は、本ページの母集団において**企業の非公開本番データによる評価が圧倒的多数を占め、公開ベンチマークが例外的である**ためである。 同じ手法が別のデータセットで再評価されると結論が逆転する例が実際に存在する(第 V 部第 21 章)。 数値を読むときは、まずこの軸のどこに位置する数値かを確認する必要がある。 ### 座標系の使い方 以降の各部は、軸 A のライフサイクル段階を主題としつつ、年代順に並んでいる。 各部の一覧表には軸 D を列として置いた。 ある手法が「何を、どの層で、どういうデータで示したのか」を、この 4 軸で読み取れる。 --- ## 第 I 部　前史(1990 年代から 2012 年) ### 第 3 章　システム管理の理論化とタイムスケール ![[Attachments/アラート管理の教科書/chapter-03.png]] システム管理は 1990 年代まで、経験則と逸話に基づく技芸として扱われてきた。 Burgess は 2000 年の arXiv 論文で、この領域に理想状態、組合せ論、ゲーム理論という異なる数理的道具立てを持ち込み、公理的な理論化を試みた。 論文はまず、システムポリシー P(t) が十分に完全であれば代表的な平均理想状態 S_p(t) を含意すると証明する(Theorem 1)。 証明の骨子は、構成 C から実状態 S_p + δS への写像が多対一であり、この非一意性を平均化操作が消去するというものである (Source: [[@2000__arXiv__On the theory of system administration]])。 理想状態が定義できる前提は、ポリシーの変化速度がユーザー挙動の変化速度より十分小さいことであり、Burgess はこれを月から週のオーダーと時間から日のオーダーの差として置く。 理想状態が定まったところで、論文は理想状態からの偏差を n 次元格子上のベクトル d として表現する。 原点である理想状態へ戻る同じ長さの経路数は H(d) = (Σd_j)! / Π(d_k!) で与えられ、ユークリッド距離とともに近似的に指数的に増大する。 この結果は、理想状態から離れるほど正しい修復手順を特定するコストが跳ね上がるという、修復の組合せ論的な困難さを定量化したものである (Source: [[@2000__arXiv__On the theory of system administration]])。 論文はさらに、自動システムの応答時間と人間の応答時間を不等式で比較する。 人間の待機時間 T_w(H) が自動システムの実行時間 T_e(A) を上回る限り、自動システムは常に人間に勝てるという結論が導かれる(式 16 から 22)。 これらの数式は実測データに基づく評価ではなく、著者の所属環境での経験に基づく概数を用いた例示的な解析的モデルである(Figure 4 の (n_g, n_b) = (99, 1) など、条件記載は解析例のパラメータのみ) (Source: [[@2000__arXiv__On the theory of system administration]])。 同論文は、ゲーム理論的な定式化をディスク容量管理のガベージコレクション戦略の比較にも適用し、quota 戦略が閾値ベース自動整理や免疫モデル型戦略に対して minimax の観点で優位に見えても、資源利用の柔軟性を失わせ組織全体の生産性を損なうと結論づける (Source: [[@2000__arXiv__On the theory of system administration]])。 Burgess は 2014 年のエッセイで、この理論的な骨格をより実務寄りの言葉に置き換える。 インフラ管理においてタイムスケールを理解すべき理由は 2 つある。 第一に観測頻度の問題であり、第二に約束を守れなかったときの是正速度を問題自身のタイムスケールに一致させる問題である (Source: [[@2014__markburgess.org__Infrastructure Management Timescales]])。 後者は 2000 年論文の応答時間比較が定量的に先取りしていた原理であり、Burgess はこれを Shannon 誤り訂正定理と Burgess Maintenance Theorem として引用する (Source: [[@2014__markburgess.org__Infrastructure Management Timescales]], [[@2000__arXiv__On the theory of system administration]])。 タイムスケールの分離度合いは系全体の結合強度の指標であり、分離が良ければ弱結合で安定に、悪ければ強結合で脆弱かつ不安定になる。 Burgess はこの限界線を「KT 境界(kernel-thought boundary)」と呼ぶ。 人間の思考は概ね 1 秒スケールに集中しており、KT 境界の外側では人間の関与そのものが構造的に不可能になる (Source: [[@2014__markburgess.org__Infrastructure Management Timescales]])。 ただし KT 境界に対応する具体的な時間スケールがミリ秒なのかマイクロ秒なのかは、エッセイ自体では定量化されていない (Source: [[タイムスケール分離と監視粒度]])。 Burgess の中核テーゼは「力学は常に意味論に勝る(Dynamics always trump semantics)」である。 ソフトウェア業界は意味論的な問題の解決には長けているが、その問題を引き起こす力学的過程そのものへの対応をほとんど試みないという指摘である (Source: [[@2014__markburgess.org__Infrastructure Management Timescales]])。 具体例として挙げられるのが監視アラームである。 マイクロ秒スケールでデータを収集するプロセスのエラーが、分から時間スケールで応答する人間にそのまま渡され、単発の一括対応をして再発を待つだけになるという不一致がある。 Burgess は、人間が消化できる速度より速く起きることを従来型の意味で監視することに意味はないと述べ、閉ループフィードバックへの置き換えを要求する。 タイムスケールの不一致は、キュー内のサービス時間がタスクの到着間隔より短くなければならないというキューイング問題として一般化できる (Source: [[@2014__markburgess.org__Infrastructure Management Timescales]])。 Burgess はエッセイの結びで、業界には現代版の体系的研究の更新が必要だと述べている (Source: [[@2014__markburgess.org__Infrastructure Management Timescales]])。 2000 年論文と 2014 年エッセイを重ねると、理論化と実務の断絶がこの部を貫く構図として見えてくる。 2000 年論文は群論、組合せ論、ゲーム理論による公理的定式化を試みたが、査読を経た実証データではなく解析的モデルと例示にとどまる (Source: [[@2000__arXiv__On the theory of system administration]])。 2014 年のエッセイは同じ著者による 14 年後の観測だが、査読論文ではなく自身のウェブサイトへの掲載であり、定量的な証明ではなく標語的な言明にとどまる (Source: [[@2014__markburgess.org__Infrastructure Management Timescales]])。 第 6 章で扱うウェブオペレーションの実務論は、こうした数理理論に一切言及せず、MTTD、MTTR、MTBF のような経験的な指標体系を独自に組み立てている。 これは、理論化の試みと実務の言語が同時代的に断絶していたことを示す徴候である。 ### 第 4 章　統計的閾値と変化点検知 ![[Attachments/アラート管理の教科書/chapter-04.png]] 1998 年の Thottan と Ji は、SNMP の管理情報ベース(MIB)変数の時系列から、ネットワーク障害を事前に検知する適応的閾値判定のアルゴリズムを提案した。 従来の商用ネットワーク管理ソフトウェアはリンク切断や帯域枯渇のような壊滅的障害しか検知できず、ルールベース手法は過去の障害シナリオの知識や運用者の専門性に依存し、トポロジやトラフィックの変化に適応できなかった。 Thottan と Ji はこの限界に対し、事前知識や静的ルールに依存せず、MIB 変数の統計的性質の変化から時間相関アラームを生成する枠組みを構築した。 提案システムは、データ処理ユニット、変化検知器、結合器という 3 段のステージで構成される (Source: [[@1998__IWSM__Adaptive Thresholding for Proactive Network Problem Detection]])。 まず、RFC 1213 が定める 171 変数のうち多くが障害検知に冗長であることを踏まえ、プロトコルスタック内のトラフィック伝播を可視化する Case 図(Case and Partridge, 1989)を用いて、非冗長な 6 変数(ifIO, ifOO, ipIR, ipIDe, ipFD, ipOR)を選定した。 続いて、15 秒間隔で収集される MIB カウンタの増分を、2.5 分間(10 ラグ)の局所定常な窓に分割し、各窓に 1 次の自己回帰(AR(1))モデルを当てはめる。 ネットワークトラフィックの時系列は強い長期依存性と非定常性を示すため、大域的な単一モデルではなく、局所的に定常とみなせる短い窓の連なりとして扱う設計である (Source: [[@1998__IWSM__Adaptive Thresholding for Proactive Network Problem Detection]])。 隣接する 2 つの非重複窓の残差分散を比較し、逐次一般化尤度比(GLR)検定によって統計的性質の変化点を検出する。 検定統計量が閾値 h を超えれば変化点と判定し、さらに 24 時間の正常データから算出した基準値との尤度比較で変数レベルのアラームを発行する。 AR 次数は赤池の最終予測誤差(FPE)基準で p=1 に決定され、残差の自己相関関数が 10 ラグ以降でほぼ消失することが窓長 10 の妥当性を裏づけた。 残差の分位数プロットでは、標準正規分布に対して長い裾野を持つものの、1 次と 2 次のモーメント推定にはガウス近似が実用上十分であることが確認され、多数のインターフェースの集約である ip 変数は中心極限定理により if 変数より正規分布に適合した (Source: [[@1998__IWSM__Adaptive Thresholding for Proactive Network Problem Detection]])。 変数レベルのアラームだけでは、単一変数の孤立したスパイクが誤警報を生む。 そこで Thottan と Ji は、下位層から上位層へのトラフィック伝播という 5 つの遷移パスに基づくデュレーションフィルタを導入し、複数変数のアラームが一定時間内に伝播しているかを確認したうえでノードレベルのアラームに統合した (Source: [[@1998__IWSM__Adaptive Thresholding for Proactive Network Problem Detection]])。 これは、単一シグナルではなく複数シグナルの一致を要求するという設計原理の初出であり、同じ発想は第 5 章の不変条件ネットワークや、第 6 章の複合条件アラートにも独立に現れる (Source: [[@1998__IWSM__Adaptive Thresholding for Proactive Network Problem Detection]], [[@2009__ICAC__Ranking the Importance of Alerts for Problem Determination in Large Computer Systems]], [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]])。 評価は、レンセラー工科大学(RPI)計算機科学科の LAN(7 サブネット、2 ルータ、133 ホスト、2 台の NFS ファイルサーバ)で、15 秒間隔の SNMP ポーリングによる実運用データを用いて行われた。 変数レベルの結果では、6 変数のうち ipOR が UNIX syslog に記録された「NFS server not responding」障害 9 件全件を捉え、平均アラーム数は 1.19 件毎時だった。 デュレーションフィルタによる統合後は、アラーム率が平均 1.4 件毎時まで低減された (Source: [[@1998__IWSM__Adaptive Thresholding for Proactive Network Problem Detection]])。 ノードレベルの先行検知性能は、データセット 1 から 4 では検知確率が 1(全件検知)、誤警報確率は 0.0037 から 0.0071 の範囲であり、障害発生の 8.7 分から 60 分前(データセット 2 を除く)にアラームが先行した(Node 1、Table IV)。 ゲートウェイルータである Node 2 でも同様の結果が得られ、内部ルータで調整したパラメータを再調整なしで異種ノードへ適用できることが確認された(Table V) (Source: [[@1998__IWSM__Adaptive Thresholding for Proactive Network Problem Detection]])。 ![[_attachments/Adaptive-Thresholding-for-Proactive-Network-Problem-Detection/fig11-output-at-node-level.png]] **図4-1**:Node 1 のノードレベル出力を 2 つの障害日について示したもので、縦軸のアラーム段階が 2 に跳ね上がる時刻と障害時刻の関係が読み取れる。本文が述べた「障害発生の 8.7 分から 60 分前にアラームが先行した」という先行検知は、この跳ね上がりが図中の障害時刻より手前で始まっていることに対応する。 (Source: [[@1998__IWSM__Adaptive Thresholding for Proactive Network Problem Detection]], 図 11) 一方、データセット 5 では検知率が 0 で検知に失敗し、データセット 6 では検知率 0.5 の部分検知にとどまり、Node 1 の 6 件中 2 件で検知が破綻している。 論文はこの破綻例の個別要因を分析していないが、検知率と誤警報率のトレードオフは閾値設定に強く依存することが示されている。 閾値を低く設定すると検知確率は 1.0 まで上がるが誤警報確率も 0.0134 に増え、高く設定すると誤警報確率は 0.0017 まで下がるが検知確率は 0.305 まで落ちる(Table VI) (Source: [[@1998__IWSM__Adaptive Thresholding for Proactive Network Problem Detection]])。 > [!warning] Table IV と Table V の検知確率は、各データセットが数件規模の障害イベントに対応する少数サンプルの割合である(Node 1 は 6 データセット、Node 2 は 4 データセット)。大規模な母集団での検知率として引用してはならない (Source: [[@1998__IWSM__Adaptive Thresholding for Proactive Network Problem Detection]])。 Thottan と Ji の手法は、静的な障害モデルやルールを使わずに、実ネットワークで障害の 5 分から 60 分前という先行検知を達成した点で、第 I 部が扱う文献のうち唯一、本番テレメトリによる定量評価を伴う研究である。 その評価規模は 7 サブネットと 133 ホストという当時の大学 LAN に限られ、既知障害はわずか 9 件であることには留意が要る (Source: [[@1998__IWSM__Adaptive Thresholding for Proactive Network Problem Detection]])。 局所定常 AR(1) モデルと逐次 GLR 検定によるこの枠組みは、後年のオフライン最適化手法やベイズオンライン変化点検知に先立ち、パラメトリックな局所定常時系列モデルと尤度比検定の組み合わせが実ネットワークの先回り型の障害検知で実用的な計算量と精度を両立しうることを示した先駆例と位置づけられる (Source: [[変化点検知]])。 ### 第 5 章　非アクショナブルアラートの発見 ![[Attachments/アラート管理の教科書/chapter-05.png]] 閾値ベースの監視は、複数のルールが同時多発的にアラートを出す状況にも直面する。 2009 年の Jiang ら(NEC Laboratories America)は、大規模コンピュータシステムにおけるアラートの重要度ランキングを、ピアレビュー機構で実現する手法を提案した。 背景には、閾値が多くの場合オペレータの経験と直感に依存して手動設定され精度にばらつきがあること、あるモバイルネットワーク OSS では全アラートの 80% が偽陽性であったこと、単一障害が多数アラートを連鎖的に発生させるアラートストームでどれを優先調査すべきか不明であることがある。 CPU 使用率とパケット数のように意味の異なる異種メトリクスの閾値は直接比較できない、という問題も加わる (Source: [[@2009__ICAC__Ranking the Importance of Alerts for Problem Determination in Large Computer Systems]])。 Jiang らの解法は、フロー強度測定値間の線形関係を ARX モデルで抽出し、長期間にわたり安定しているモデルをシステム不変条件として採用することから始まる。 不変条件ネットワーク上であるメトリクスの値を固定すると、線形関係を通じて他のメトリクスの定常状態の値が求まり、この値伝播によって、あるルールの閾値を他のメトリクスの等価閾値へ変換できる。 オンライン段階では、受信したアラートについて、実測値がいくつの等価閾値を超えているかを数える NTV(Number of Threshold Values)を計算する。 NTV が大きいほど、他の多くのルールのコンセンサスを得ており真陽性である確率が高いと判断し、アラートをランク付けする (Source: [[@2009__ICAC__Ranking the Importance of Alerts for Problem Determination in Large Computer Systems]])。 このピアレビューの発想は、単一ルールの閾値設定バイアスを多数ルールのコンセンサスで補正する仕組みであり、第 4 章のデュレーションフィルタと同じく複数シグナルの一致を要求する設計である (Source: [[@2009__ICAC__Ranking the Importance of Alerts for Problem Determination in Large Computer Systems]], [[@1998__IWSM__Adaptive Thresholding for Proactive Network Problem Detection]])。 評価は Apache、JBoss、MySQL からなる 3 層 Web システムのテストベッドで行われ、111 メトリクスから 975 個の不変条件が抽出された。 全 6 ルールからアラートが発生した場面では、NTV ランキングが DB CPU% のアラートを最重要と正しく判定し、モデルベース検知でもこの判定の妥当性が裏づけられた。 SCP コピーによる問題注入の場面でも、Web CPU% と Web Recv Packet のアラートが正しく上位にランクづけられた (Source: [[@2009__ICAC__Ranking the Importance of Alerts for Problem Determination in Large Computer Systems]])。 このテストベッド規模の検証は根本原因の箇所特定までは扱っておらず、あくまでオペレータが優先調査すべきアラートを絞り込む段階の実証である(条件は 3 層テストベッド、111 メトリクス、975 不変条件、報告された評価シナリオは 2 件) (Source: [[@2009__ICAC__Ranking the Importance of Alerts for Problem Determination in Large Computer Systems]])。 一方、2012 年の Tang ら(Florida International University)は、アラートの重要度ではなく待機時間の設計によって非アクショナブルなアラートに対処した。 IBM Tivoli モニタリングシステムを運用する現場では、モニタリング条件を保守的に設定する慣行のため、システム管理者がチケットを開いてサーバに接続しても問題が見当たらない非アクショナブルチケットが大量発生していた。 Tang らは、非アクショナブルアラートの大多数が一過性であり、一定時間待機すれば自然に消えるという観察から出発する。 あるソフトウェアサービス状態監視の状況では、非アクショナブルアラートの 75% 超が 20 分以内に自動消滅した(Figure 2) (Source: [[@2012__NOMS__Optimizing System Monitoring Configurations for Non-Actionable Alerts]])。 ![[_attachments/noms2012-situation/fig2-figure.png]] **図5-1**:非アクショナブルアラートの持続時間分布で、10 分未満と 10 分から 20 分の 2 つの階級に度数が集中している。本文の「75% 超が 20 分以内に自動消滅した」という数値は、この左端 2 本の高さが全体に占める割合に対応する。待機時間の設計という発想がこの分布から導かれた。 (Source: [[@2012__NOMS__Optimizing System Monitoring Configurations for Non-Actionable Alerts]], 図 2) 提案手法は、過去のアラートとインシデントチケットのオフライン解析から量的アソシエーションルールマイニング(Srikant and Agrawal, SIGMOD 1996)で予測ルールを生成し、Laplace 精度の降順でルールを選択したうえで、各ルールにカバーされる一過性アラートの最大持続時間を待機時間としてチケット生成を遅延させる (Source: [[@2012__NOMS__Optimizing System Monitoring Configurations for Non-Actionable Alerts]])。 待機時間はリアルアラートの最大許容遅延時間を超えないよう設計されており、リアルアラートであっても SLA の許す範囲で遅延するだけで見逃しは発生しないという保証がつく (Source: [[@2012__NOMS__Optimizing System Monitoring Configurations for Non-Actionable Alerts]])。 同じ非アクショナブルアラートという課題に対し、2009 年の研究は重要度による選別、2012 年の研究は時間による選別という異なる軸で対処している。 前者は複数ルールの合意を得て「どれを見るか」を決め、後者は自然消滅を待って「いつ見るか」を決めており、判断の粒度そのものが異なる。 評価は IBM Tivoli モニタリングシステムの本番サーバから収集した 2011 年の実データで行われた(Account1 は総イベント数 18,974、非アクショナブルイベント数 9,281、属性数 33、状況数 73、ノード数 989。Account2 は総イベント数 50,377、非アクショナブルイベント数 39,971、属性数 1,082、状況数 320、ノード数 1,212。各 3 か月間の収集、最大遅延 360 分、遅延比率 0.25)。 Account1 では非アクショナブルチケットの 25% 超を削減し、リアルチケットの遅延は 3% 未満にとどまった。 Account2 では非アクショナブルチケットの 75% 超を削減し、リアルチケットの遅延は同じく 3% 未満だった (Source: [[@2012__NOMS__Optimizing System Monitoring Configurations for Non-Actionable Alerts]])。 Account2 の性能が高い理由は、非アクショナブルアラートの比率が約 79% と高く、イベント属性数も 1,082 と多いため予測ルールの抽出余地が大きいことにある。 比較対象の Revalidate は全チケットを一律遅延させる手法であり、非アクショナブルチケットの削減率こそ高いが、リアルチケットへの遅延が本手法の 1,000 倍から 10,000 倍に達する (Source: [[@2012__NOMS__Optimizing System Monitoring Configurations for Non-Actionable Alerts]])。 Tang らが手法選択の理由として挙げるのは、モニタリング状況自体が量的アソシエーションルールと等価であるため既存システムへの組み込みが容易であることに加え、システム管理者や顧客がルールの正当性を人間の判断で検証できることである。 SVM やニューラルネットワークは精度が高くても、監視設定ルールとして実装し説明することが困難だとして退けられている。 論文は限界も明記しており、動的で頻繁に変化する IT 環境には月次バッチ処理の粒度が合わない可能性があること、属性名が異なるだけの重複ルールへの自動対処がないことを課題として挙げる (Source: [[@2012__NOMS__Optimizing System Monitoring Configurations for Non-Actionable Alerts]])。 > [!important] 2009 年の研究は統計的な不変条件推定とランキングというブラックボックス寄りの手法を選び、2012 年の研究は人間が検証可能なアソシエーションルールを選んだ。同じ「精度より説明可能性」という優先順位は、第 6 章の FMEA にも独立に現れる (Source: [[@2009__ICAC__Ranking the Importance of Alerts for Problem Determination in Large Computer Systems]], [[@2012__NOMS__Optimizing System Monitoring Configurations for Non-Actionable Alerts]], [[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視]])。 ### 第 6 章　監視実務の常識化 ![[Attachments/アラート管理の教科書/chapter-06.png]] ここまでの学術研究とは対照的に、2011 年の『ウェブオペレーション』は数理理論に一切言及せず、Flickr や Ganglia の実例から監視の実務知を積み上げる。 第 3 章はマット・マッシーとジョン・オルスポーによる執筆で、メトリクスの収集とアラートは目的の異なる別の活動であると強調する。 メトリクスの収集はガソリンメーターの残量表示、アラートは「空」の警告ランプに相当するという比喩で、両者を担当するツールを分離しておくことの利点が説かれる (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]])。 Flickr では、メトリクス収集ツールの Ganglia と監視アラートツールの Nagios を分離して運用し、この分離が複合条件による洗練されたアラート設計を可能にした。 具体的には、Apache のプロセス数とデータベースのコネクション数の両方が Critical の閾値に達した場合にのみアラートを出す条件により、ノイズが軽減された (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]])。 これは、第 4 章のデュレーションフィルタや第 5 章の NTV と同型の、複数シグナルの一致を要求する設計原理が、実務の現場でも独立に発見されていたことを示す (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]], [[@1998__IWSM__Adaptive Thresholding for Proactive Network Problem Detection]], [[@2009__ICAC__Ranking the Importance of Alerts for Problem Determination in Large Computer Systems]])。 もう 1 つの設計は、写真や動画のアップロード数のように 1 日のピークと谷の差が既知の指標に対し、その差を大きく超える急激な変化にのみアラートを出す「変化の加速度」に基づく設計である。 メトリクス自体は、ビジネス、アプリケーション機能、システムとサービスという時間分解能の異なる 3 層に整理され、機能をローンチする前にイベントメトリクスの収集を準備しておくべきだという教訓が Flickr の実例から導かれる (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]])。 マッシー自身が Ganglia の設計思想を語る節では、収集と集約のコストを低く保つこと、新規ノードやメトリクスを自動発見すること、通信の信頼性より鮮度を優先することが一貫した原則として挙げられる。 gmond はクラスタ内の軽量な UDP、gmetad は分散クラスタを接続する TCP というように、収集タスクの性質に応じてトランスポートを使い分ける設計であり、マルチキャストによるゼロ設定はノード数百までしかスケールしない (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]])。 第 6 章は devopsdays の創始者パトリック・デボイスによる一人称のエッセイで、自身の 3 つの職歴を貫く監視の旅として、単純な HTTP 疎通確認から応答時間、依存関係、組織横断、アラート設計へと段階的に高度化する過程を描く。 デボイスは、可用性を A = MTTF/MTBF = MTTF/(MTTF+MTTD+MTTR) という式で定式化する。 MTTD は故障の発見、通知、原因理解までを含む複合的な時間、MTTR は既知の状態へのリセットや正しい情報の発見までを含む復旧時間であり、可用性を上げるには MTTD と MTTR を下げ MTTF を上げる必要がある (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視]])。 コンポーネントの依存関係は直列、並列、結合の 3 種に分類され、冗長性は単一障害点を排除する一方、複雑さの増大というオーバーエンジニアリングの罠を伴うと注意が促される。 サービスの確認には可用性、機能性、品質、状況、信頼性という 5 つのレベルがあり、確認結果の収集方法は監視システム自身が確認するアクティブチェックと、他のツールから監視システムへ入力するパッシブチェックに分かれる (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視]])。 閾値は事前に定義するのが難しく継続的な改善を要するとされ、最小値と最大値だけでは急激な変化を検知できないため最大値変化率を監視する必要があると述べられる。 状態遷移の速度が非常に速い場合は振動(flapping)と呼ばれ、振動状態が続く間は通知を 1 つに絞る仕組みが望ましいとされる (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視]])。 アラートは対応可能でなければならず、対応不能なアラートで人間の手を煩わせるのはエネルギーの無駄だと明言される。 アラートが多すぎるとエンジニアは燃え尽き症やオオカミ少年化に陥り、重要なアラートが無視されるようになる (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視]])。 この対応可能性を担保する手段として、FMEA(Failure Mode and Effects Analysis)を用いて可能性のある障害を一覧化し、検知度、発生度、深刻度でスコアづけすることで監視すべき最も重要な対象を絞り込む方法が示される (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視]])。 FMEA は、第 5 章で SVM やニューラルネットワークではなく人間が検証できるアソシエーションルールが選ばれた判断と同じく、精度そのものよりも運用者が判断し検証できることを優先する設計思想である (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視]], [[@2012__NOMS__Optimizing System Monitoring Configurations for Non-Actionable Alerts]])。 監視システム自身も単一障害点になりうるため、本番環境と別の管理ネットワーク、DNS、通知経路を用意し、監視システム自体を監視し、冗長化し、保護する必要があるとされる。 「誰が見張りを見張るのか」という古代ローマの警句が引用され、監視を監視することの必要性が古典的な問いとして位置づけられる (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視]])。 組織の責任区分が曖昧なとき、自らの潔白を証明しようとして無駄な時間がかかる現象は MTI(Mean Time to Innocence)と呼ばれ、部門間の継続的な知識共有がこれを減らすとされる (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視]])。 アラート対応の実務では、通知先を人でなく役割に割り当てること、確認応答を要求し一定時間内に応答がなければ再送すること、封じ込め、除去、回復という 3 段階で対応することが推奨される (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視]])。 2 つの章を通じて一貫するのは、監視はシステムそのものではなくエンドユーザとビジネスを支援するために存在するという立場であり、アラート設計の技術的な精緻さよりもこの立場との整合が優先されるべきだという主張である (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視]])。 Burgess の 2000 年論文が群論、組合せ論、ゲーム理論で理想状態を公理的に定義しようとしたのに対し、この 2 章は MTTD、MTTR、MTBF という経験的な指標と Ganglia の設計判断を語るのみで、数理理論への言及は一度もない (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]], [[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視]], [[@2000__arXiv__On the theory of system administration]])。 Burgess 自身が 2014 年に業界には体系的研究の更新が必要だと述べていることは、この断絶が Burgess にも自覚されていたことを示唆する (Source: [[@2014__markburgess.org__Infrastructure Management Timescales]])。 第 I 部が扱う文献群を通じて見えるのは、理論化、統計的検知、アラート選別、実務知の集積という 4 つの系譜が、同じアラート管理という問題を別々の言語で並行して立てていた 1990 年代から 2012 年の姿である。 --- ## 第 II 部　症状ベースアラーティングの確立(2016 年から 2018 年) ### 第 7 章　症状と原因の分離 ![[Attachments/アラート管理の教科書/chapter-07.png]] 前史から引き継いだ課題は、分散システムの監視をどう設計するかという問いに、SRE 実務が 2016 年前後にほぼ同時多発的に同じ答えへ収束した点にある。 #### 起点としての Ewaschuk の文書 収束の起点に置けるのが、Rob Ewaschuk(Google SRE)が 2014 年から 2015 年にかけて公開 Google Docs として書き、改訂を続けた「My Philosophy on Alerting」である。 この文書は後に SRE Book 第 10 章の基礎になったとされる。 根拠は 7 年間のオンコール経験であり、定量評価は伴わない (Source: [[@2015__Rob Ewaschuk__My Philosophy on Alerting]])。 Ewaschuk はページの条件を、緊急(Urgent)、重要(Important)、実行可能(Actionable)、実在(Real)の 4 つに絞る。 「また鳴ったか」と確認するだけのページや、スクリプトで自動復旧できる定型対応のために人間を起こしてはならない。 人間が緊張感を持って緊急対応できるのは 1 日あたり数回が限界であり、過剰監視は過少監視より害が大きいとされる (Source: [[@2015__Rob Ewaschuk__My Philosophy on Alerting]])。 症状と原因の区別もここで明文化される。 MySQL のダウンは近接原因(proximate cause)であり、クエリの失敗が症状である。 ユーザーが関心を持つのは、可用性と基本機能、レイテンシ、正確性と完全性と鮮度と永続性、個別機能の 4 カテゴリに限られ、症状ベースのアラートはこの 4 つを対象にする (Source: [[@2015__Rob Ewaschuk__My Philosophy on Alerting]])。 原因ベースのアラートには 3 つの弊害が挙げられる。 冗長化やフェイルオーバーが働いてユーザー影響がないのに鳴ること、インフラ変更のたびに偽のページが出てルール保守が泥沼化すること、原因と症状の両方に張ると重複によるアラームストームが起きることである (Source: [[@2015__Rob Ewaschuk__My Philosophy on Alerting]])。 ただし Ewaschuk は原因アラートを全面的には禁じない。 クオータ枯渇や、ほぼ満杯でさらに増加中のストレージ、冗長性を失った N+0 状態のように「崖に向かって歩いている」状態と、トップレベルの症状メトリクスに埋もれる原因の 2 つは例外として許す (Source: [[@2015__Rob Ewaschuk__My Philosophy on Alerting]])。 計測点については、ファンアウト先のバックエンドではなく、ロードバランサのようなスタックの最前線からアラートを出すべきだとする。 最前線なら、ネットワーク遅延やタイムアウトを含む真のユーザー体験を捉えられ、ルール数も集約できるからである (Source: [[@2015__Rob Ewaschuk__My Philosophy on Alerting]])。 症状で起こされた担当者が原因の目星を付けられるよう、同時に発火中の原因系ルールを通知本文に 1 行で添える「Also Firing」という機構も提案されている (Source: [[@2015__Rob Ewaschuk__My Philosophy on Alerting]])。 以下に見る 2016 年の 3 系統は、時系列上この文書の後に位置する。 SRE Book を除く 2 系統が Ewaschuk の文書を参照したかどうかは、wiki のソースからは確認できない。 Google の SRE Book 第 6 章は、モニタリングをホワイトボックスとブラックボックスの 2 種に分け、役割を分担する枠組みを提示する。 ホワイトボックスモニタリングはログやプロファイルなどシステム内部の計装値に基づき、原因の診断とまだ顕在化していない問題の予測に適する。 ブラックボックスモニタリングは HTTP レスポンスコードやレイテンシなど外部から見える振る舞いに基づき、ユーザが現在体験している症状を捉えるのに適する。 両者は補完関係にあり、ブラックボックスは今何が壊れているかを示し、ホワイトボックスはなぜ壊れているかと、もうすぐ壊れそうなものを示す (Source: [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]])。 同じ 2016 年、Rabenstein(SoundCloud)は SREcon16 Europe で、分散システムでは原因と症状が緩く結合すると述べた。 単一マシンの停止やロードアベレージの高騰、ディスクや CPU の使用率などは、システムの規模が上がるほど問題の良いシグナルとは限らず、ノイズになりうる (Source: [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]])。 ページは人間の緊急反応を消費する希少資源であり、その回数には限界があるため、すべてのページはアクショナブルでなければならないと Rabenstein(SoundCloud)は主張する。 ブラックボックス監視はユーザから見える進行中の症状に向き、ホワイトボックス監視は差し迫った問題や原因調査に必要だが、内部詳細へページする誘惑は抑える必要があると Rabenstein(SoundCloud)は説く。 原因は不要ではなく、チケットや情報通知、調査用の粒度として扱い、人間を起こす経路とは分けるべきだとされる (Source: [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]])。 Treat(OmniTI)は同じ年の SREcon16 で、用語そのものを分離するガバナンスを提示した (Source: [[@2016__SREcon16__Less Alarming Alerts]])。 メトリクスは測定できるもの、グラフは傾向を見るシステム、通知はイベント通知としてのメール、アラートは人を起こすページと段階的に整理し、あらゆる異常通知をページにしないことを求めた (Source: [[@2016__SREcon16__Less Alarming Alerts]])。 SRE Book のホワイトボックスとブラックボックスの役割分担、Rabenstein(SoundCloud)の規模依存の観察、Treat(OmniTI)の用語分離というガバナンスは、いずれも独立した動機から出発しながら、ページを症状に限定するという同じ結論に到達している。 > [!important] 3 系統はいずれもページを症状に限定するという結論で一致するが、Google は分担の設計思想として、SoundCloud は規模依存の観察として、OmniTI は事前ガバナンスとして、それぞれ異なる出発点から到達している (Source: [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]], [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]], [[@2016__SREcon16__Less Alarming Alerts]])。 2018 年になると Chamberlain(Xero)は、クラウド移行後に倍増したアラートへの対処として、Rob Ewaschuk の草稿論文を参考に、根本原因ベースの個別アラートを症状ベースの少数アラートへ集約したと述べる (Source: [[@2018__SREcon18Asia__You Can't Stop Fires with an Ambulance]])。 この草稿は口頭説明でのみ言及され、当時 Xero 社内で回覧されていたという (Source: [[@2018__SREcon18Asia__You Can't Stop Fires with an Ambulance]])。 Xero が参照した草稿が本章冒頭の Ewaschuk の文書と同一かどうかは、発表の記述からは確定できない。 ただし「根本原因ベースから症状ベースへ」という Xero の転換の向きは、その文書の主張と一致する (Source: [[@2018__SREcon18Asia__You Can't Stop Fires with an Ambulance]], [[@2015__Rob Ewaschuk__My Philosophy on Alerting]])。 症状ベースへの転換は、静的な閾値設計そのものの見直しも伴った。 Rabenstein(SoundCloud)は、Nagios 型の静的なディスク使用率 85% 閾値が、横ばいで問題ない状態と急増して枯渇へ向かう状態を同じアラートとして扱ってしまう欠陥を指摘した (Source: [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]])。 代わりに Prometheus 型の時系列予測では、現在値ではなく将来の枯渇見込みを見て、横ばいの高使用率では鳴らさず急増時にだけ鳴らす設計が可能になるとした (Source: [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]])。 ![[_attachments/srecon16europe_slides_rabenstein/page-015.png]] **図7-1**:同じ 85% の閾値を超えた 2 つの時系列を並べたもので、左は横ばいのまま推移し右は急増して 100% に達する。本文が述べた「横ばいで問題ない状態と急増して枯渇へ向かう状態を同じアラートとして扱ってしまう」という静的閾値の欠陥は、左右どちらも 85% 線を跨いでいることに対応し、傾きによる予測が右だけを鳴らせることを示す。 (Source: [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]], p.15) Wilkinson(Google)は翌 2017 年の SREcon17 Americas で同じ問題を取り上げ、「90% 使用」や「残り 500MB」のような静的しきい値は容量差やワークロード差で偽陽性を生むと述べた (Source: [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]])。 より一般的には、満杯までの時間と人間が修復に要する時間の比較としてアラートを設計すべきだとした (Source: [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]])。 Rabenstein(SoundCloud)と Wilkinson(Google)は 1 年の間隔を置いて同じ問題設定を報告し、いずれも時系列の傾きによる予測という同一の解法に到達している (Source: [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]], [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]])。 ページ用の異常検知は単純で堅牢でなければならないとも Rabenstein(SoundCloud)は付言する (Source: [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]])。 しきい値や因果を自動学習する複雑な仕組みはページ経路には不向きであり、そうした仕組みはページ以外の用途に分けるべきだとされる (Source: [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]])。 なお、ページング条件を SLO 違反という単一の基準へ接地する設計は第 III 部で扱う。 #### 後年の教科書による再確認 症状ベースの原則は、その後の実務書で前提として扱われるようになる。 Mike Julian の『入門 監視』(2019 年、邦訳)第 1 章は、先に「動いている」とは何かを定義し、それを基準に監視せよと説く。 Web アプリなら `HTTP GET /` のレスポンスコード、ページ内の特定文字列、リクエストレイテンシが基準になる。 OS の低レベルなメトリクスは診断には有用だが、人を起こすアラートには値しないとされる (Source: [[@2019__OReillyJapan__入門 監視 - Chapter 1 監視のアンチパターン]])。 同書第 2 章は、監視をロードバランサのようなユーザーに最も近い地点から始め、最初の指標として HTTP の 5xx、次にレイテンシを見るよう勧める (Source: [[@2019__OReillyJapan__入門 監視 - Chapter 2 監視のデザインパターン]])。 これは Ewaschuk のいう最前線からの監視と同じ設計だが、Ewaschuk の 4 カテゴリより範囲が狭く、原因アラートの例外(N+0、増加中のストレージ)にも触れない (Source: [[@2015__Rob Ewaschuk__My Philosophy on Alerting]], [[@2019__OReillyJapan__入門 監視 - Chapter 2 監視のデザインパターン]])。 2026 年の SRE Book 第 2 版は、第 1 版の「症状でアラートせよ」に「いつ症状が重大か」を判断する層を加える。 静的閾値は低トラフィックでは過敏になり高トラフィックでは寛容すぎるため、統計や ML のベースラインからの逸脱で判定するという方向である(判定の数理は第 12 章で扱う)。 一方で、クォータや資源使用量のような原因ベースのアラートも全サービスへ横断設定し、盲点を作らないとする (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 9 Observability and Monitoring]])。 同書第 22 章は、原因(CPU 90%)ではなくユーザー影響(レイテンシが高い)で鳴らす症状ベースのアラートを、異種の技術スタックが混在する環境で監視を統一する手段としても位置づける (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 22 SRE in Diverse Environments]])。 同書第 9 章は、症状を測る側の盲点も指摘する。 Google Maps で検索結果が 0 件になる障害は、RPC のエラーとレイテンシの監視では「成功」に見え、サーバー側の時系列から作った SLO は顧客が目的を果たせない状態でも健全を示しうる。 そこで同書は、重要なユーザージャーニー(CUJ)を計装した顧客中心の SLO へ移ることを求める (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 9 Observability and Monitoring]])。 この時期の文献はいずれも定量評価を欠くか自社の事例報告にとどまり、比較対象や統制群を持つ研究ではない。 Rabenstein(SoundCloud)、Treat(OmniTI)、Chamberlain(Xero)の報告は、いずれも自社の本番テレメトリに基づく経験の記述であって、公開ベンチマークや研究室での再現実験は伴わない。 ### 第 8 章　ゴールデンシグナルと時系列基盤 ![[Attachments/アラート管理の教科書/chapter-08.png]] SRE Book 第 6 章は、サービスの健全性を把握するために最低限計測すべき指標として、レイテンシ、トラフィック、エラー、サチュレーションという 4 つのゴールデンシグナルを提示する (Source: [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]])。 レイテンシはリクエストの処理にかかる時間で、成功リクエストと失敗リクエストのレイテンシを区別しなければならない。 高速に返るエラーレスポンスを含めると、成功リクエストの実態が見えなくなるためである (Source: [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]])。 トラフィックはシステムに対する需要の量で、ウェブサービスなら秒間 HTTP リクエスト数、ストリーミングなら I/O レートやセッション数など、サービス種別に応じた指標で計測する (Source: [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]])。 エラーは失敗したリクエストの割合で、明示的な失敗、暗黙的な失敗、ポリシー違反を区別する (Source: [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]])。 サチュレーションはシステムリソースの利用率で、最も制約の厳しいリソースに注目し、多くのシステムは利用率 100% に達する前に性能が劣化するため、目標値をあらかじめ設定しておく (Source: [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]])。 レイテンシをはじめとする指標は平均値では評価しない。 平均値で評価すると外れ値やロングテールが隠蔽されるため、50 パーセンタイル、99 パーセンタイル、99.9 パーセンタイルの分布を計測し、ユーザ体験の実態を可視化する (Source: [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]])。 平均レイテンシが 100ms でも 99 パーセンタイルが 5 秒であれば、100 リクエストに 1 回はユーザが著しい遅延を体験している (Source: [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]])。 『入門 監視』第 4 章は、この統計の選び方を実務者向けに展開する。 パーセンタイルは外れ値を除いて大部分のユーザーの品質を表すが、平均を取れず、期間をまたぐときは元データから計算し直す必要がある。 データポイントを捨てているので、レイテンシでは最大値も併せて見る。 手法を選ぶ前に、データに大きな偏りがあるか、極端な外れ値が頻発するか、値に上限と下限があるかを確かめるよう求める。 レイテンシには理論上の上限がなく、CPU 使用率は 0% から 100% に収まる (Source: [[@2019__OReillyJapan__入門 監視 - Chapter 4 統計入門]])。 同章は、閾値のチェックをホストではなく時系列 DB の値に対して行い、データ収集と閾値判定を別の機能に分けることも勧める (Source: [[@2019__OReillyJapan__入門 監視 - Chapter 4 統計入門]])。 これは 2011 年の Flickr の収集と警告の分離(第 6 章)と、次に見る Borgmon の宣言型モデルと同じ方向の設計である。 ゴールデンシグナルを実際に評価するための基盤が、SRE Book 第 10 章が扱う Borgmon である。 Borgmon は 2003 年頃、Borg クラスタ管理システムと並行して誕生した Google 内部のモニタリングシステムである (Source: [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]])。 従来のモニタリングはターゲットごとにチェックスクリプトを実行する命令型で、ターゲット数に比例して負荷が増大していた。 Borgmon はメトリクスを並列に収集し、ルールを一元的に評価する宣言型モデルへ転換することで、このスケーラビリティの問題を解消した (Source: [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]])。 オープンソースの Prometheus は Borgmon の設計から直接的な影響を受けている (Source: [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]])。 時系列データはタイムスタンプと値のペアとしてラベルセットで多次元的に組織化される。 `{var=http_requests, job=webserver, instance=host0:80, zone=us-west}` のように、複数のラベルの組み合わせで 1 つの時系列が一意に識別される (Source: [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]])。 ルールは `rate()` や `sum without instance()` などの代数的な演算とラベルフィルタリングを組み合わせ、インスタンスをまたいだアグリゲーションを固定間隔で評価する。 アラートルールの例として、エラー率が 1% を超過し、かつ絶対的なエラー数が毎秒 1 件を超えている状態が 2 分間持続した場合に発火するルールが示される。 比率としての閾値と絶対数としての閾値を二重に課すことで、統計的に無意味な少量のエラーでの誤報を防止する。 `for 2m` に相当する最小持続時間の条件は、フラッピング防止のために求められる仕組みである (Source: [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]])。 これらのルール設計の背後には、監視の保守コストをサービス規模に対して劣線形に抑えるという設計目標がある。 メトリクス収集とアラート評価を分離することで、モニタリングの保守コストをサービス規模に対して劣線形に増加させられると SRE Book 第 10 章は述べる (Source: [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]])。 同じ著者である Wilkinson(Google)は、翌年の SREcon17 Americas でもほぼ同じ言葉でこの目標を再提示し、サービス規模の伸びに対して運用作業の保守コストが劣線形に抑えられなければ監視は破綻すると述べた (Source: [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]])。 Wilkinson(Google)はさらに、`task:requests:rate10s` のようにレベルと操作と名前を含む変数の命名規約を示し、データセンター単位やグローバル単位へトポロジに沿って集約する記録ルールが、この保守コストの劣線形化を実装レベルで支えると説明した (Source: [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]])。 ### 第 9 章　ノイズとの戦いの主題化 ![[Attachments/アラート管理の教科書/chapter-09.png]] 症状と原因の分離が確立した後、SRE 実務の焦点はアラートそのものの質、つまりノイズとの戦いへ移る。 Treat(OmniTI)は SREcon16 で、メトリクス、グラフ、通知、アラートという 4 つの用語を段階的に区別した。 アラートは既存の理解の外側でシステムが振る舞っている証拠として扱われるべきで、改善は事業側が合意できる語彙、つまりビジネス影響によって説明されなければならないとも述べた (Source: [[@2016__SREcon16__Less Alarming Alerts]])。 Treat(OmniTI)は悪いアラートの判定基準を 4 点に整理した。 ビジネス影響を判断できない、修復が不要である、誰にも知らせる必要がない、回避策がある、のいずれかに該当するアラートは悪いアラートであり、削除するか通知へ変換するか修正を実装するかのいずれかで対処すべきだとした。 修復できないなら起こす必要はなく、朝まで待てるなら起こす必要もないという原則も添えられる (Source: [[@2016__SREcon16__Less Alarming Alerts]])。 偽陽性が増えれば反応性は下がるとも Treat(OmniTI)は指摘する。 医療の集中治療室、車の警報、虚偽緊急通報、航空管制の偽警報研究を並べ、偽陽性が応答を鈍らせる構造は IT 運用に限らないことを示した (Source: [[@2016__SREcon16__Less Alarming Alerts]])。 サイト停止時に監視が 200 応答コードだけを確認し、応答コードが存在しない状態を見落とした事例を挙げ、OOM は根本原因になりうるが常に停止を引き起こすわけではないため、単純に OOM でページすれば偽陽性が増えると述べた。 代替として、OOM 検知、アプリサーバ再起動、問題プロセス終了、新ノード起動と旧ノード停止を自動化し、すべて失敗した場合だけアラートする設計を示した (Source: [[@2016__SREcon16__Less Alarming Alerts]])。 技術的な削減策を大規模に実施した事例が、Chen(Baidu)による 2017 年の報告である。 Baidu の監視システム Argus は、1 人あたり 1 日 100 件超のアラート SMS を送信し、有効アラート率は 15% 未満だったと Chen(Baidu)は報告する。 重複率 58%、夜間のアラート確認率 25%、受信者平均 3 名、単一インスタンスアラート 88% という 4 つの観察から、アラートグルーピング、重要度キャリブレーション、オンコールエスカレーション、自動修復という 4 つの施策を導いた (Source: [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]])。 アラートグルーピングでは、同一ルールのアラートをバッファリングして一括配信するほか、アソシエーションルールマイニングによるクロスモジュールパターンの検出、ネットワークデバイス障害時のアラートサージ抑制を組み合わせた (Source: [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]])。 重要度キャリブレーションでは、アラート送信後の一定時間内に監視画面へのアクセスログが存在するかどうかで確認率を測定し、夜間に限って重要度レベルを見直した (Source: [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]])。 単一インスタンスアラートの 40% 超が単純操作で復旧可能だったため、ディスク空き容量アラートでのログ自動削除やプロセス再起動などの自動修復をアラートトリガで実行し、自動修復が実行されたアラートは配信自体を抑制した (Source: [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]])。 2015 年 1 月から 2016 年 11 月の週次アラート数の推移では、2015 年 5 月から 7 月頃の施策投入以降、アラート量は 85% 削減を維持したと報告される。 ただし対象期間、対象サービス範囲の詳細、および 4 施策それぞれの寄与率はスライドに記載がなく、条件記載なしとして扱う (Source: [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]])。 ![[_attachments/srecon17asia-chen-draining-the-flood/page-018.png]] **図9-1**:2015 年 1 月から 2016 年 11 月の週次アラート数を、全体、日中、夜間の 3 系列で示したもの。施策投入期間を示す帯より後で水準が下がり、以降低い水準を保っている。本文の 85% 削減という数値はこの推移図の読み取りに基づいており、帯の幅が示すとおり 4 施策が同時期にまとめて投入されたため、施策ごとの寄与を分離できないことも同じ図から読み取れる。 (Source: [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]], p.18) 技術的施策だけでなくマネジメント層の支援も必要だとも Chen(Baidu)は付言し、重要度レベルの引き下げの推進と確認率のオンコール業務評価への組み込みを挙げた (Source: [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]])。 Chamberlain(Xero)の 2018 年の報告は、この技術的削減がインシデント発生の抑制とは異なる対象であることを示す逆説として読める。 Xero では、症状ベースアラーティングへの簡素化と chatbot によるインシデント管理自動化という技術的対策を講じたにもかかわらず、2016 年 2 月から 2018 年 3 月にかけて月次インシデント数は年を追うごとに明確な増加トレンドを示したと Chamberlain(Xero)は報告する。 ポストモーテムのたびに要因を特定し作業項目を作成していたにもかかわらず、全体の発生率は下がらなかった (Source: [[@2018__SREcon18Asia__You Can't Stop Fires with an Ambulance]])。 Chamberlain(Xero)は自ら 2 年分のポストモーテムを手動で横断集計し、リリースプロセスが最多の要因であり、容量関連の約 4 倍の頻度を占めることを発見したと述べる。 この横断集計を 2 年間怠っていたことが最大の反省点だと Chamberlain(Xero)は振り返る (Source: [[@2018__SREcon18Asia__You Can't Stop Fires with an Ambulance]])。 ポストモーテムのアクション実施率は約 50% にとどまり、原因は参加者がオンコールの SRE、オンコールのプロダクト担当、カスタマーサクセスに限られ、機能開発と信頼性作業の優先順位を決定できる権限者が同席していなかったことにあった。 テックリード、プロダクトオーナー、上級マネジメントという 3 グループを、顧客影響とビジネス目標という「正しい言語」で会話に巻き込む必要があると Chamberlain(Xero)は結論づける (Source: [[@2018__SREcon18Asia__You Can't Stop Fires with an Ambulance]])。 > [!contradiction] Chen(Baidu)はアラート量そのものの 85% 削減を報告する一方、Chamberlain(Xero)は症状ベースアラーティングと chatbot 自動化を講じてもインシデント数自体は増え続けたと報告する (Source: [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]], [[@2018__SREcon18Asia__You Can't Stop Fires with an Ambulance]])。 > 両者は「アラート量の削減」と「インシデント発生の抑制」という異なる対象に取り組んでおり、Xero の事例は技術的介入だけでは足りず、ポストモーテムの横断集計という組織的な真因の発見に 2 年を要したことを示す (Source: [[@2018__SREcon18Asia__You Can't Stop Fires with an Ambulance]])。 ### 第 10 章　大規模事業者の監視システム ![[Attachments/アラート管理の教科書/chapter-10.png]] 2017 年から 2018 年にかけて、症状ベースアラーティングの原則は大規模事業者の監視システム全体の設計に組み込まれていく。 Bostock(Cloudflare)は SREcon17 Europe で、当時 116 拠点、600 万以上のウェブサイトを配信するエニーキャストエッジネットワークを Nagios から Prometheus へ移行した 18 か月の経験を報告した。 毎日のインターネットリクエストの 10%、HTTP 500 万リクエスト毎秒、DNS 120 万リクエスト毎秒を、世界 116 データセンター、150 か国で処理していたという規模が背景にある (Source: [[@2017__SREcon17 Europe__Monitoring Cloudflare's Planet-Scale Edge Network]])。 各 PoP 内に Prometheus インスタンスを配置し、監視対象と同じ障害ドメインで動作させることで、ネットワーク障害時にも監視自体が生き残る設計を採ったと Bostock(Cloudflare)は説明する (Source: [[@2017__SREcon17 Europe__Monitoring Cloudflare's Planet-Scale Edge Network]])。 ![[_attachments/srecon17e-bostock-cloudflare-monitoring/frame-006.jpg]] **図10-1**:1 つの PoP の内部構成で、Prometheus が同じ PoP 内のサーバ群を直接スクレイプしている。本文が述べた「監視対象と同じ障害ドメインで動作させる」という設計は、矢印が PoP の外へ出ていないことに対応する。 (Source: [[@2017__SREcon17 Europe__Monitoring Cloudflare's Planet-Scale Edge Network]], frame-006) コアデータセンターの Prometheus が各 PoP の Prometheus からメトリクスのサブセットをフェデレーションで集約し、全メトリクスではなくサービスレベルの概観に十分なサブセットだけを転送する (Source: [[@2017__SREcon17 Europe__Monitoring Cloudflare's Planet-Scale Edge Network]])。 アラート設計の原則として、原因でなく症状にアラートすること、マシンでなくサービスにアラートすることを組織的に推進したと Bostock(Cloudflare)は述べる。 症状にアラートすれば個別マシンの負荷ではなくサービスレベルの影響が見え、アラートノイズが大幅に減るとし、すぐに対応不要な問題は JIRA チケットへ送りチームがバックログとしてトリアージする運用にしたという (Source: [[@2017__SREcon17 Europe__Monitoring Cloudflare's Planet-Scale Edge Network]])。 良い監視は無料では実現せず、トレーニングと投資、組織変革が必要で時間がかかるとも Bostock(Cloudflare)は付言する (Source: [[@2017__SREcon17 Europe__Monitoring Cloudflare's Planet-Scale Edge Network]])。 Bostock(Cloudflare)は同じ 2017 年の PromCon で、この構成の実装をさらに具体的に示した。 各 PoP には独立した 2 台の Prometheus を置き、両者が同じ PoP の全サーバーをクラスタリングも状態共有もせずに並行してスクレイプする。 コアの Prometheus は生メトリクスを取らず、PoP 側の recording rule で事前集約した拠点単位のメトリクスと死活の `up` だけを 30 秒間隔のフェデレーションで集める。 WAN 帯域と中央の負荷を抑えるためである。 発表時点で本番の Prometheus は 185 台、1 台あたり最大 460 万時系列であり、保持期間は 15 日に絞って長期分析には使わない (Source: [[@2017__PromCon__Monitoring Cloudflare's Planet-Scale Edge Network with Prometheus]])。 移行の動機は、集中型の Nagios が単一マシンで数十万件のチェックを行っており、障害時に監視自体がボトルネックになったことにあった (Source: [[@2017__PromCon__Monitoring Cloudflare's Planet-Scale Edge Network with Prometheus]])。 6 年後の 2023 年、Lukasz Mierzwa(Cloudflare)は規模が 916 インスタンス、合計約 49 億時系列(平均約 500 万、最大約 3,000 万系列毎インスタンス)に達したと報告する。 この規模での主なリスクはカーディナリティ、すなわちラベルの一意な組み合わせ数の爆発であり、その防御は第 13 章で扱う (Source: [[@2023__Cloudflare-Blog__How-Cloudflare-Runs-Prometheus-at-Scale]])。 翌 2018 年、Ren Xinchi(Alibaba Group)は SREcon18 Asia/Australia で、30 以上の事業部にまたがる数百万台のオンラインサーバを運用する Alibaba の全社モニタリングシステムを報告した。 1,000 万以上のモニタリング項目から数十億のアラームとデータが生成されるという規模のなかで、インフラストラクチャ層、システムとアプリケーション層、ビジネス層、顧客フィードバック層の 4 層構造を採り、ビジネス層を最上位に据えた (Source: [[@2018__SREcon18 Asia__Introduction to Alibaba Monitoring System]])。 ビジネス層が最も重要と位置づけられる理由は、顧客影響と直結し「30% の顧客が影響を受けている」のように定量的に表現できる点にあると Ren Xinchi(Alibaba Group)は述べる。 ビジネス健全性は、総数、成功数、成功率、応答時間、失敗数という 5 つのゴールデンエレメントの組み合わせで統合的に表現される (Source: [[@2018__SREcon18 Asia__Introduction to Alibaba Monitoring System]])。 たとえば総数が増加しながら成功率が低下していれば、一部の顧客が障害に遭遇してリトライしていると解釈できる。 IDC 別、エラーコード別、クライアント別などの次元分析によって、障害の局所化も支援される (Source: [[@2018__SREcon18 Asia__Introduction to Alibaba Monitoring System]])。 > [!important] SRE Book の 4 つのゴールデンシグナルはシステム層の健全性を測るのに対し、Alibaba の 5 ゴールデンエレメントはビジネス層の顧客影響を測る (Source: [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]], [[@2018__SREcon18 Asia__Introduction to Alibaba Monitoring System]])。 > 少数の指標の組み合わせでサービス全体の健全性を要約するという発想は共有されながら、対象とする層が異なる (Source: [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]], [[@2018__SREcon18 Asia__Introduction to Alibaba Monitoring System]])。 障害の約 70% が変更に起因するため、モニタリンググラフ上に変更情報を重ねて表示し、障害発生の 1 分から 2 分前に行われた変更を即座に特定してロールバックの判断を加速する運用も導入されたと Ren Xinchi(Alibaba Group)は説明する (Source: [[@2018__SREcon18 Asia__Introduction to Alibaba Monitoring System]])。 インテリジェントモニタリングの導入によりアラーム精度がベースラインの 20% から 80% に改善したとも報告されるが、具体的な手法は本発表では共有されず、前年の同僚の講演に委ねられている (Source: [[@2018__SREcon18 Asia__Introduction to Alibaba Monitoring System]])。 Cloudflare の PoP 内 Prometheus と Alibaba の 4 層構造は、いずれも自社の本番テレメトリに基づく事例報告であり、比較対象を持つ定量評価は伴わない。 第 II 部の文献はすべて SRE 実務の系譜に属し、学術 AIOps や LLM エージェントの知識は含まれない。 --- ## 第 III 部　SLO 接地とルール品質の工学(2018 年から 2026 年) 第 II 部は、ページすべき対象をユーザーに見える症状へ限定するという原則の確立を扱った。 第 III 部は、その症状をサービスレベル目標へ数値として接地し、発火条件そのものを工学的に定式化する系譜と、その定式化を支えるルール自体が壊れていないかを保証する系譜を扱う。 SLI の設計と SLO の設定は [[SLI-SLO教科書]] が扱う。本ページでは繰り返さない。 ### 第 11 章　バーンレートアラートの定式化 ![[Attachments/アラート管理の教科書/chapter-11.png]] Wilkinson は SREcon18 Asia で、SLI を計測、SLO を目標、SLA を経済的合意と三層に整理したうえで、症状を「SLO で計測できるものすべて」と定義した。 分散システムでは可用性を稼働時間の比ではなくリクエスト成功率で定義するほうが適する (Source: [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]])。 症状ベースアラートは SLO が危険になったときだけ発火させるアラートであり、Wilkinson のチームは導入前に Google 全チームで最悪のオンコールシフトを 6 か月ごとの評価で 2 回連続して記録していたが、導入後は 4 週間連続してシフトあたり 2 ページ未満を達成した (Source: [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]])。 #### バーンレートという指標 バーンレートとは、SLO に対してどれだけ速くエラーバジェットを消費しているかを表す指標である。 99.9% で 30 日の SLO では、バーン率 1 が 30 日でちょうど予算を使い切る速度、バーン率 1000 が 43 分で使い切る速度に相当する (Source: [[@2018__Google SRE Workbook__Alerting on SLOs]])。 Google SRE ワークブックは、SLO ベースアラートの目的を、エラーバジェットを大きく消費する重大イベントを予算消費前に通知することと定式化する (Source: [[@2018__Google SRE Workbook__Alerting on SLOs]])。 #### 6 つのアプローチの比較 SRE ワークブックは、単純な短期エラー率閾値から推奨構成までを 6 段階で比較する (Source: [[@2018__Google SRE Workbook__Alerting on SLOs]])。 1. 短期エラー率が SLO 閾値を超えたら通知する。実装は単純だが、短時間の軽微な事象に過敏で重大性を表せない。 2. 長い窓でエラー率を評価する。精度は上がるが、検知時間とリセット時間が長くなり、解決後もアラートが残りやすい。 3. `for` のような持続時間句で長い窓を代用する。重大障害でも軽微障害でも待ち時間が同じ固定値になり、瞬間的に正常化するとタイマーがリセットされるため、100% 障害を 1 時間見逃すなど再現率と検知時間が悪化する。 4. 単一バーン率で通知する。固定量の予算消費に基づけるが、やや低いバーン率を見逃す。 5. 複数バーン率でページとチケットを分ける。再現率と優先度付けは改善するが、重複通知の抑制が必要になる。 6. 複数ウィンドウかつ複数バーン率にする。長い窓で重大性を確認し、短い窓で現在も燃焼中かを確認するため、精度、再現率、検知時間、リセット時間のバランスが最もよい。 評価軸は、精度(検知されたイベントのうち重大イベントである割合)、再現率(重大イベントのうちアラートされた割合)、検知時間、リセット時間(解決後にアラートが残る時間)の 4 つである (Source: [[@2018__Google SRE Workbook__Alerting on SLOs]])。 #### 推奨構成と短窓の設計 推奨される開始点は、ページ用に 1 時間で 2% の予算消費と 6 時間で 5% の予算消費を置き、チケット用に 3 日で 10% の予算消費を置く設計である (Source: [[@2018__Google SRE Workbook__Alerting on SLOs]])。 さらに短い窓を長い窓の約 12 分の 1 程度に置き、長窓と短窓が同時に閾値を超えるときだけ通知すると、精度とリセット時間のバランスが改善する (Source: [[@2018__Google SRE Workbook__Alerting on SLOs]])。 Wilkinson は Fast Burn アラートを次の PromQL 式で示した (Source: [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]])。 ```promql expr: delta(errors[1h]) > (expected_events * error_budget / burn_period) = delta(errors[1h]) > ((1000 qps * 7d) * 0.01 / 24h) = delta(errors[1h]) > 70 ``` この式は、バーン期間中に 1 日分のエラーバジェットを超えたらページするという条件を、アラート窓 1 時間、エラー率閾値 70 件毎秒、スケールされたエラーバジェット 252,000 という具体値に落としたものである (Source: [[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]])。 #### 推奨値と実装値の一致 SRE ワークブックの推奨初期値と、eBay の非同期パイプラインへの実装値は、バーン率の定義(消費率を窓長と遵守期間の比で割った速度)で照らし合わせると数値が一致する。 | ページ用の窓 | SRE Workbook 推奨(予算消費) | eBay 実装(バーン率) | |---|---|---| | 1h と 5m | 1 時間で 2% 消費 | 14.4 | | 6h と 30m | 6 時間で 5% 消費 | 6 | (Source: [[@2018__Google SRE Workbook__Alerting on SLOs]], [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]]) eBay のケースでは、Critical を 1h と 5m でバーン率 14.4(消費予算 2%)、6h と 30m でバーン率 6(消費予算 5%)とし、Warning を 1d と 2h でバーン率 3(消費予算 10%)、3d と 6h でバーン率 1(消費予算 10%)とする 4 段構成を採用した (Source: [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]])。 実際に採用されたのは Warning の 2 段階のみで、Critical の 2 段階は各サービスの SLO 目標値に合わせて個別設定するとされている (Source: [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]])。 ![[_attachments/2025__SREcon25Americas__Beyond-Sequential/page-039.png]] **図11-1**:バーン率の定義式と 4 段構成の対応表。式は「予算消費率かける遵守期間わる警告窓」であり、2% 消費と 1 時間窓から 14.4 が導かれる過程が示されている。本文の表が示した推奨値と実装値の一致は、この計算式を経由して初めて同じ数値として読めるようになる。 (Source: [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]], p.39) #### 非同期パイプラインへの移植 eBay の非同期ランキングサービスは、Producer から Event Queue、Consumer、Retry Queue へと複数ホップする構造を持ち、同期的な HTTP サービスとは形が異なる (Source: [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]])。 それでも可用性 SLI を SUCCESS と ABANDONED の二値に基づく比率として定義し、RETRY を過渡状態として除外することで、複数ウィンドウかつ複数バーン率のアラートの枠組みをそのまま移植できている (Source: [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]])。 実装された Prometheus アラートルールは次のとおりである。0.144 はバーン率 14.4 とエラーバジェット 0.01 の積である。 ```promql (( sli_error:ratio_rate5m{sli_name="SLI_RankingConsumer_RANK_SEED_ITEM_availability"} > 0.144 and sli_error:ratio_rate1h{sli_name="SLI_RankingConsumer_RANK_SEED_ITEM_availability"} > 0.144 )) or (( sli_error:ratio_rate30m{sli_name="SLI_RankingConsumer_RANK_SEED_ITEM_availability"} > 0.06 and sli_error:ratio_rate6h{sli_name="SLI_RankingConsumer_RANK_SEED_ITEM_availability"} > 0.06 )) ``` (Source: [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]]) 同期 HTTP サービス向けに定式化された複数ウィンドウかつ複数バーン率のアラートが、SLI の定義だけを差し替えれば非同期パイプラインへ移植できるという点は、2018 年の定式化が持つ汎用性を示す実例である (Source: [[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]])。 #### SRE Book 第 2 版での再掲と SLO 定義からの自動生成 2026 年の SRE Book 第 2 版第 8 章は、30 日窓の SLO について、1 時間で 2% の速いバーンをページに、3 日で 10% の遅いバーンをチケットに振り分ける構成を再掲する。 これはワークブックの推奨初期値と同じ値である (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 8 Service Level Objectives]], [[@2018__Google SRE Workbook__Alerting on SLOs]])。 第 2 版で新しく書かれたのは、アラートを手で書かない運用である。 Google は SLO Repository を持ち、メトリクスやログからセルフサービスで SLI と SLO を定義すると、集中アラート構成サービスが SLO 定義からアラートを決定的に生成する。 同時に、すべての API やユーザー操作に SLO が要るわけではなく、すべての SLO にアラートが要るわけでもないと明記される (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 8 Service Level Objectives]])。 B2B では顧客の重要度がパレート分布に従うため、集約 SLO が上位顧客の実質的な停止を覆い隠す。 そこで顧客別 SLO を置くが、そのアラートは軽微な劣化ではなく本当の停止を反映させ、バーンレートアラートは信号量が十分な大口顧客に限る。 Google Cloud はこの顧客別 SLO と顧客中心のアラートにより、顧客から報告される前に検知と緩和ができるようになったとされる (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 8 Service Level Objectives]])。 ### 第 12 章　バーンレートの限界と予測的外挿 ![[Attachments/アラート管理の教科書/chapter-12.png]] 前章の複数ウィンドウかつ複数バーン率のアラートは、どのようなサービスにも一様に適用できるわけではない。 低トラフィックのサービスや超高可用性を要求するサービスでは、この適用がそのまま破綻する。 #### 低トラフィックという破綻条件 10 リクエスト毎時のような低トラフィックサービスでは、1 件の失敗が 10% のエラー率になり、99.9% SLO では 1000 倍のバーン率として即座にページ対象になりうる。 対策として、人工トラフィック、関連サービスの上位集約、ユーザー影響を下げるプロダクト変更、SLO の再交渉が挙げられる (Source: [[@2018__Google SRE Workbook__Alerting on SLOs]])。 人工トラフィックは既存のブラックボックスプローブや統合テストを活用できる一方で、実ユーザーだけが影響を受ける障害を隠す危険がある (Source: [[@2018__Google SRE Workbook__Alerting on SLOs]])。 SRE Book 第 2 版第 8 章は、低トラフィックのサービスでは SLO 未達の確信度を二項検定で測るという対策を加える (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 8 Service Level Objectives]])。 同章は SLO モデルそのものの弱点も認める。 事象を数えて成功と失敗に分類できるという前提は、連続的な計算過程や AI モデルの応答の正否では揺らぎ、対応も二値的になって段階的な対応や予防を捉えにくい (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 8 Service Level Objectives]])。 #### 超高可用性という破綻条件 99.999% のような極端に高い可用性目標では、100% 障害が 26 秒で予算を使い切ってしまうため、アラートで守るのではなく、カナリアリリースなど設計側で全停止確率を下げる必要がある (Source: [[@2018__Google SRE Workbook__Alerting on SLOs]])。 Observability Engineering 第 2 版第 12 章はこれを定量化し、SLO ターゲットが約 99.95%(月間許容停止 21 分 54 秒)までは事前対応としてバーンアラートが有効に機能するが、それを超える厳格な SLO では事前予防としての有効性が下がり、劣化の報告と警告の用途に限定されると論じる (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]])。 独立した 2 つのソースが、可用性目標が一定の水準を超えるとバーンレートアラートが守りとして機能しなくなる同じ限界を、異なる言い方で指摘している。 #### 固定ウィンドウとスライディングウィンドウ 固定ウィンドウは暦に従ってリセットされ、スライディングウィンドウは直近 N 日間を常に評価する。 固定ウィンドウは月初に突然バジェットがリセットされる一方、ユーザーの記憶や不満は暦どおりにリセットされないため、SLO の実務にはスライディングウィンドウが適切とされる (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]])。 #### 相対バーンと予測的バーン 相対バーンアラートは、直近のベースラインウィンドウで観測された失敗数と、そのウィンドウでエラーバジェットが比例的に許容する失敗数の比率で発火させる方式であり、総トラフィック量を考慮するため低トラフィック時の誤発火を避けやすい。 理論計算例として、月間 1,000 万リクエストで SLO 99.9%(許容失敗 1 万件毎月)のサービスでは、月間 2,880 個の 15 分ウィンドウがあり、定常状態で 1 ウィンドウあたり約 3.4 件の失敗が許容される。4 倍の相対バーンアラートは直近 15 分ウィンドウで 13 件超の失敗、20 倍なら 68 件超の失敗で発火する (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]])。 予測的バーンアラートは、現在の傾向が続いた場合にエラーバジェットが将来枯渇するかを予測する方式であり、ルックアヘッドウィンドウとベースラインウィンドウの 2 つのパラメータを持つ (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]])。 #### factor of four の経験則 ベースラインウィンドウはルックアヘッドウィンドウの最大 4 分の 1 程度までが、季節性補正なしに実務上信頼できる線形予測の上限である。24 時間アラームは直近 6 時間、4 時間アラームは直近 1 時間のデータに基づくのが目安になる (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]])。 単一のルックアヘッドウィンドウだけでなく、複数の時間スケールのバーンアラートを併設し、いずれかが発火したら対応するという指針も示される。異なるベースラインからの外挿は互いに矛盾する結論を出しうるため、両方を監視して早い方の警告で行動する (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]])。 #### 線形外挿と比例外挿の矛盾 短期の予測的バーンアラートには、直近ベースラインの失敗数をそのまま将来へ引き伸ばす線形外挿と、典型的なトラフィック量に対する失敗率を将来のトラフィック量に適用する比例外挿の 2 方式がある (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]])。 > [!contradiction] 過去 6 時間に 50 ユニット中 25 ユニット(50%)が失敗したという理論計算例で、線形外挿は「24 時間後に 105 件で、予算 438 件未満なので安全」と判定する。比例外挿は同じデータから「日次 1,440 ユニットの 50% にあたる 720 ユニットが失敗し、約半日でエラーバジェットが枯渇するため即時のオンコール対応が必要」と判定する。両者は同一の観測から正反対の緊急度を導く (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]])。 比例外挿は低トラフィック時間帯に発生した障害の深刻さを線形外挿のように過小評価しない点で優位とされる (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]])。 #### コンテキスト対応バーンの計算コスト 短期方式はベースラインウィンドウのデータのみを使い、それ以前にエラーが発生しなかったと仮定して外挿するため計算コストは低いが、季節性や通常のトラフィック変動を考慮しない。 コンテキスト対応方式は SLO ウィンドウ全体の良品と不良品の累計を保持し、直近のベースラインウィンドウの失敗率で残りの期間を外挿する。計算コストは高いが、残余バジェット量に応じて緊急度を変えたい場合に有効である (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]])。 本番実績として、Honeycomb では小規模な SLO データセットに対する評価間隔ごとの再計算コストが、通常のユーザー起点クエリコストである 1 日数十ドルに対して AWS Lambda で 1 日 5,000 ドル超まで膨らんだ実例があり、コンテキスト対応バーンアラートの運用にはキャッシュ戦略が必須になると警告されている (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]])。 > [!warning] ここまでの外挿計算例(月間 1,000 万リクエストのサービス例、6 時間で 50 ユニットの例など)はいずれも設計上の理論計算であり、実測に基づく本番実績は Honeycomb のコスト事例だけである。理論計算例を実測値として引用してはならない (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]])。 #### SLO に接地しない統計的判定という別系統 SRE Book 第 2 版は、バーンレートとは異なる 3 つの判定方式を同じ本の中に並べる。 いずれも静的閾値がトラフィック量に適応できないという診断から出発する。 1 つ目は第 9 章の二項判定である。 各リクエストをベルヌーイ試行とみなし、高カーディナリティ次元の生カウントではなく、観測エラー率の二項比率の信頼区間の下限が SLO 由来の許容不能エラー率(SLO 99.9% なら 0.001)を超えたときだけページする。 区間の種類と信頼水準は記載されていない (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 9 Observability and Monitoring]])。 2 つ目は付録 G の動的ベースラインである。 サービスごとに直近 2 週間のトラフィックから期待誤り確率を求め、Wilson の信頼区間の上限を観測が超えたらアラートする。 低トラフィックでは許容幅が広がって少数の偶発的な失敗では鳴らず、高トラフィックでは幅が狭まって小さな上昇にも敏感になる。 周期性のある資源使用量などには単純な統計が効かないため、そこだけ ML の予測モデル([[TimesFM]] のような汎用時系列モデルでもよい)を使い、コストと説明可能性の制約から他の監視手法を置き換えないとする (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Appendix G Modern Observability - Statistics and ML]])。 3 つ目は付録 F のレイテンシアラートである。 ワークロードを件数 $B$(例: 1 万)以上かつ変動係数 0.5 以下の「意味のある」コホートに分け、30 日から 60 日のベースラインで各ワークロードの z スコアを計算し、z が 2 を超えるワークロードの割合が実測ベースラインから有意に増えたらサービス全体の劣化とみなす。 被覆率の目標は全ワークロードの 65% 以上である。 有意性の検定方法は記載されていない (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Appendix F The Mathematics of Latency Alerting]])。 | 方式 | 出典 | 比較の基準 | ベースライン窓 | 評価データ | |---|---|---|---|---| | バーンレート | 第 8 章、ワークブック | SLO 由来の固定目標 | 1 時間、6 時間、3 日(SLO 窓 30 日) | 事例報告のみ | | 二項判定 | 第 9 章 | SLO 由来の固定エラー率 | 記載なし | 事例報告のみ | | 動的ベースライン | 付録 G | 直近の期待誤り確率 | 直近 2 週間 | 記載なし | | コホート相対 | 付録 F | コホート内の分布 | 30 日から 60 日 | 記載なし | (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 8 Service Level Objectives]], [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 9 Observability and Monitoring]], [[@2026__OReilly__Site Reliability Engineering 2E - Appendix F The Mathematics of Latency Alerting]], [[@2026__OReilly__Site Reliability Engineering 2E - Appendix G Modern Observability - Statistics and ML]]) 4 方式の使い分けと優先順位を統合して書いた箇所は、同書の中にもない。 第 9 章と付録 G はどちらも二項分布を使うが、前者は SLO 由来の固定値に対して区間の下限を、後者は動的ベースラインに対して区間の上限を見ており、判定の向きが逆である。 窓の長さにも根拠が書かれていない。 #### 正規分布の仮定をめぐる実務書と第 2 版の一致 2019 年の『入門 監視』第 4 章は、標準偏差は正規分布のデータにしか期待どおり働かず、監視データのほとんどはこのモデルに当てはまらないと警告する (Source: [[@2019__OReillyJapan__入門 監視 - Chapter 4 統計入門]])。 同書第 3 章は固定閾値の代替として信頼区間や標準偏差を挙げており、同じ本の中で推奨と警告が並んでいる (Source: [[@2019__OReillyJapan__入門 監視 - Chapter 3 アラート、オンコール、インシデント管理]])。 7 年後の付録 F は、この警告を実測で裏づける形になっている。 付録 F の z スコアはコホート内の正規分布を仮定するが、正規分布なら z が 2 を超える割合は 2.28% のはずのところ、実測のベースラインは約 4% だった。 著者はモデルの不完全さとシステムの自然な変化をその理由に挙げ、遅延は対数正規に従いがちなので経験分布で、件数の少ないコホートは階層ベイズで拡張するとする。 約 4% を測ったサービスの条件は記載がない (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Appendix F The Mathematics of Latency Alerting]])。 付録 F の対処は、仮定を捨てるのではなく、理論値ではなく実測のベースラインと比べることで仮定の誤差を吸収する設計である。 #### LLM による SLI 式生成の限界 生成 AI はドメイン特化言語での SLI 式生成を加速できるが、比較された 2 つのモデルはいずれも、内部スパンを除外する条件のような重要フィルタを初期応答では省略しており、人間によるレビューが必要だと注意が促されている (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]])。 ### 第 13 章　アラートルール自体の品質保証 ![[Attachments/アラート管理の教科書/chapter-13.png]] 前 2 章は、バーンレート計算という発火条件の中身を扱った。 しかし、その計算を行うルール自体が壊れていれば、発火条件がどれだけ精緻でも意味を持たない。 #### 静かに機能しなくなるルール Prometheus のアラートルールは、有効な PromQL であっても静かに機能しなくなることがある。原因は、メトリクス名のタイポ、メトリクスの廃止、ラベル変更、`rate()` の時間範囲不足、recording rule チェーンの切断である。 Prometheus はクエリが何も返さない場合にエラーを出さないため、アラートが来ないという状態は、すべて正常で発火する必要がないのか、ルールが壊れていて本来発火すべきアラートが来ていないのかを区別できない (Source: [[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]])。 `rate()` は少なくとも 2 データポイントを必要とする。スクレイプ間隔が 1 分のとき `rate(metric[1m])` は 1 点しか取得できず計算不能になり、永遠にアラートが発火しなくなる (Source: [[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]])。 recording rule から recording rule、そして alerting rule という連鎖で中間ルールが変名されると、連鎖が切れてアラートが沈黙する。別チームが管理するルールでは特に発見しにくい (Source: [[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]])。 #### 3 段階のリント Cloudflare が開発した pint は、この問題への対策を 3 段階で提供する (Source: [[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]])。 1. 静的解析。PromQL 構文エラーをローカルやステージング環境で検証する。 2. ライブ検証。実際の Prometheus に対してメトリクスとラベルの存在を確認し、変更行のみを検証する CI モードでも使える。 3. watch デーモン。定期実行で問題をメトリクスとして公開し、Prometheus でアラート化する、いわば監視の監視である。 Cloudflare では Prometheus を 2017 年から使用し、時系列数のピークが単一 Prometheus で約 3,000 万に達した環境で、pint によるルールのレビューからデプロイ、運用までの全段をカバーしている (Source: [[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]])。 #### pint 以前の Cloudflare の手当て Cloudflare の手当ては pint から始まったわけではない。 2017 年の PromCon で Bostock(Cloudflare)は、アラートルールを作成時に過去データへ当てて発火頻度を検証すること、annotations に Runbook と Grafana ダッシュボードへのリンクを必ず書くことを運用規律として挙げた (Source: [[@2017__PromCon__Monitoring Cloudflare's Planet-Scale Edge Network with Prometheus]])。 監視基盤そのものについては、同じデータセンター内の Prometheus どうしがメッシュ状に互いをスクレイプし、トップレベルの Prometheus が下位を監視する二重構造を採った。 Alertmanager の障害は、Grafana のアラートルールによるデッドマン監視で検知する。 質疑では、常時発火する合成アラートを PagerDuty まで流し、通知が途絶えたら PagerDuty 側で異常とみなすパイプライン全体の疎通確認も議論された (Source: [[@2017__PromCon__Monitoring Cloudflare's Planet-Scale Edge Network with Prometheus]])。 第 6 章で見た「誰が見張りを見張るのか」という 2011 年の問いに対する、実装レベルの答えの 1 つである (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視]], [[@2017__PromCon__Monitoring Cloudflare's Planet-Scale Edge Network with Prometheus]])。 #### ルールの前提である時系列の健全性 2023 年の Mierzwa(Cloudflare)の報告は、ルールではなくルールが参照する時系列の側を守る。 ラベル値がリクエストパスや例外のスタックトレースのような外部入力に由来すると、悪意の有無にかかわらず系列数が爆発する。 1 回しかスクレイプされなかった系列も 1 時間から 3 時間はメモリに残るため、短命な系列は情報量に対して割高になる (Source: [[@2023__Cloudflare-Blog__How-Cloudflare-Runs-Prometheus-at-Scale]])。 防御は 3 層で組まれる。 1. 全スクレイプに既定でかける基本制限。ラベル数 64、ラベル名 128 文字、ラベル値 512 文字、`sample_limit` 200 であり、必要なチームは明示的に緩和できる。 2. CI での容量検証。スクレイプ設定を変える変更について、増える時系列数に対して全 Prometheus サーバーに空き容量があるかを事前に確かめ、足りなければマージを止める。 3. 独自パッチによる実行時の上限。TSDB の系列総数に上限を設け、上限に達したら既存系列への追記は許し新規系列の作成だけを間引く。`sample_limit` の超過時もスクレイプ全体を失敗させず、既存系列だけを受理する。 (Source: [[@2023__Cloudflare-Blog__How-Cloudflare-Runs-Prometheus-at-Scale]]) 上限超過を示すメトリクスからは責任チームへアラートが飛ぶ。 設計思想は、ハードな失敗より優雅な劣化(graceful degradation)を選ぶことにある。 起こりうる組み合わせ数と実際に観測される組み合わせ数は大きく違うことが多いため、静的な事前検証だけに頼らないとされる (Source: [[@2023__Cloudflare-Blog__How-Cloudflare-Runs-Prometheus-at-Scale]])。 2017 年は初期のラベル標準化と事後調査、2023 年は既定の制限と CI と実行時の上限というように、同じ組織の中で防御の重心が事前の規律から実行時の防御へ移っている (Source: [[@2017__PromCon__Monitoring Cloudflare's Planet-Scale Edge Network with Prometheus]], [[@2023__Cloudflare-Blog__How-Cloudflare-Runs-Prometheus-at-Scale]])。 ただし、新規系列を黙って間引けば観測の欠落が生じうる。 その欠落がアラートの見逃しにどう効くかは、この報告からは確認できない。 #### 導入時の検査 SRE Book 第 2 版も、ルールを出荷する前の検査を求める。 第 22 章は、新しいアラートは試験するか、少なくとも就業開始時に有効化するよう勧める (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 22 SRE in Diverse Environments]])。 第 13 章は、新サービスのローンチ前にチェックリストでトイルを洗い出し、ページが来すぎる場合と来るべきものが来ない場合の両面を見るとする (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 13 Automation and Tooling]])。 #### 発火前と発火後という別レイヤー アラートルールの品質保証は、発火の中身を扱う文献群と、発火の前提を扱う文献群に分業している。 前 2 章が扱った内容はすべて前者に属し、本章の pint による静的検証と動的検証は後者に属する。この 2 つは直交する介入点である (Source: [[Prometheusルールリント]])。 #### アラートルールの分散評価という別の問題設定 Mormul らの DEAR は、これとはさらに異なる問題を扱う。 大規模クラウド環境の監視では、精度とネットワーク帯域消費の間にトレードオフがあり、集中型のエージェントベース監視はデータを集約してから中央サーバへ送るため精度が落ち、完全分散型は管理複雑性が増大する (Source: [[@2020__CLOUD__DEAR - Distributed Evaluation of Alerting Rules]])。 DEAR はアラートルールをバイナリ式木に変換して各 VM 上の軽量評価エンジンに自動配布し、アラート判定のみをローカルで行うことで、このトレードオフを解消しようとするプラグインである。ルール管理は中央のアラートフレームワーク上に残すため管理複雑性は増えない。 バイナリ式木を中間表現とすることで、n 個のアラートフレームワークと m 個の評価エンジンの間の変換を、n かける m 個ではなく n たす m 個のアダプタで済ませられる (Source: [[@2020__CLOUD__DEAR - Distributed Evaluation of Alerting Rules]])。 評価尺度は洞察までの時間である。OpenStack 上の 2 VM(各 2 vCPU、4GB RAM)を用いた実験では、集約ありの設定で従来手法の洞察までの時間が最大 27 秒超まで増大したのに対し、DEAR は約 360ms から 380ms で一定だった (Source: [[@2020__CLOUD__DEAR - Distributed Evaluation of Alerting Rules]])。 DEAR はここまで見てきた SLO バーンレート系の文献群とほぼ接点を持たず独立に発展している。 評価規模も 2 VM の小規模テストベッドにとどまり、本番テレメトリで検証された SRE ワークブックや eBay の事例、Cloudflare の pint とは検証規模の桁が異なる。 本部で唯一、研究室構築の環境に基づく文献であり、他の章がすべて本番テレメトリまたは設計上の理論計算に基づく点との違いを意識する必要がある。 ### 第 14 章　アラート品質のモデル化 ![[Attachments/アラート管理の教科書/chapter-14.png]] 前章までは、発火条件の定式化とルールの健全性という 2 つの介入点を扱った。 これに対し、発火したアラート、あるいは発火しなかったアラートの品質そのものをどう測るかは、別の問いとして残る。 #### 真と偽と欠落の 3 種のアラーム Moshe Zadka は SREcon22 Americas で、アラームを真アラーム、偽アラーム、欠落アラームの 3 種に分類した (Source: [[@2022__SREcon22 Americas__Modeling Alert Quality]])。 真アラームは実際の障害を指し示し修復が必要だったものであり、アラートシステムの存在理由である。 偽アラームは実際には問題がなかった、または即時修復を要しなかったもので、純粋なコストである。 欠落アラームは障害が発生したのに発火しなかったものであり、アラートの追加と削除が真アラームと欠落アラームを相互変換するため、品質計測に欠かせない分類とされる (Source: [[@2022__SREcon22 Americas__Modeling Alert Quality]])。 #### 4 区間のレイテンシ分解 真アラームのタイムラインは、発生から検知、検知から確認、確認から診断、診断から復旧という 4 区間に分解される。 各区間は独立に改善できる。発生から検知まではよりスマートなルールや少ないデータ要件で、検知から確認までは確認ボタンやオンコールローテーションの最適化で、確認から診断までは診断情報の付与で、診断から復旧までは Runbook リンクやワンクリック復旧で短縮できる (Source: [[@2022__SREcon22 Americas__Modeling Alert Quality]])。 欠落アラームも同じ 4 区間を持つが、検知が顧客クレームなど別経路で起きるため発生から検知までの区間が長くなる。 偽アラームは検知から確認、診断までの 3 区間のみを持ち、復旧は発生しない (Source: [[@2022__SREcon22 Americas__Modeling Alert Quality]])。 #### アラーティングのコストと非アラーティングのコスト Zadka はアラート品質を、アラーティングの総コストと非アラーティングの総コストを合算し符号反転した、アンチクオリティとしてモデル化する (Source: [[@2022__SREcon22 Americas__Modeling Alert Quality]])。 アラーティングのコストは、偽アラームのコスト(人数、時間、不便さの積)と、既知問題の重複発火であるユーセレスアラームのコストからなる。 非アラーティングのコストは、欠落アラームによる復旧までの追加時間と、検知遅延による被害拡大からなる (Source: [[@2022__SREcon22 Americas__Modeling Alert Quality]])。 #### Goodhart の法則とブラックスワンへの警告 アラート品質は遅行指標であり、十分なサンプルが溜まるまでノイズが多いため、偽アラーム件数のような即時追跡可能な指標で補完する必要がある (Source: [[@2022__SREcon22 Americas__Modeling Alert Quality]])。 中期的な品質計測に過剰適合すると、稀だが壊滅的な事象への備えを失う。 アラート品質を報酬や昇進、ボーナスの目標にすると、人々は品質そのものではなく指標の最適化に走るという Goodhart の法則が働く。 品質指標はチームが自発的に追跡するフィードバック機構として使うべきで、業績評価の目標にはすべきでないとされる (Source: [[@2022__SREcon22 Americas__Modeling Alert Quality]])。 #### QoA 3 軸との対応 Quality of Alerts は、アラートの有用性を指示性、精度、処理容易性の 3 軸で評価する学術的な枠組みである。 Zadka のコストモデルは、この 3 軸を「何にコストがかかるか」で再記述したものと読める。 指示性はアラーティングのコストを下げること、精度は真アラームの検知区間の短縮、処理容易性は確認から診断、復旧までの各区間の短縮に対応する (Source: [[Quality of Alerts]])。 ただし、ユーザー影響に基づく SLO 接地の物差しと、Zadka のコストに基づく物差しという 2 系統は並存しているが、定量的な相互検証は行われていない。 #### 有用なアラートの 2 条件 Observability Engineering 第 2 版は、SLO ベースのアラートが有用であるための条件を、ユーザー体験の劣化を示す信頼できる指標であることと、体系的にデバッグし対処できることの 2 つに絞る。 いずれかを満たさないアラートは目的を果たしていないため削除すべきだとされる (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]])。 この 2 条件は、SRE Book が挙げる緊急なユーザー影響、アクショナブル、新規性、調査を要するという 4 基準のサブセットとして位置づけられる (Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]])。 #### 組織の指標としてのアクショナブル率 SRE Book 第 2 版第 13 章は、アラートのうち対処可能だった割合を追跡し、定期的に見直すことを運用負荷の計測の一部に据える。 定例の本番ミーティングで前期間のページと割り込みを見直し、自動化の候補を特定する (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 13 Automation and Tooling]])。 ただし、その割合の実測値は示されていない。 同書第 6 章は、こうしたスコアカードの KPI がほぼすべて代理指標であり、武器化、ゲーミング、グッドハートの法則、視野狭窄の危険を持つと認める。 それでも客観的事実を与え抽象的な問題を具体化するので、無いよりはよいとする (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 6 Organizational Structures for SRE]])。 品質指標を業績評価の目標にすべきでないという Zadka の警告と、同じ危険を別の側から述べている (Source: [[@2022__SREcon22 Americas__Modeling Alert Quality]])。 同書第 21 章は、アラートに応答する AI の性能そのものにも同じ枠を当てる。 AI エラーバジェット、有用性 SLO(例として、提案の 95% が人間に採用される)、安全性 SLO、緩和提案のレイテンシ SLO を置き、AI の性能をサービス信頼性の問題として扱う。 95% は例示であって実測ではない (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]])。 --- ## 第 IV 部　選別と削減(2014 年から 2026 年) 第 III 部までが「何を鳴らすか」の設計論だった。 第 IV 部は、鳴ってしまったアラートを 1 件ずつ選り分ける後処理の系譜を扱う。 多数のアラートを少数のインシデントへ束ねる集約は第 V 部が扱う。 ### 第 15 章　重要度マイニングとランキング ![[Attachments/アラート管理の教科書/chapter-15.png]] この章は、生成されたアラート集合から重要度に応じた順序を与える手法群を扱う。 いずれも軸 B では後処理パイプラインに属し、軸 C はほぼすべてが学術 AIOps である。 | 手法 | 年 | 媒体 | 組織 | 教師信号 | 評価データの出自 | |---|---|---|---|---|---| | CAM(重要アラートマイニング) | 2014 | KDD | UC Santa Barbara、LogicMonitor、Army Research Lab、University of Illinois Urbana-Champaign | なし(統計的依存規則マイニング) | 本番テレメトリと合成データ | | アラートとインシデントのクラスタリング | 2014 | KDD | Pivotal Software | なし(教師なしクラスタリング) | 本番テレメトリ(エンタープライズ IT) | | CAR(協調アラートランキング) | 2018 | CIKM | NEC Laboratories America | なし(教師なし統一最適化) | 本番テレメトリ(企業セキュリティ)と合成データ | | AlertRank | 2020 | ISSRE | Tsinghua University、China Construction Bank、BizSeer | あり(弱教師、解決記録から自動ラベル) | 本番テレメトリ(商業銀行) | | DeepIP | 2020 | ASE | Microsoft Research、Tianjin University ほか | あり(履歴チケット化ラベル) | 本番テレメトリと公開ベンチマーク(汎化性検証のみ) | | COMET | 2024 | ISSRE | Microsoft、Chinese Academy of Sciences ほか | あり(履歴チーム割当ラベル) | 本番テレメトリ(Microsoft) | | 性能アラートトリアージ | 2026 | ICPE Companion | Polytechnique Montréal | あり(バグ報告への紐付けラベル) | 公開ベンチマーク(Mozilla、Zenodo 公開) | #### 各手法の位置づけ 重要アラートマイニング問題は、アラート間の因果グラフ上で、修正すれば他の多くのアラートの発生を抑えられる k 個のアラートを見つける問題として定式化される。 Zong ら(UC Santa Barbara)は、この問題が NP 完全であることを最大被覆問題からの帰着で証明した。 期待便益関数が単調劣モジュラであることを利用し、貪欲近似で近似比 1-1/e を保証する。 上下界枝刈りは素朴な貪欲法比で最大 30 倍、木サンプリングは最大 5,000 倍高速化する一方、損失率 0.1 から 0.2 程度の質の低下を伴う (Source: [[@2014__KDD__Towards Scalable Critical Alert Mining]])。 評価は LogicMonitor 提供の本番データセンターテレメトリ(122 台のサーバ、50,772 メトリクス)と、その経験分布から生成した合成データの両方で行われた (Source: [[@2014__KDD__Towards Scalable Critical Alert Mining]])。 Lin ら(Pivotal Software)は、半構造化アラートには Jaccard 距離と連結成分検出、正規化グラフカットによるクラスタリングを、非構造化インシデントチケットには NMF と KD 木、完全リンケージ階層クラスタリングを、それぞれ独立に適用する 2 系統フレームワークを提案した。 手法自体はランキングでなくクラスタリングだが、語と位置の組の頻度を可視化する構造保持型の表示と、クラスタ単位の MTTR 算出によって、どのクラスタから対処すべきかの優先順位付けを支援する (Source: [[@2014__KDD__Unveiling Clusters of Events for Alert and Incident Management in Large-Scale Enterprise IT]])。 評価は本番エンタープライズ IT テレメトリ(3 か月で 500 万件のアラート、67,000 件のインシデントチケット)で行われ、教師なし手法ゆえに定量的な精度指標でなく KPI の可視化と定性評価にとどまる (Source: [[@2014__KDD__Unveiling Clusters of Events for Alert and Incident Management in Large-Scale Enterprise IT]])。 Lin ら(University of Houston、NEC Laboratories America でのインターンシップ中)が提案する CAR は、前置木ベースの階層ベイズモデルでアラート系列の時間的依存性を、エンティティ埋め込みでカテゴリカル属性間のコンテンツ相関をそれぞれ学習する。 両者を凸最適化で統合し、アラートとアラートパターンを同時にランキングする (Source: [[@2018__CIKM__Collaborative Alert Ranking for Anomaly Detection]])。 評価は企業侵入検知システムの本番アラート(173 台、1 か月、3,322 件、うち真陽性 41 件)と、真陽性比率を変えた合成データの双方で行われ、ROC-AUC 0.998、PRC-AUC 0.719 を達成した。 教師なしかつ事前知識不要という制約下で時間相関とコンテンツ相関を統一最適化する設計は、単独の時間モデルや単独のコンテンツモデルの盲点を補完する (Source: [[@2018__CIKM__Collaborative Alert Ranking for Anomaly Detection]])。 AlertRank は重要アラート識別を二値分類でなくランキング問題として定式化し、非重要と重要の比率が約 50 対 1 というクラス不均衡に対処しつつ、エンジニアに調査順序を提示する。 解決記録の TF-IDF ベクトル化と k-means クラスタリングによって、手動ラベル付けなしに連続的な重要度スコアを訓練データへ自動付与する弱教師設計を採る (Source: [[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems]])。 アラートのテキストと時系列の特徴量に KPI 異常の特徴量を組み合わせた 40 次元の特徴量集合で XGBoost ランキングモデルを学習し、商業銀行の本番テレメトリ(3 データセット、各 6 か月、37 万件から 43 万件)で F1 スコア 0.89 を達成した。 インクリメンタル学習によって、ソフトウェア変更後のモデル劣化(F1 0.68)を F1 0.88 まで回復させる適応性を持つ (Source: [[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems]])。 Hmissa ら(Polytechnique Montréal)は、Mozilla の性能アラートサマリが報告済みバグと関連付けられるかを予測するトリアージパイプラインを提案した。 直近 20% を将来の保留テストセットとする厳密な時系列分割によって時間的リークを排除する。 短、中、長の 3 解像度で計算したデルタ、傾き、分位点統計などのマルチスケール時系列特徴量 40 個を、構造化アラートメタデータ 94 個、時間文脈特徴量 7 個と融合する構成が、テスト AUPRC 0.851 を達成した (Source: [[@2026__ICPE Companion__Performance Alert Triage with Time-Aware Learning and Multi-Scale Time-Series Features]])。 評価は Mozilla の Firefox 性能テストデータセット(Zenodo 公開、17,989 件の生アラート、3,912 件のアラートサマリ)を用いており、この部で扱う手法の中で公開ベンチマークを主評価に使う数少ない例である。 最重要特徴量は関連アラート数であり、バグ報告前に集計されるアラート集約統計が重大度の代理指標として機能する (Source: [[@2026__ICPE Companion__Performance Alert Triage with Time-Aware Learning and Multi-Scale Time-Series Features]])。 Wang ら(Microsoft)が提案する COMET は、生ログを絞り込み、大規模言語モデルにドメイン知識を注入したプロンプトでキーワードを抽出し、FastText 埋め込みと類似検索でインシデントの担当チームを推薦する。 議論や生成要約よりも、LLM が抽出したキーワードの方がトリアージの入力表現として有効であることを比較実験で示した (Source: [[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]])。 Microsoft の 2 つの大規模クラウドサービスに 6 か月以上本番展開し、オフライン ACC@1 で 0.65、オンライン展開で ACC@1 を 30% 改善し緩和までの時間を 35% 短縮した (Source: [[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]])。 Chen ら(Tianjin University、本研究は Microsoft Research 訪問時に実施)は、Microsoft の 18 の大規模オンラインサービスの 6 か月分のインシデントを分析し、平均 50.32% のインシデントがエンジニアが高優先度で修正しない付随的なものであることを実証した。 付随的なインシデントを設計どおり、顧客エラー、修正しない、再現不能、一過性、誤報の 6 カテゴリに分類し、この識別を二値分類として定式化したアテンション付き CNN を提案した (Source: [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]])。 このモデルは直前 10 件の関連インシデントをアテンション機構で統合し、18 システムの本番テレメトリで AUC 平均 0.808 を達成し、バグの重大度予測を流用したベースライン(ルールベース 0.624、ベイズ 0.586)を全システムで上回った。 Mozilla のバグ報告データセットへ転用した評価では、既存手法を適合率で 41.00%、再現率で 10.29% 改善しており、公開ベンチマークは汎化性検証の補助として位置づけられている (Source: [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]])。 #### 横断的観察 クラス不均衡下でランキング問題として定式化するという設計判断は、AlertRank、2026 年の性能アラートトリアージ、DeepIP、CAR の 4 系統で独立に収斂している (Source: [[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems]], [[@2026__ICPE Companion__Performance Alert Triage with Time-Aware Learning and Multi-Scale Time-Series Features]], [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]], [[@2018__CIKM__Collaborative Alert Ranking for Anomaly Detection]])。 教師ありと教師なしの分岐は企業データの入手可能性と表裏一体である。 教師なし系は少量データでも動作する一方、教師あり系は大規模本番データと弱教師信号(解決記録、障害報告書、バグ報告への紐付け、履歴チーム割当)の存在を前提とする (Source: [[@2014__KDD__Towards Scalable Critical Alert Mining]], [[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems]])。 企業本番データによる評価が主流であり、公開ベンチマークでの評価は例外的である。 2026 年の性能アラートトリアージが主評価に公開データを使う唯一の例であり、DeepIP は Mozilla を汎化性検証の補助にのみ使う (Source: [[@2026__ICPE Companion__Performance Alert Triage with Time-Aware Learning and Multi-Scale Time-Series Features]], [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]])。 2024 年の JNCA サーベイは、alert determination の中でも重要度ランキングの系統として本章の手法群を横並びで整理しており、これらが同一のプロセスに属することを裏付ける (Source: [[@2024__JNCA__A survey on intelligent management of alerts and incidents in IT services]])。 ### 第 16 章　抑制とフィルタリング ![[Attachments/アラート管理の教科書/chapter-16.png]] アラート抑制の代表的な静的ポリシーは X-out-of-Y ポリシー(直近 Y 時間内に X 件のイベントが観測されたらアラートを解除する)であり、既存製品でも専門家が手動で値を設定してきた (Source: [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]])。 #### 動的抑制ポリシー Bhukar ら(IBM India Research Laboratory)が提案する Dynamic-X-Y は、移動平均エンベロープによるピーク検出と密ピーク検出、隣接領域の統合を組み合わせて過去イベント時系列から持続領域を検出する。 メトリクスまたはサービスごとに個別の X と Y を教師なしで自動学習する (Source: [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]])。 メトリクスデータセットで抑制なし比 45.8%、静的ポリシー比 7.4% の正解率改善、ログデータセットで抑制なし比 37.5%、静的ポリシー比 35.7% の改善を達成した。 ログの持続領域の平均イベント数が静的ポリシーの固定値を大幅に上回るため、静的ポリシーはログデータセットで実質的に抑制なしと同じ判定に劣化する。 同じ静的ポリシーがメトリクスドメインでは機能する一方、ログドメインでは機能しないという非汎化性は、単一のドメイン非依存パラメータでは抑制ポリシーを設計できないことを示す (Source: [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]])。 教師なしで学習した X と Y の全メトリクス平均(X=9.06、Y=54.06)は、66 通りの組み合わせをブルートフォース探索した教師あり最適値(X=9、Y=50、正解率 94.42%)にほぼ一致し、ラベル付きデータなしで教師あり探索の上界近傍の性能に到達できることを示した。 IBM 内部の産業事例では、抑制なし比 61.53%、静的ポリシー比 44.44% のアラートノイズ削減を達成し、IBM の本番ツールに統合済みである (Source: [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]])。 ![[_attachments/2024__SAC__Bhukar-Dynamic-Alert-Suppression/fig9-figure.png]] **図16-1**:同一のメトリクスに対し、生データ、抑制なし、静的ポリシー、動的ポリシーの 4 段を上から並べたもの。下へ行くほど矩形の数が減り、本文の 13 件、9 件、5 件という通知数の推移が視覚的に対応する。本文の削減率 61.53% と 44.44% は、この 3 段の矩形数の比である。 (Source: [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]], 図 9) #### クリック行動に基づくフィルタリング Voutsas ら(Netdata)は、クラウドモニタリングのアラートフィルタリングを「管理者がそのアラートをクリックして対応するかどうか」の二値分類として初めて定式化した。 アラート名、ファミリー、分類、ステータス、継続時間、ノード単位の警告と重要アラートの総数などの特徴量でランダムフォレストを学習し、Netdata の本番ログ(10 万サンプル、10 か月、12,000 超の固有管理者反応)で精度 70.6%、F1 0.751、推論 7.3 ミリ秒を達成した (Source: [[@2023__JCC__Filtering Alerts on Cloud Monitoring Systems]])。 密なニューラルネットワークは訓練に 10 秒超かかり推論も遅く、精度でもランダムフォレストに劣ったため、著者らはより高度なニューラルネットワークでの追求を断念した。 精度 70% という上限は、アラートの重要性が管理者間で主観的に異なり同一管理者でも状況によって変化するというユーザー行動の主観性を反映した結果であり、著者らは能動学習による個別化を今後の方向として挙げる (Source: [[@2023__JCC__Filtering Alerts on Cloud Monitoring Systems]])。 #### 横断的観察 静的ポリシーの汎化不能性は、抑制とフィルタリングという別々の介入点で独立に確認されている。 メトリクスで最適だった静的ポリシーはログデータで抑制なしと変わらない水準まで劣化し (Source: [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]])、フィルタリング側でもクリック行動という主観的な弱教師信号に頼らざるを得ない (Source: [[@2023__JCC__Filtering Alerts on Cloud Monitoring Systems]])。 抑制は発火前の統計学習、フィルタリングは発火後のユーザー反応に基づく弱教師学習という点で介入点が異なるが、いずれもラベル不足という制約下で機能する設計になっている (Source: [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]], [[@2023__JCC__Filtering Alerts on Cloud Monitoring Systems]])。 ### 第 17 章　要約 ![[Attachments/アラート管理の教科書/chapter-17.png]] この章は、複数のアラートを同一障害に起因するものとしてまとめる技術のうち、LLM を用いない教師ありと教師なしの手法と、性能異常アラートのアクショナブル化を扱う。 #### 意味情報と挙動情報の統合 Chen ら(Fudan University)が提案する OAS は、アラートの意味情報と挙動情報をそれぞれ独立に学習したうえで、要素積による統合モジュールで 2 アラート間の相関を 2 クラス分類として決定する。 意味情報の側は CBOW で得た文脈情報と IDF で得た意味寄与度を重み付き集約し、挙動情報の側は Skip-Gram に着想を得た浅いニューラルネットワークで同一障害に起因するアラートの共通挙動を学習する。 教師信号には障害報告書を用いており、企業に蓄積された障害対応の知識を自動的に学習に取り込む教師あり集約として、先行する教師なし手法と一線を画す (Source: [[@2022__ICSE__Online Summarizing Alerts through Semantic and Behavior Information]])。 時間窓 5 分以内で新着アラートを最も相関の高い既存インシデントへ逐次割り当てるオンライン集約戦略を採り、各アラートを 1 度だけ処理することで過去インシデントを変更しない。 2 つの大手商業銀行の本番テレメトリ(Bank A は 50,947 件、Bank B は 500,000 件)で評価し、Bank B では誤ったアラートを含まないインシデントの割合が 99% 超、有効圧縮率が約 54% に達した (Source: [[@2022__ICSE__Online Summarizing Alerts through Semantic and Behavior Information]])。 #### 伝播パスのセマンティクス検証 ProAlert は、既存のトポロジベース手法がコンポーネント間の接続性のみを考慮し、トポロジの意味である「何が伝播しやすいか」を無視する点を課題とする。 歴史的アラートと CMDB トポロジから、コンポーネントタイプの組ごとに頻出する障害伝播のセマンティクスを DBSCAN で教師なしにクラスタリングし、伝播パターンとして蓄積する。 新着アラート間に構造制約を満たす伝播パスが存在するかを検証し、テキスト類似度と伝播妥当性を組み合わせた相関スコアで同一障害かどうかを判定する (Source: [[@2025__FSE__Alert Summarization for Online Service Systems by Validating Propagation Paths of Faults]])。 大規模商用金融企業の本番テレメトリ(S1 は 51,352 件、S2 は 125,830 件)で評価し、S1 で有効圧縮率 93.53%、正しいインシデントに含まれるアラートの割合 99.71% を達成して先行手法を上回った。 OAS が教師あり学習を前提とするのに対し、ProAlert は教師なしで伝播パスのセマンティクスを学習する点で、系譜上の発展にあたる (Source: [[@2025__FSE__Alert Summarization for Online Service Systems by Validating Propagation Paths of Faults]])。 #### アクショナブル化と排他的レイテンシ TraceArk は、マイクロサービスの分散トレースから性能異常をアラーティングする際、子コンポーネントの異常の影響が親コンポーネントのレイテンシに伝播して偽陽性ノイズを生む問題に対し、子コンポーネントの影響を除いた排他的レイテンシを基軸にすることでこれを排除する。 同一コンポーネントでも呼び出しパスによってレイテンシ分布が大きく異なるため、サービス、オペレーション、パスの 3 粒度でトレースを集約する設計を採る。 XGBoost による異常評価に、10 件から 30 件のエンジニアフィードバックを半教師あり学習で組み込み、解釈可能性を保ったまま F1 を 0.5936 から最大 0.74 まで向上させる (Source: [[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems]])。 Microsoft Exchange の本番環境で 4 か月稼働し適合率 0.9068 を達成した一方、研究室評価では Exchange データセットで F1 0.5936 にとどまる (Source: [[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems]])。 > [!warning] 本番デプロイの適合率 0.9068 は「アクショナブルと報告されたもののうちエンジニアが確認した割合」であり、F1 0.5936 とは指標の性質が異なる。両者を直接比較してはならない (Source: [[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems]])。 ### 第 18 章　アンチパターンとアクショナビリティ ![[Attachments/アラート管理の教科書/chapter-18.png]] | # | 分類 | アンチパターン | 定義 | OCE の影響認識(18 名中) | 現行対処 | 対応する自動化手法 | |---|---|---|---|---|---|---| | A1 | 個別 | 不明瞭な名前または記述 | 「Instance x is abnormal」のような曖昧な記述 | 高 11、低 7、影響なし 0 | SOP による文脈付加(限定的有用性) | 本部の対象論文に直接対応する自動化手法はない | | A2 | 個別 | 誤解を招く重大度 | 過剰または過小な severity 設定 | 高 8、低 8、影響なし 2 | OCE による手動見直し | AlertRank(重要度の自動ランキング)、TraceArk(アクショナビリティ評価) | | A3 | 個別 | 不適切または陳腐化した生成ルール | 耐障害性の進化に伴う下層指標の意義変化に未追随 | 高 13、低 4、影響なし 1 | アラート相関分析 | 本部の対象論文に直接対応する自動化手法はない | | A4 | 個別 | 一過性と振動するアラート | 短時間で自動解除される、または生成と解除が振動する | 高 7、低 10、影響なし 1 | アラートブロッキング | Dynamic-X-Y(動的抑制ポリシー) | | A5 | 集合 | 繰り返すアラート | 同一アラート戦略から繰り返し発火する | 高 7、低 10、影響なし 1 | アラート集約 | 第 V 部の集約手法が扱う | | A6 | 集合 | 連鎖するアラート | 依存伝播でサービス間に連鎖する大量のアラート | 高 14、低 4、影響なし 0 | アラート相関分析、新出アラート検知 | 第 V 部が扱う | (Source: [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]]) #### 経験的研究としての位置づけ 6 つのアンチパターンは Huawei Cloud の 2 年間で 400 万件超のアラートと 18 名の OCE への調査から実証的に同定された、個別 4 種と集合 2 種で構成される (Source: [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]])。 現行の対処は 4 系統に整理され、アラートブロッキングとアラート相関分析は 18 名全員が有効と評価した一方、適応的オンライン LDA による新出アラート検知は有効 13、限定的 3、有効でない 2 とばらつきが残った (Source: [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]])。 標準処理手順(SOP)の有用性評価は割れている。 全体の有用性では有用 4、限定的 14 にとどまるのに対し、個別アンチパターンの診断では有用 9、限定的 7、有用でない 2、集合アンチパターンの診断では有用 5、限定的 13 であり、SOP は個別より集合の診断に弱い。 予防ガイドラインは、何を監視するか(下層インフラでなくサービス品質に直結する指標を選ぶ)、いつ警告するか(サービス品質への影響時のみ発火させる)、どのように呈示するか(タイトル、重大度、位置情報を診断に有用な形に整える)の 3 観点で設計される。 88.9% の OCE がガイドラインを厳守すれば診断が容易になると認めつつ、実務では遵守されないと報告しており、予防と運用の間に実践のギャップが存在する (Source: [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]])。 アンチパターン論文自体は 6 類型の同定と現行対処の整理にとどまり、自動化の具体的実装は担わない。 A4 には動的抑制ポリシーが、A2 には自動ランキングとアクショナビリティ評価が対応するというように、自動化は同時代の別論文が担う分業構造になっている (Source: [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]], [[@2024__ICSE-SEIP__Dynamic Alert Suppression Policy for Noise Reduction in AIOps]], [[@2020__ISSRE__AlertRank - Automatically and Adaptively Identifying Severe Alerts for Online Service Systems]], [[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems]])。 #### アクショナブルアラートの 2 条件 TraceArk はアクショナブルアラートを、異常がエンジニアの迅速な行動を動機づけるほど影響が大きいことと、アラーティングが解釈可能でアクションの指針を届けられることの 2 条件で定義する (Source: [[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems]])。 実務書の側では、アクショナビリティは棚卸しの問いとして運用される。 『入門 監視』第 3 章は、ノイズ削減を「すべてのアラートは誰かがアクションする必要がある状態か」という問いから始め、1 か月分の履歴を見直して、各アラートで取ったアクションと影響から、削除、閾値変更、再設計、自動化の余地を探すよう勧める (Source: [[@2019__OReillyJapan__入門 監視 - Chapter 3 アラート、オンコール、インシデント管理]])。 > [!contradiction] Ewaschuk はすべてのページが実在(Real)の問題を指すことを要求する (Source: [[@2015__Rob Ewaschuk__My Philosophy on Alerting]])。 > 一方『入門 監視』第 3 章は、100% 正確なアラートの実現は難しく、まだ解決されていない問題だと認めたうえで、誤報はかなり減らせるとする (Source: [[@2019__OReillyJapan__入門 監視 - Chapter 3 アラート、オンコール、インシデント管理]])。 > 前者は設計の規範を、後者は到達可能な水準を述べており、同じ理想を異なる距離から語っている。 アクショナビリティの議論はエンジニアへの提示内容にとどまり、対応手順を記した Runbook の整備自体は第 VI 部が扱う。 #### 修復研究の手薄さ AIOps の障害管理に関するサーベイの第 4.5 章は、修復をインシデントトリアージ、解決策推薦、復旧の 3 段階に分け、予防、予測、検知、診断に比べ AI 関連の科学的貢献が少ないと指摘する。 著者らはこれを、診断で問題の性質が明らかになれば複雑なモデルなしでも復旧手順がほぼ即座に特定でき実行可能になるためと説明し、レビュー対象文献もインシデントトリアージ 2 件、解決策推薦 3 件、復旧 1 件の合計 6 件にとどまる。 復旧については、マッピング研究を通じても AI による際立った直接復旧アクションの貢献が見当たらず、唯一の近い事例でも復旧アクション自体は事前定義ルールで実行され、AI の役割は先行する検知と根本原因分析の段にとどまる (Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.5 Remediation]])。 この 2021 年時点の指摘は、この部が扱う 2022 年以降の研究群でも埋まっていない。 いずれの文献も「鳴らすか、どう束ねるか、どう解釈可能にするか」に集中し、「鳴った後どう直すか」は今後の課題として触れられる程度にとどまる (Source: [[@2022__ICSE__Online Summarizing Alerts through Semantic and Behavior Information]], [[@2025__FSE__Alert Summarization for Online Service Systems by Validating Propagation Paths of Faults]], [[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems]], [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]])。 --- ## 第 V 部　アラートストームと集約(2020 年から 2025 年) 第 IV 部は 1 件ずつ選り分ける後処理を扱った。 第 V 部は、多数のアラートを少数のインシデントへ束ねる系譜を扱う。 ### 第 19 章　ストームの実証的定義と検知 ![[Attachments/アラート管理の教科書/chapter-19.png]] #### アラートストームの実証的定義 AlertStorm は、中国の商業銀行の 3 年分で 300 万件超の実世界アラートデータに基づき、アラートストームを独立の研究対象として初めて実証的に定義した論文である。 同論文は、アラートストームへの対処に平均 55 分と 6 名のエンジニアを要する事例を報告している (Source: [[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems]])。 この規模は産業用アラームフラッドの既存基準と対比できる。 ISA 18.2 や EEMUA 191 が定める産業アラームフラッドの基準は 10 分あたり 10 件毎オペレータであり、IT サービスのアラートストームはこれと桁違いに大きい (Source: [[アラートストーム]])。 #### 極値理論による適応的検知 AlertStorm は、アラートストーム検知を変化点検知問題として定式化し、Peaks-Over-Threshold に基づく極値理論で一般化パレート分布の尾部をフィットする。 極値理論は正常状態のアラート件数の履歴からモデルをフィットして動的に閾値を調整するため、新サービス追加などの環境変化に適応できる (Source: [[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems]])。 3 年分のデータを 1 年ごとに 3 分割したデータセット A、B、C での評価では、極値理論に基づく手法はすべてのデータセットで F1 スコア 0.9 を超えた(A が 0.94、B が 0.93、C が 0.95) (Source: [[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems]])。 #### 固定閾値法の経年劣化 比較対象の固定閾値法(1 分あたり 500 件超)は、データセット A から C へ年次が進むにつれ F1 スコアが 0.90、0.83、0.72 と低下した (Source: [[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems]])。 この劣化は、システム規模の拡大による新サービス追加で通常時のアラート件数が増加し、静的閾値が動的環境に追随できなくなったことに起因する (Source: [[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems]])。 固定閾値法の手動設定に依存する設計は、監視対象の拡張速度が速い環境ほど再調整コストを支払い続けなければならないという構造的な弱点を持つ。 #### クラウドの断続的バーストとスーパーコンピュータの連続的過負荷 アラートストームの形態は事業ドメインによって分化する。 クラウドサービスのアラートストームは、障害をトリガーとして断続的に発火し収束するパターンであり、極値理論による変化点検知が有効に働く (Source: [[アラートストーム]])。 一方、SuperAgg が対象とするスーパーコンピュータ環境では、アラートは断続的なストームではなく連続的なバーストの流れとして現れ、著者らはこれをアラート過負荷と命名する。 NG-Tianhe では、130 日間で 366 万件超の生アラートが発生し、データセット A(2023 年 1 月 28 日から 3 月 31 日)で 155 万件、データセット B(2023 年 4 月 1 日から 6 月 6 日)で 212 万件を記録した。 ブラックリスト抑制後でも 10 分あたり 200 件以上のアラートが観測時刻の 50% で発生し、1 日あたり 1 万件以上のアラートが全観測日で発生する (Source: [[@2024__ISSRE__Exploring Hierarchical Patterns for Alert Aggregation in Supercomputers]])。 18 名のオペレータへのアンケートでは、10 分で 10 件を処理できると回答したのは 66.67% にとどまり、重要アラートの対処に平均 2.11 時間毎日を費やしていた (Source: [[@2024__ISSRE__Exploring Hierarchical Patterns for Alert Aggregation in Supercomputers]])。 既存の類似度ベースのアラート集約手法は、アラートレベルが 3 段階の有限の離散値であるためランダム選択に退化し、スーパーコンピュータの構造化されたアウトオブバンドアラートには近視眼的にしか機能しない (Source: [[@2024__ISSRE__Exploring Hierarchical Patterns for Alert Aggregation in Supercomputers]])。 断続的ストームと連続的過負荷は変化点検知が有効な前提そのものが異なる別問題であり、持続シナリオでは検知器ではなく集約戦略自体の再設計が要る (Source: [[アラートストーム]])。 #### ネットワークの重大障害におけるアラート洪水と location 階層 第三の形態として、SkyNet は重大なネットワーク障害に伴うアラート洪水を扱う。 SkyNet が対象とする重大障害は年間数回しか発生しないが損失の大半を占める前例のない事象であり、単発のアラートストームや持続的な過負荷とは異なる第三のカテゴリを成す (Source: [[アラートストーム]])。 大規模クラウドの本番ネットワーク(89 データセンター、29 リージョン、10 の 5 乗オーダーのデバイス規模)で、単一の監視ツールのみによる障害検知カバレッジは 3% から 84% にとどまる (Source: [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]])。 このため SkyNet は、Ping、Traceroute、Syslog、SNMP と GRPC、インバンドネットワークテレメトリなど 12 種類の異種監視ツールを統一入力形式で統合する。 SkyNet の Locator モジュールは、Region、City、Logic Site、Site、Device、Cluster という 6 段の location 階層にアラートを挿入し、あるノードのサブツリー内アラート数が閾値を超えるとそのサブツリーをインシデントツリーとして複製する (Source: [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]])。 インシデント生成の閾値は、2 件の障害アラート、または 1 件の障害アラートと 2 件のその他アラート、または 5 件の任意のアラートのいずれかであり、この設定で偽陽性率 20% 未満、偽陰性率 0% を 1.5 年間維持した。 前処理は毎時 10 万件のアラートを通常時 1 万件未満、重大障害時 5 万件未満まで圧縮し、location 階層をたどるインシデント生成は最悪でも 10 秒未満で完了する (Source: [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]])。 location 階層への挿入は、時系列の発火順序ではなく物理的な所在によってアラートを束ねる設計であり、次章で扱う「時間的順序が根本原因を反映しない」という発見と整合する。 本章で扱う 3 論文はいずれも単一事業者の非公開本番テレメトリで評価されており、公開ベンチマークは存在しない (Source: [[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems]], [[@2024__ISSRE__Exploring Hierarchical Patterns for Alert Aggregation in Supercomputers]], [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]])。 ### 第 20 章　相関と集約 ![[Attachments/アラート管理の教科書/chapter-20.png]] #### 手法の一覧 | 手法 | 年 | 媒体 | 組織 | 集約の判断材料 | 評価データの出自 | |---|---|---|---|---|---| | AlertStorm | 2020 | ICSE-SEIP | China EverBright Bank ほか | テキスト類似度とトポロジ距離の重み付き合成 | 単一事業者の非公開本番テレメトリ | | LinkedIn のスパイク検知 | 2021 | SREcon21 | LinkedIn | 修正 Z スコアによる時系列スパイクの外れ値判定 | 単一事業者の非公開本番テレメトリ | | GRLIA | 2021 | ASE | Huawei Cloud ほか | 障害影響グラフの補完とインシデント種別のグラフ表現学習 | 単一事業者の非公開本番テレメトリ | | DyAlert | 2023 | ASE | Alibaba Group ほか | 動的グラフ上の異種 GNN と GRU による時空間リンク予測 | 単一事業者の非公開本番テレメトリ | | COLA | 2024 | ICSE-SEIP | Huawei Cloud ほか | 時間相関と空間相関の統計判定に加え、不確実ペアのみ SOP を用いた LLM 推論 | 単一事業者の非公開本番テレメトリ | | SuperAgg | 2024 | ISSRE | National University of Defense Technology ほか | センサ層の時系列パターンとシステム層の主従関係による 2 段階階層集約 | 単一スーパーコンピュータの非公開運用テレメトリ | 本部の対象論文はいずれも単一事業者または単一システムの非公開本番テレメトリで評価されており、複数事業者を横断する公開ベンチマークは存在しない。 #### 各手法の位置づけ AlertStorm は、テキスト類似度単独でもトポロジ距離単独でもなく、重み 0.6 の合成が最良になることをアブレーションで確認した最初の集約手法である (Source: [[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems]])。 DBSCAN によるクラスタリング後、各クラスタのセントロイドを代表アラートとして選択し、調査対象アラート件数を 98% 以上削減した (Source: [[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems]])。 LinkedIn のスパイク検知は、アラート相関が推定した根本原因候補から一時的なレイテンシスパイクを分離する後段フィルタである。 約 5 日間の運用で 193 件の推奨のうち 71 件(36.4%)がスパイクと判定され、偽陽性率 1% 未満を達成した (Source: [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]])。 グラフベースのリンク予測や表現学習を用いず、機械学習を導入しない単純な統計手法でトイルを 30% から 40% 削減した点が特徴である (Source: [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]])。 GRLIA は、インシデント本文の類似度に依存せず、障害伝播経路上の中間サービスが耐障害性や監視設定の閾値ゆえにインシデントを出さない沈黙の問題を、KPI トレンド類似度による障害影響グラフの補完で解消する。 Louvain コミュニティ検出で影響範囲を推定した後、DeepWalk 型のランダムウォークを Word2Vec に入力してインシデント種別ごとの表現ベクトルを教師なしで学習する。 障害影響グラフの補完を除いたアブレーションでは、3 データセットで NMI が 0.831、0.866、0.912 から 0.782、0.808、0.846 へ低下し、補完が集約精度の主要因であることを示した (Source: [[@2021__ASE__Graph-based Incident Aggregation for Large-Scale Online Service Systems]])。 DyAlert は、アラートストームの本質をアラートの伝播と捉え、集約問題をリンク予測問題として定式化する。 アラートノードとメトリクスノードを配置した離散時間動的グラフに、辺の種類ごとに異種 GNN で空間表現を、GRU で時間表現を学習する。 85 ビジネスユニットで約 3 万サービスの本番データ(2022 年 7 月から 8 月)、6,995 件のアラートによる評価で、DyAlert は F1 スコア 0.759 を達成し、既存手法を適合率と再現率でそれぞれ平均 41.8%、10.1% 上回った (Source: [[@2023__ASE__Dynamic Graph Neural Networks-Based Alert Link Prediction for Online Service Systems]])。 COLA は、意味類似度手法が見落とす因果的アラートペアと、統計手法が扱えない低頻度アラートの双方に対処するため、外部知識として標準処理手順を初めてアラート集約に導入した。 時間相関と空間相関で信頼度の高いペアを即座に確定し、信頼度の低いペアのみを標準処理手順を用いた LLM 推論に回すハイブリッド設計を採る。 本番 3 データセット(約 50 万アラート、3,000 の標準処理手順)で F1 0.901 から 0.930 を達成し、LLM 単体の平均推論時間 42.81 秒から 50.02 秒毎ペアを、5.78 秒から 8.94 秒毎ペアへ圧縮した (Source: [[@2024__ICSE-SEIP__Knowledge-aware Alert Aggregation in Large-scale Cloud Systems - a Hybrid Approach]])。 SuperAgg は、スーパーコンピュータの構造化アウトオブバンドアラートに対し、センサ層のアラートパターン 4 カテゴリを教師なし対照学習と人間の判断を交えて発見し、システム層のセンサ間主従関係を Apriori 法で採掘する 2 段階階層構造を採る。 2 つのデータセットでの評価では、集約率 99.04% と 98.64%、集約精度 99.18% と 95.88% を達成し、3 つのベースラインに対し集約精度で少なくとも 83.8%(データセット A)、43.2%(データセット B)上回った。 アブレーションでは、センサ層の集約単独で集約率 98.88% と 98.33%、精度 100% と 100% を達成し、センサ層が支配的な貢献者であることを示した (Source: [[@2024__ISSRE__Exploring Hierarchical Patterns for Alert Aggregation in Supercomputers]])。 #### テキスト類似度単独の限界 4 本の論文が、独立した技法でこの発見を反復確認している。 AlertStorm のアブレーションはテキストのみの設定が複合設定に劣ることを示し、DyAlert のアブレーションはテキスト意味情報単独に対しメトリクス情報の追加が F1 を 10.1% 押し上げることを定量化した (Source: [[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems]], [[@2023__ASE__Dynamic Graph Neural Networks-Based Alert Link Prediction for Online Service Systems]])。 COLA は、意味類似度手法が因果的な論拠を見落とすという限界そのものを設計の出発点に据え、外部知識で補う設計転換を行った (Source: [[@2024__ICSE-SEIP__Knowledge-aware Alert Aggregation in Large-scale Cloud Systems - a Hybrid Approach]])。 SuperAgg は、離散的なアラートレベルを持つ構造化アラートに対して類似度ベース手法を適用すると、類似度の値域が狭いためクラスタリングがランダム選択に退化すると指摘する (Source: [[@2024__ISSRE__Exploring Hierarchical Patterns for Alert Aggregation in Supercomputers]])。 これら 4 本は、対象ドメインと技法が異なるにもかかわらず、同一の結論へ収束している。 #### 時間的順序と根本原因の乖離 DyAlert は、システムが 30 秒から 1 分間隔でメトリクスをサンプリングするため複数アラートが同時刻に記録され、シーケンスとして表現すると伝播方向を捉えられなくなる時系列崩壊を報告する (Source: [[@2023__ASE__Dynamic Graph Neural Networks-Based Alert Link Prediction for Online Service Systems]])。 DyAlert は、2 アラートの時空間表現の二乗差を用いる対称なリンク予測で、この順序依存性を回避する設計を採る (Source: [[@2023__ASE__Dynamic Graph Neural Networks-Based Alert Link Prediction for Online Service Systems]])。 SkyNet は、ネットワーク行動が先に乱れデバイスエラーの Syslog が数分遅れて記録される事例を報告し、時系列順に従って因果を推論する典型的なアプローチを設計上否定する (Source: [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]])。 SkyNet のアラートツリー構造はタイムアウトウィンドウで同一 location のアラートを束ねる設計であり、順序の仮定を置かない (Source: [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]])。 集約系とネットワーク障害検知系という異なるドメインで、時間的順序への依存を避ける設計が独立に選ばれたことは、この発見の頑健性を示す。 時間的順序を使う側の系譜もある。 2014 年の Luo ら(Jilin University、Microsoft Research)は、アラートどうしではなく、イベント列(アラートやジョブ開始)と時系列メトリクスの相関を、存在、時間順序、単調効果(正か負か)の 3 側面で判定する手法を KDD で提案した (Source: [[@2014__KDD__Correlating Events with Time Series for Incident Diagnosis]])。 各イベントの前後から長さ $k$ の部分時系列を切り出し、無作為に切り出した部分時系列と区別できるかを最近傍統計量による多変量二標本検定で判定する。 前側が異なれば時系列がイベントに先行し、後側だけが異なればイベントが時系列に先行するとみなす。 $k$ は自己相関の第 1 ピークから自動で選ぶ (Source: [[@2014__KDD__Correlating Events with Time Series for Incident Diagnosis]])。 ![[_attachments/2014__KDD__Correlating-Events-with-Time-Series-for-Incident-Diagnosis/fig03-temporal-order.png]] **図20-1**:CPU 負荷の高いプログラムの開始イベントが CPU 使用率の上昇に先行し、CPU 使用率の上昇が SQL クエリのアラートに先行する例。本文が述べた「アラートを結果の側に置き、その前段のメトリクスへ遡る」という使い方は、2 本の矢印が時系列の立ち上がりの前後に分かれて置かれていることに対応する。 (Source: [[@2014__KDD__Correlating Events with Time Series for Incident Diagnosis]], Figure 3) Microsoft の本番データ 2 種(システム監視とカスタマーサポート)で、エンジニアが付けた正解に対し、相関の存在の判定で F1 0.7962 と 0.8631 を得て、Pearson 相関(0.6974 と 0.6030)と J-measure(0.6148 と 0.7398)を上回った。 時間順序の判定は F1 0.8021 と 0.8205 だった (Source: [[@2014__KDD__Correlating Events with Time Series for Incident Diagnosis]])。 著者ら自身、相関から因果は導けないと明言し、得られるのは因果の向きの仮説にとどまるとする (Source: [[@2014__KDD__Correlating Events with Time Series for Incident Diagnosis]])。 アラート間の発火順を信じる素朴な設計を退けた DyAlert や SkyNet と、統計検定で順序を確かめて仮説として使う Luo らの手法は、時間的順序をそのまま因果とみなさないという点で矛盾しない (Source: [[@2023__ASE__Dynamic Graph Neural Networks-Based Alert Link Prediction for Online Service Systems]], [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]], [[@2014__KDD__Correlating Events with Time Series for Incident Diagnosis]])。 #### 軽量統計手法と表現学習の分業 検知とノイズ除去の段では、軽量な統計手法が機械学習に匹敵するか上回る現象が繰り返し観察される。 AlertStorm の極値理論は F1 スコア 0.9 超をすべてのデータセットで達成し、固定閾値法だけでなく学習ベースの異常検知よりも計算効率で優位に立つ (Source: [[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems]])。 LinkedIn のスパイク検知の修正 Z スコアは、グラフ学習や深層モデルを用いず偽陽性率 1% 未満を達成した (Source: [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]])。 一方、集約とリンク予測の段では表現学習やグラフ学習が必要になる。 GRLIA はテキスト類似度に依存せずグラフ表現学習でインシデント種別を扱い、DyAlert は異種 GNN と GRU で時空間表現を学習し、いずれも軽量な統計手法だけでは到達できない精度を得ている (Source: [[@2021__ASE__Graph-based Incident Aggregation for Large-Scale Online Service Systems]], [[@2023__ASE__Dynamic Graph Neural Networks-Based Alert Link Prediction for Online Service Systems]])。 技法選択がライフサイクル段階によって分業しているという構図は、検知とノイズ除去が異常の有無という単純な判定であるのに対し、集約とリンク予測がどのアラート同士が同一原因かという組合せ的な判定であることに対応する。 #### LLM 採用境界とデータ規模 COLA は、アラート単位の相関判定という比較的小さな粒度に LLM を適用し、相関マイニングで高信頼ペアを事前に処理することで LLM への入力を絞り込むハイブリッド分業により実用化した (Source: [[@2024__ICSE-SEIP__Knowledge-aware Alert Aggregation in Large-scale Cloud Systems - a Hybrid Approach]])。 一方 SkyNet は、Syslog が 15 分で約 1,000 万エントリに達し既存 LLM の最大 2,000 万トークンのコンテキストをリアルタイムに消化できないことを理由に、重大なネットワーク障害の検知に LLM を意図的に不採用とした (Source: [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]])。 SkyNet は代わりに、約 1,000 ルールの標準処理手順との役割分担で既知の単純な故障パターンに対処し、未知かつ重大な障害に SkyNet 自身の location 階層と severity スコアを充てる (Source: [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]])。 COLA と SkyNet の分岐は、扱うデータの粒度がアラートペア単位かシステム全体のログストリーム単位かという規模の違いに規定されており、LLM 採用の是非は技術トレンドとしての進歩よりもまず入力規模の設計で決まる。 ### 第 21 章　インシデント検知と予測 ![[Attachments/アラート管理の教科書/chapter-21.png]] #### アラートのみを入力とした 2 値分類による検知 Warden は、クラウドのインシデント管理において、各チームがシステム全体の部分的な視界しか持たないために複数サービスにまたがるインシデントの検知が遅れる「戦場の霧」の問題に対処する。 Warden は、直近の時間窓内のアラート信号集合からインシデント発生確率を推定する 2 値分類モデルとして Balanced Random Forest を採用する (Source: [[@2021__ATC__Fighting the Fog of War - Automated Incident Detection for Cloud Systems]])。 Azure の 26 主要サービス、18 か月分、1,000 万件超のアラートによる評価で、適合率 90% 以上を維持した設定で再現率約 58%、F1 スコア 0.71 を達成した。 成功検知したインシデントの約 68% で Warden は人間より早く検知しており、時間短縮の中央値は当該インシデントの緩和時間全体の約 15% に相当する (Source: [[@2021__ATC__Fighting the Fog of War - Automated Incident Detection for Cloud Systems]])。 #### 信号選択と寄与度の推定 Warden は、全監視項目のアラートをそのままモデルに入力すると検知モデルが飽和するという問題に対し、重み付き相互情報量で監視項目とインシデントサブタイプの相関をスコアリングし、上位 150 件の監視項目のみを選択する。 監視項目数を 25 から 300 の範囲で変化させた実験では、25 から 150 への増加で再現率が大きく上昇し、150 を超えると追加監視項目の寄与が薄れることを確認した (Source: [[@2021__ATC__Fighting the Fog of War - Automated Incident Detection for Cloud Systems]])。 Warden は、検知結果への寄与度をアラート信号のグループ単位で評価する Group Shapley Value を提案する。 履歴上 3 回以上リンクされた頻出アラート信号のペアや同一クラスタから短時間に発火したペアをグルーピングしたうえで、Shapley 値法を応用したモンテカルロ近似で各グループの寄与度を推定する (Source: [[@2021__ATC__Fighting the Fog of War - Automated Incident Detection for Cloud Systems]])。 識別されたアラートグループの所属サービス集合と実際の影響サービス集合の Jaccard 指数は、53% のケースで完全一致し、78% のケースで 0.5 以上を記録した (Source: [[@2021__ATC__Fighting the Fog of War - Automated Incident Detection for Cloud Systems]])。 この手法は、個別特徴単位のモデル解釈とは異なり、アラート信号のグループ単位で寄与度を評価する点が本質的な違いである (Source: [[アラート相関]])。 #### ベイジアンネットワークによる依存関係発見 AirAlert は、クラウドシステム全体に対するグローバルウォッチャとして全アラート信号を収集し、FCI アルゴリズムでアラート信号とアウテージの依存関係グラフを学習する。 AirAlert は、ベイジアンネットワークが接続を発見した信号のみを XGBoost に投入するモードと、全信号を投入するモードの 2 つを持ち、ベイジアンネットワークを診断ツールと特徴選択ツールの二重に使う設計を採る (Source: [[@2019__WWW__Outage Prediction and Diagnosis for Cloud Service Systems]])。 コンポーネントレベルの単一故障では単一信号の閾値超過ルールでも F1 が 70% 台を確保できるが、複数サービス横断のサービスレベルではこの単純ルールの F1 が 7.72 から 11.63 まで崩壊し、複合信号を扱うモデルが必要になる。 Microsoft クラウドの 1 年分、6 サービス、約 8,000 時刻サンプルでの評価では、サービスレベルで F1 88.78%、53.92%、75.08% を達成した (Source: [[@2019__WWW__Outage Prediction and Diagnosis for Cloud Service Systems]])。 #### multi-instance learning によるノイズ抑制 eWarn は、観測窓を 1 つの bag として、より細粒度のインスタンス窓群を instance とみなす multi-instance learning を、テキスト特徴と統計特徴に組み合わせる。 正例の bag に含まれるインスタンスを階層クラスタリングでクラスタリングし、インスタンス数が多いクラスタほど予兆的である可能性が高いという観察に基づきクラスタサイズに比例した重みを各インスタンスへ付与する (Source: [[@2020__ESEC-FSE__Real-Time Incident Prediction for Online Service Systems]])。 商業銀行の 11 の実サービスシステムでの評価で、この仕組みを除去すると平均 F1 が 0.82 から 0.66 へ低下し、ノイズアラート抑制への寄与を確認した。 同じ実験で、テキスト特徴のみでは平均 F1 0.69、統計特徴のみでは 0.36 にとどまり、両特徴の併用が必要であることを確認した (Source: [[@2020__ESEC-FSE__Real-Time Incident Prediction for Online Service Systems]])。 > [!contradiction] AirAlert の原論文は、Microsoft クラウド本番のサービスレベル予測で F1 最大 88.78% を報告する (Source: [[@2019__WWW__Outage Prediction and Diagnosis for Cloud Service Systems]])。 > 一方 eWarn 論文は、同じ AirAlert を中国の大手商業銀行の 11 実サービスシステムで比較対象として評価し、「アラート種別の件数のみに依存しノイズ処理もない」単純な特徴設計だと評価したうえで平均 F1 0.51 と報告する (Source: [[@2020__ESEC-FSE__Real-Time Incident Prediction for Online Service Systems]])。 > 両者は評価データセットが異なるため直接比較できないが、同一手法の評価が文脈によって逆転するこの事実は、単一事業者データでの性能報告がそのままベンチマーク間の再現性を保証しないことを示す。 #### 予測可能性の限界 eWarn は、電源障害のような突発的要因によるインシデントを原理的に予測困難な事例として報告する。 こうした予兆のないインシデントは、学習時に正例として扱われるためノイズラベルの一因となり、モデルの性能に上限を課す (Source: [[@2020__ESEC-FSE__Real-Time Incident Prediction for Online Service Systems]])。 eWarn は、アプリケーション層のインシデントは低レベルコンポーネントの障害に起因するため予測しやすいと述べ、予測可能性の差は障害の階層的な位置づけに依存すると論じる (Source: [[@2020__ESEC-FSE__Real-Time Incident Prediction for Online Service Systems]])。 予測窓のサイズはラベリング品質を直接左右するパラメータであり、システムごとに最適値が異なることも、単一の予測モデルを全システムへ汎用適用する難しさを示す (Source: [[@2020__ESEC-FSE__Real-Time Incident Prediction for Online Service Systems]])。 Warden、AirAlert、eWarn の 3 手法はいずれも単一事業者の非公開本番テレメトリで評価されており、本部を通じて確認してきた評価データの出自の一様性がここでも繰り返される。 #### テレメトリの外から来る検知 以上の 3 手法はいずれもアラート信号を入力にする。 SRE Book 第 2 版第 21 章が紹介する Google の Detectr は、入力を利用者のフィードバックに置き換える。 Gemini を使い、非構造化のフィードバックを LLM によるフィルタリングとクラスタリングで対処可能なアラートへ変換する。 クラスタの量が重大度の信号になり、フィードバックを書く手間自体がノイズフィルタとして働く。 2025 年第 4 四半期から 2026 年第 1 四半期の測定で累計数千時間の顧客影響を削減したとされるが、測定方法は記載されていない (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]])。 同章は、従来の統計的異常検知が利用者の意図を理解できず普及しなかったと述べ、メトリクスが正常でも利用者が苦しむ文脈依存の隙間に AI の最大の潜在力があるとする (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]])。 Charity Majors(Honeycomb)の 2026 年のマニフェストは、同じ隙間を別の言葉で指摘する。 ページの閾値は高く、性能の変化、コストの漸増、エッジケース、前日のデプロイの副作用は検知されずに通り過ぎ、気づいた時には原因と結果の距離が開いているという (Source: [[@2026__Honeycomb Blog__Honeycomb 10 Year Manifesto Part 1]])。 > [!contradiction] 統計的な異常検知(AIOps)が期待に届かなかった理由について、SRE Book 第 2 版第 21 章は利用者の意図を理解できなかったことに求める (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]])。 > Majors(Honeycomb)は、浅いデータセットからは価値がほとんど出ないことが AIOps の欠陥だったとし、原因をデータの深さと関係の保持に求める (Source: [[@2026__Honeycomb Blog__Honeycomb 10 Year Manifesto Part 1]])。 > 前者は意味理解を足せば埋まると読み、後者は構造化イベントという基盤がなければ AI も機能不全を増幅するだけだと読む。どちらの診断も実証データを伴わない。 Honeycomb のマニフェストは製品ベンダーの立場表明であり、実証データを含まない (Source: [[@2026__Honeycomb Blog__Honeycomb 10 Year Manifesto Part 1]])。 --- ## 第 VI 部　配送とルーティング 第 V 部までで、何を鳴らすかという生成の問題と、量をどう抑えるかという削減の問題を扱った。 第 VI 部では、削減を経て残ったアラートを誰にどう届けるかという配送の問題を扱う。 軸 C はいずれの章も SRE 実務であり、軸 D はいずれも事例報告にとどまる。 配送段階の効果を定量的に評価した学術研究や公開ベンチマークは、本ページの母集団には存在しない。 誰に届けるかという経路設計にとどめ、受け取る人間の体制や負荷は第 VII 部が扱う。 ### 第 22 章　振り分けとページングの設計 ![[Attachments/アラート管理の教科書/chapter-22.png]] まず緊急度による経路分岐から見る。 Anatomy of an Incident の第 1 章は、アラートを緊急度に応じてページ(即時の人間介入)、アラート(数時間以内の対応)、メトリクスまたはログ(プル型で対応不要)の 3 経路に振り分けるべきだと述べる (Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 1 Introduction]])。 行動不能なアラートをチケット化する運用は、対応者のトイルとアラート疲労という 2 種の害を生むだけで、実際の検知に対する信号対雑音比をかえって悪化させる (Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 1 Introduction]])。 同種の分岐は事例報告でも独立に現れる。 Sohei Iwahori(GREE, Inc)が SRE NEXT 2020 で報告した振り分けは、発生を知りたいが即時アクション不要なら Slack 通知のみ、即時不要だが何らかの対応が必要なら JIRA チケットの自動起票、その場で直ちに具体的アクションが必要なら PagerDuty のオンコールという 3 段階である (Source: [[@2020__SRENext2020__Practices for Making Alerts Actionable]])。 この 3 段階は実装レベルの設計であり、通知先の分岐そのものを内製のアラートコントロールシステムに実装している (Source: [[@2020__SRENext2020__Practices for Making Alerts Actionable]])。 同じ Sohei Iwahori(GREE, Inc)が SRE NEXT 2023 で報告した振り分けは、調査目的か、サービス影響があるか、具体的対応アクションがあるか、今すぐ対応が必要か、機械的対応が可能かという条件を分岐させ、チャット通知、チケット、オンコール通知のどれを選ぶかをアラート追加の時点で決めさせる (Source: [[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか]])。 横断オンコールアラートについては、偽陽性の検証、対応 Runbook の記載、背景を含めた全体周知という追加条件を課し、アラート追加時点でアクションを固めることでアラート疲れを軽減する狙いを述べる (Source: [[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか]])。 2020 年の発表と 2023 年の発表は、同一組織かつ同一発表者による経年変化として読める (Source: [[@2020__SRENext2020__Practices for Making Alerts Actionable]], [[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか]])。 2020 年は振り分け先を実装レベルで 3 段階に分ける設計であり、2023 年はアラートを追加する前に振り分け先と判断材料を決めさせる上流統制である。 これらを並べると、振り分けの設計は 3 段階から 4 段階程度の粒度に収束する一方、どの基準で閾値を引くかは組織ごとに異なる (Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 1 Introduction]], [[@2020__SRENext2020__Practices for Making Alerts Actionable]], [[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか]])。 #### チャットという中間経路の是非 振り分けの粒度が収束する一方で、緊急でない通知をどこへ流すかは割れている。 Ewaschuk はページ未満の通知を 2 つに分ける。 数時間から数日で対応する課題はチケットにし、重複を自動で 1 件に集約して週次のオンコール引き継ぎでトリアージする。 長期のトレンドは日次のサマリーレポートにする。 そのうえで、メーリングリストや Slack、IRC のチャンネルへアラートを垂れ流すことを、例外なく黙殺されるとして禁じる (Source: [[@2015__Rob Ewaschuk__My Philosophy on Alerting]])。 > [!contradiction] 『入門 監視』第 3 章もメールを人を起こす手段から外す点では Ewaschuk と一致するが、すぐに対応が必要ならページャ、注意は要るがすぐのアクションは不要なら社内チャット、記録と診断用ならログという 3 経路を示し、チャットを正規の中間経路に置く (Source: [[@2019__OReillyJapan__入門 監視 - Chapter 3 アラート、オンコール、インシデント管理]])。 > Ewaschuk はチャットへの垂れ流しを禁じ、中間経路をチケットとレポートに限る (Source: [[@2015__Rob Ewaschuk__My Philosophy on Alerting]])。 > GREE の 2020 年の 3 段階も最下段を Slack 通知に置いており、実務の事例報告はチャットを経路として残す側にある (Source: [[@2020__SRENext2020__Practices for Making Alerts Actionable]])。 SRE Book 第 2 版第 10 章は、人を呼ぶ手段をメールやチャットではなく明示的なページに統一する「ページファースト」の規範を置く (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 10 Incident Management and On-Call]])。 これは人を起こす経路の統一であり、緊急でない通知をチャットへ流すかどうかには触れていない。 #### 発火時にラベルで決めるか、事後に分類するか 振り分けを決める時点にも 2 つの設計がある。 Cloudflare は 2017 年時点で、アラートルールに付けた `notify` ラベルの単語を Alertmanager の正規表現でマッチさせ、`continue: true` でチャット、Jira、PagerDuty へ多重に振り分けていた。 SRE を深夜に直接呼ぶもの、日中の Jira 起票にとどめるもの、チャット通知で済ませるものを、ルールを書く時点でラベルとして決める (Source: [[@2017__PromCon__Monitoring Cloudflare's Planet-Scale Edge Network with Prometheus]])。 ![[_attachments/monitoring-cloudflares-planet-scale-edge-network-with-prometheus/page-043.png]] **図22-1**:RAID の劣化を検知するアラートルールの例。`notify="jira-sre"` というラベルが付いており、このアラートは人を起こすページではなく Jira のチケットへ送られる。annotations には Grafana ダッシュボードと社内 Wiki の Runbook へのリンクが書かれている。本文が述べた「振り分け先をルールを書く時点でラベルとして決める」設計と、第 13 章で見た Runbook とダッシュボードの必須化が、1 枚のルール定義に同居していることが分かる。 (Source: [[@2017__PromCon__Monitoring Cloudflare's Planet-Scale Edge Network with Prometheus]], p.43) これに対し、2017 年の ACM Computing Surveys の Li ら(Tao Li ほか)は、ITIL 型の流れを描く。 監視はメトリクスを閾値と比べてアラートを出し、アラートが遅延を超えて持続するとイベントになり、イベントは企業コンソールで集約されてインシデントチケットとして登録される。 振り分けはその後、過去チケットから学習したチケット分類で行う (Source: [[@2017__CSUR__Data-Driven Techniques in Computing System Management - Chapter 6 Problem Diagnosis in System Management]])。 前者は宛先を人が事前に宣言し、後者は宛先を事後に機械が推定する。 第 VIII 部第 29 章のチケットトリアージは、後者の系譜の LLM 時代の姿である。 次に、通知先そのものを動的に決める設計を見る。 Luis Mineiro(Zalando SE)が提案した Adaptive Paging は、症状ベースアラーティングが招くクリスマスツリー効果(1 つの障害で全関連サービスがアラートを発火し全チームが呼び出される現象)と、症状を所有するチームへの通知集中という 2 つの副作用に対処する。 Adaptive Paging は、SLO 閾値を超過した症状スパンから出発し、全子スパンのタグを検査してエラーのパスを再帰的にたどり、子スパンがなくなった最深のスパンを持つサービスのチームへ通知する。 複数のエグゼンプラを取得してパスごとにスコアを付与し、複数の子スパンがエラーの場合は最悪 2 チームへ通知する設計である (Source: [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]])。 ![[_attachments/srecon19emea-mineiro-adaptive-paging/page-031.png]] **図22-2**:1 本のトレース上でエラーを示すスパンが赤枠で強調され、症状スパンから最深のエラースパンまで矢印がたどられている。本文が述べた「エラーのパスを再帰的にたどり、子スパンがなくなった最深のスパンを持つサービスのチームへ通知する」というアルゴリズムは、この 3 段の矢印の連なりに対応する。 (Source: [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]], p.31) 適用限界も報告されている。 計装が欠落している場合はトレースが途切れるため、依存先を推定するフォールバックに頼る。 サーキットブレーカーが開いた場合も同様にトレースが途切れる。 オンコール体制を持たないサービスへは、エスカレーション先のマッピングがないため最も近い親チームへフォールバックする。 可用性への適用に比べ、レイテンシへの適用はより複雑になると口頭で補足されている。 MTTR の改善率や偽陽性率などの定量的な成果は報告されていない (Source: [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]])。 もう 1 つの動的ルーティングの系統は、分散トレーシングではなく属性による重複排除である。 上岡輔乃(LINEヤフー株式会社)が JANOG58 で報告した oyakata は、22,000 台以上のデータセンターネットワークにおける一次対応の人手ボトルネックと、複数チームによる自動化の乱立という 2 つの課題に対処するために構築された。 基盤には Apache Airflow の Operator、Task、Provider、Sensor という概念を採用し、基盤開発チームが共通 Operator を提供し、各ネットワークチームがそれを使ってワークフローを実装する分業モデルを取る。 Airflow 単体では監視システムからのアラート駆動の起動、アラート種別とワークフローの紐付け、重複アラートの起動抑制ができないため、これらを補う内製 API として oyakata を開発した (Source: [[@2026__JANOG58__ネットワーク監視の自動化はどこまでできるのか - Apache Airflowによるアラート対応基盤]])。 重複排除は、対象機器と NetBox から取得した対向ポートの双方にホスト名とインターフェースの組み合わせのタグを付与し、タグが一致すれば発生順によらず重複とみなしてワークフローの起動をスキップする仕組みである。 ワークフロー内には LLM エージェントを 1 つの Task として組み込み、関連アラートの判定やアラート分類、専門家エージェントによる調査確認を行う設計も採用している。 複数のネットワークチームへの本番導入により、アラート一次対応の 90% 以上を自動対応へ移行したと報告されるが、この 90% という数値の分母、すなわち対象アラートの母数や集計期間はスライド上に明示されていない (Source: [[@2026__JANOG58__ネットワーク監視の自動化はどこまでできるのか - Apache Airflowによるアラート対応基盤]])。 Adaptive Paging と oyakata のタグベース重複排除は、いずれも MTTR の改善率や偽陽性率に相当する定量評価の算出根拠を欠く点で共通する (Source: [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]], [[@2026__JANOG58__ネットワーク監視の自動化はどこまでできるのか - Apache Airflowによるアラート対応基盤]])。 最後に、振り分けとページングの設計を貫く実務目標を確認する。 マイク・クリスチャン(Yahoo!)は、監視を信号対雑音比を調整し続けるプロセスと位置づけ、放置してポケベルが鳴るのを待つだけでは足りず、些細なアラートで担当者を頻繁に起こせば重要な兆候も無視されるようになると述べる (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]])。 調整がうまくいけば、数十のデータセンタに数百台のサーバがある環境でもアラート回数を週数回まで減らせるとする (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]])。 緊急度分岐、動的ルーティング、属性ベースの重複排除は、いずれもこの調整という目標に対する異なる介入点であり、経路を固定する設計ではなく調整し続ける運用として捉えるべきである (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 17 夜中に聞こえる奇妙な物音（と、ぐっすり眠る方法）]], [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]], [[@2026__JANOG58__ネットワーク監視の自動化はどこまでできるのか - Apache Airflowによるアラート対応基盤]])。 ### 第 23 章　Runbook と調査準備 ![[Attachments/アラート管理の教科書/chapter-23.png]] Runbook に何を書くかという設計判断から始める。 Sohei Iwahori(GREE, Inc)は、従来の障害対応手順書がエスカレーション先の参照情報、検索性、アラート自体を見直すための背景説明を欠いており、手順だけではなぜそのアラートがあるのかが失われると指摘する。 この指摘に基づき、Runbook は短期的な定型解決策よりも、背景、判断材料、解決につながる文脈やヒントを残すものとして設計されている (Source: [[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか]])。 テンプレートは症状、背景、確認項目、解決、事後確認、関連情報という構成を取り、しきい値の詳細ではなく背景と判断材料を残す方針を具体化する。 定型コマンドで解決できるなら自動化対象であり、人間を起こす以上は判断の材料が必要になるという原則も述べられる (Source: [[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか]])。 Runbook リポジトリからインデックスを生成し、アラート処理時に Runbook の情報をメッセージへ付加し、存在しない場合は作成を促す導線も実装されている。 口頭説明では、Runbook が有効に働く条件として、知見の積み上げが可能で、原因ベースのアラートを利用または併用している環境が挙げられる。 ブラックボックスに基づく症状アラートは原因が無数にあるため、固定 Runbook での対応が難しいという補足も添えられる (Source: [[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか]])。 Runbook の位置づけについては、立場の対立がある。 > [!contradiction] 自動化可能な Runbook は自動化への踏み石として一時的に存在すべきものであり、長期間存続すること自体が組織に自動化文化が根付いていない症状だとする立場がある (Source: [[ダッシュボードとランブックの運用]])。 > 一方、Sohei Iwahori(GREE, Inc)の運用は、背景、判断材料、文脈を Runbook へ長期的に残し、エスカレーション先の未知性を減らすことを目的としており、Runbook を恒久的な背景情報の保管庫として位置づける (Source: [[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか]])。 > 両者は、定型的に自動化できるものは自動化すべきだという点では一致する (Source: [[ダッシュボードとランブックの運用]], [[@2023__SpeakerDeck__Runbookに何を書き、どのようにアラートを振り分けるか]])。 「機械的な手順は自動化する」という合意は、より早い文献にも共通する。 Ewaschuk は長大なフローチャートの Playbook をアンチパターンとし、それを書くくらいならシステムを自動修復できるよう改修すべきだとする (Source: [[@2015__Rob Ewaschuk__My Philosophy on Alerting]])。 『入門 監視』第 1 章は、手順書が単なるコマンドの羅列なら、アラートを出す前に監視ツール自身に実行させるよう勧める (Source: [[@2019__OReillyJapan__入門 監視 - Chapter 1 監視のアンチパターン]])。 同書第 3 章は、コピー&ペーストで済むほど単純な手順しか書けないなら自動化してアラート自体を削除し、既知の定型手順は人間に通知する前に自動復旧を試すとする (Source: [[@2019__OReillyJapan__入門 監視 - Chapter 3 アラート、オンコール、インシデント管理]])。 一方、手順書の粒度は割れる。 > [!contradiction] Ewaschuk は、アラートの意味、初動で見る箇所、現在の既知パターンを Wiki 等に書いたアラート単位の簡潔なメモを最良の Playbook とする (Source: [[@2015__Rob Ewaschuk__My Philosophy on Alerting]])。 > 『入門 監視』の付録 A は、サービス単位で、概要、メタデータ、エスカレーション手順、外部依存、内部依存、技術スタック、メトリクスとログ、アラートの 8 項目を網羅する手順書の雛形を示す。該当がなくても「外部依存はありません」と項目を残し、各アラートの説明には発報条件に加えて疑うべき原因とまず見る調査先を書く (Source: [[@2019__OReillyJapan__入門 監視 - Appendix A 手順書の例 Demo App]])。 > 前者はアラートに、後者はサービスに手順書を結びつけている。 付録 A の 4 件のアラートはサインイン失敗率(5 分間で 5% 超)と処理時間(1 秒超)という症状であり、不正なデプロイや PostgreSQL の性能といった原因は手順書の側に書かれる (Source: [[@2019__OReillyJapan__入門 監視 - Appendix A 手順書の例 Demo App]])。 症状で起こし原因は付帯情報で示すという構造は Ewaschuk の Also Firing と同じだが、原因の置き場所が、Ewaschuk では動的な通知本文、付録 A では静的な文書である (Source: [[@2015__Rob Ewaschuk__My Philosophy on Alerting]], [[@2019__OReillyJapan__入門 監視 - Appendix A 手順書の例 Demo App]])。 SRE Book 第 2 版第 22 章は、手順書の読み手を SRE 以外へ広げる。 プレイブックを非 SRE 向けに書き、初期の切り分けの委譲、オンボーディング、将来の自動化の擬似コードを兼ねさせる。 直近 5 件の障害について書き、RAG で問い合わせできるようにし、サービスが到達不能でも読めるよう GitHub リポジトリ、ローカルの退避パッケージ、オフライン版に置く (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 22 SRE in Diverse Environments]])。 同書第 9 章は、手順書を読む前の段階を自動化する。 アラートが発火したら症状チェックを自動で実行し、専用ダッシュボードと緩和案を出す (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 9 Observability and Monitoring]])。 同書第 10 章は、調査の目的を根本原因ではなく緩和への道筋を見つけることに置き、ロールバック、キャパシティ増強、再起動、トラフィック移動といった汎用的な緩和策を用意して調査と織り交ぜる。 これらの緩和は診断実験も兼ねる (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 10 Incident Management and On-Call]])。 次に Warning アラートの扱いを見る。 Warning アラートは、即座に人間が対応する Critical アラートよりも低い重要度として扱われるが、重大事故の前兆を含む可能性がある警告である。 池田将士(カヤック)は、AWS WAF の月次稼働率 99.95% を前提に、ALB の 1 分間レスポンスで 5xx が 1 件以上なら 1 週間で 5 件の Warning アラートが出ても不思議ではないと述べ、頻度の高さを示す。 Warning アラートの初期判断の調査は、手作業、週次反復、戦術的、長期価値の薄さ、サービス成長への比例という性質を持ち、トイル化しやすいと指摘する (Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]])。 対応は 2 つの介入点に分かれる。 GREE の振り分けにおける JIRA チケットの自動起票は、人間へのタスク割り当てそのものを自動化する介入である (Source: [[@2020__SRENext2020__Practices for Making Alerts Actionable]])。 これに対し池田将士(カヤック)の prepalert は、Mackerel のアラート Webhook を起点に AWS Lambda、SQS、CloudWatch Logs Insights、S3 select、Redshift data API から情報を集め、Mackerel のアラートメモへ貼ることで、人間が判断するための材料そのものを自動収集する (Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]])。 前者はアラートを人間の作業キューへ乗せる自動化であり、後者はそのアラートに人間が向き合う前の調査を自動化する (Source: [[@2020__SRENext2020__Practices for Making Alerts Actionable]], [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]])。 導入後は、週次定例前に初期判断の情報がそろうため振り返り時間を短縮できたと報告される。 レスポンスタイムの 99 パーセンタイルが 1.5 秒を超えた Warning に対し、画像アップロード API の 1 件が 17.9 秒だったことを自動メモで確認し、エラーバジェットの残量を踏まえて放念できた例が挙げられる。 脆弱性攻撃の事例では、アプリケーション側では有効な攻撃になっていないにもかかわらず 5xx が返ってエラーバジェットを消費していたことが自動収集した情報から判明し、WAF で遮断する対策につながった (Source: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]])。 最後に、アクショナブル化を実現する実務上の柱を確認する。 Sohei Iwahori(GREE, Inc)は、オンプレミスから AWS への移行後に静観アラートが急増した経験から、アクショナブル化を 5 本の柱で整理する。 第一の柱は定期計測であり、月次のオンコールアラート上位 10 件を集計し、毎月どう扱うべきかを検討する定例運用が改善の起点になる。 第二の柱は判定条件の最適化であり、Prometheus の持続時間句による期間判定や、チェック系監視の連続検知判定で、一時的スパイクや誤検知を抑制する (Source: [[@2020__SRENext2020__Practices for Making Alerts Actionable]])。 第三の柱が、本章前半で見た振り分けの 3 段階設計である。 第四の柱は自動復旧であり、プロセス再起動のような副作用がない定型アクションを AWS Lambda と AWS SSM による仕組みで自動化し、結果をチャット通知する。 導入は副作用がなく実行前より状態が悪化しない箇所から着手し、自動対応ルールと人間向けルールを分離することが実務上のプラクティスとして述べられる。 第五の柱は共通判定指標であり、全 CPU 使用率、ディスク I/O 使用率、NIC 割り込み CPU 使用率の最大値として定義された独自指標を整備し、80 を超えたら対応が必要という基準を全チームで共有することで、オンコール担当者の判断コストを下げる (Source: [[@2020__SRENext2020__Practices for Making Alerts Actionable]])。 これら 5 本の柱を実施した結果、月次オンコールアラート件数は 2018 年 9 月のピーク時の 300 件超から、2018 年 12 月から 2019 年 7 月にかけて概ね 180 件から 220 件の水準へ安定したと報告される。 ピーク比で約 4 割の削減にあたるが、この数値は発表者自身が述べるとおりグラフ読み取りによる概算であり、正確な分母や算出方法は開示されていない (Source: [[@2020__SRENext2020__Practices for Making Alerts Actionable]])。 --- ## 第 VII 部　オンコールと人間 第 VI 部はアラートの届け方の設計を扱った。 第 VII 部は受け取る側の人間を扱う。この部だけは年代ではなく主題で切る通時的な部である。 インシデント発生後の指揮と役割分担、ポストモーテムの運営は姉妹ページ [[インシデント対応の教科書]] と [[ポストモーテムの教科書]] が扱う。本部では踏み込まない。 ### 第 24 章　オンコール体制の設計 ![[Attachments/アラート管理の教科書/chapter-24.png]] #### 時間配分の制約が定める最小人数 SRE Book 第 11 章は、オンコールを担当者の健康を犠牲にせず信頼性を達成するという前提のもとで、時間配分の量的均衡と障害頻度の質的均衡という 2 軸で設計すべき対象として扱う。 Google では、エンジニアリング業務に最低 50%、オンコールに最大 25%、その他の運用作業に最大 25% という時間配分を採用する。 この制約が、単一拠点で 8 名、複数拠点では各拠点 6 名という最小チーム人数を逆算的に決定する。 質的均衡の指標は、12 時間シフトあたりのインシデント上限を 2 件とし、1 件あたり根本原因分析、修復、ポストモーテム執筆を含めて平均 6 時間を見込むというものである (Source: [[@2016__OReilly__SRE Book - Chapter 11 Being On-Call]])。 ページングイベントの分布はできるだけ平坦であるべきで、日次の中央値 0 件が望ましいとされる。 プライマリとセカンダリのローテーションを分離し、セカンダリはページのフォールバックまたは非緊急運用に充てる。 複数拠点チームであれば、夜間のみのローテーションではなく昼間だけをつなぐフォロー・ザ・サン体制を組むことで、夜間シフトの健康被害を避けつつローテーション規模の縮小による本番習熟の低下も防げる (Source: [[@2016__OReilly__SRE Book - Chapter 11 Being On-Call]])。 運用負荷が持続的に過大な場合、SRE チームは開発チームへオンコール責任、いわゆるページャーを返却できる権限を持つべきである。 このページャー返却は SRE と開発の間の健全な緊張関係を体現する仕組みとして位置づけられる。 逆に運用の過少負荷も危険であり、静穏すぎるシステムへのオンコールは過信と本番システムへの習熟不足を招くため、Wheel of Misfortune 演習や年次の災害復旧訓練による習熟維持が求められる (Source: [[@2016__OReilly__SRE Book - Chapter 11 Being On-Call]])。 Google SRE ワークブックの第 8 章はこの量的かつ質的な均衡を実務に展開し、ページャー負荷を単発のアラート件数ではなく、同じ本番バグが何度ページを生むか、どのコンポーネントが主因か、他の監視信号と相関するかに分解して分析すべきだと述べる。 ページングイベントは、即時対応かつ SLO 影響を持つもの、翌営業日対応のもの、情報のみのものというように扱いを分ける。 エラーバジェット違反時には新機能開発やロールアウトを止めて信頼性改善へ集中するという運用が、ページャー負荷削減の手段としても使われる。 オンコールスケジュールは公平性と個人事情の両立が必要であり、自動スケジューラ、ピアレビュー付きの交代、パートタイム勤務への対応、最小人員の余裕が求められる (Source: [[@2018__Google SRE Workbook__On-Call]])。 なお「エンジニアリングに最低 50%」という数値は週次のノルマとして読まれがちだが、この目安の出典である SRE Book 第 5 章は「いくつかの四半期あるいは 1 年を通して平均してみたとき」という条件を付している。 『SREをはじめよう』第 8 章は、この但し書きが省かれたまま引用される誤用が広く見られると警告する (Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 8 SREのある一日]])。 同章はオンコール期間中の作業をインシデントと障害のモードと呼び、目の前の障害が作業内容を決定する反応的な性質を持つと位置づける (Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 8 SREのある一日]])。 #### 第 2 版での数値の扱い 2026 年の SRE Book 第 2 版第 6 章は、エンジニアリング作業 50% 以上、運用作業 50% 以下、オンコール 25% 以下という第 1 版の目安を維持しつつ、これは目標ではなく閾値として扱うと明記する。 最小人数も、時差 6 時間から 9 時間の 2 拠点で follow-the-sun を組むなら各拠点 6 名以上、夜間オンコールのある単一拠点なら 8 名以上と第 1 版の値を引き継ぐ。 新たに、最小規模の 2 倍に達したら 2 チームに分割すること(新設より分割のほうが混乱が少ない)と、8 名未満のチームは運用負荷をより規律的に監視することが加わった (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 6 Organizational Structures for SRE]], [[@2016__OReilly__SRE Book - Chapter 11 Being On-Call]])。 同書第 10 章は、SRE が扱うインシデントを 1 シフトあたり最大 2 件とする目安を残しつつ、1 件あたりの対応時間を 4 時間から 6 時間と見積もる。 第 1 版は平均 6 時間としていた (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 10 Incident Management and On-Call]], [[@2016__OReilly__SRE Book - Chapter 11 Being On-Call]])。 応答時間の要件からも人数を引き、3 分以内の応答が要件なら最低 2 名が即応できる状態にし、30 分以上なら外出もできるとする。 ローテーションの計画には制約ソルバーを使い、解がなければ応答時間、代休、勤務形態のどれを緩めるかを決める (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 10 Incident Management and On-Call]])。 いずれの数値も、導出の根拠データは記載されていない。 同章はまた、全員に通知すると傍観者効果が起き、特定個人に頼ると単一障害点になることを、構造化されたオンコール体制が要る理由に挙げる。 上位には、Google の Tech IRT と製品領域別の IRT を組み合わせる連合型のインシデント対応チームや、小組織向けにシニアエンジニアのプールがインシデントごとに集まるスウォーム型を置く (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 10 Incident Management and On-Call]])。 IRT の運営そのものは [[インシデント対応の教科書]] の領分であり、ここでは立ち入らない。 > [!contradiction] SRE Book 第 2 版第 6 章は、単独の SRE は単一障害点であり持続不可能だとし、少人数チームを編成できないなら開発側に DevOps の考え方を根付かせるべきだとする (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 6 Organizational Structures for SRE]])。 > 同じ本の第 22 章は、大きなチームがなくても SRE はできるとし、単独 SRE の優先順位を、同じ障害の止血、可視化(メトリクス、アラート、ログ)、最も恐れられている作業の自動化、開発者セルフサービスの順に示す。単独 SRE はトイル 80% から始まることが多いとも書く (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 22 SRE in Diverse Environments]])。 > 第 6 章は Google のような大組織の設計を、第 22 章は小規模組織や規制産業の現実を扱っており、同一書籍の中で前提とする組織規模が異なる。 実務書の側の人数算定はさらに小さい。 『入門 監視』第 3 章は、メンバーごとに 3 週間の間隔を空けるには 4 人、バックアップのローテーションも組むなら 8 人が必要だとし、バックアップ担当はそれなりの大きさのチームでない限り不要とする。 ローテーションは出勤日に始め(例として水曜午前 10 時)、ソフトウェアエンジニアも加える。 運用への「丸投げ」を避け、よいソフトウェアを作る動機と運用エンジニアへの共感を生むためである (Source: [[@2019__OReillyJapan__入門 監視 - Chapter 3 アラート、オンコール、インシデント管理]])。 SRE Book の 8 名は時間配分の上限から逆算した値であり、『入門 監視』の 4 名はオンコールの間隔から逆算した値であって、算定の基準が異なる。 #### オンコール慣行そのものへの反対論 ここまでの設計論は、オンコールという慣行の存在を前提として量と質を最適化するアプローチである。 これに対し、Niall Richard Murphy(Microsoft)は『SREの探求』第 30 章で、オンコールという慣行そのものの正当性を問い直す。 Murphy はオンコールを担当させる根拠を、既知の既知、既知の未知、未知の未知、プロダクションの知恵の 4 カテゴリに分類する。 症状、トリガー、影響、修正方法がすべて分かっている既知のバグと、変更管理やクォータ超過など統計的に予見可能な外部要因は、原則としてソフトウェアで完全に解決可能であり、それを妨げているのは人件費の方が安上がりだというコストの都合にすぎないとする。 唯一正当な理由はプロダクションの知恵、すなわち現実の状況でシステムがどう動作するかを意図的に学ぶための配置だけだと Murphy は主張する (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 30 オンコール反対論]])。 この立場から Murphy は強いオンコール反対と弱いオンコール反対という 2 つの理論的立場を提示する。 強い立場はソフトウェアが決定論的であることを根拠に、障害原因を系統的に排除し基盤レイヤーをより高レベルで信頼性の高いものへ置き換えるべきだとする。 弱い立場は未知の未知への完全な自動対応は不可能だと認めつつ、無人列車のアナロジーで、パーティション化による安全な停止によってオンコールを人間の介入なしで機能させようとする。 理論的立場は異なるが、両者は標準化された再利用可能なツールキットソフトウェアという同じ処方箋に収束し、業界規模の集団的な協働によってのみオンコールという苦痛を伴う経験を取り除けると Murphy は結論づける (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 30 オンコール反対論]])。 > [!contradiction] Niall Murphy は SRE Book 第 11 章の編者の一人として、ストレスホルモンが熟慮的認知を阻害するという知見を、心理的安全性の確保によるオンコール品質の改善という運用最適化の論拠に用いている (Source: [[@2016__OReilly__SRE Book - Chapter 11 Being On-Call]])。 > 同じ Murphy が 5 年後、『SREの探求』第 30 章の著者として、ストレス下の人間が複雑な非定型タスクで 25% から 30%、些細なタスクでも 0.5% から 10% のエラー率を示すというヒューマンエラー研究の知見を、オンコールという慣行そのものを終わらせる根拠として用いる (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 30 オンコール反対論]])。 > ストレスが熟慮的認知を阻害するという同一の経験的事実が、一方では運用改善の根拠に、他方では慣行廃止の根拠になっている。なおヒューマンエラー研究の数値は同章での孫引きであり、引用元の調査条件は章内に記載がない (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 30 オンコール反対論]])。 #### オプトインとオプトアウト 根本解決への移行が実現するまでの間として、Murphy はトレーニング、優先順位付け、便宜、勤務時のパフォーマンス改善という 4 領域の現実的な改善策も提示する (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 30 オンコール反対論]])。 便宜の中には、補償、柔軟なスケジュール、体調回復のための休息制度に加えて、反発を招かない免除、すなわちオンコールのオプトアウトの方針が含まれる (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 30 オンコール反対論]])。 『SREの探求』第 29 章の著者 James Meickle(Quantopian)は、逆向きの制度提案としてオプトインを論じる。 同章は、米国の雇用機会均等委員会が職務の不可欠性の判定に用いる 3 要因、すなわち必要スキルの程度、そのタスクのために職務が作られたか、他の従業員が代替できるかをオンコールに当てはめる。 そこでは、ページャーローテーションの構築が必要でバス因子が高いため代替可能性は低く、オンコール自体は多くのチームにとって不可欠だが、すべての SRE がページャーを携帯することまでは不可欠ではないと結論づけられる。 その帰結として Meickle は、追加報酬を伴うオプトイン方式の義務としてオンコールを制度に組み込めるかを検討すべきだと提案する (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 29 燃え尽きを超えて]])。 Murphy のオプトアウトは全員参加を既定としつつ不参加への報復を禁じる設計であり、Meickle のオプトインは不参加を既定としつつ希望者が追加対価を得て参加する設計であって、初期状態が逆向きになっている。 ### 第 25 章　疲労とインセンティブと燃え尽き ![[Attachments/アラート管理の教科書/chapter-25.png]] #### アラート疲労の実態と医療領域のアナロジー Kishore Jalleda(当時 Zynga の SRE 責任者)は SREcon17 Europe の発表冒頭で、集中治療室のモニタリング過剰を引用する。 ECG モニターアラームの 72% から 99% が偽または臨床的に無意味であり、2010 年にはマサチューセッツ州の病院でアラート疲労による患者死亡事故が起きたという。 この医療領域の数値は発表内での孫引きであり、引用元の調査条件はスライド上に記載がない (Source: [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]])。 Jalleda はこれをテクノロジー業界のアラート疲労と構造的に同じ問題だとしたうえで、Zynga では 2009 年から 2013 年にかけて NOC 要員を約 1 名から 13 名に増やしたが、月間アラート件数は約 1 万件から 10 万件超へ増加したと報告する。 人の投入がアラート増加のペースに追随できないという実例から、Jalleda はヘッドカウントの追加がアラートノイズへのスケーラブルな解決策にならないと結論づける (Source: [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]])。 #### アラートバジェットによるインセンティブ設計 Jalleda はツールの改善でなく組織的なインセンティブの再設計で問題に取り組んだ。 Clean Room イニシアティブと呼ばれる施策は、開発チームごとにアラートバジェットを設定し、予算を超過したチームへの SRE サポートを一時停止し、予算を遵守するチームにはワールドクラスの SRE サポートを提供するという仕組みである。 SRE サポートは権利ではなく獲得すべき特権として位置づけ直された (Source: [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]])。 この取り組みにより、偽アラームは 90% 削減され、SRE の応答時間は 5 分まで短縮したと報告される。 目指した状態は、シフトあたり根本原因付きのアラートが 2 件未満、開発者のオンコール化、SRE はインフラとツール開発に専念、テレビモニタゼロというものだった (Source: [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]])。 #### 急激な削減が生む新たな不安 Tony Lykke(当時 Hudson River Trading)は着任後わずか 4 か月で、6 年間かけて積み上がった高緊急度ページを週平均 201 件(累計 71,317 件)から週平均 56 件(累計 1,015 件)まで削減した実務報告を SREcon19 Americas で行った (Source: [[@2019__SREcon19 Americas__Fixing On-Call When Nobody Thinks It's (Too) Broken]])。 削減の手法自体は、既存の Nagios と PagerDuty の間に Python 製のフィルタ層を挿入するだけという最小限のアーキテクチャ変更であり、力点は audience の理解から始まりコミュニケーションで終わる 9 段階の合意形成の手順に置かれていた (Source: [[@2019__SREcon19 Americas__Fixing On-Call When Nobody Thinks It's (Too) Broken]])。 ![[_attachments/srecon19americas-lykke-oncall/page-002.png]] **図25-1**:月次の高緊急度ページ数の推移で、図中に本文が引いた 71,317 件と週平均 201 件、削減後の 1,015 件と週平均 56 件が注記されている。右端で棒が急落しており、本文が述べた「一晩でほぼ半減させた」削減の急峻さは、この落差の形に対応する。同じ急峻さが、次段で述べる沈黙への不安を招いた。 (Source: [[@2019__SREcon19 Americas__Fixing On-Call When Nobody Thinks It's (Too) Broken]], p.2) しかし、ページ数を一晩でほぼ半減させたこと自体が、チームの安心ではなく新たな不安を招いたと Lykke は振り返る。 理由は「ページャーからの沈黙は、歴史的に監視スタック自体が壊れていることを意味していた」という連想であり、周知やドキュメント、コミットメッセージを尽くしてもコミュニケーションが足りない状態だったという (Source: [[@2019__SREcon19 Americas__Fixing On-Call When Nobody Thinks It's (Too) Broken]])。 この不安を緩和するため、Slack のアラートチャンネルはダウングレードやサイレンス処理の理由を自動投稿するログとして再定義され、ページが来ないことと何も起きていないことを区別できるようにされた (Source: [[@2019__SREcon19 Americas__Fixing On-Call When Nobody Thinks It's (Too) Broken]])。 #### 慢性ストレスと急性ストレスの区別 Beth Adele Long(Continuous Re-integration)は SREcon26 Americas で、オンコール業務には性質の異なる 2 種類のストレスが存在すると指摘する。 ページャーを持ち続けること自体から生じる持続的な負荷を慢性ストレス、インシデント対応中の超警戒状態を急性ストレスと呼ぶ。 Long は意識の 2 モードというフレームを用い、目標指向で抽象思考的、言語的、合理的な Ordinary Mind が、自律神経系の本来の自己修正機能を抑制してしまうと説明する (Source: [[@2026__SREcon26Americas__The Critical Resource Is You - Practical Destressing for On-Call Engineers]])。 この抑制を迂回するため、身体知性に根ざした Body Scan、Breath、Movement、Boredom という 4 つのツールが提示される。 Long はまた、ストレスは単なる負荷であってそれ自体は良くも悪くもなく、適切な回復が伴う健全なストレスはキャパシティを拡大すると再フレーミングする。 これらの主張の生理学的根拠はスライド上に示されていない (Source: [[@2026__SREcon26Americas__The Critical Resource Is You - Practical Destressing for On-Call Engineers]])。 #### インシデント後の人的回復とピアサポートの欠如 Jaime Woo(元 Shopify)は SREcon18 Americas で、システムが障害から回復してもエンジニア自身が回復しているとは限らないと問う。 Shopify の本番エンジニア 40 名を対象としたストロー投票では、42.5% がインシデント後にストレスまたは非常に強いストレスを感じると回答した。 Woo 自身がこの調査を業界全体の代表値ではないと強調しており、これをそのまま業界の実態として引用しないよう口頭で釘を刺している (Source: [[@2018__SREcon18Americas__Your System Has Recovered from an Incident, but Have Your Developers]])。 同じ調査では、インシデント後に同僚が様子を尋ねることはほぼなく、45% がまったくないと回答している (Source: [[@2018__SREcon18Americas__Your System Has Recovered from an Incident, but Have Your Developers]])。 Woo は医師、スタンドアップコメディアン、オリンピアンという 3 領域からの学びを引く。 医療ミス後の医師は二次被害者となり孤立感を覚えるが、ピアサポートが有効であり、SRE における英雄文化からの脱却にも同じ枠組みが使えるとする (Source: [[@2018__SREcon18Americas__Your System Has Recovered from an Incident, but Have Your Developers]])。 オリンピック選手を対象とした研究を引き、セルフコンパッション介入が反芻思考、自己批判、ミスへの懸念を有意に低下させると紹介する。 この孫引きの数値についても、スライド上に原論文の調査条件の詳細は示されていない (Source: [[@2018__SREcon18Americas__Your System Has Recovered from an Incident, but Have Your Developers]])。 セルフコンパッションは先天的なものではなく意図的に訓練できるとし、人間向けのインシデントレスポンスの設計が必要だと締めくくる (Source: [[@2018__SREcon18Americas__Your System Has Recovered from an Incident, but Have Your Developers]])。 #### デプロイ負荷とバーンアウトの組織的危険因子 『LeanとDevOpsの科学』第 9 章は、デプロイに伴う恐怖感や不安をデプロイ関連の負荷と定義し、2015 年から 2017 年の調査でこれを測定した結果、負荷の大きいチームほどソフトウェアデリバリのパフォーマンス、組織のパフォーマンス、組織文化のいずれも低いことを統計的に示す。 負荷の典型的な原因は、デプロイの容易性を欠いた設計、手作業による本番変更、チーム間の複雑な引き継ぎの 3 つに整理される (Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 9 作業を持続可能にするデプロイ負荷とバーンアウトの軽減]])。 同章はさらに、Christina Maslach の研究に基づき、過重労働、自律性の欠如、不十分な報奨、人間関係の断絶、公平性の欠如、価値観のズレという 6 つの組織的危険因子がバーンアウトを予測すると紹介する。 ストレスの多い仕事の身体的悪影響は受動喫煙や肥満の場合と同等であり、病欠、長期就業不能、高離職率による損害は米国全体で年間 3,000 億ドルにのぼるという調査研究が引かれるが、この数値も本章内での孫引きであり調査条件そのものは記載がない (Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 9 作業を持続可能にするデプロイ負荷とバーンアウトの軽減]])。 技術的プラクティスとリーン思考のプラクティスの実践は、デプロイ関連の負荷とバーンアウトの症状の双方を緩和すると同章は結論づける。 組織の価値観、すなわち公式に発表されたものではなく構成員が日々実感し体現するよう求められている本音の価値観と、構成員個人の価値観の一致は、バーンアウトを緩和し、あるいは解消しうるとされる (Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 9 作業を持続可能にするデプロイ負荷とバーンアウトの軽減]])。 #### 職務の一モードとしての回復とセルフケア 『SREをはじめよう』第 8 章は、SRE の一日を平均的な一日として描くのではなく、8 つの相互排他的でないモードとして提示する。 その 1 つである回復とセルフケアのモードは、他のすべてのモードに付随するモードとして位置づけられる (Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 8 SREのある一日]])。 著者は、週 60 時間から 75 時間の労働を称賛すべきこととしてではなく、修正すべきシステムの失敗として捉えるべきだと主張する (Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 8 SREのある一日]])。 Jalleda のインセンティブ設計が偽アラーム 90% 削減という定量成果を前面化し、Lykke の急激な削減が沈黙への不安を生んだと報告するのに対し、この章は成果の定量化そのものよりも、担当者が回復とセルフケアの時間をためらわずに取れる文化を管理職の責任として組み込むことに焦点を置く。 #### 負荷の上下限と補償 SRE Book 第 2 版第 10 章は、ページング負荷が過大ならアラート疲れと浅い調査を招き、過少なら経験不足を招くとして、負荷に上限と下限の両方を置く (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 10 Incident Management and On-Call]])。 第 1 版が静穏すぎるシステムへのオンコールを過信と習熟不足の原因とした議論を引き継いでいる (Source: [[@2016__OReilly__SRE Book - Chapter 11 Being On-Call]])。 同書第 13 章は、深夜に起こされることや文脈の切り替えを招くことのように、節約時間が小さくても煩わしさの大きい短いタスクは自動化に値するとする。 個別チケットの処理より、問題のクラス全体を直した人を評価と昇進の基準で報いることも求める (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 13 Automation and Tooling]])。 『入門 監視』第 3 章は、オンコールへの補償として、シフト直後の有給休暇 1 日とシフトごとの手当を挙げる。 睡眠や家族との時間を損なうからである。 オンコール担当の役割には、場当たり的対応をしていない時間を回復力と安定性の改善に充てることを含めるべきだとする (Source: [[@2019__OReillyJapan__入門 監視 - Chapter 3 アラート、オンコール、インシデント管理]])。 ### 第 26 章　トリアージ技能の伝達 ![[Attachments/アラート管理の教科書/chapter-26.png]] #### 試行錯誤型オンボーディングの否定 SRE Book 第 28 章は、火中の栗を拾わせる式の試行錯誤型アプローチを明確に否定し、理論的理解と実践経験を組み合わせた構造化された学習パスの設計を主張する。 具体的には、知識を段階的に積み上げる累積的学習パス、モニタリング追加や自動化改善など本番システムへの理解を深める意味あるプロジェクト、本番システムの構成図を自力で描きデバッグツールを使いこなす能力の涵養、過去のインシデントから教育的なポストモーテムを厳選する読書会、経験豊富なゲームマスターが進行する Wheel of Misfortune 演習という 5 つの訓練手法が柱となる。 これらに加え、業務時間内から始めるシャドーオンコール、制御下での本番システム操作、ドキュメンテーション整備への参加といった補助的な実践を通じ、オンコール着任前に自信と能力の両面を担保する。 人間のスケールをマシンのスケールより速くせよという原則が全体を貫く (Source: [[@2016__OReilly__SRE Book - Chapter 28 Accelerating SRE On-Call]])。 Google SRE ワークブックの第 8 章は、新しいチームが短期間でオンコールに入るための実務として、スタータープロジェクト、チェックリスト、メンタリング、深掘り会、Wheel of Misfortune、シャドーオンコール、明確なハンドオフが有効だったと報告する (Source: [[@2018__Google SRE Workbook__On-Call]])。 SRE Book 第 2 版第 10 章は、訓練の目標を手順の習得から判断の較正へ移す。 トリアージの成否は修正を見つけることではなく、正確な分類と適切なエスカレーションの速さで決まるとし、判断力を熟練者の思考の声出し、シャドーイング、シミュレーションの振り返りで較正する。 結果から遡って行動を裁く結果バイアスを避けることも求める (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 10 Incident Management and On-Call]])。 #### 認知的徒弟制による暗黙知の伝達 Paige Cruz(Chronosphere、元 SRE)は SREcon23 Americas で、ドキュメントを読み、バディとペアを組み、プライマリをシャドウし、リバースシャドウするという従来のオンコールオンボーディング経路の限界を指摘する。 この方式はオンボーディングバディの指導力に依存し、アラート調査の認知スキルが体系的に伝達されないと Cruz は述べる (Source: [[@2023__SREcon23 Americas__Cognitive Apprenticeship in Practice with Alert Triage Hour of Power]])。 オンコール知識はシステム、テレメトリ、ビジネスコンテキストの 3 領域に分かれるとしたうえで、Cruz は教育心理学の認知的徒弟制の 6 段階、すなわちモデリング、コーチング、スキャフォールディング、アーティキュレーション、リフレクション、エクスプロレーションに、自らが設計した Alert Triage Hour of Power が対応することを見出す (Source: [[@2023__SREcon23 Americas__Cognitive Apprenticeship in Practice with Alert Triage Hour of Power]], [[認知的徒弟制]])。 Alert Triage Hour of Power は週 1 時間、Facilitator、Driver、Scribe、Support という 4 ロール制の構造化ミーティングで、実際のアラートを調査し確認から勧告までの調査フローを踏む (Source: [[@2023__SREcon23 Americas__Cognitive Apprenticeship in Practice with Alert Triage Hour of Power]])。 ![[_attachments/srecon23-americas-cruz-cognitive-apprenticeship/page-053.png]] **図26-1**:認知的徒弟制の 6 段階を左から右へ並べたもの。本文が述べた「モデリング、コーチング、スキャフォールディング、アーティキュレーション、リフレクション、エクスプロレーション」という順序と、見習いから熟練者への移行という方向づけがこの並びに対応する。 (Source: [[@2023__SREcon23 Americas__Cognitive Apprenticeship in Practice with Alert Triage Hour of Power]], p.53) 勧告は KEEP、TUNE、DELETE の 3 択であり、アラートは貴重品ではないという標語で削除への心理的抵抗を克服する。 この実践は 3 年間継続し、常連参加者は 5 名から 15 名から 20 名に成長した。 一方でスパムアラートの削減率は 0% であり、Cruz はこれを学習そのものが正当な組織的目標だと位置づける (Source: [[@2023__SREcon23 Americas__Cognitive Apprenticeship in Practice with Alert Triage Hour of Power]])。 この削減率 0% という評価は、第 25 章で見た Jalleda のインセンティブ設計が偽アラーム 90% 削減という定量成果を前面化したのと対照的であり、削減件数と学習効果という異なる軸で成功が語られていることを示す。 #### 訓練の体系化を専売特許の防衛と見る批判 > [!contradiction] SRE Book 第 28 章は、体系化されたオンボーディング投資こそが必要であり、試行錯誤型アプローチを避けるべきだと明言する (Source: [[@2016__OReilly__SRE Book - Chapter 28 Accelerating SRE On-Call]])。 > これに対し Dave O'Connor(Twilio の VP Engineering、元 Google SRE)は SREcon22 EMEA で、3 か月に及ぶオンボーディングや黒帯といった認定制度、災害復旧演習を批判し、インシデント対応の複雑化は自己実現的予言であり、SRE による意図的なゲートキープが生み出すものだと論じる。 > O'Connor は、オンコールを SRE の特権として複雑化し秘密化することが「良い仕事の報酬はさらなる仕事」という罠を生み、SRE を魔法の妖精として固定化すると述べる (Source: [[@2022__SREcon22EMEA__Oncall - An Equal-Opportunity Waste of Time]])。 O'Connor は、まずリードグループがオンコールの余裕を適正化し、次いで「全エンジニアがオンコールを均等に担うと仮定した場合、何を期待するか」という思考実験によって SRE の真の専門性を炙り出す補助輪を外す演習を提案する。 これは SRE の価値をオンコール運用の増強ではなく工学的成果の乗数効果に置き直そうとする主張であり、訓練の体系化それ自体が SRE の存在証明として自己目的化することへの警告である (Source: [[@2022__SREcon22EMEA__Oncall - An Equal-Opportunity Waste of Time]])。 認知的徒弟制の実践が示す暗黙知の言語化と、O'Connor が批判する意図的な複雑化は、いずれも訓練の中身を体系立てて明示化する点で外形は似るが、前者は学習の伝達を目的とし、後者はその明示化が組織内での権力保持の手段に転化しうる危険を指摘しており、両立場が扱う射程は異なる。 --- ## 第 VIII 部　LLM とエージェント(2024 年から 2026 年) 第 VII 部までで確立された設計原則、すなわち症状ベースアラーティングによる接地、SLO によるルール品質の工学、選別と削減によるノイズ処理、集約によるストーム対応、そして人間中心のオンコール体制は、いずれも 2024 年以降 LLM とエージェントという新しい実装手段に出会う。 本部が示すのは、LLM が第 III 部から第 VII 部の原則を置き換えたという物語ではない。 むしろ逆に、本番デプロイを報告する文献のほぼすべてが、コストと推論遅延を理由にアラート処理の一部を非 LLM の手法へ意図的に残し続けている。 第 27 章から第 30 章で、どこに LLM を当て、どこに当てないという設計判断そのものと、その判断が生んだ 2 つの対立する路線、そして人間の介在点をどう設計するかを扱う。 ### 第 27 章　LLM を使う範囲の切り分け ![[Attachments/アラート管理の教科書/chapter-27.png]] | システム | 年 | 媒体 | 組織 | LLM の適用範囲 | 非 LLM が担う部分 | 評価データの出自 | 本番デプロイ | |---|---|---|---|---|---|---|---| | 二段階アラート集約 | 2024 | Electronics | State Grid Jiangsu Electric Power | クラスタ要約とサービス依存グラフへのノード写像 | 時空間 DBSCAN による粗いクラスタリング | 本番テレメトリ(電力業界 3 データセット、2 万件から 4.6 万件) | 記載なし(本番データによる評価のみ) | | AlertGuardian | 2025 | ASE | Company-X | 行動指針つき要約生成、ルール精錬提案 | デノイズを担う軽量グラフモデル | 本番テレメトリ(4 システム、9 日分、最大 388 万アラート) | あり(デノイズは 1 年超、要約と精錬は 3 か月超のパイロット) | | LogPilot | 2025 | ASE | ByteDance、The Chinese University of Hong Kong | アラート定義の意図解釈によるログ絞り込み、クラスタ代表の診断と要約 | Drain によるログ構造化、階層的凝集クラスタリング | 本番テレメトリ(4 サービス、202 アラート) | あり(12 サービス、3,500 件超のアラート) | | PAGER | 2026 | AAAI | Adobe | Shapley 値に基づく寄与の自然言語説明、対話 UI の質問理解と RAG | 障害予測を担う 2 つの random forest 分類器 | 本番テレメトリとユーザースタディ(社員 10 名) | 統合済みと主張(運用期間の記載なし) | | AlertRCA | 2024 | CCGRID | Tsinghua University ほか | なし(LLM を一切用いない) | BERT ベースのベクトル化、因果スコア推定、根本原因の順位づけ | 本番テレメトリ(5,000 サービス、15 か月) | 記載なし(オフライン評価のみ) | | FaultProfIT | 2024 | ICSE-SEIP | Huawei Cloud ほか | 比較対象の 1 つとして登場するのみ | 階層誘導型対照学習による障害パターン分類 | 本番テレメトリ(22,560 件のインシデント) | あり(6 か月、社内プラットフォームへ統合) | | AIM | 2026 | FSE Companion | York University、IBM Research | アラート要約、根本原因推論、緩和計画生成、playbook 生成の全段 | パーセンタイル閾値による KPI 重大度分類 | 公開ベンチマーク | なし(シミュレーション検証のみ) | | Detectr | 2026 | SRE Book 第 2 版 | Google | 利用者フィードバックのフィルタリングとクラスタリング | 記載なし | 事例報告のみ(測定方法の記載なし) | あり(2026 年初頭に中核基盤へ移行) | | AI Operator | 2026 | SRE Book 第 2 版 | Google | 本番アラートの一次調査の要約、根拠つきの緩和案 | 記載なし | 事例報告のみ(ゴールデンデータと LLM-as-a-Judge による評価。精度の記載なし) | あり(緩和の実行は人間の承認つき) | 本番デプロイを報告する文献に共通するのは、すべてを LLM に任せる設計が 1 つも存在しないという事実である。 #### オンラインのデノイズを LLM に任せない理由 AlertGuardian は、日次で膨大に発生するアラートのオンラインのデノイズを LLM ではなく軽量グラフモデルに担わせる。 理由は 2 つある。 1 つはコスト効率で、日次の膨大なアラート全件に LLM を適用すればトークン費用が非現実的になる。 もう 1 つは推論速度で、自己回帰生成の遅延がリアルタイム診断の要件を満たさない (Source: [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]])。 この軽量グラフモデルは 4 データセットで 93.82% から 95.50% のアラート削減率を達成し、オンライン推論は 1 分窓あたり平均 200 ミリ秒未満で完了する (Source: [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]])。 2024 年の二段階アラート集約も同じ判断を採っており、まず計算の安い時間しきい値で粗くグループ化してから DBSCAN にかけ、LLM はクラスタ要約とサービス依存グラフへのノード写像という後段に限定する (Source: [[@2024__Electronics__Leveraging Large Language Models for Efficient Alert Aggregation in AIOPs]])。 > [!warning] この二段階アラート集約の論文は、LLM の適用を新規性として主張しながら、使用したモデル名と版を本文中に一切明示していない。トークン使用量や API コストの記載もない (Source: [[@2024__Electronics__Leveraging Large Language Models for Efficient Alert Aggregation in AIOPs]])。 #### クラスタリングで代表だけを LLM に渡す設計 LogPilot は、アラート 1 件あたり平均 198.65 件、最大 3,000 件超に及ぶ関連リクエストを、階層的凝集クラスタリングで少数のクラスタにまとめ、各クラスタの代表リクエスト 1 件だけを LLM の診断に回す。 この設計により、1 アラートあたりの LLM 呼び出し数は最大 13 回、平均 2.56 回に抑えられ、全リクエストを個別診断する場合と比べて 98.71% の呼び出し削減を達成する。 結果としてエンドツーエンドのレイテンシは平均 58.6 秒、1 アラートあたりのコストは 0.074 ドルに収まり、この数値開示に基づいて本番 12 サービスへの展開が成立している (Source: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]])。 #### 予測を古典的分類器に任せ LLM を説明生成に限る設計 PAGER は、ワークフロー段階間のジョブ障害予測そのものを 2 つの random forest 分類器に担わせ、LLM は Shapley 値による特徴量寄与を自然言語の原因記述へ変換する説明生成と、対話インターフェースのクエリ理解、自然言語からの SQL 生成、RAG、応答合成に限定する。 random forest は 2 つの重複予測でそれぞれ F1 67.8(標準偏差 1.1)と F1 57.5(標準偏差 4.4)を達成し、ランダム予測器とロジスティック回帰を有意に上回った。 予測そのものではなく、LLM が生成した自然言語の説明と会話インターフェースが、ユーザースタディでのタスク容易性(4.70 対ベースライン 2.10)と結果への自信(4.10 対 2.40)の有意な向上に寄与している (Source: [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]])。 #### 分類の中核を非生成モデルが担う例 FaultProfIT は、階層誘導型対照学習で訓練した MacBERT と Graphormer の組み合わせで障害パターン分類の中核を担い、生成 LLM である ChatGLM は比較対象のベースラインとしてのみ登場する。 ChatGLM の F1 は 62.5% にとどまり、階層構造を活用しない他のベースライン(Dense Passage Retriever 54.1%、MacBERT 単体 60.1%)よりは高いものの、階層型テキスト分類の既存最良手法の 75.1%、そして提案手法の 78.3% を下回る (Source: [[@2024__ICSE-SEIP__FaultProfIT - Hierarchical Fault Profiling of Incident Tickets in Large-scale Cloud Systems]])。 AlertRCA はさらに一歩進み、アラートに基づく根本原因分析のパイプライン全体から LLM を排除し、BERT による意味ベクトル化と、非対称アテンションを持つグラフニューラルネットワークだけで、手作業ルールを持つ既存手法を上回る精度を達成した。 サービスベースのデータセットで top-1 精度 77.4%、業務ドメインのデータセットで 85.3% であり、いずれも手作業ルールを要する既存手法(それぞれ 74.3%、81.2%)を上回る (Source: [[@2024__CCGRID__AlertRCA - Causality Enhanced Graph Representation Learning for Alert-Based Root Cause Analysis]])。 AIM は逆に、パーセンタイル閾値による KPI の重大度分類というルールベースの前処理を先に通し、中程度以上の重大度と判定された KPI のみを LLM のプロンプトに含める。 このルールベースのアラート表現を除去すると全モデルと全データセットで性能が一貫して低下する (Source: [[@2026__FSE Companion__Leveraging LLMs for Alert Summarization and Mitigation Plan Generation]])。 これらの独立した企業と著者陣による共通の設計判断は、アラート処理のどの段に LLM を当てるかという問いが、精度だけでなくコストと推論遅延の制約からも決まることを示している。 #### 実務書が示す導入の順序 SRE Book 第 2 版は、LLM をどの段に当てるかを、どの順に広げるかという形で書く。 第 10 章は AI を低リスクの検知とトリアージから導入し、従来の自動化で足りる処理を AI に置き換える必要はないとする (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 10 Incident Management and On-Call]])。 第 21 章は、緩和は既定の選択肢から速度を優先して選ぶ過程であり、根本原因分析は仮説を生成する発見の過程だとして、この区別を AI の適用方法を分ける根拠に置く (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]])。 第 9 章は、現段階の AI 支援は人間が介在する調査段階に限られ、人の介在なしに自己修復させるにはまだ頑健な仕組みが要ると認める (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 9 Observability and Monitoring]])。 Majors(Honeycomb)は別の制約を挙げる。 AI は浅いデータ、分断されたシグナル、存在論的な混乱を直せず、むしろ機能不全を増幅するという (Source: [[@2026__Honeycomb Blog__Honeycomb 10 Year Manifesto Part 1]])。 学術系の文献がコストと推論遅延を LLM の適用範囲の制約に挙げたのに対し、こちらは入力データの質を制約に挙げている。 ### 第 28 章　自律診断とバーチャルオンコール ![[Attachments/アラート管理の教科書/chapter-28.png]] #### アラート定義の意図解釈によるログ絞り込み LogPilot は、既存の自動化手法が抱える 2 つの欠陥、すなわちアラートを考慮しないログの絞り込みと、推論に向けた複雑なデータの組織化不全を、アラートとログを対応づけるエージェントで解く。 このエージェントは PromQL で書かれたアラート定義の意味的意図を解釈し、アラートごとに軽量で実行可能なログフィルタリングツールを生成する。 ![[_attachments/arxiv-2509.25874/fig2-framework.png]] **図28-1**:3 つのフェーズからなる全体構成で、左から意図を踏まえたログの絞り込み、リクエスト中心のログ処理、クラスタリングに基づく LLM 診断が並ぶ。本文が述べた「クラスタリングで代表だけを LLM に渡す」設計は、第 3 フェーズで複数のリクエストが少数のクラスタにまとまり、各クラスタから 1 本ずつ分析レポートが出ている箇所に対応する。 (Source: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]], 図 2) 社内分析では 96.4% 超のアラートがアカウント ID やゲートウェイ、エラーコード、ポッド名などのラベルフィールドを含み、フィールド名が完全一致しなくてもその意味がログに反映されるため、PromQL の意味的シグナルでログ抽出を導ける。 ツール品質は人手採点で完全な設計時に平均 0.984 に達する一方、ログ例を与えない場合は 0.352 まで落ち込み、サービス固有のログスキーマの知識が絞り込み精度を左右することを示す (Source: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]])。 #### RAG による社内文書の参照 LogPilot の要約エージェントは、各クラスタの独立した根本原因分析の結果を集約したうえで、歴史的な標準処理手順の文書を RAG で検索して提案を生成する。 この診断レポートは 2025 年 6 月以降 12 の本番サービスに展開され、2025 年 7 月末までに 3,500 件超のアラートを分析し、生成レポートの全体受容率は 84.21%(完全正解 60.53%、部分正解 23.68%)に達した (Source: [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]])。 #### 因子抽出と因果マイニングの分解 VOCE は、複数のアラートから同一インシデントの根本原因に最も近い起点アラートを特定するタスクを、単一の LLM 呼び出しではなく階層分解で解く。 まずシステム階層の低さ、影響範囲の広さ、深刻度の高さという 3 因子を CoT プロンプトで抽出させる。 著者らは 1 か月分の本番データ(10,680 アラート、827 インシデント)を人手でラベル付けし、起点アラートがこれら 3 因子で最上位となる割合がそれぞれ 94.56%、95.16%、93.35% に達する一方、時間順で最初に発火したかを示す因子は 45.34% にとどまることを定量化した。 次に因果マイニングで、同一ソース内から隣接ソース間へと推論範囲を段階的に広げる階層分解を適用し、各サブタスクを 5 回反復して多数決で安定化させたうえで伝播グラフを構築し、固有ベクトル中心性で起点アラートを提示する。 GPT-4o を用いた構成は accuracy 88.90% で、同じ CoT プロンプトを単一タスクとして適用する構成の 84.19%、素朴な直接質問の 81.30% を上回り、LLaMA-2 13B を用いた構成でも 81.26% と同様の傾向を示した (Source: [[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model]])。 時間順の因子が半数にも満たないという発見は、時系列順を前提とする従来の根本原因分析手法への反例であり、第 V 部で確認した「時間的順序は根本原因を反映しない」という観察を別の角度から裏づける (Source: [[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model]])。 #### マルチエージェント協調と木探索 OncallX は、曖昧なオンコールクエリの理解強化、木探索に基づく専門エージェントの協調、知識グラフによるチケットトリアージという 3 モジュールでエンドツーエンドのオンコール自動化を構成する。 インシデント対応を担う中央プランナーはドメイン専門エージェント群を木探索で協調させ、計画、実行、統合の 3 ステップと、行き詰まった際に以前の意思決定点へ戻るリフレクション機構で構成される。 gpt-3.5-turbo-16k をバックボーンとする構成は Pass Rate 78.26% を達成し、素朴な直接応答の 72.46%、ReAct を用いる構成の 71.01% を上回った。 アブレーションでは、ユーザー意図の強化モジュールを除去すると Pass Rate が 65.22% へ低下しトークン消費が倍増し、マルチエージェントと木探索プランナーを除去すると 62.32% まで低下する。 本番環境に 2 か月間展開され、平均インシデント対応時間は人手の 0.58 人日から 21 秒へ短縮された (Source: [[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]])。 #### 階層タクソノミによる障害パターンのプロファイリング FaultProfIT は、インシデントの事後分析であるポストモーテムの段階で、障害を固定タクソノミの葉ノードに分類する障害パターンのプロファイリングを自動化する。 対象とするタクソノミは 5 階層、7 つの上位カテゴリ、334 の葉ノードから成り、Graphormer で階層構造をグラフとしてエンコードし、対照学習で分類に重要なトークンのみを残した正サンプルを自動生成する。 提案手法は F1 78.3% を達成し、階層を無視するフラット分類や、同じく階層型テキスト分類の既存手法を上回った。 信頼性分析プラットフォームに 6 か月以上統合され、手動のポストモーテムでは深刻度の高いインシデントしか対象にならず捕捉できなかったメモリ過負荷の増加傾向を、自動プロファイリングが第 10 週の時点で可視化した (Source: [[@2024__ICSE-SEIP__FaultProfIT - Hierarchical Fault Profiling of Incident Tickets in Large-scale Cloud Systems]])。 #### アラートのみを入力とするグラフ学習による根本原因の順位づけ AlertRCA は、トレースや手作業ルールを要さず、アラートイベントのみを入力に根本原因を順位づけるエンドツーエンドの深層学習手法である。 BERT で各アラート属性を意味ベクトル化し、サービス依存グラフから自動生成したアラート依存グラフにアテンションで因果スコアを与え、分散集約構造と自己残差構造を持つネットワークで根本原因確率を出力する。 5,000 サービス、1 億 8,500 万アクティブユーザーを抱える EC 企業の 15 か月分の本番データで評価し、サービスベースのデータセットで top-1 精度 77.4%、top-3 精度 96.8% を達成した。 推論は CPU のみで平均 2 秒毎障害であり、汎用のグラフニューラルネットワークや PageRank に基づく手法をいずれも上回った (Source: [[@2024__CCGRID__AlertRCA - Causality Enhanced Graph Representation Learning for Alert-Based Root Cause Analysis]])。 本章で扱った 5 つの設計は、いずれも LLM を診断の一部工程に限定し、残りを軽量モデルや古典的アルゴリズムに委ねる構成を採っている点で、第 27 章の設計判断と一貫している。 #### Google の AI Operator 学術論文の外では、SRE Book 第 2 版第 21 章が Google SRE の AI Operator を紹介する。 本番アラートの一次対応者として動くエージェントであり、自律性の段階(第 30 章)ごとに役割が変わる。 L1 では調査結果の要約を人間に渡し、L2 ではクラスタからのトラフィック退避や更新のロールバックといった根拠つきの緩和案を人間の承認のもとで実行する。 L3 はタスク再起動のような十分に理解された低リスク操作に限り、L4 は長期目標とされる (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]])。 評価は、ゴールデンデータとして用意した理想的な人間の対応と自動行動を比べ、LLM-as-a-Judge が批評と改善案を返す形で行い、調査ロジックと意思決定を磨く。 エージェントには RAG で系のトポロジ、依存マップ、ライフサイクルイベント、過去のインシデントを与え、道具は MCP のような標準化インターフェース経由で使わせる (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]])。 精度や採用率の実測値は示されておらず、本章の学術系の 5 手法と数値で比べることはできない。 ### 第 29 章　チケットトリアージの 2 つの路線 ![[Attachments/アラート管理の教科書/chapter-29.png]] チケットトリアージには、ファインチューニングを避ける路線と、知識蒸留と強化学習で小型モデルを調整する路線という 2 つの対立するアプローチが並立している。 同一の研究グループが、この 2 つの路線を独立に、かつ決定版を定めないまま追求している点が特徴的である。 #### ファインチューニング不要の路線 OncallX のチケットトリアージモジュールは、生のディスカッションを LLM で要約してノイズを除去したうえで、過去チケットから LLM が抽出したエンティティと関係を知識グラフに蓄積し、オンライン時にはこの知識グラフでカテゴリ候補を頻度順に絞り込むファインチューニング不要の設計を採る。 バックボーンは gpt-3.5-turbo-16k および doubao-1.5-pro-32k で、145 件のテストセット(学習用 8,517 チケット)において ACC@1 0.652、ACC@3 0.774 を達成し、既存の最良手法(ACC@1 0.359)を 28.0 ポイント上回った。 アブレーションでは知識グラフの除去が最大の性能低下(ACC@1 で 20.9 ポイント低下)をもたらし、知識グラフによるカテゴリ空間の制約が精度の中核であることを示す (Source: [[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]])。 #### 知識蒸留と強化学習による小型モデル調整の路線 CoTriage は逆に、教師 LLM(GPT-3.5-Turbo-16k)の推論を CoT テンプレートで蒸留し、少数のラベルつきチケットから小規模言語モデルを教師あり微調整したうえで、自己強化メカニズムと DPO による反復改善を重ねる。 さらに、この分類器を報酬モデルとして用い、その予測信頼度を報酬にチケット要約器を DPO で調整する。 同じ組織の本番データ(1,678 チケット、12 チーム、テストセット 220 件)で評価し、最良のバックボーンである Qwen3-8B で ACC@1 0.618、Macro-F1 0.506 を達成した。 同一バックボーンの LLM ベースライン(ACC@1 0.607)を上回り、非 LLM ベースライン(ACC@1 0.336)に対しては 28.2 ポイントの差をつけた。 トークン消費は同系列の比較手法(15.62k トークン)比で約 72.9% 削減しつつ Macro-F1 で上回る (Source: [[@2026__nkcs.iops.ai__Collaborative Knowledge Distillation and Reinforcement Learning for Automated Ticket Triage in Large-Scale Production Systems]])。 > [!contradiction] OncallX(ファインチューニング不要、知識グラフとプロンプティング)と CoTriage(知識蒸留と強化学習によるファインチューニング)は、いずれも Ruowei Fu を筆頭著者、Shenglin Zhang を責任著者とし、同じ組織のデータを対象とする。 > OncallX は 145 件のテストセットで ACC@1 0.652 を、CoTriage は 220 件のテストセットで ACC@1 0.618 を報告するが、データセット規模と分割方法が異なるため両者の数値は直接比較できない。 > 同一の研究グループが同一ドメインで決定版のアプローチを定めないまま 2 つの路線を独立に発表しているという事実そのものが、チケットトリアージにおいてどちらが優れるかがまだ定まっていないことを示している (Source: [[@2026__nkcs.iops.ai__Collaborative Knowledge Distillation and Reinforcement Learning for Automated Ticket Triage in Large-Scale Production Systems]], [[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]])。 #### 車載ドメインでの再実装が示した先行手法の脆弱性 同じ研究グループが車載ドメイン向けに提案した InsightTriage は、本番データ(インシデントチケット 4,526 件、テストセット 604 件、73 種のインシデントタイプ)で複数の先行トリアージ手法を比較ベースラインとして再実装した。 その結果、ルールベースのキーワードフィルタリングに依存する COMET は Weighted F1 0.211 と、比較した 4 手法(0.500、0.662、0.664)の中で最低の性能となった。 著者らは、症状駆動でキーワードが多様な車載ドメインでは COMET のルールベース手法が有効に機能しないためと考察している。 InsightTriage 自身は、車両ログから LLM がオフラインで自動構築するコンポーネントレベルの構造化知識ベースと、対照的な事前学習によるログ検索器を組み合わせ、Weighted F1 0.801 を達成して最良ベースラインを 13.7 ポイント上回った。 構造化知識ベースを除去すると Weighted F1 は 0.669 へ、ログ検索器を除去すると 0.609 へ低下し、両モジュールがそれぞれ有意に寄与することをアブレーションで確認している (Source: [[@2026__ASE__LLM-Assisted Joint Ticket and Log Analysis for Incident Triage in Intelligent and Connected Vehicles]])。 先行手法をドメインを変えて再実装すると最低性能に転落するという事実は、チケットトリアージ手法の精度がドメイン固有の症状表現に強く依存しており、汎用的な優劣が定まっていないことをあらためて示している。 ### 第 30 章　人間の介在点と運用の信頼 ![[Attachments/アラート管理の教科書/chapter-30.png]] LLM とエージェントがアラート処理へ入り込むほど、人間がどこで判断を差し戻せるかという設計が問題になる。 #### 承認ゲートと拒否インターフェース AlertGuardian のルール精錬は、検出、RAG、ルール生成、レビューの各エージェントから成るオーケストレータなしのマルチエージェントパイプラインで動くが、構文検査とシミュレーションによる自動検証を経てもなお、精錬提案は最終的に SRE が承認する仕組みを採る。 4 データセットで合計 1,174 件のルール精錬を提案し、375 件(32%)が受容された。 方策別では冗長ルールの統合が 80.0% から 83.3% と高い受容率を示す一方、可変ワークロード下の時間条件付与は 7.5% から 14.0% と最も低く、方策によって人間の承認を得やすさが大きく異なる (Source: [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]])。 JISEM 誌に発表された Human-AI Reliability Framework は、拒否インターフェースをより体系的に扱い、即時停止から調査のための一時停止、しきい値変更、手動運用への復帰まで緊急度に応じた段階を設けるべきだと論じる。 同論文は自律水準を、手動、支援、ガードレールつき自動化、適応型自動化、自律的修復という 5 段階で整理し、水準が上がるほど応答速度の便益と引き換えに、誤った介入やフィードバックループの不安定化、状況認識の喪失というリスクが増すと述べる (Source: [[@2026__JISEM__When Systems Are Uncertain Human Reliability Engineering in AI-Driven Production]])。 #### 独立に提案された自律性の段階 AI や自動化にどこまで任せるかを段階で表す枠組みは、JISEM の論文のほかにも、SRE Book 第 2 版の 3 つの章と Honeycomb のマニフェストがそれぞれ独自に提示している。 | 出典 | 段の数 | 段の刻み方 | 終点の扱い | |---|---|---|---| | Human-AI Reliability Framework(JISEM) | 5 | 手動、支援、ガードレールつき自動化、適応型自動化、自律的修復 | 水準が上がるほどリスクが増す | | SRE Book 第 2 版第 13 章 | 3 | 検知して通知、行動を提案して通知、行動して通知 | 各段をチームがレビューする | | SRE Book 第 2 版第 10 章 | 4 | 読み取り専用、定型変更、人間レビューつきの複雑な変更、完全自律 | 完全自律を北極星に置く | | SRE Book 第 2 版第 21 章 | 5(L0 から L4) | 監視、調査、アクチュエーション、承認、自己指向のどこまでを自動化するか | すべてのシステムが L4 を目指すべきではない | | Honeycomb マニフェスト | 3 | オートパイロット、コパイロット、アナリストを課題ごとに切り替える | 人間はループから去らない | (Source: [[@2026__JISEM__When Systems Are Uncertain Human Reliability Engineering in AI-Driven Production]], [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 13 Automation and Tooling]], [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 10 Incident Management and On-Call]], [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]], [[@2026__Honeycomb Blog__Honeycomb 10 Year Manifesto Part 1]]) 同じ書籍の中でも段の数と終点がそろっていない。 第 13 章は部分自動化で止まることは全手動より問題になりうるとし、最後の 10% に最大の価値があると述べて完全自動化へ押す (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 13 Automation and Tooling]])。 第 21 章は、適切な自律レベルは重要度、リスク許容度、運用成熟度、障害コストで決まるとし、昇格の前提条件として、試験の網羅、明確なロールバック機構、確立したエラーバジェット、現レベルでの運用実績を挙げる (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]])。 #### SLO に接続された格下げと遮断 第 21 章の安全設計は、アラートと SLO の仕組みに AI の権限を接続する点に特徴がある。 透明性(推論、使った信号、確信度の説明)、文脈認識(デプロイ凍結、エラーバジェット、進行中のインシデントを考慮した実行前のリスク評価)、段階的認可の 3 本柱を置き、いずれもエラーバジェットや SLO の延長として実装できるとする。 エラーバジェットが枯渇したら AI を自律実行から人間が関与する助言役へ自動で格下げし、確信度が閾値を下回る緩和案はオンコールに提示しない。 ブレークグラス機構でエージェントの本番アクセスを即座に遮断でき、止められること自体が心理的安全性を支えるとされる (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]])。 可逆性も共通の条件になっている。 第 21 章は元に戻し方を知らない操作をエージェントに実行させず、操作、検証、ロールバックを 1 つのトランザクションにして、健全性の閾値に届かなければ自律的に逆操作させる。 前進修正はエージェントに向かないとされる (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]])。 第 10 章も、実行、即時検証、失敗時の自動ロールバックを 1 つの監査可能なトランザクションとして扱い、推論と信号と確信度を記録するよう求め、人間によるレビューと承認はトイルではなくフィードバックだとする (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 10 Incident Management and On-Call]])。 第 13 章は、レート制限、範囲の制限、閾値を超えたら停止して人間へエスカレーションするサーキットブレーカーを強力な自動化の安全装置に挙げ、オペレータの技能低下(Bainbridge の「自動化の皮肉」)を自動化の落とし穴の 1 つに数える (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 13 Automation and Tooling]])。 人間の位置づけには温度差が残る。 第 21 章は、人間がループの上から外へ出るかどうかは不確実だと留保する (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]])。 Majors(Honeycomb)は、人間はループから去らず、ループの中で決定し、ループの上で意図の宣言、試験、検証を通じて長期に舵取りすると断言する (Source: [[@2026__Honeycomb Blog__Honeycomb 10 Year Manifesto Part 1]])。 #### 確率的アラート設計の原則 同論文が提案する確率的アラート設計は、固定閾値の違反通知から、介入の期待価値と意思決定の文脈を伝える意思決定支援へアラートを再設計する原則である。 具体的には、待機より介入が優れる場合にのみ通知する、同じ意思決定文脈の相関シグナルを束ねる、偽陽性と偽陰性の非対称なコストを示す、介入の期待価値と作業内容と期限を示す、技術シグナルを業務上の意味へ翻訳する、適時の延期や却下の手段を提供するという 6 原則から成る (Source: [[確率的アラート設計]], [[@2026__JISEM__When Systems Are Uncertain Human Reliability Engineering in AI-Driven Production]])。 信頼校正の正確度という指標も提案し、過信状態では誤った推薦の受容率が高く、偽陽性を経験した後は正しい推薦さえ拒否率が高まるという非対称な挙動を整理している (Source: [[@2026__JISEM__When Systems Are Uncertain Human Reliability Engineering in AI-Driven Production]])。 > [!warning] この論文は概念と設計の論文であり、独自の実験、本番データによる検証、ベースライン比較を持たない。提案された指標の測定プロトコルと実運用での妥当性は今後の課題として著者自身が明記している (Source: [[@2026__JISEM__When Systems Are Uncertain Human Reliability Engineering in AI-Driven Production]])。 #### AI 運用下の信頼の再設計 Theofilos Papapanagiotou(Amazon)による SREcon25 EMEA での発表は、人間とエージェントが同一データと同一インターフェースから推論すべきだという立場を採り、信頼性の定義を稼働率中心のシステム信頼性から、発見可能性、説明可能性、推論力を含む認知的信頼性へ拡張する。 本番環境への変更提案には、エージェントの推論過程とドライランの結果を提示したうえで人間が承認する仕組みを設け、最初の仮説提示までの SLO を 30 秒とする設計目標を掲げている (Source: [[@2025__SREcon25EMEA__Modernizing Incident Response with LLMs, RAG, and the MCP]])。 Eddie Redick(CTC Ops)は SREcon26 Americas で、AI を信頼すると回答したのは調査対象の 16% にとどまる一方、68% が 2026 年中に AI エージェントの統合を予定しているという信頼のパラドックスを指摘する。 AI Ops の成功は技術導入そのものではなく、20% のテクノロジーと 80% の業務再設計(文化、プロセス、人材、ガバナンス)の比率で決まると主張する (Source: [[@2026__SREcon26Americas__Human Factors in the Age of AI Ops]])。 これらの数値はいずれも第三者の産業調査からの引用であり、発表自体の一次評価ではない。調査元を確認できていないものも含まれると原典が断っている (Source: [[@2026__SREcon26Americas__Human Factors in the Age of AI Ops]])。 #### 産業統計と巨大事業者の実測値のスケール差 Redick の発表が引用する産業調査は、組織平均で 1 日 960 件超、大企業では 3,000 件超のアラートが発生し、そのうち 30% が未調査のまま消えると報告する (Source: [[@2026__SREcon26Americas__Human Factors in the Age of AI Ops]])。 これに対し AlertGuardian が報告する実測値は、70% 超のシステムが平均で毎分 200 件以上のアラートを発火し、1 システムあたり日次で 288,000 件を超えうるというものであり、業界調査の水準とは 2 桁近い開きがある (Source: [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]])。 この食い違いは、産業調査が想定する大企業の規模と、超大規模クラウド事業者の実際のアラート量が同じ尺度で語れないことを示しており、アラート疲労を論じる際にどちらの数値を参照しているかを明示する必要がある。 #### Google の方針と人間の指揮者 Google Cloud Blog の記事は、Google SRE が異常検知後のアラートの群化、前処理、拡充を担うエージェントと、その自律処理を担うハンドラを実装していると述べる一方、この 2 つのエージェントはインシデント管理を人間から奪う設計ではないと明記する。 インシデント管理の上に被せるエージェント層は、コミュニケーション監視、SRE 間のハンドオフ文書生成、ポストモーテムの下書き、内外コミュニケーション管理という 4 種のエージェントから成るが、いずれも人間の SRE が Incident Commander のもとで行う認知作業を補助するものであり、人間の指揮者を置き換えない。 Google はエージェント設計の前提として、既存自動化の温存、既存ポリシーの遵守、行動の説明可能性と透明性を含む 9 つの原則を課しており、なかでもブラックボックスの自動化よりも透明性を優先するという原則が、なぜどう行動したかを却下した選択肢も含めて説明できることを要求する (Source: [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]])。 #### ML サービス監視における対照的な立場 Lina Weichbrodt(元 Zalando SE のシニアリサーチエンジニア)は SREcon23 EMEA で、LLM やエージェントによる高度化とは対照的に、ML サービスの監視には既存の監視スタックで十分始められるという保守的な立場を提示する。 主張の中心は、症状ベースアラーティングの原則、すなわち原因でなくエンドユーザーへの影響に着目するという原則を ML サービスへそのまま転用することであり、本番評価メトリクスとステークホルダーの懸念を最優先、後処理後のサービス応答分布を次点、入力と特徴量データの分布を最後に監視する優先順位づけを提案する。 MLOps 専用プラットフォームの早期導入には否定的で、ある金融会社のデータサイエンティストが「入力フィールドの分布変化アラートが週に複数届くが、上流のビジネス変更か自然変動か分からず一切対処しなかった」と報告した事例を、専用ツール導入前に組織的な準備が必要な根拠として挙げる (Source: [[@2023__SREcon23 EMEA__Symptom-based Alerting for Machine Learning]])。 この立場は、第 27 章から第 29 章で見た LLM とエージェントによる高度化路線とは方向性が異なり、症状ベースアラーティングという第 II 部の原則がモデル監視という新しい対象にもそのまま有効であり続けることを示す対照例である。 --- ## 第 IX 部　横断的知見 以下は、単一の文献からは言えず、母集団を並べて初めて見えた観察である。 ### 発見 1　複数シグナルの一致という設計原理が 30 年にわたり独立に再発見されている 単一の信号ではなく複数の信号の一致を発火条件にするという設計は、1998 年のプロトコル伝播に基づくデュレーションフィルタ、2009 年の不変条件ネットワークによる複数ルールのコンセンサス、2011 年の実務における複合条件アラート、2016 年の比率と絶対数の二重条件という形で、互いに引用関係を持たないまま反復して現れる (Source: [[@1998__IWSM__Adaptive Thresholding for Proactive Network Problem Detection]], [[@2009__ICAC__Ranking the Importance of Alerts for Problem Determination in Large Computer Systems]], [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]], [[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]])。 統計的検定、線形不変条件、運用上の経験則、時系列クエリという異なる道具立てが、同じ形の解に収束している。 ### 発見 2　テキスト類似度単独では因果連鎖を捉えられないという帰結が、異なる技法で 4 回確認された 重み付き合成のアブレーション、動的グラフによる定量化、外部知識を導入する設計転換、離散的アラートレベルでの退化の指摘という 4 つの経路から、同じ結論に到達している (Source: [[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems]], [[@2023__ASE__Dynamic Graph Neural Networks-Based Alert Link Prediction for Online Service Systems]], [[@2024__ICSE-SEIP__Knowledge-aware Alert Aggregation in Large-scale Cloud Systems - a Hybrid Approach]], [[@2024__ISSRE__Exploring Hierarchical Patterns for Alert Aggregation in Supercomputers]])。 対象がクラウドかスーパーコンピュータかを問わず成り立つ点で、ドメイン依存の観察ではない。 ### 発見 3　アラートの時間的順序は根本原因を反映しない 集約系はサンプリング間隔による順序情報の崩壊を報告し、ネットワーク障害検知系は障害の兆候が Syslog より先に現れることを理由に順序の仮定を捨て、LLM による因子分析は起点アラートが時間順で最初である割合が 45.34% にとどまることを人手ラベルで定量化した (Source: [[@2023__ASE__Dynamic Graph Neural Networks-Based Alert Link Prediction for Online Service Systems]], [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]], [[@2025__FASE__VOCE - A Virtual On-Call Engineer for Automated Alert Incident Analysis Using a Large Language Model]])。 3 つの独立した系譜が、時間順に因果を推論する素朴な設計を同じ理由で退けている。 ### 発見 4　同じ手法の評価が、データセットを変えると逆転する アウテージ予測手法は原論文で F1 88.78% を報告する一方、別のデータセットでの再評価では平均 F1 0.51 と報告された (Source: [[@2019__WWW__Outage Prediction and Diagnosis for Cloud Service Systems]], [[@2020__ESEC-FSE__Real-Time Incident Prediction for Online Service Systems]])。 インシデントトリアージ手法は本番展開で 30% の改善を報告する一方、車載ドメインでの再実装では比較した 4 手法中で最低の Weighted F1 0.211 となった (Source: [[@2024__ISSRE__Large Language Models Can Provide Accurate and Interpretable Incident Triage]], [[@2026__ASE__LLM-Assisted Joint Ticket and Log Analysis for Incident Triage in Intelligent and Connected Vehicles]])。 この 2 例は、単一事業者データでの性能報告が手法の汎用的な優劣を保証しないことを示す。 ### 発見 5　評価データの出自が構造的に偏っている 本ページの母集団において、学術 AIOps の手法はほぼすべてが企業の非公開本番テレメトリで評価されている。 公開ベンチマークを主評価に使う例は、本ページの範囲では 2026 年の性能アラートトリアージだけであり、他は汎化性検証の補助にとどまる (Source: [[@2026__ICPE Companion__Performance Alert Triage with Time-Aware Learning and Multi-Scale Time-Series Features]], [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]])。 発見 4 の逆転現象は、この偏りの帰結として読める。 さらに、著者自身が単一組織での評価にとどまることを限界として明記する例が母集団全体にわたって繰り返される (Source: [[@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]])。 ### 発見 6　技法の重さはライフサイクル段階に対応して分業している 検知とノイズ除去の段では、極値理論や修正 Z スコアのような軽量な統計手法が学習ベースの手法に匹敵するか上回る (Source: [[@2020__ICSE-SEIP__Understanding and Handling Alert Storm for Online Service Systems]], [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]])。 一方、集約とリンク予測の段ではグラフ表現学習が必要になる (Source: [[@2021__ASE__Graph-based Incident Aggregation for Large-Scale Online Service Systems]], [[@2023__ASE__Dynamic Graph Neural Networks-Based Alert Link Prediction for Online Service Systems]])。 この分業は、異常の有無という単純な判定と、どのアラート同士が同一原因かという組合せ的な判定の違いに対応する。 ### 発見 7　LLM を使う範囲は精度ではなくコストと推論遅延で決まる 本番デプロイを報告する文献のいずれも、アラート処理の全段を LLM に任せていない (Source: [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]], [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]], [[@2024__ICSE-SEIP__FaultProfIT - Hierarchical Fault Profiling of Incident Tickets in Large-scale Cloud Systems]])。 不採用の理由として挙げられるのは精度ではなく、日次の全件処理でのトークン費用と、自己回帰生成の遅延がリアルタイム要件を満たさないことである (Source: [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]])。 同じ理由から、入力規模がコンテキスト長を超える領域では LLM が意図的に排除される (Source: [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]])。 ### 発見 8　説明可能性を精度に優先する判断が 2012 年から 2026 年まで一貫している 精度の高い手法があってもルールベースを選ぶという判断は、2012 年の量的アソシエーションルール、2011 年の FMEA、2023 年の解釈可能性を保つ決定木の制限、2026 年の透明性の原則という形で繰り返し現れる (Source: [[@2012__NOMS__Optimizing System Monitoring Configurations for Non-Actionable Alerts]], [[@2011__OReillyJapan__ウェブオペレーション - Chapter 6 監視]], [[@2023__ICSE-SEIP__TraceArk - Towards Actionable Performance Anomaly Alerting for Online Service Systems]], [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]])。 運用者が判断を検証できることが、この領域では一貫して精度より優先されている。 2026 年の SRE Book 第 2 版付録 G も、ML による異常検知の限界に説明可能性とコストを挙げ、ML を周期性のある指標に限って統計手法と併用するとする (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Appendix G Modern Observability - Statistics and ML]])。 ### 発見 9　アラート削減の成功が 3 つの異なる軸で語られている 件数削減を成果とする立場、学習効果を成果とし削減率 0% を許容する立場、削減そのものが新たな不安を生むという副作用を報告する立場が並存する (Source: [[@2017__SREcon17 Europe__Want to Solve Over-Monitoring and Alert Fatigue - Create the Right Incentives]], [[@2023__SREcon23 Americas__Cognitive Apprenticeship in Practice with Alert Triage Hour of Power]], [[@2019__SREcon19 Americas__Fixing On-Call When Nobody Thinks It's (Too) Broken]])。 さらに、アラート量の削減とインシデント発生の抑制が別の対象であることも示されている (Source: [[@2017__SREcon17 Asia__Draining the Flood - A Combat against Alert Fatigue]], [[@2018__SREcon18Asia__You Can't Stop Fires with an Ambulance]])。 削減率の数値を比較する前に、何を成功と定義しているかを確認する必要がある。 ### 発見 10　修復段の空白が 2021 年の指摘以降も埋まっていない AIOps のサーベイが 2021 年に修復を最も手薄なカテゴリと指摘して以降、本ページの母集団に現れる 2022 年から 2026 年の文献も、鳴らすか、どう束ねるか、どう解釈可能にするかに集中している (Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.5 Remediation]])。 LLM 時代の文献においても、緩和計画の生成までを扱う研究は本番デプロイを伴わず、本番デプロイを伴う研究は診断までで止まる (Source: [[@2026__FSE Companion__Leveraging LLMs for Alert Summarization and Mitigation Plan Generation]], [[@2025__ASE__LogPilot - Intent-aware and Scalable Alert Diagnosis for Large-scale Online Service Systems]])。 ### 発見 11　同一の人物や研究グループが対立する立場を並立させている オンコールの最適化を説いた書籍の編者が 5 年後に慣行の廃止を説き (Source: [[@2016__OReilly__SRE Book - Chapter 11 Being On-Call]], [[@2021__OReillyJapan__SREの探求 - Chapter 30 オンコール反対論]])、チケットトリアージではファインチューニング不要の路線と蒸留と強化学習の路線を同一の研究グループが独立に追求している (Source: [[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]], [[@2026__nkcs.iops.ai__Collaborative Knowledge Distillation and Reinforcement Learning for Automated Ticket Triage in Large-Scale Production Systems]])。 いずれも、その領域で決定版の答えがまだ定まっていないことを示す徴候である。 同じ徴候は単一の書籍の中にも現れる。 SRE Book 第 2 版では、単独 SRE を持続不可能とする章と実行可能とする章が並び (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 6 Organizational Structures for SRE]], [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 22 SRE in Diverse Environments]])、自動化の終点を完全自律に置く章と、すべてが L4 を目指すべきではないとする章が並ぶ (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 10 Incident Management and On-Call]], [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]])。 ### 発見 12　アラートの判定基準が「固定目標」と「相対ベースライン」の 2 系統に分かれたまま統合されていない SLO 由来の固定目標に対して判定するバーンレートと二項判定、直近の平常に対して判定する動的ベースラインとコホート相対の z スコアが、同じ SRE Book 第 2 版の中に並んでいる (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 8 Service Level Objectives]], [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 9 Observability and Monitoring]], [[@2026__OReilly__Site Reliability Engineering 2E - Appendix F The Mathematics of Latency Alerting]], [[@2026__OReilly__Site Reliability Engineering 2E - Appendix G Modern Observability - Statistics and ML]])。 いずれも静的閾値がトラフィック量に適応できないという同じ診断から出発しているが、窓の長さは 1 時間から 60 日まで散らばり、どれにも選択の根拠が書かれていない。 2016 年の Rabenstein と 2017 年の Wilkinson がディスク容量で示した「傾きによる予測」(第 7 章)も、固定閾値からの離脱という同じ方向の一例であり、この 10 年で判定の対象が資源の残量からエラー率とレイテンシの分布へ広がったと読める (Source: [[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]], [[@2017__SREcon17 Americas__A Practical Guide to Monitoring and Alerting with Time Series at Scale]])。 ### 発見 13　自動化の権限を段階で表す枠組みが少なくとも 5 通り独立に提案され、段の境界がそろわない 学術の概念論文、実務書の 3 つの章、ベンダーのマニフェストが、それぞれ 3 段から 5 段の梯子を示している (Source: [[@2026__JISEM__When Systems Are Uncertain Human Reliability Engineering in AI-Driven Production]], [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 13 Automation and Tooling]], [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 10 Incident Management and On-Call]], [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]], [[@2026__Honeycomb Blog__Honeycomb 10 Year Manifesto Part 1]])。 段を刻む基準は、何を自動化するか(監視、調査、実行、承認)、変更の複雑さ、課題の性質と一致しない。 共通するのは、可逆性とロールバックを昇格の条件に置く点と、人間の承認を最後まで残す段を持つ点だけである (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 10 Incident Management and On-Call]], [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]], [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 22 SRE in Diverse Environments]])。 --- ## 第 X 部　未解決の問い 以下は、本ページの母集団からは答えが確認できなかった問いである。次に何を読むべきかの作業リストとして使える。 - **軽量統計手法と学習ベース手法の境界はどこにあるか。** 検知とノイズ除去の段で軽量手法が有効だという観察は複数あるが (Source: [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]])、どの条件でグラフ学習が必要になるかを同一データセット上で比較した研究は本ページの母集団にない。各手法が別々の非公開データで評価されているため、境界を実証的に引けない。 - **アラート品質の 2 つの物差しは接続できるか。** ユーザー影響に基づく SLO 接地と、真と偽と欠落のコストモデルは相補的だと整理されているが、定量的な相互検証は行われていない (Source: [[Quality of Alerts]], [[@2022__SREcon22 Americas__Modeling Alert Quality]])。とくに欠落アラームのコストを品質の 3 軸でどう表現するかが未整理である。 - **欠落アラートをどう測るか。** 品質モデルは欠落アラームを 3 分類の 1 つとして扱うが (Source: [[@2022__SREcon22 Americas__Modeling Alert Quality]])、本ページの母集団にある学術手法はいずれも発火したアラートの選別と集約を対象としており、鳴らなかったものを体系的に数える手法を扱っていない。 - **公開ベンチマークの不在をどう埋めるか。** 発見 4 と発見 5 が示す再現性の問題に対し、複数事業者を横断する公開ベンチマークの構築を試みた研究は本ページの母集団にない。単一の公開データセットを主評価に使う例が 1 件あるのみである (Source: [[@2026__ICPE Companion__Performance Alert Triage with Time-Aware Learning and Multi-Scale Time-Series Features]])。 - **LLM 採用の境界を決める定量的な基準はあるか。** 入力規模とコンテキスト長の比較で採否が分かれた事例はあるが (Source: [[@2024__ICSE-SEIP__Knowledge-aware Alert Aggregation in Large-scale Cloud Systems - a Hybrid Approach]], [[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]])、どの規模で何を LLM に任せるべきかを一般化した基準は示されていない。モデルの世代交代でこの境界がどう動くかも扱われていない。 - **人間の介在点をどう設計すべきか。** 承認ゲートと段階的な拒否インターフェースの必要性は理論として提示されているが、その提案は概念論文にとどまり実証を伴わない (Source: [[@2026__JISEM__When Systems Are Uncertain Human Reliability Engineering in AI-Driven Production]])。一方、本番デプロイを報告するマルチエージェント実装には介在点の設計が明記されていないものがある (Source: [[@2025__ASE__LLM-Powered Multi-Agent Collaboration for Intelligent Industrial On-Call Automation]])。SRE Book 第 2 版はエラーバジェット枯渇時の格下げや確信度による提示抑制という具体的な設計を Google の実務として示したが、その効果の測定値は伴わない (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]])。理論と実装の間の橋は、設計の記述までは架かったが、実証はまだない。 - **アラート疲労のスケールを比較可能にできるか。** 業界調査が示す 1 日あたりの件数と巨大事業者の実測値には 2 桁近い開きがある (Source: [[@2026__SREcon26Americas__Human Factors in the Age of AI Ops]], [[@2025__ASE__AlertGuardian - Intelligent Alert Life-Cycle Management for Large-scale Cloud Systems]])。規模を正規化した比較指標が存在しないため、削減率の議論が同じ土俵で行えない。 - **配送段階の効果を定量化できるか。** 通知先の動的ルーティングも属性ベースの重複排除も、MTTR の改善率や偽陽性率を示していない (Source: [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]], [[@2026__JANOG58__ネットワーク監視の自動化はどこまでできるのか - Apache Airflowによるアラート対応基盤]])。配送段階の介入は本ページの母集団において唯一、定量評価の系譜を持たない段階である。 - **オンコール慣行の廃止論は検証できるか。** 標準化されたツールキットによってオンコールを不要にできるという主張は理論的な立場の提示にとどまり (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 30 オンコール反対論]])、これを部分的にでも実現した事例報告は本ページの母集団にない。 - **固定目標と相対ベースラインをどう使い分けるか。** SLO 由来の固定目標に対する判定と、直近の平常に対する判定が同じ書籍に並ぶが、どの指標にどちらを当てるか、両方が鳴ったときにどちらを優先するかは書かれていない (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 9 Observability and Monitoring]], [[@2026__OReilly__Site Reliability Engineering 2E - Appendix G Modern Observability - Statistics and ML]])。窓の長さ(2 週間、30 日、30 日から 60 日)の選び方も根拠がない (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Appendix F The Mathematics of Latency Alerting]])。また、動的ベースラインは平常からの逸脱を検知する方式なので、慢性的な劣化が窓の長さ以上続けば平常として吸収されうると考えられるが、この点を論じたソースは母集団にない。 - **オンコールの人数と負荷の閾値に根拠はあるか。** 1 シフト最大 2 件、オンコール 25% 以下、拠点あたり 6 名または 8 名という数値は第 1 版から第 2 版へ引き継がれたが、導出の根拠データはどちらにも記載されていない (Source: [[@2016__OReilly__SRE Book - Chapter 11 Being On-Call]], [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 6 Organizational Structures for SRE]], [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 10 Incident Management and On-Call]])。実務書は別の基準から 4 名という値を出しており (Source: [[@2019__OReillyJapan__入門 監視 - Chapter 3 アラート、オンコール、インシデント管理]])、規模ごとの妥当な値を比較した研究は本ページの母集団にない。 - **観測の欠落はアラートの見逃しにどう効くか。** カーディナリティ防御で新規系列を間引く設計は、観測の欠落と引き換えに監視基盤を守る (Source: [[@2023__Cloudflare-Blog__How-Cloudflare-Runs-Prometheus-at-Scale]])。見逃しは重大障害につながるとされるが (Source: [[@2017__CSUR__Data-Driven Techniques in Computing System Management - Chapter 6 Problem Diagnosis in System Management]])、部分的な欠落が検知に与える影響を測った報告はない。欠落アラートの測定という前の問いと地続きである。 - **修復の自動化はなぜ進まないのか。** 修復が最も手薄だという指摘に対し (Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.5 Remediation]])、診断が済めば復旧手順はほぼ自明になるためという説明が与えられているが、この説明自体を検証した研究は見当たらない。本番で自動修復を運用した報告は定型アクションの範囲にとどまる (Source: [[@2020__SRENext2020__Practices for Making Alerts Actionable]])。 --- ## 関連 - 概念: [[アラート管理]] / [[アクショナブルアラート]] / [[アラート疲労]] / [[アラートポリューション]] / [[アラートストーム]] / [[アラート相関]] / [[アラート集約]] / [[アラート抑制]] / [[アラートフィルタリング]] / [[アラートランキング]] / [[アラートアンチパターン]] / [[Quality of Alerts]] / [[Adaptive Paging]] / [[オンコール]] / [[オンコールストレス管理]] / [[認知的徒弟制]] / [[確率的アラート設計]] - 姉妹ページ: [[SLI-SLO教科書]](SLI の設計と SLO 目標値の決め方。本ページは SLO をアラート発火条件へ接地する側だけを扱う) / [[インシデント対応の教科書]](アラートが鳴った後の指揮と収束) / [[ポストモーテムの教科書]](事後の学習と運営) - MOC: [[structures/000 Index.md]]