アラーティングは監視の歴史からAI時代までどう変わり、理想はどこにあるか

# アラーティングは監視の歴史からAI時代までどう変わり、理想はどこにあるか複数の問いに、wiki 内の監視、アラート、オブザーバビリティ、AIOps の文献で答える。個別の論点は既存ページが詳しく扱っているため、本ページは論点ごとの要点と参照先の索引として機能させる。中心となる参照先は [[アラート管理の教科書]]、[[現代の理想的なアラーティング]]、[[現代の理想的なアラーティング-判断モデル]]、[[LLM学習インフラ実運用の教科書]] である。 ## 1. 過去から現代アラートに至る流れ | 時代 | 代表 | 特徴 | 解いた問題 | 残った課題 | | ------------ | -------------------------------- | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1993 | Swatch | syslog を中央に集め、正規表現で拾って通知する。時間窓で重複を間引く | 事後調査用だった syslog を常時監視に転用した | パターンは人手で書く正規表現で、未知の形式に追随できない ([[@1993__LISA__Automated System Monitoring and Notification With Swatch]]) | | 1998–2001 | Nagios / Zabbix / MRTG / RRDtool | ホストとサービスを単位にチェックする一体型ツール ([[@2025__YAPC Fukuoka 2025__SREのためのテレメトリー技術の探究]]) | 管理者が不要にページャーで呼ばれることを防ぐ ([[Nagios]]) | 命令型チェックの負荷が対象数に比例する。中央の Nagios が障害時のボトルネックになった (Cloudflare) ([[@2017__PromCon__Monitoring Cloudflare's Planet-Scale Edge Network with Prometheus]])。静的閾値は「横ばいの 85%」と「急増して枯渇に向かう 85%」を区別できない。「チェックボックス監視」の典型とされる ([[@2019__OReillyJapan__入門監視 - Chapter 1 監視のアンチパターン]]) | | 2000 年代 | Ganglia (+ Nagios) | マルチキャストによる自動発見と、木構造の集約 | 収集と通知を分離し、複合条件のアラートを可能にした (Flickr) | 数百ノード規模でスケールが頭打ちになる ([[Ganglia]]) | | 2006– | Graphite / StatsD / collectd | 時系列基盤と組み合わせ型監視。whisper は容量が固定のロールアップ | 専用部品の疎結合化と、アプリケーションメトリクスの民主化 ([[@2019__OReillyJapan__入門監視 - Chapter 2 監視のデザインパターン]]) | carbon-cache のマルチコア非対応、ページキャッシュの圧迫、複製の一貫性、過去データの精度劣化 (Mackerel での運用経験) ([[Graphite]]) | | 2003–2015 | Borgmon → Monarch / Gorilla | ラベル付き多次元時系列と、ルールの宣言的評価 ([[@2016__OReilly__SRE Book - Chapter 10 Practical Alerting from Time-Series Data]]) | 監視の保守コストをサービス規模に対して劣線形に抑える | チームごとの運用負担、スキーマの欠如、手動シャーディング。これを Monarch が解いた ([[Borgmon]], [[Monarch]]) | | 2015– | Prometheus + Alertmanager | Borgmon 系のプル型、ラベル、PromQL。一体型から分離型へ移った ([[@2018__Google SRE Workbook__Monitoring]]) | 障害ドメインと同居する配置、傾きによる予測アラート、症状ベースアラート ([[Prometheus]]) | 空の結果でもエラーにならず、ルールが静かに壊れる。高カーディナリティによる OOM ([[Prometheus]]) | | 2010 / 2014– | SaaS (Datadog / Mackerel) | 運用を事業者に委ねる「監視の民主化」。ロール単位で監視設定を自動適用する (Mackerel) | 監視基盤を自前で運用する負担をなくした | 静的閾値の表現力に限界があり、機械学習による異常検知は誤検知を避けられない ([[@2019__OReillyJapan__入門監視 - Appendix C 実践監視SaaS]])。Datadog は現在 Bits AI SRE まで統合している ([[Datadog]]) | | 2016– | Honeycomb / OpenTelemetry | 構造化イベントを単一の真実の源泉にする。OTel は API、SDK、セマンティック規約、Collector でベンダー中立の計装を担う ([[OpenTelemetry]]) | 高カーディナリティの探索と、ベンダーロックインの解消 | 三本柱に分けると関係が失われるという批判がある ([[@2026__Honeycomb Blog__Honeycomb 10 Year Manifesto Part 1]])。Collector の設定と安定性が課題で、相関 ID 方式の優位も未実証である ([[オブザーバビリティの三本柱]]) | アラート設計の思想は、この技術史と並行して「原因への閾値」から「症状と SLO」へ(2016–2018)、さらに「選別・集約・LLM」へ(2020–)と移った ([[アラーティングの進歩-年代別]])。 **wiki にないもの**: Zabbix のページ(リンクだけが存在する)、Nagios のプラグインや NRPE の構成、Graphite のドット区切り階層命名、Datadog と Mackerel の製品史。 ## 2. なぜ今アラーティングを見直すのか。AI 時代に特有のことは何か 1. **変更量が人間の時間尺度を超える**: 配信が 10 倍になれば、他の条件が同じならインシデントもほぼ 10 倍になる ([[@2026__OReilly__Site Reliability Engineering 2E - Chapter 19 SRE at the Tipping Point]])。DORA 2025 では AI 利用が 90% に達し、スループットは上がったが配信の不安定性は増え続けている ([[@2025__DORA__State of AI-assisted Software Development - Chapter 1 Executive summary]])。Majors は、ページの閾値が高いため、コストの漸増や前日デプロイの副作用を見逃すと指摘する ([[@2026__Honeycomb Blog__Honeycomb 10 Year Manifesto Part 1]])。 2. **エラーを出さない劣化**: LLM アプリケーションは、コスト制約のもとでエラーを出さずに品質だけを落とす。可用性とレイテンシの SLI では捕捉できない ([[LLMアプリケーション信頼性]])。対策として、Intercom はコストに SLO を張り、Honeycomb MCP はクエリ成功率に SLO を張った ([[agentic時代のSLI-SLO運用]], [[GenAI オブザーバビリティ]])。 3. **受け手が人間だけではなくなった**: Google では AI Alerting Agent がアラートを前処理し、Autonomous AI Alert Handlers がそれを処理する ([[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]])。アラートは「人を起こす通知」から「エージェントへの入力」へ意味を広げつつある。 4. **テレメトリのコスト**: オブザーバビリティのコストは 15 年間、年 40% 以上増えてきた ([[@2026__OReilly__Observability Engineering 2E - Chapter 27 Diagnosing Your Observability Investment]])。 5. **従来からの未解決問題**: 「オオカミ少年アラート問題」は、[[Yuuki Tsubouchi]] が SRE NEXT 2024 で挙げた 6 つのオープンチャレンジの筆頭である ([[@2024__yuuk.io__SRE-NEXT-2024]])。 **空白**: AI による変更量の増加がアラート件数を押し上げたことを直接測った資料はない。 ## 3. SLO ベースアラートとは何か。実際どこまで有効か **定義**: エラーバジェットの消費速度(バーンレート)が危険な水準に達したときだけ発火させるアラートである。99.9%、30 日の SLO では、バーンレート 1 は 30 日で予算を使い切る速度、1000 は 43 分で使い切る速度に当たる。推奨構成は、ページ用が「1 時間で 2% 消費」と「6 時間で 5% 消費」、チケット用が「3 日で 10% 消費」である。長い窓と、その 12 分の 1 の短い窓の両方が閾値を超えたときに発火させる (複数窓・複数バーンレート) ([[@2018__Google SRE Workbook__Alerting on SLOs]])。 **有効性の証拠**: - Google の Wilkinson のチームは、全チームで最悪のオンコールだった状態から、4 週連続で 1 シフトあたり 2 ページ未満に下げた ([[@2018__SREcon18 Asia__A Theory and Practice of Alerting with Service Level Objectives]])。 - eBay は非同期パイプラインに SLI の定義を差し替えるだけで移植した。バーンレート 14.4 / 6 は Workbook の推奨値と一致する ([[@2025__SREcon25Americas__Beyond Sequential - A Recipe for Async Pipeline Observability and Alerting]])。 **限界**(いずれも [[アラート管理の教科書]] 第 12 章): - **低トラフィック**: 1 件の失敗が 1000 倍のバーンレートになる。対策は人工トラフィック、上位での集約、SLO の再交渉である。 - **超高可用性**: 99.999% では全面障害が 26 秒で予算を使い切る。約 99.95% を超える SLO では事前対応の手段として効かなくなり、劣化の報告用途に限られる ([[@2026__OReilly__Observability Engineering 2E - Chapter 12 Acting On and Debugging SLO-Based Alerts]])。 - **予測的バーンの外挿の矛盾**: 線形外挿と比例外挿は、同じ観測から正反対の緊急度を導く (未解決の矛盾として記録済み)。 - **計算コスト**: Honeycomb ではコンテキスト対応バーンの再計算に 1 日 5,000 ドル超かかった例がある。 - **SLO 化しにくい対象**: 原因系(ディスク枯渇など)は「満杯までの時間と修復に要する時間の比較」として再定式化する必要がある。GPU 訓練ジョブや LLM の品質劣化は、そもそも SLI の設計が確立していない(第 7 節、第 2 節)。 **結論**: 高トラフィックで 99.9% 前後の、リクエスト型または一部の非同期型サービスではよく効く。それ以外では前提条件を満たさない。 ## 4. 原因起点アラートと症状起点アラートの違い症状起点(ブラックボックス)は「ユーザーが今どう困っているか」を示し、原因起点(ホワイトボックス)は「なぜ壊れたか」「もうすぐ壊れそうなもの」を示す ([[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]])。分散システムでは原因と症状の結びつきが緩く、単一マシンの停止や CPU 使用率は規模が大きくなるほどノイズになる ([[@2016__SREcon16 Europe__Alerting for Distributed Systems - A Tale of Symptoms and Causes, Signals and Noise]])。Google、SoundCloud、OmniTI は 2016 年に別々の出発点から「ページは症状に限る」という同じ結論に達した。原因は捨てず、チケット、ダッシュボード、Runbook、自動添付される診断情報に回す ([[アラート管理の教科書]] 第 7 章、[[現代の理想的なアラーティング-判断モデル]])。副作用として、症状を持つチームにアラートが集中する。この問題は、通知先だけをトレースの因果関係で動的に決める [[Adaptive Paging]] で緩和できる。 ## 5. アラートの品質とは何か。どう計測するか。コストで測るとはどういうことか - **3 軸 (QoA)**: 指示性(ユーザー影響を示すか)、精度(重大度は正しいか)、処理容易性(適切な受け手が迅速に処理できるか)の 3 つで測る ([[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]], [[Quality of Alerts]])。 - **Workbook の 4 指標**: 精度、再現率、検知時間、リセット時間 ([[@2018__Google SRE Workbook__Alerting on SLOs]])。 - **コストモデル (Zadka)**: アラームを真、偽、欠落の 3 種に分ける。品質を「アラーティングのコスト(偽アラームへの対応と重複発火)+ 非アラーティングのコスト(欠落による復旧遅延と被害拡大)」の符号反転として定義する。真アラームの時間は、発生→検知→確認→診断→復旧の 4 区間に分けて区間ごとに改善する。アラートの追加や削除は真アラームと欠落アラームを相互に変換するので、件数を減らすこと自体は品質ではない ([[@2022__SREcon22 Americas__Modeling Alert Quality]])。 - **運用で測る指標**: Baidu のアテンション率 (夜間に詳細が閲覧された割合)、アラートバジェット、KEEP/TUNE/DELETE の定期レビューがある ([[現代の理想的なアラーティング-判断モデル]])。 - **注意**: 品質は遅行指標なので、偽アラームの件数のような即時指標で補う。報酬や評価の目標にすると Goodhart の法則が働く (Zadka)。 - **空白**: QoA を自動でラベル付けし継続計測する手法はまだない。SLO に基づく物差しとコストに基づく物差しを定量的に突き合わせた研究もない。 ## 6. 障害のたびにアラートを足すと何が起きるか。鳴らない問題のほうが怖いか足し続けると、「監視を増やせば安全」という誤った連想から [[アラートポリューション]] が起き、[[アラート疲労]] に至る。Baidu では 1 人あたり 1 日 100 件超で、有効なアラートは 15% 未満だった。2026 年の産業調査では、アラートの 30% が調査されないまま消えている。一方、Microsoft の約 950 件のインシデント分析では、検知失敗の最大要因は「アラートがそもそも無い」ことで、40.41% を占めた。検知に失敗したインシデントの 27.25% はアウテージに発展し、顧客からの報告で見つかった場合の検知時間は 10.7 倍だった ([[@2023__ESEC-FSE__Detection Is Better Than Cure - A Cloud Incidents Perspective]])。さらに XiHe では、AI による RCA の誤診断の 85.7% が決め手となるアラートの欠落から生じていた ([[@2026__SIGCOMM__Networked Agent Memory and Causality Representation - Experiences towards Interpretable Cloud-Scale Root-Causing]])。つまり、足し続けてもノイズが増えるだけで欠落は埋まらず、両方の問題が同時に悪化しうる。「鳴らない」ことは、発覚が遅れる点と、AI による診断の前提まで崩す点で怖い。ただし、両者を同じ尺度で比べた定量研究は wiki にない。wiki の立場は、両方を Zadka のコストモデルの同じ式に入れて扱う、というものである。 ## 7. 監視そのものをどう監視するか 1. **ルールの健全性**: Prometheus のアラートルールは、メトリクス名の廃止、ラベル変更、`rate()` の時間範囲不足、recording rule の連鎖切断で静かに鳴らなくなる。Cloudflare の [[pint]] は、静的解析、変更行だけのライブ検証 (CI)、定期実行のデーモンの 3 段で対処する。デーモンは問題をメトリクスとして公開し、Prometheus 自身でアラート化する ([[@2022__Cloudflare-Blog__Monitoring-our-Monitoring]], [[Prometheusルールリント]])。 2. **パイプラインの疎通**: 常に発火し続ける合成アラートを Prometheus から Alertmanager 経由で PagerDuty に流し、それが途絶えたら通知する。これがデッドマンズスイッチである。拠点ごとの Prometheus は相互に監視し合い、上位の Prometheus が階層的に監視する ([[@2017__PromCon__Monitoring Cloudflare's Planet-Scale Edge Network with Prometheus]])。 3. **データの不在の検知**: cron ジョブの失敗は成功ログからは分からない。状態ファイルの最終更新時刻で検知するデッドマン装置を使う ([[@2019__OReillyJapan__入門監視 - Chapter 8 サーバ監視]])。 4. **監視の存在とカバレッジ**: 鳴るべき対象にそもそも監視があるかを確かめる。Microsoft の intelligent monitoring framework がこれに当たる (Ganatra+、[[現代の理想的なアラーティング]] の層 0)。 5. **GPU 訓練**: PyTorch の Watchdog は 30 分のタイムアウトを待ってから発火するため、それ自体が遅い監視になる ([[@2026__PPoPP__CCL-D - A High-Precision Diagnostic System for Slow and Hang Anomalies in Large-Scale Model Training]])。 ## 8. GPU クラスタのモニタリング - **規模が効く**: 平均故障間隔 (MTTF) は約 1/(ノード数 × 障害率) で、8 GPU なら 47.7 日、1,024 GPU なら 7.9 時間、16,384 GPU なら 1.8 時間になる ([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。Llama 3 の訓練は 54 日で 466 回中断し、その 78% がハードウェア起因だった。ByteDance ではインフラ障害は件数で 11% だが、消費した GPU 時間では 82% を占めた ([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。 - **障害モード**: - **Xid**: 種別ごとにジョブ失敗率が異なる。119 や 94 は 100%、NVLink の 74 は約 54% である ([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]])。 - **ECC と熱**: 室温が約 5°C 上がると、NVLink と ECC のエラーが増えた (Kalos)。 - **サイレントデータ破損 (SDC)**: 合成ベンチマークは欠陥 GPU の 60% 超を見逃す。 - **ハングとスロー**: ByteDance の暗黙的障害は 3 か月で 5,948 件。 - **ストラグラー**: ジョブの 42.5% が 10% 以上遅くなる。平均 2% の速度低下がスループットを 20–30% 落とす ([[GPUレジリエンス]], [[GPU性能変動]])。 - **何を見るか**: 一次シグナルはハードウェアカウンタではなく、ステップ時間のように利用者に見える量に置く。判定は絶対閾値ではなく、同じ役割のピアとの相対比較で行う。層は 5 つに分ける ([[LLM学習インフラ実運用の教科書]] 6.9 節)。 1. 常時計測の基盤層: DCGM の電力、温度、ECC、NVLink と NIC のスループット 2. 意味づけ層: 反復時間 3. 非侵入の外部層: RDMA、スイッチ 4. 異常時にだけ起動する深掘り層 5. オフラインの what-if 分析 - **Web 監視との違い**: - 集合通信の同期構造によって、1 台の異常が数百ミリ秒で全ランクに同じ症状として現れ、発生源を隠す。 - 可用性 SLO の代わりに、有効訓練時間比 (ETTR)、MFU、Goodput を使う。 - loss は訓練が進んでいることしか示さず、正しさは示さない。 - 提供側は利用者のコードを計装できない ([[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]])。 - **実装例**: さくらONE は DCGM、Node、Lustre、IPMI と自作の RDMA Exporter を OTel Collector に集め、VictoriaMetrics と Grafana で可視化している ([[@2025__O11yConTokyo2025__AIスパコン「さくらONE」のオブザーバビリティ]])。 - **誤検知の許容**: 緩和策が軽く可逆であれば、偽陽性を多めに許してよい。Guard は FPR 12.4% を許容する。751 のメトリクスを調べても、単独で使える先行指標はなかった ([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。 - **空白**: GPU クラスタ向けのアラート設計 (閾値、通知経路、エラーバジェット)、DCGM の詳細、推論クラスタの障害統計は wiki にない。 ## 9. 4 フェーズモデル [[現代の理想的なアラーティング]] が、12 の介入点を発火のタイミングで圧縮したモデルである。 | フェーズ | 介入点 | 目的 | |---|---|---| | A. 保証 | 監視の存在判定、ルールの健全性 (pint)、評価インフラ | 鳴るべきときに鳴ることを確かめる | | B. 抑制 | 動的 X-out-of-Y など | 発火数そのものを減らす | | C. 配信最適化 | フィルタリング、ルーティング、集約、相関、ランキング | 届けるアラートを絞り、正しい受け手に届ける | | D. 解決支援 | 調査準備 (prepalert)、RCA、自律ハンドラ | 人間またはエージェントによる解決を速める | 使い方は、全フェーズを実装することではない。自組織のボトルネックがどのフェーズにあるかを診断し、Zadka のコストが最も大きい区間から着手する。研究はフェーズ C と D に偏り、A と修復は薄い ([[アラート管理の教科書]] 発見 10)。 ## 10. Agentic SRE でアラーティングはどう変わるか。人間向けのアラートは残るか - **変わる点**: アラートは自律ハンドラの入力にもなる。判断モデルは、ページ、チケット、自律ハンドラ、診断情報、削除への振り分けとして定式化している。「自動修復できるならページしない」 (Jalleda) は、「エージェントが処理できるなら人間を呼ばない」へ拡張される。Google では L2/L3 の自律緩和が本番で稼働し、InvD で MTTM を 44% 削減した ([[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]], [[SRE AI Autonomy Levels]])。 - **人間向けのアラートは残る**: 次の証拠がある。 - Google は Incident Commander を置き換えず、透明性を優先している。 - SRE 2E は、未知の未知を含むインシデントでは人間が最後の理解者になるとする ([[@2026__OReilly__Site Reliability Engineering 2E - Chapter 21 How AI Supports SRE]])。 - SkyNet は重大障害を意図的に LLM の自律処理から外した。15 分で約 1,000 万件の Syslog が出るからである ([[@2025__SIGCOMM__SkyNet - Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures]])。 - AI が単独で書いたインシデント要約は欠陥率が高く (完全性 35%、事実性 42%)、人間との協働版が優位だった ([[インシデントレスポンスAIレベル]])。 - **残るアラートの性質**: 数は減り、1 件の重みが増す。重大、広域、未知、不可逆な事象の承認と指揮が残る。本文は「何が起きたか」に加えて、エージェントの仮説、ドライランの結果、承認と拒否の手段を運ぶ。Amazon は、エージェントが示した仮説とドライランを人間が承認する方式をとり、最初の仮説が出るまでの SLO を 30 秒にしている ([[@2025__SREcon25EMEA__Modernizing Incident Response with LLMs, RAG, and the MCP]], [[確率的アラート設計]])。 - **空白**: エージェントの権限を SLO やエラーバジェットで縛る設計、人間向けアラートの本文をどう変えるべきかの実証、オンコールを廃止した事例は、いずれも wiki にない。Bits AI SRE の「解決時間 95% 減」はベンダーの自己申告なので割り引いて読む。 ## 11. 論文の最先端をそのまま現場に持ち込めないのはなぜか [[アラート管理の教科書]] 第 IX 部の横断的な発見による。 1. **評価の逆転** (発見 4): アウテージ予測は原論文で F1 88.78% だったが、他データでは 0.51 だった。COMET は本番で 30% 改善したが、車載ドメインでの再実装では最下位だった。 2. **評価データの偏り** (発見 5): ほぼすべての研究が単一企業の非公開テレメトリで評価されている。 3. **LLM の採用範囲は精度でなくコストと遅延で決まる** (発見 7): 本番報告で全段を LLM に任せた例はない。 4. **説明可能性が精度より優先される** (発見 8、2012–2026 年で一貫)。 5. **修復段の空白** (発見 10): 緩和計画の研究は本番に出ておらず、本番に出た研究は診断で止まっている。 6. **ベンチマークの天井が低い**: ITBench の緩和成功率は 11.43%、OpenRCA は 11.34%。「pod を再起動すれば 44% 解ける」という報酬ハッキングもある ([[SRE Benchmark]], [[RCA評価設計]])。 7. **規模の差**: 産業統計の 1 日 960 件と、AlertGuardian の 1 日 28.8 万件では桁が違う。 2022 年の DICOMO 講演も、AIOps 研究は情報を補助する支援に偏り、直接の判断や操作には届いていないと整理している。そのうえで、少ないデータで学べる実験可能性と、解釈性を要件に挙げている ([[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]])。 ## 12. 理想のアラーティングとは何か。ゆうきさんの考える理想と、そこに向けて起きていること **wiki に統合された定義** ([[現代の理想的なアラーティング]]): SLO を起点に、顧客が影響を受けている、または受けようとしているときにのみ発火する。発火前にルールの健全性と社会的な合意を保証し、発火後は適切な受け手へ文脈付きで届ける。人間の判断が要らない障害は自律的に処理する。これらの全過程を、測定可能なコストとして管理する。判断モデル版では、これを「人間を呼ぶ権利は高価である」を中心に置いた信頼性制御ループとして再構成している ([[現代の理想的なアラーティング-判断モデル]])。 **[[Yuuki Tsubouchi]] 自身の著作から読み取れる方向**: 以下は wiki 内の本人の文章からの抽出であり、本人の現在の見解そのものではない。 - **2017**: 最終目標は、コンピュータだけでシステムを運用できる状態にすることである。そのために観測、制御 (フィードバック制御)、実験の 3 軸で自律化する。SRE を「SLO を制約とし、変更速度を最大化する最適化問題」と見る ([[@2017__yuuk.io__ウェブシステムの運用自律化に向けた構想]])。 - **2022**: 技術者と AI が対話的に障害を予防し回復する段階を経て、AI が自律対応する段階へ進む。そのための要件として、実験可能性と解釈性を持つ [[Interactive AIOps]] を置く。「どこまで AI を信じるか」は未解決とする ([[@2022__DICOMO__AI時代に向けたクラウドにおける信頼性エンジニアリングの未来構想]])。 - **2024**: LLM を推論機械と見なし、観察、仮説、調査、検証のループを担わせる。課題は、テレメトリのダイジェスト化、Runbook の AI 向け再構造化、説明可能性、人間と AI の協調である ([[@2024__yuuk.io__The-World-of-LLM4SRE]])。SRE を「信頼性を適切な値に制御可能とすること」と定義し、オオカミ少年アラートを未解決課題の筆頭に置く ([[@2024__yuuk.io__SRE-NEXT-2024]])。これらを合わせると、理想は「人を起こす通知の最適化」ではない。アラートを、信頼性を目標値に保つ制御ループのセンサー兼トリガーとして設計し直すことである。人間に届くのは、AI が解釈可能な根拠を添えても判断を委ねきれない事象だけになる。 **そこに向けて今起きていること**: - 症状と SLO への接地が定着した (Workbook、eBay)。 - ルールの品質保証が現れた (pint)。 - 欠落の定量化が進んだ (Ganatra+)。 - エージェントがアラートの受け手になり始めた (Google の AI Alerting Agent と自律ハンドラ、Datadog Bits AI SRE、自律度 L2/L3 の本番稼働)。 - GenAI とコストへの SLO の拡張が始まった (Intercom、Honeycomb MCP)。 - AI による変更量の増加がこの転換を急がせている (SRE 2E 第 19 章、DORA)。 **まだ届いていないこと**: - エンドツーエンドの多層パイプラインの本番報告がない。 - QoA の自動計測がない。 - エージェントに任せる範囲の境界の理論がない。 - 修復段の研究が本番に出ていない。 - GPU や LLM ワークロードに向けたアラート設計がない。 ## 関連 - [[アラート管理の教科書]] / [[SLI-SLO教科書]] / [[LLM学習インフラ実運用の教科書]] - [[現代の理想的なアラーティング]] / [[現代の理想的なアラーティング-判断モデル]] / [[アラーティングの進歩-年代別]] / [[agentic時代のSLI-SLO運用]] - [[Quality of Alerts]] / [[アラート疲労]] / [[アラートポリューション]] / [[Prometheusルールリント]] / [[agentic SRE]] / [[SRE AI Autonomy Levels]] / [[GPUレジリエンス]] / [[RDMAネットワーク監視]]