Atlassianは、マイクロサービス環境におけるインシデントの根本原因分析は、もはや手作業によるレビューだけでは信頼できないと考えている。数百の相互接続されたサービスが複数のリージョンで稼働している場合、1件の障害から大量のメトリクス、ログ、トレースが生成される一方、当番エンジニアは通常、複数の個別ダッシュボードを行き来し、問題の発生源とその伝播経路について頭の中で仮説を組み立てなければならない。
CNCFのブログ記事で、AtlassianのSantosh Balaranganathan、Michael Yoo、James Moessis、James Kieltyka、Jason Lee、Lavender Neeshamは、根本原因分析を自動化するシステムについて説明している。このシステムは仮説生成の自動化を目指しており、対応チームが証拠を手作業で再構成するのではなく、より迅速に検証と修復の段階へ移行できるようにする。
根本原因分析を複数シグナルの相関付け問題へ変換する
この設計は、証拠の3つの層、すなわちシグナルの種類、時間、サービスのトポロジーを結び付けることを中心としている。シグナルにはメトリクス、ログ、トレースが含まれ、時間的な同時性によって関連している可能性のあるイベントを特定し、サービス依存関係グラフによって、障害を開始したサービスと、その後に影響を受けたサービスを区別する。
プロセスは、OpenTelemetryから導出されたサービスマップによって検索範囲を絞り込むことから始まる。プラットフォームの全サービスを分析するのではなく、システムは劣化したユーザー体験の経路上にあるサービスを特定し、通常は数百ではなく数十のサービスからなる範囲を形成する。このマップは、文書上で想定された構造ではなく、本番トラフィックにおける時間区間間の親子関係から抽出された実際の通信を反映している。
監視データから優先順位付き仮説へ
範囲を特定した後、独立したモジュールが各シグナルの種類における異常を検出する。メトリクスでは、AtlassianはRED指標、すなわちリクエストレート、エラーレート、応答時間を監視し、中央値絶対偏差やパーセンタイル範囲などの統計手法を使用する。各異常状態は、強度の値、観測値、そしてそこから逸脱したベースラインを生成する。
分散トレースは、予期しない例外、新たなエラー伝播パターン、特定の区間における応答時間の増加を探すために調査される。ログには埋め込みに基づくクラスタリング技術を適用して意味的に類似したエントリをまとめ、その後、サービスの通常の分布と比較して新しい、またはまれなエラーグループを目立たせる。
すべての検出器は、結果をタイムスタンプ、サービス名、シグナルの種類、重大度、詳細を含む統一スキーマのイベントへ変換する。この層により、相関エンジンは各検出器が状態を検出した方法に依存せずにイベントを分析できる。また、新しい検出器を追加したり、ある統計モデルを機械学習ベースのモデルに置き換えたりする際にも、システム全体を再構築する必要がない。
障害の方向を特定するための時間と依存関係グラフ
エンジンは、通常はプラスマイナス5分に設定可能な時間ウィンドウ内で近接するイベントをまとめる。各グループには時間的整合性のスコアが付与され、イベントが近いほど関連している可能性が高くなる。同じ仮説が数十回重複するのを防ぐため、システムはサービスシーケンスのフィンガープリントを使用し、繰り返される障害チェーンを、再試行回数とともに1つのグループへ統合する。これにより、5分間に47回繰り返された障害パターンを、同一の仮説47件ではなく、1つのパターンとして記述できる。
次にシステムは、最も大きな影響を受けたノード、つまり同システムが「下流ノード」と呼ぶものを特定し、依存関係グラフを逆方向にたどって、それより前に時間的な異常を示したサービスを探す。サービスBがサービスAから呼び出され、Bの問題がAの問題より先に現れた場合、Bは障害の発生源としてより有力な候補となり、Aの問題は後続の影響として扱われる。最終評価では、時間的整合性と伝播経路のスコアを組み合わせて仮説を順位付けする。
結果は、サービスと信頼度のスコアの一覧にとどまらない。各仮説には、疑わしいサービス、伝播経路、各ノードにおける証拠、例えば閾値を超えたメトリクスや障害に関連するトレース番号などに加えて、イベントの順序と特定の発生源が優先された理由を説明する人間向けの記述が含まれる。
この手法が運用チームにとって重要な理由
ここでの実務的な価値は、対応エンジニアを置き換えることではなく、検証可能な仮説に到達するまでの時間を短縮することにある。Atlassianは、根本原因分析エンジンを、より広範なインシデント対応プラットフォームに接続している。このプラットフォームには、障害がユーザーに与えた影響の検出、担当チームの特定、利用可能な証拠に基づいてリリースのロールバックやフィーチャーフラグの無効化などの措置を提案できるインシデントアシスタントが含まれる。また、エンジニアが仮説を受け入れたか、拒否したか、修正したかを記録し、時間の経過とともに重みを改善する。
この経験は、各シグナル向けに複雑な機械学習モデルを構築するよりも、解釈可能な単純な手法から始める方が適切な場合があることを示している。中央値絶対偏差やパーセンタイル範囲などの手法は、多くのメトリクス異常を検出するのに十分だった一方、統計手法があまり適していないログのクラスタリングやトレース構造の分析には機械学習手法が使われた。
しかし、この手法が制約をなくすわけではない。仮説の品質は、監視データの一貫性、サービス依存関係グラフの正確さ、検出器が実際の障害とノイズを区別する能力に左右される。また、信頼度スコアは因果関係の最終的な証拠ではない。そのためAtlassianは、各証拠の出所と、それを結果に結び付ける説明を示すことの重要性を強調している。同社は今後、追加データを要求して仮説を修正できる、言語モデルに基づくオーケストレーションの利用を検討している。ただし、レート制限、隔離された実行環境、証拠の出所を明確に記録するログが必要となる。
certi.newsによる編集部の見解：このアプローチにおける実際の変化は、インシデント分析を個別ツール間の手作業による比較から、シグナル、時間、トポロジーを統合する統一プロセスへ移行することにある。その運用上の成功は、順位付けアルゴリズムだけでなく、解釈可能性、データ品質、フィードバックループに左右される。したがって、完全な根本原因分析の自動化を約束するよりも、モジュール性、重複の排除、証拠の記録の方が、すぐに適用しやすい原則に見える。