# Spike Detection in Alert Correlation at LinkedIn ## 概要 [[Nishant Singh]]（[[LinkedIn]] シニア SRE、Production-SRE チーム）が SREcon21 Americas で発表したスライド。数千のマイクロサービスで構成される LinkedIn の本番環境において、障害発生時にアラート相関システムが推奨する根本原因候補から「一時的スパイク（統計的外れ値だが障害ではない）」を分離する手法を提案する。修正 Z スコア（Modified Z-Score）と MAD（中央絶対偏差）を用いた単純な統計手法を採用し、ML を導入せずにトイルを 30–40% 削減した実践報告である。 ## 主要メッセージ - LinkedIn のアラート相関（Alert Correlation）システムは、Callgraph からサービス間依存を取得し、Autoalerts からアラートを取り込み、相関結果を Slack・Iris・Web UI へ通知する（p.11）。 - 障害時に大量のサービスが同時にアラートを発火するため、根本原因の特定は「干し草の中の針」問題となり、誤エスカレーションが深夜のページャ疲労を引き起こす（p.8–9）。 - スパイク（一時的なレイテンシ急増）と持続的な障害を区別するため、Iglewicz & Hoaglin の修正 Z スコアを採用した（p.18–19）。 - 判定ルール（p.24）: (a) スパイクが検出されなければ REAL ALERT、(b) 5 個の連続スパイクデータポイントかつ全グラフの約 70% が同傾向なら REAL ALERT、(c) 70% 未満なら SPIKE。 - 約 5 日間の評価で 193 件の推奨中 122 件（63.6%）が REAL ALERTS、71 件（36.4%）が SPIKES、偽陽性率は 1% 未満（p.28）。 ## 視覚的に重要な図表 **p.5 LinkedIn スタックアーキテクチャ** ![[_attachments/srecon21_slides_singh/page-005.png]] ユーザーリクエストが Internet → Border Router → EDGE（IPVS → ATS）→ DATA CENTER へ至る経路と、Stickyrouting Service の位置を示す。 **p.11 アラート相関フレームワーク** ![[_attachments/srecon21_slides_singh/page-011.png]] Autoalerts からのアラート取り込みと Callgraph からのサービス/エンドポイント依存関係取得を AC Engine が統合し、相関結果を User・Iris・Slack・Web UI に配信するアーキテクチャ。 **p.12 Slack 通知の実例** ![[_attachments/srecon21_slides_singh/page-012.png]] Alert Correlation の Slack 推奨メッセージ。Possible Root Cause、Confidence（0.69）、Severity（0.76）、Impacted Upstreams（10 件）と影響を受けたサービス一覧を表示する。 **p.15 スパイクの可視化** ![[_attachments/srecon21_slides_singh/page-015.png]] 2020-10-20 のレイテンシグラフ。11:00 頃に約 1.2k まで急伸し直後にベースラインへ復帰する典型的なスパイクパターン。 **p.19 修正 Z スコアの数式とグラフ** ![[_attachments/srecon21_slides_singh/page-019.png]] $M_i = 0.6745(x_i - \tilde{x}) / MAD$ の数式と、閾値 ±3.5 を超える外れ値を青点で示すグラフ。Iglewicz & Hoaglin の推奨閾値。 **p.24 判定アプローチ** ![[_attachments/srecon21_slides_singh/page-024.png]] 5 ステップの判定手順。サービスグラフ取得 → Autometrics からデータ取得 → 修正 Z スコア適用 → データ統合 → 判定（スパイクなし=REAL ALERT / 5 連続+70% 同傾向=REAL ALERT / 70% 未満=SPIKE）。 **p.28 評価結果の円グラフ** ![[_attachments/srecon21_slides_singh/page-028.png]] 約 5 日間の 193 件の推奨。REAL ALERTS 122 件（63.6%）・SPIKES 71 件（36.4%）。偽陽性率は 1% 未満。 ## 技術的詳細 ### アラート相関システム（Alert Correlation） LinkedIn の AC Engine は、Autoalerts からアラートを取り込み、Callgraph からサービス間のエンドポイント依存関係を取得し、レイテンシまたはエラー率の高いサービスを根本原因として推定する。推定結果は Confidence と Severity のスコア付きで Slack・Iris（LinkedIn 内製の通知プラットフォーム）・Web UI へ配信される。 ### 修正 Z スコアによるスパイク検知 標準偏差ベースの Z スコアは外れ値自体の影響を受けるため、MAD（中央絶対偏差）ベースの修正 Z スコアを採用する。 - $MAD = \text{median}\{|x_i - \tilde{x}|\}$ — 外れ値に対してロバストな散布度（p.20） - $M_i = 0.6745(x_i - \tilde{x}) / MAD$ — 修正 Z スコア（p.19） - 閾値: $|M_i| > 3.5$ を外れ値と判定（Iglewicz & Hoaglin の推奨） ### 実装上の課題（p.23） 1. 30 分ウィンドウ内で正確なデータポイントが必要 2. 複数メトリクスを扱う必要がある 3. 推奨生成と同時にニアリアルタイムで判定が必要 4. 偽陰性をほぼゼロにしたい ## 口頭説明・補足 transcript から補足される情報: - アラートは**過去 15 日間のメトリクス時系列から標準偏差を導出して**生成される。チームによっては偽陽性回避のために閾値を高く設定しており、歴史的に構成されたアラートがスパイクに起因する偽陽性の原因になっている。 - 70% の閾値は「長期間のイテレーションの末に見つけたスイートスポット」と口頭で説明されており、系統的なパラメータ探索の結果である。 - 偽陰性（真のアラートをスパイクと判定すること）は「絶対に許容できない」としてゼロを目標にする一方、偽陽性（スパイクを真のアラートと判定すること）は「ある程度は許容」としている。この非対称な設計方針がスパイク判定の保守的な閾値に反映されている。 - スパイク検知機能は Slack 推奨に加え、下流クライアント向けに API エンドポイントとしても公開されており、他チームがデータを再利用できる。 - LinkedIn のメトリクスは高度に標準化されているため、Callgraph の構築が容易だったとの説明。 ## 概念・実体への接続 - [[アラート相関]]: 本発表はアラート相関の出力を後段でフィルタリングするアプローチ。相関結果の信頼度を統計的に裏付ける実装例。 - [[異常検知]]: 修正 Z スコアは MAD ベースのロバストな外れ値検知手法であり、ML に依存しない軽量な検知手法の産業実装例。 - [[アラート管理]]: スパイク分離は誤エスカレーション削減の直接的手段。[[AlertGuardian]] のグラフベース denoise とは別アプローチ。 ## 限界・不確実点 - SREcon21 の正確な発表日が不明（2021 年開催、メタデータから年のみ判明）。`date_published` は `2021` とした。 - 評価期間が約 5 日間と短く、長期的な偽陰性率やスパイク/REAL ALERT の比率の安定性は不明。 - Autometrics（LinkedIn 内部メトリクスシステム）の詳細仕様はスライドに記載なし。 - 30 分ウィンドウのデータポイント数やサンプリング間隔の具体値はスライドに記載なし。 - YouTube 動画の音声から Whisper で transcript を取得済み。口頭説明の補足情報は上記「口頭説明・補足」節に反映した。