インシデント相関分析 - L0 カリキュラム

ストーリー

田

田中VPoE

異常検知、アラート設計、AIOpsの基盤ができた。最後のピースは「インシデント相関分析」だ。TaskFlow社のインシデントデータを見ると、46%が複数チーム関与のインシデントで、その原因特定に平均4時間かかっている

あなた

チームをまたぐインシデントが最も困難ですよね。どのサービスが根本原因か分からない

あ

田

田中VPoE

その通りだ。分散システムではインシデントの「症状」が最初に表れる場所と「原因」がある場所が異なることが多い。API Gatewayでエラーレートが上昇しているが、根本原因はデータベースのコネクションリークだった、というケースだ

あなた

メトリクス・ログ・トレースの3本柱を相関させて追跡するということですね

あ

田

田中VPoE

それに加えて「時間的相関」「トポロジカル相関」「変更相関」の3つの観点で分析する。これらを組み合わせたインシデント相関分析の手法と、組織的なインシデント対応プロセスを設計する

インシデント相関分析の3つの観点

観点の全体像

観点	定義	問い	ツール
時間的相関	異常イベントの発生時刻の相関	「何が最初に起きたか」	時系列分析、イベントタイムライン
トポロジカル相関	サービス依存関係に基づく相関	「影響はどう伝播したか」	サービスマップ、トレース分析
変更相関	デプロイ/設定変更との時間的相関	「何が変わったか」	デプロイ履歴、設定変更ログ

時間的相関分析

イベントタイムラインの構築

ステップ	アクション	ツール
1	インシデント発生前後の全イベントを収集	ログ集約、メトリクスクエリ
2	時系列に沿ってイベントを並べる	イベントタイムライン
3	「最初の異常」を特定する	時間的逆追跡
4	因果関係の仮説を立てる	相関分析

実例: TaskFlow社のインシデント分析

インシデントタイムライン:

14:30:00  Payment Service: DBコネクション数が緩やかに上昇開始
14:32:15  Task Service: v2.15.3 デプロイ完了
14:33:00  Task Service: DBコネクション数が急増（通常の3倍）
14:33:30  Database: アクティブコネクション数が上限の90%到達
14:34:00  Task Service: レイテンシP99が220ms→1500msに上昇
14:34:15  Payment Service: DBコネクション取得タイムアウト発生
14:34:30  API Gateway: エラーレートが0.02%→2.5%に上昇 ← アラート発報
14:35:00  ジャーニーSLO「タスク作成」: 違反検知

根本原因: Task Service v2.15.3 のコネクションリーク
  → DBコネクションプール枯渇
  → Payment Service（同じDB利用）も影響を受ける
  → API Gateway経由でユーザーにエラーが返る

発見のポイント:
  - アラートはAPI Gatewayで発報（症状の場所）
  - 根本原因はTask Serviceのデプロイ（原因の場所）
  - 時間的相関で14:32のデプロイと14:33の異常開始を結びつける

トポロジカル相関分析

サービスマップを活用した影響伝播分析

分析手法	説明	効果
上流追跡	エラーが発生しているサービスの依存先を確認	下流の根本原因を特定
下流追跡	障害サービスに依存している上流を確認	影響範囲の把握
共通依存分析	複数サービスが同時に障害の場合、共通の依存先を確認	共有リソース障害の検出

分散トレースによる相関分析

分析タイプ	手法	適用場面
エラートレース分析	エラーステータスのトレースを抽出し、失敗スパンを特定	リクエスト単位の障害原因特定
レイテンシ分析	遅延トレースを抽出し、ボトルネックスパンを特定	パフォーマンス劣化の原因特定
比較分析	正常時と異常時のトレースパターンを比較	異常パターンの特徴抽出

分散トレース相関分析の例:

正常トレース:
  Gateway(5ms) → Auth(3ms) → Task(15ms) → DB(8ms)
  合計: 31ms

異常トレース:
  Gateway(5ms) → Auth(3ms) → Task(1200ms) → DB(1150ms)
  合計: 1358ms

差分分析:
  DB応答時間: 8ms → 1150ms（144倍）
  → DBレイヤーに問題があることが明確
  → DBのコネクション数、クエリ実行計画を確認

変更相関分析

変更イベントの統合管理

変更タイプ	データソース	相関の重要度
アプリケーションデプロイ	CI/CDパイプライン（GitHub Actions等）	最高
インフラ変更	Terraform、CloudFormation	高
設定変更	フィーチャーフラグ、環境変数	高
依存サービス変更	外部API、クラウドサービスのメンテナンス	中
トラフィック変動	マーケティングイベント、メディア掲載	中

変更イベントの可視化

変更とメトリクスの統合ビュー:

