[ホンマでっかSRE勉強会 #1 - connpass](https://honmadekka.connpass.com/event/395755/) ## タイトル アラーティングをどう進歩させるのか？ — 最先端とのギャップ分析 ## 発表時間 15分 ## TL;DR 多数の論文・SREcon講演等の文献から、アラーティングのライフサイクルを4フェーズ（保証→抑制→配信最適化→解決支援）で整理し、各フェーズの設計要件を7つの原則として抽出した。自身が設計・運用するマネージドHPC/AIサービスのGrafana Alerting設計をフェーズごとに照合し、ギャップを特定し、そのギャップをどう埋めるかを具体的に示す。発表のねらいは、アラーティングという"伝統的すぎて話題になりにくい"領域において、「最先端はどこにあるのか？」「自分たちはどこにいるのか？」「どう進歩させるのか？」を聴衆と共有し、議論を促すことである。 - (1.5min) 導入 — アラーティングの重要性と発表概要 - (1.5min+) 4フェーズモデル — 全体像・サービス紹介・ギャップ全体像 - (7min) Phase A — 理論・到達点・ギャップ - (2.5min) Phase B〜D・横断 — 到達点とギャップ - (2.5min) まとめ --- ## 1. 導入（1.5min） ### アラーティングの重要性（50秒） **メッセージ**: AIの時代でもアラーティングは消えない。むしろ重要性が増している。 - [[The Software Development Lifecycle is Dead]] は、SDLCの中で"Monitoring"が最後まで残ると主張している。 - Bainbridge, "Ironies of Automation," *Automatica*, 1983 [^Bainbridge,Automatica1983] によれば、AIによる高度に運用が自動化されたとしても、予期しないイベントが発生すれば、人間のオペレーターに制御が戻ってくる。おそらくは「アラート」という形で。 - Papapanagiotou et al. [^Papapanagiotou+,GCPBlog2026] は Agentic AI（エージェント型AI）をSREに導入し始めているが、その入力もアラートである。人間が受けるにせよ、エージェントが受けるにせよ、アラーティングの品質がインシデント対応の初動を大きく左右する。 ### 発表概要（30秒） 多数の論文・SREcon講演等の文献から、アラーティングのライフサイクルを4フェーズで整理し、7つの設計原則を抽出した。自身が設計・運用するマネージドHPC/AIサービスのGrafana Alerting設計をフェーズごとに照合し、ギャップをどう埋めるかを示す。 - **最先端はどこにあるのか？** — 論文・SREcon講演を体系的に整理して明らかにする - **自分たちはどこにいるのか？** — 4フェーズモデルでギャップを可視化する - **どう進歩させるのか？** — 場当たり的な改善ではなく、体系的にギャップを埋める ## 2. 4フェーズモデル（1.5min） ### アラーティングの4フェーズモデル（40秒） **メッセージ**: 多数の論文・SREcon講演等の文献を横断調査し、アラーティングのライフサイクルを4フェーズで整理した。40年弱の進化史から抽出した7つの設計原則は、各フェーズの設計問いに対応する。 | フェーズ | 設計問い | | ------------ | --------------- | | **A. 保証** | 何で鳴らすか？ 本当に鳴るか？ | | **B. 抑制** | 不要な発火をどう減らすか？ | | **C. 配信最適化** | 誰に、どう届けるか？ | | **D. 解決支援** | 受け手が何をするか？ | | **横断** | 品質をどう測るか？ | - アラートは A→B→C→D のパイプラインを流れる。**Phase Aが壊れていれば、B以降をどれだけ磨いても意味がない**。 ### 照合対象のサービス（30秒） - マネージドHPC/AIスパコンサービス。GPUノード、Lustreストレージ、RoCEネットワーク、Slurm、LDAPなどで構成される。Grafana Alertingで監視。1チーム運用。 ### ギャップ全体像（30秒） | フェーズ | ギャップ | | ---------- | ---------------------------- | | A. 保証 | SLO/バーンレート未導入。CI検証・常設カナリアなし | | B. 抑制 | — | | C. 配信最適化 | ML系は意図的に対象外 | | D. 解決支援 | 自動収集・RCA・エージェント処理は未着手 | | 横断（品質） | QoA/コストモデル未導入 | - **Phase Aにギャップが集中**。B・Cは実用水準に到達済み。以下、Phase Aを掘り下げる。 ## 3. Phase A: 保証 — 理論・到達点・ギャップ（7min） ### 症状で鳴らす、原因では鳴らさない（1min） - 「CPUが高い」「ディスクが90%」ではなく、「顧客が影響を受けている」で鳴る。 - Ewaschuk [^Ewaschuk,SREBook2016] の4ゴールデンシグナル → Thurgood et al. [^Thurgood+,SREWorkbook2018] のマルチウィンドウ・マルチバーンレートアラートへ。 - SLOを起点にすると、原因指標の組み合わせ爆発を回避でき、閾値の手動チューニングから解放される。 ### 鳴るべきアラートが本当に鳴るか（1min） - アラートは「鳴りすぎる」だけでなく「**静かに壊れて鳴らなくなる**」。 - Cloudflare SRE Team [^CloudflareSRE,Blog2022]: Prometheusルールの静かな故障モード — メトリクス名廃止、ラベル変更、recording ruleチェーン切断。 - Ganatra et al. [^Ganatra+,FSE2023]: Microsoftの大規模実証で、検知失敗の最大要因は「**そもそもアラートが無いこと**」（全修正項目の40.41%）。「鳴りすぎ」より「鳴らなすぎ」のほうが深刻。 - 対策: pint [^CloudflareSRE,Blog2022] のCI（劣化の挿入を防ぐ）+ デーモン（漸進的劣化を検出する）による二重保証。 ### Phase A: 到達点（1min） **severity × urgency（重大度×緊急度）の直交分離** - 「原因ではなく症状で通知する」が設計原則の筆頭。criticalの基準は「ユーザーが接続/ジョブ投入/ストレージ利用をできない」等の顧客影響で定義。 - 空間的影響（severity）と時間的緊急性（urgency）を独立軸にした。「criticalだが静かな対応でよい」状態を表現できる。Zeng et al. [^Zeng+,ICSE2023] のTraceArkにおける2軸分離と構造的に同型。 **Meta Monitoring（監視系の監視）の完全分離** - 「監視系の故障と監視対象の故障を混ぜない」をnotification policy tree（通知ポリシーツリー）で構造的に強制。Cloudflare SRE Team [^CloudflareSRE,Blog2022] の「第零の介入点」思想と同じ設計意図。 - No Data / Error / Missing Seriesを3分類。`offset` + `unless`で「過去存在し現在ない」exporter欠落を検知。 ### ギャップ1: SLO/バーンレートの不在（1.5min） - 現状: 症状起点の思想を閾値ベースの実装で代替。`critical閾値テンプレート`で手動チューニング。 - 何が変わるか: バーンレートで鳴る設計にすると、pending periodの手動チューニングが不要になり、warningの閾値もSLOから自動導出できる。 - ただしAI/HPCサービスでは、「症状起点」だけではカバーしきれない領域がある。GPU、NVLink、NICなどハードウェアに近い障害は頻発し、放電を挟む再起動やベンダー修理が必要になるケースも多い。これらは症状（ジョブ失敗）に先行して原因指標（Xid error、link down）で検知するほうが、被害拡大前に対処できる。**SLO駆動と原因ベースアラートの二層構成**がHPC/AIの現実的な到達点となる。 - どう進歩させるか: SLO駆動を上層に導入しつつ、HW原因ベースアラートを下層に維持する二層構成。 - 上層（SLO）: ジョブ投入可用性（login → slurmctldの疎通）、GPU計算容量（利用可能ノード数 / 全ノード数）、ストレージ可用性（Lustre mount成功率） - 下層（原因）: GPU Xid error、NVLink degraded、NIC link down → 放電再起動/ベンダー修理判断の起点 ### ギャップ2: ルール健全性のCI検証がない（1.5min） - 現状: Meta Monitoring（監視系の監視）でdatasource / evaluation error（データソース異常、評価エラー）を検知するが、PromQL構文・ライブ検証はない。常設カナリアも未実装。 - リスク: ラベル変更やrecording ruleチェーン切断で、アラートが静かに死ぬ。Ganatra et al. [^Ganatra+,FSE2023] の「そもそもアラートが無い」問題の一形態。 - どう進歩させるか: - 既存の`Preview → Approve → Apply`にpint [^CloudflareSRE,Blog2022] またはGrafana AdvisorのCIステップを追加。 - 常設カナリア（`lifecycle=experimental`の`vector(1)` alert）を各routeに配置し、通知経路の死活を常時検証。 ## 4. Phase B〜D・横断: 到達点とギャップ（2.5min） ### Phase B〜D: 到達点と将来（1min） - **B（抑制）**: pending + keep_firing_for + silence + mute timingで実装済み。probe系と容量系で使い分け。 - **C（配信最適化）**: quarantine routeで必須ラベル欠落を本番routeから排除（Yang et al. [^Yang+,DSN2022] のアンチパターンA1を構造的に予防）。`lifecycle=experimental`で検証中ルールを本番通知から完全隔離。Grafana notification grouping + severity×urgencyで実質ランキング。 - **D（解決支援）**: 必須annotation 5項目（`summary`、`impact`、`first_action`、`dashboard_url`、`runbook_url`）。Treat [^Treat,SREcon2016] の発火前4問テストを構造的に組み込み。岩堀 [^Iwahori,SRENEXT2023] のRunbookガバナンスと同等。 - **将来の拡張余地**: prepalert的自動証拠収集（池田 [^Ikeda,SRENEXT2023]）、RCA、autonomous handlerは未着手。Phase Aのギャップ解消後の次フェーズ候補。 - **意図的な対象外**: ML集約・ランキング・動的因果ルーティングは、1チーム運用かつアラート総量の規模から現時点では不要と判断。 ### 横断: 品質の定量管理 — ギャップ3（1.5min） - 現状: アラートの「良い/悪い」を体系的に判定する枠組みがない。QoA 3軸（Yang et al. [^Yang+,DSN2022]）やコストモデル（Zadka [^Zadka,SREcon2022]）は未導入。 - どう進歩させるか: - Yang et al. [^Yang+,DSN2022] のQoA 3軸（指示性・精度・処理容易性）で個々のアラートを評価可能にする。 - Zadka [^Zadka,SREcon2022] 式の4区間分解（発生→検知→確認→診断→復旧）で各区間のコストを可視化。 - インシデント振り返り時に「このインシデントを検知すべきアラートは存在していたか」を定常的に問い、欠落アラームのコストも計測に組み込む。 ## 5. まとめ（2.5min） - 多数の論文・SREcon講演から、アラーティングのライフサイクルを保証→抑制→配信最適化→解決支援の4フェーズで整理し、7つの設計原則を各フェーズに対応づけた。 - HPC/AIサービスに照合すると、**Phase A（保証）にROI最大のギャップが集中**: SLOベースアラーティングとルール健全性CI。Phase B・Cは静的手法で実用水準に到達。 - **論文やSREconのような最先端の議論を体系的に整理すると、場当たり的な改善から、体系的にギャップを埋めるアプローチをとることができる。** --- ## 参考資料 - [[wiki/questions/現代の理想的なアラーティング]] — 最先端7原則+4組織条件の統合定義 - [[wiki/questions/アラーティングの進歩-年代別]] — 50ソースの年代別レビュー - [[さくらONE Grafana Alerting 設計 2026-04]] — 照合対象の設計文書 - [[さくらONE Alerting 設計の理想モデルに対する位置づけ]] — 最先端とのギャップ分析 ## 引用文献 [^Bainbridge,Automatica1983]: Lisanne Bainbridge, "Ironies of Automation," *Automatica* 19(6), pp. 775–779, Pergamon Press, 1983. [^Ewaschuk,SREBook2016]: Rob Ewaschuk, "Monitoring Distributed Systems," in *Site Reliability Engineering*, O'Reilly, 2016. [^Treat,SREcon2016]: Robert Treat, "Less Alarming Alerts!," *SREcon16*, 2016. [^Jalleda,SREcon2017]: Kishore Jalleda, "Want to Solve Over-Monitoring and Alert Fatigue? Create the Right Incentives!," *SREcon17 Europe*, 2017. [^Wilkinson,SREcon2017]: Jamie Wilkinson, "A Practical Guide to Monitoring and Alerting with Time Series at Scale," *SREcon17 Americas*, 2017. [^Thurgood+,SREWorkbook2018]: Steven Thurgood, Jess Frame, Anthony Lenton, Carmela Quinito, Anton Tolchanov, Nejc Trdin, "Alerting on SLOs," in *The Site Reliability Workbook*, O'Reilly, 2018. [^Ren,SREcon2018]: Ren Xinchi, "Introduction to Alibaba Monitoring System," *SREcon18 Asia*, 2018. [^Mineiro,SREcon2019]: Luis Mineiro (Zalando SE), "Are We All on the Same Page? Let's Fix That," *SREcon19 EMEA*, 2019. [^Mormul+,CLOUD2020]: Mathias Mormul, Pascal Hirmer, Christoph Stach, Bernhard Mitschang, "DEAR: Distributed Evaluation of Alerting Rules," *IEEE CLOUD*, 2020. [^Zhao+,ISSRE2020]: Nengwen Zhao, Panshi Jin, Lixin Wang, Xiaoqin Yang, Rong Liu, Wenchi Zhang, Kaixin Sui, Dan Pei, "AlertRank: Automatically and Adaptively Identifying Severe Alerts for Online Service Systems," *IEEE ISSRE*, 2020. [^Singh,SREcon2021]: Nishant Singh, "Spike Detection in Alert Correlation at LinkedIn," *SREcon21 Americas* (USENIX), 2021. [^CloudflareSRE,Blog2022]: Cloudflare SRE Team, "Monitoring our Monitoring," *Cloudflare Blog*, 2022. (pint はこの記事で公開された Prometheus ルールリンター) [^Yang+,DSN2022]: Tianyi Yang, Jiacheng Shen, Yuxin Su, Xiaoxue Ren, Yongqiang Yang, Michael R. Lyu, "Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems," *DSN* (IEEE/IFIP), 2022. [^Zadka,SREcon2022]: Moshe Zadka, "Modeling Alert Quality," *SREcon22 Americas*, 2022. [^Ganatra+,FSE2023]: Vaibhav Ganatra, Anjaly Parayil, Supriyo Ghosh, Yu Kang, Minghua Ma, Chetan Bansal, Suman Nath, Jonathan Mace, "Detection Is Better Than Cure: A Cloud Incidents Perspective," *ESEC/FSE*, 2023. [^Zeng+,ICSE2023]: Zhengran Zeng, Yuqun Zhang, Yong Xu, Minghua Ma, Bo Qiao, Wentao Zou, Qingjun Chen, Meng Zhang, Xu Zhang, Hongyu Zhang, Xuedong Gao, Hao Fan, Saravan Rajmohan, Qingwei Lin, Dongmei Zhang, "TraceArk: Towards Actionable Performance Anomaly Alerting for Online Service Systems," *ICSE-SEIP*, 2023. [^Iwahori,SRENEXT2023]: 岩堀総平 (GREE), "Runbookに何を書き、どのようにアラートを振り分けるか？," *SRE NEXT 2023 / SpeakerDeck*, 2023. [^Voutsas+,CSCN2023]: Fotios Voutsas, John Violos, Aris Leivadeas, "Filtering Alerts on Cloud Monitoring Systems," *IEEE CSCN (JCC)*, 2023. [^Ikeda,SRENEXT2023]: 池田将士, "Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵," *SRE NEXT*, 2023. [^Bhukar+,ICSE2024]: Karan Bhukar, Rohan Arora, Harshit Kumar, Ruchi Mahindru, Seema Nagar, Amit Paradkar, Pooja Aggarwal, "Dynamic Alert Suppression Policy for Noise Reduction in AIOps," *ICSE-SEIP*, 2024. [^Yu+,CCGrid2024]: Zhaoyang Yu, Qianyu Ouyang, Changhua Pei, Xin Wang, Wenxiao Chen, Liangfei Su, Huai Jiang, Xuanrun Wang, Jianhui Li, Dan Pei, "AlertRCA: Causality Enhanced Graph Representation Learning for Alert-Based Root Cause Analysis," *IEEE/ACM CCGRID*, 2024. [^Chen+,FSE2025]: Jia Chen, Yuang He, Peng Wang, Xiaolei Chen, Jie Shi, Wei Wang, "Alert Summarization for Online Service Systems by Validating Propagation Paths of Faults," *FSE* (ACM SIGSOFT), 2025. [^Yang+,SIGCOMM2025]: Bo Yang, Huanwu Hu, Yifan Li, Yunguang Li, Xiangyu Tang, Bingchuan Tian, Gongwei Wu, Jianfeng Xu, Xumiao Zhang, Feng Chen, Cheng Wang, Ennan Zhai, Yuhong Liao, Dennis Cai, Tao Lin, "SkyNet: Analyzing Alert Flooding from Severe Network Failures in Large Cloud Infrastructures," *SIGCOMM*, 2025. [^Papapanagiotou+,GCPBlog2026]: Ioannis Papapanagiotou, Stevan Malesevic, Chris Heiser, Ruslan Meshenberg, "AI in SRE: Where Google is Deploying Agentic AI to Improve Operations," *Google Cloud Blog*, 2026. [^Shan+,DatadogBlog2026]: Daniel Shan, Tristan Ratchford, "Building Bits AI SRE: Autonomous Incident Investigation Agent," *Datadog Tech Blog*, 2026.