# Adaptive Paging ## 定義 Adaptive Paging は、分散トレーシングの因果関係と OpenTracing セマンティック規約を活用して、アラートの通知先を動的に決定するアラートハンドラである（[[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That|Mineiro SREcon19 EMEA]]）。症状ベースアラーティングの「SN 比は高いが通知先が固定される」という限界を解消し、問題の根本原因に最も近いチームへ通知することで、クリスマスツリー効果（全サービスがアラートを発火し全チームが呼び出される現象）とアラート爆撃（症状を所有するチームへの負荷集中）の両方を回避する。 ## アルゴリズム 1. アラーティングルールで SLO 閾値を超過した症状シグナルスパン（例: `place_order` in `checkout-service`）から開始する。 2. そのスパンの全子スパンのタグを検査する。 3. `error=true` のパスを追跡する。 4. 子スパンがなくなるまで再帰的に繰り返す。 5. 最深の `error=true` スパンを持つサービスの運用チームへ通知する。 複数のエグゼンプラ（SLO 違反トレースの標本）を取得し、各エグゼンプラに対して上記の走査を行い、根本原因候補にスコアを付与する。最高スコアのサービスを最も可能性の高い根本原因として通知先に選ぶ。 ## 前提条件 - **分散トレーシングの計装**: OpenTracing（現 [[OpenTelemetry]]）のセマンティック規約でサービスが計装されていること。 - **必須タグ**: `error`（操作の失敗フラグ）、`peer.service`（リモートサービス名）、`span.kind`（client/server）、`component`（ソフトウェアパッケージ）。 - **サービスとエスカレーション先のマッピング**: どのサービスがどのチームのオンコールに対応するかのマッピング。 ## 横断的知見 - **Adaptive Paging は [[アラート管理]] の介入点分類に新たな層を追加する**: 本 wiki の [[アラート管理]] は抑制・フィルタリング・集約・ランキング・RCA・監視評価・調査準備の 7+ 介入点を整理してきた。Adaptive Paging はこれらとは異なる「通知先ルーティング」（dispatch routing）という介入点を追加する。既存の介入点がアラートの件数・重要度・内容を操作するのに対し、Adaptive Paging はアラートの宛先を操作する。件数を 1 に維持したまま宛先だけを変える点で、抑制やフィルタリングとは直交する介入である。(Source: [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]], [[アラート管理]]) - **「アラートのみで RCA」系統と「トレースで根本原因を特定してから通知」系統は相補的**: [[AlertRCA]]（Yu+ CCGRID2024）や [[ESRO]]（Chakraborty+）がアラートイベントのみからグラフ表現学習で根本原因を推定するのに対し、Adaptive Paging は分散トレースのスパンツリーをリアルタイムに走査して根本原因を推定する。前者はトレース基盤が未整備でも動作し、後者はトレースが計装済みであれば個別リクエストの因果連鎖を直接辿れる。両者の入力が異なるため、トレースカバレッジが部分的な環境では alert-based RCA をフォールバックとして併用する設計が考えられる。(Source: [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]], [[@2024__CCGRID__AlertRCA - Causality Enhanced Graph Representation Learning for Alert-Based Root Cause Analysis]]) - **FSF のスパンツリー動的因果推論と Adaptive Paging のトレースウォーキングは同型のアルゴリズムである**: [[@2022__IEEE CLOUD__Localizing and Explaining Faults in Microservices Using Distributed Tracing|FSF（IEEE CLOUD 2022）]] は「エラーのある子スパンを持つスパンは根本原因候補から除外する」動的因果推論で loss=0 を達成した。Adaptive Paging（2019）は 3 年早くほぼ同一のアルゴリズム（`error=true` の子スパンを再帰的に辿り最深を根本原因とする）を実運用のアラートルーティングに適用した。FSF が学術的に形式化した手法を、Mineiro が実務的に先行実装していたことになる。ただし FSF はログとの異種テレメトリ融合で「なぜ」を補完するのに対し、Adaptive Paging は「どこ」の特定後に通知先決定で止まる。(Source: [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]], [[@2022__IEEE CLOUD__Localizing and Explaining Faults in Microservices Using Distributed Tracing]]) - **Adaptive Paging は [[Quality of Alerts]] の handleability 軸を「通知先の適切さ」で操作する**: Yang+ DSN2022 の QoA 3 軸のうち handleability（処理容易性）は target と presentation に依存する。Adaptive Paging は presentation を変えず target（通知先チーム）を動的に変更することで、受信者が問題に直接対処できる確率を上げる。これは handleability の操作として読める。(Source: [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]], [[@2022__DSN__Characterizing and Mitigating Anti-patterns of Alerts in Industrial Cloud Systems]]) ## 課題と限界 - **複数エラーパス**: 複数の子スパンが `error=true` の場合、スコアリングヒューリスティックで優先順位を付けるが、最悪の場合は複数チームへ通知する。 - **計装の欠落**: サービスが計装されていない場合、トレースが途切れる。`peer.service` + `span.kind=client` で依存先を推定するフォールバックを使う。 - **サーキットブレーカー**: 開放時にトレースが途切れるが、`peer.service` タグで依存先を推定可能。 - **サービスとオンコールのマッピング**: 全サービスがオンコール体制を持つわけではない。マッピングが無い場合は最も近い親チームにフォールバックする。 - **レイテンシへの適用**: 可用性（`error=true`）に加えてレイテンシにも適用可能だが、レイテンシの場合はより複雑になる（口頭説明）。 - **定量的評価の欠如**: MTTR 改善率や偽陽性率などの定量的成果は報告されていない。 ## 未解決の問い - Adaptive Paging のスコアリングアルゴリズムの詳細は公開されていない。複数エラーパスへの対処として、エグゼンプラ数 × パスごとの出現頻度以外にどのような特徴量が有効か。 - 計装カバレッジが部分的な環境で Adaptive Paging の精度はどの程度劣化するか。FSF が Train-Ticket（41 サービス完全計装）で loss=0 を達成したのは理想条件下であり、計装欠落率 vs 根本原因特定精度の定量関係は未報告。 - Adaptive Paging と alert-based RCA（AlertRCA・ESRO）をフォールバック構成で併用した場合の設計パターンは未報告。 - Google の autonomous AI alert handlers（[[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]]）は Adaptive Paging と同じ「通知先の動的決定」機能を内包しているか。 - OpenTelemetry のセマンティック規約は OpenTracing から後方互換だが、Adaptive Paging の実装が依存する具体的なタグ（`peer.service` 等）は OpenTelemetry でどのように変遷したか。 ## 関連 - 親概念: [[アラート管理]]、[[アクショナブルアラート]] - 技術基盤: [[分散トレーシング]]、[[OpenTelemetry]] - 評価軸: [[Quality of Alerts]]（handleability 軸との接続） - 類似手法: [[FSF]]（スパンツリー動的因果推論） - 人物・組織: [[Luis Mineiro]]、[[Zalando SE]] - ソース: [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]] ## 出典 - [[@2019__SREcon19 EMEA__Are We All on the Same Page - Lets Fix That]]（p.20-21 定義、p.25 セマンティック規約、p.31 トレースウォーキングアルゴリズム、p.33 結果、p.37 課題）