エラーレート (%)
3.0 │                              ╱╲
2.5 │                            ╱    ╲
2.0 │                          ╱        ╲
1.5 │                        ╱            ╲
1.0 │                      ╱                ──
0.5 │──────────────────╱
0.0 │─────────────────────────────────────────
    14:00  14:15  14:30  14:45  15:00  15:15

    ▼ 14:32 Task Service v2.15.3 デプロイ
    ▼ 14:45 Task Service v2.15.2 ロールバック

→ デプロイ→エラー上昇→ロールバック→エラー収束
  の因果関係が視覚的に明確

組織的なインシデント対応プロセス

インシデントコマンドシステム

役割	責任	誰が担当するか
インシデントコマンダー（IC）	全体の指揮、意思決定、コミュニケーション	オンコールSRE or 自動アサイン
テクニカルリード（TL）	技術的な調査・対応の指揮	障害サービスのテックリード
コミュニケーションリード（CL）	ステークホルダーへの状況報告	SREリード or マネージャー
スクライブ	タイムラインの記録	自動化 + 手動補完

インシデント対応と相関分析の統合フロー

インシデント検知（自動）
  │
  ├── 1. 自動相関分析の実行（2分以内）
  │     ├── 時間的相関: 直近30分のイベントタイムライン生成
  │     ├── トポロジカル相関: 影響を受けたサービスの特定
  │     └── 変更相関: 直前のデプロイ/設定変更の検出
  │
  ├── 2. インシデントチャネル自動作成（Slack）
  │     ├── 相関分析結果の自動投稿
  │     ├── 関連ダッシュボードリンク
  │     ├── ランブックリンク
  │     └── 影響を受けるチームの自動メンション
  │
  ├── 3. 人的対応
  │     ├── ICが対応方針を決定
  │     ├── TLが根本原因調査を指揮
  │     └── CLがステークホルダーに状況報告
  │
  └── 4. ポストモーテム
        ├── 自動生成されたタイムラインをベースに作成
        ├── 根本原因と寄与要因の分析
        └── 改善アクションの策定

ポストモーテムと可観測性改善のフィードバック

ポストモーテムの出力	可観測性への反映
「アラートが遅すぎた」	アラート閾値の見直し、バーンレートアラートの追加
「根本原因の特定に時間がかかった」	トレースカバレッジの拡大、相関IDの追加
「影響範囲の把握が困難だった」	サービスマップの更新、依存関係の可視化強化
「同じ障害が再発した」	異常検知パターンの追加、自動修復の検討
「変更との因果関係の確認に時間がかかった」	デプロイマーカーの追加、変更ログの統合

相関分析の高度化

メトリクス・ログ・トレース相関の実装

相関タイプ	実装方法	効果
メトリクス→トレース	メトリクスのスパイク期間のトレースを自動検索	異常の具体的な原因パスを特定
トレース→ログ	トレースIDでログを検索	リクエスト単位のエラー詳細を確認
ログ→メトリクス	エラーログの集計をメトリクスとして表示	エラーの傾向把握
全体相関	共通のトレースID/スパンIDで3シグナルを横断検索	End-to-Endの因果関係追跡

相関分析の精度を高めるデータ品質要件

要件	説明	優先度
統一されたタイムスタンプ	全テレメトリデータがNTPで同期されたタイムスタンプを持つ	最高
共通の相関ID	トレースID、スパンIDが全サービスで伝播される	最高
統一されたサービス名	service.name属性が全テレメトリで一貫している	高
デプロイマーカー	デプロイイベントがメトリクス上にアノテーションされる	高
構造化ログ	ログがJSON形式で、トレースIDフィールドを含む	高

「インシデント相関分析の精度は、日頃のデータ品質への投資で決まる。障害が起きてから”データが足りない”と気づくのでは遅い。相関IDの伝播、構造化ログ、デプロイマーカー — これらの”地味な仕込み”がインシデント時に劇的な効果を発揮する」 — 田中VPoE

まとめ

ポイント	内容
3つの相関観点	時間的相関、トポロジカル相関、変更相関を組み合わせて根本原因を特定
分散トレース	エラートレース、レイテンシ分析、比較分析でリクエスト単位の原因追跡
組織的対応	インシデントコマンドシステムと自動相関分析の統合
データ品質	相関ID、統一タイムスタンプ、構造化ログが分析精度の基盤

チェックリスト

時間的相関、トポロジカル相関、変更相関の3つの観点を理解した
分散トレースを活用した相関分析の手法を理解した
インシデントコマンドシステムと相関分析の統合フローを理解した
データ品質要件と相関分析精度の関係を理解した

次のステップへ

次は演習です。ここまで学んだ異常検知、アラート設計、AIOps、インシデント相関分析を統合して、TaskFlow社の予防的インシデント検知システムを設計しましょう。

推定読了時間: 30分