DatabricksがAIを活用してインシデント調査を迅速化する方法

前回のブログ記事では、DatabricksがAIを使用して数千のデータベースをデバッグする方法をご紹介しました。今回は、その続きとして、当社のエンジニアがAIを活用し、70以上のリージョンと3つのクラウドにまたがる1,500以上のKubernetesクラスターで、数百のマイクロサービスをどのように運用しているかを探ります。

午前2時に障害が発生したとき、オンコールエンジニアは「何が変わったのか？」という1つの問いに素早く答える必要があります。

AI SREは、インシデントが発生するとすぐに調査を開始する、AI搭載のデバッグエージェントです。スタック全体からのシグナルを関連付け、エンジニアを根本原因分析へと導きます。

本記事では、AI SREの誕生につながったデバッグの歩み、その背後にあるアーキテクチャ、そしてインシデント発生時にLLM搭載システムを信頼できるものにするために私たちが従ったエンジニアリング原則について説明します。

AI SRE導入前：午前2時の体験

よくあるオンコールの呼び出しを想像してみてください。顧客向けのAPIでレイテンシーのスパイクが発生します。エンジニアは目を覚まし、いつものお決まりの作業を開始します：

• ダッシュボードやリージョン全体でサービスメトリクスを検査する。
• 関連性があり、かつ異常なエラーがないかログを検索する。
• デプロイ、依存関係の変更、フィーチャーフラグの更新を確認する。
• クラウド、ネットワーク、共有プラットフォームの健全性を確認する。
• 適切なランブックを見つけて実行する。

これらのワークフローはそれぞれ単体ではうまく機能しますが、デバッグのワークフロー、つまりそれらのシグナルを相互に関連付ける作業は、完全にエンジニアの頭の中に委ねられています。経験豊富なエンジニアであれば、以前にそのパターンを見たことがあるため、数分で行うことができます。一方、経験の浅いエンジニアは数時間を費やすか、他の誰かにエスカレーションすることになります。

ツール自体が主な問題ではありませんでした。SLAに対応するオンコールエンジニアに、シグナルを関連付ける負担がのしかかっていたのです。

技術ではなく、顧客から始める

私たちはエージェントの構築から始めたわけではありません。人々がデバッグする様子を観察することから始めました。

数週間にわたり、数十のチームのオンコールエンジニアにインタビューを行い、彼らのデバッグジャーニーをエンドツーエンドでマッピングしました。ポストモーテム（事後分析書）や調査ドキュメントを読み込みました。そして、「どこに時間を費やし、どこで行き詰まっているのか？」というシンプルな質問を投げかけました。

一貫して3つのパターンが浮かび上がりました：

• コンテキストの収集にほとんどの時間が費やされていた。エンジニアの目の前に適切なシグナルが揃えば、実際の「なるほど（根本原因の特定）」の瞬間は多くの場合迅速でした。しかし、それらのシグナル（適切なメトリクス、適切な時間枠、関連するデプロイ、変更されたアップストリームの依存関係など）を収集することに、調査時間の60〜80%が費やされていました。
• 知識が偏っていた。どのチームにも、システムがどのように失敗するかを「熟知している」エキスパートが数人いました。これらのエキスパートが不在のとき、調査は劇的に遅れました。ランブックは存在していましたが、古くなっていたり不完全であったりすることが多く、新しい障害モードには対応できませんでした。
• プラットフォームの健全性は、問題が発生するまで見えなかった。多くのインシデントは、クラウドプロバイダーやネットワークの停止といった大規模なインフラの問題、あるいは認証（Auth）のような重要なシステムの障害に起因していました。しかし、アプリケーションレイヤーでデバッグを行うエンジニアには、それらのシグナルを簡単に確認する方法がなかったため、問題が下位のインフラレイヤーにあることに気づく前に、アプリケーションレベルの仮説を追及することに時間を費やしていました。

デバッグを、再現可能な一連の調査ステップとそれに続くエキスパートの判断として認識すると、AIエージェントがその作業を加速できることが明らかになりました。しかし、単一のチームだけで、すべてのサービス、シグナル、障害モードを理解するエージェントを構築することは不可能です。コンテキストの収集、ツールやランブックの実行、エビデンスの関連付けといった共通のビルディングブロックを処理しつつ、各チームが独自の運用知識で拡張できる共有プラットフォームが必要でした。問いは、「デバッグを自動化できるか？」から「より迅速で情報に基づいた診断と解決を実現するために、すべてのチームにAI搭載プラットフォームをどのように提供するか？」へと移行しました。

AI SREのご紹介

AI SREは、インシデント発生時に開始される「自動トリアージ」と、オンコールエンジニアが仮説を検証し追加のエビデンスを要求できる「インタラクティブな調査」という、相互に補完し合う2つの体験をサポートします。

インシデント発生時の自動トリアージ

インシデントが発生すると、エンジニアがノートPCを開くよりも前に、AI SREが即座に起動します。3つの調査トラックを並行して立ち上げ、補完的なエビデンスを収集して初期評価を作成します：

プラットフォームの健全性チェックは、サービスが実行されている環境を評価します。

• 基盤となるクラウドインフラストラクチャは健全か？
• 該当するリージョンでネットワークの問題が発生していないか？
• アップストリームの依存関係（データベース、メッセージキュー、共有サービス）でパフォーマンス低下が発生していないか？

これだけでも、多くの無駄な調査を排除できるため、エンジニアがアプリケーションコードのデバッグに30分を費やした挙句、根本原因が大規模なインフラの問題だったと気づくような事態を防ぐことができます。

サービスレベルの分析は、影響を受けたサービスとその直接的な依存関係に関するログ、メトリクス、トレースを取得します。最近のデプロイや設定変更を調査します。単に「CPU使用率が高い」だけでなく、「午前2時47分にCPUが3倍に急上昇。これは処理パイプラインのバッチサイズを変更したデプロイと一致している」といったように、サービスのベースライン動作に対する異常を特定します。

ランブックの実行において、AI SREはチーム固有のペルソナを想定します。チームは、ドメインエキスパートが実行するチェック、監視するしきい値、講じる緩和策などのデバッグ手順をコード化します。チームは「スキル」を使用して、既存のランブックをエージェント型ランブックに変換できます。これらのスキルは、コードベース、オブザーバビリティデータ、過去のインシデント履歴を活用して、ランブックの正確性とコンテキスト認識を高めます。その後、オンコールエンジニアに代わってこれらのステップを実行し、ドメインエキスパートが行うのと同様の調査を、数分ではなく数秒で実行します。

エンジニアがインシデントの詳細を初めて読む頃には、AI SREはすでに豊富な診断サマリーを作成しています。何が壊れたのか、何が変わったのか、チームのランブックが何をチェックするよう指示しているのか、すべてのシグナル、関連性、次のステップが1つのビューにまとめられています。

より深い調査のためのインタラクティブなデバッグ

すべての調査が自動トリアージで終わるわけではありません。根本原因が微妙な場合や、エンジニアが仮説を検証したい場合もあります。AI SREのUIは、エンジニアが自然言語で追加の質問をしたり、追加のシグナルを要求したり、特定の時間枠やコンポーネントを掘り下げたりできるインタラクティブなデバッグ環境を提供します。

ここで、構造化された健全性チェックと対話型AIの組み合わせが威力を発揮します。エンジニアは「このアラートの10分前のKafkaコンシューマーラグに何か異常はありましたか？」と尋ねるかもしれません。AI SREは関連するメトリクスを取得し、インシデントのタイムラインに重ね合わせて、検出した内容を説明します。

デバッグのための階層型アーキテクチャ

顧客インタビューから得た最大のインサイトは、デバッグは単一の問題ではなく問題のスタックであり、それらを解決するには意図的な抽象化が必要であるということでした。私たちはAI SREを階層型プラットフォームとして設計しました。各レイヤーが明確な責任を持ち、その上のレイヤーはより高レベルの関心事に集中できるようになっています。

プリミティブは基盤を形成します。これは、すべての調査が最終的に依存する生の運用データです。メトリクス、アラート、ログ、リリース情報、コードのプリミティブはすでに存在していますが、インシデント発生時にこれらにアクセスするには、5つの異なるクエリ言語を使用する5つの異なるツールの間を行き来する必要がありました。プリミティブレイヤーはこれらのシステムを置き換えるものではなく、それらを信頼できる唯一の情報源として認識します。

APIレイヤーはプリミティブを利用し、基盤となるデータへの制御された統一的なアクセスを提供します。すべてのデバッグツールがログやメトリクスストアなどのデータソースに直接クエリを実行するのではなく、認証、レート制限、データ正規化を処理する目的別のAPI（Observability API、Deployment API、Alerts API）を構築しました。これが、「生のインフラ」を「デバッグ可能なインフラ」に変換するレイヤーです。また、基盤となるシステムを入れ替えても、その上にあるデバッグツールが破損することはありません。

Core Engineは、インテリジェンスが宿る場所です。ボットフレームワークはデバッグワークフローを構築するためのオーケストレーションレイヤーを提供し、エンジンは並列実行、結果の相関関係、LLMを活用した統合のメカニズムを処理します。これは自社開発のボットが動作するプラットフォームですが、重要なのは、独自のボットを構築したいすべてのチームが利用できるプラットフォームでもあるということです。

Application Layerは、実際にデバッグが行われる場所です。ここで、プラットフォームレベルのインシデントトリアージボットが動作します。また、サードパーティのAIツールをプラグインして、すべてをゼロから再構築することなく、補完的な機能を提供することもできます。

この分離により、中央で維持されるワークフローとチームが所有するランブックの両方をサポートしながら、データアクセスとオーケストレーションを独立して改善できます。

非決定論的な世界で信頼性を構築する

信頼がすべてであるインシデント対応において、LLMを活用したエージェントの信頼性を十分に高めるには、意図的なエンジニアリングが必要でした。いくつかの原則が私たちの指針となりました。

オープンエンドな推論の前の構造化されたチェック。 AI SREは、まず決定論的なプラットフォームのヘルスチェックとランブックのステップを実行します。LLMレイヤーは結果を統合して説明しますが、データ収集はモデルの判断に委ねられません。

ブラックボックスな回答よりも透明性を。 AI SREが提示するすべての結論は、特定のメトリクス、ログ行、デプロイの差分など、基礎となる証拠にリンクしています。エンジニアは単に信頼するだけでなく、推論を検証できます。オンコールのエンジニアは監査できない推奨事項に基づいて行動することはないため、これは譲れない条件でした。

段階的な機能縮小（グレースフルデグラデーション）。 AI SREが確信を持って根本原因を特定できない場合は、その旨を明示し、収集した証拠を関連性順に整理して提示します。限界について正直な部分的な調査は、ハルシネーションによる診断よりもはるかに有用です。

インパクト

AI SREは現在、Databricks全体の150以上のチームをサポートしており、週に250人以上の有効ユーザーが毎日2,000回以上の調査を実行し、数時間のデバッグ時間を節約しています。ローンチ以来、好意的なフィードバックをいただいています。

「ストレージプラットフォームチームは、トリアージをAI SREに大きく依存しています。これは私の調査を先導してくれます。アラートを開く前に、エージェントがシグナルを関連付け、初期の根本原因分析を作成してくれます。複数のチームが日常業務にエージェントワークフローを組み込める、真に汎用的なデバッグプラットフォームを構築してくれたチームに感謝します。」—Gaurav Garg, Sr. Staff Engineer

「AI SREが登場する前は、インシデントの最初の段階は、ダッシュボード、時間枠、フリート全体のフィルターなどのコンテキストの組み立てでした。現在では、関連するコンテキストが1つの場所に集まり、すでにアラートやインシデントにスコープされています。エージェントの言葉をそのまま信じる必要はありません。証拠は調査に組み込まれており、ワンクリックで事前フィルタリングされた基盤ツールが開き、自分で検証できます。」—Himanshu Mishra, Senior Engineer

「AI SREは、メトリクス、ログ、依存関係の健全性を統合し、インシデントトリアージを加速し、根本原因をより早く表面化させることで、インシデント対応を変革し、企業全体のMTTRを削減しました。」—Adama Kone, Manager - NOC Team

最も重要な成果は、エンジニアの判断に取って代わることではありませんでした。調査のための、より迅速で証拠に裏付けられた出発点を提供することでした。

学んだこと

AI SREの構築から得られた3つの教訓：

チームに専門知識を所有させる。 すべてのチームのドメイン知識をエンコードしようとする中央集権的なエージェントは、常に古く、脆弱になります。エージェントランブックをチームが所有および維持する構成可能なプリミティブにすることで、プラットフォームがボトルネックになることなく、成長するにつれて賢くなるプラットフォームにAI SREを変換しました。

モデルを最適化する前にコンテキストレイヤーを構築する。 私たちは、プロンプトエンジニアリングよりも、エンジニアが実際にインシデントをどのように調査しているかをマッピングすることに多くの時間を費やしました。問題を理解するためのその先行投資は、私たちが正しいもの、つまり、オブザーバビリティシステムにボルトで固定されたチャットボットという明白なものではなく、コンテキストを組み立てて既知のチェックを実行するエージェントを構築したことを意味します。

追跡可能な証拠を通じて信頼を獲得する。 オンコールのエンジニアはプレッシャーの下で作業しており、誤った手がかりを追いかける余裕はありません。AI SREが行うすべての推奨事項は、追跡可能な証拠によって裏付けられています。この透明性こそが、懐疑的だった初期の採用者を日常的なユーザーに変えたのです。

ガードレールは人よりもエージェントにとって重要です。 エージェントにオブザーバビリティデータへのアクセスを許可することは、単にアクセスを開放するだけでなく、APIレイヤーを再設計することを意味しました。エージェントは人間とは異なる方法でクエリを実行します。彼らはエンドポイントにバースト的にアクセスし、並列でチェックを実行し、疲れたり自主的に引き下がったりしません。ビジネスに不可欠なアラートや監視を支えるインフラを停止させることなく、エージェントが迅速に動作できるように、ガードレールを組み込む必要がありました。

今後の展望

今日のAI SREは、インシデント対応の調査フェーズ、つまり何がなぜ起こったのかを理解することに焦点を当てています。自然な次のステップは、単に問題を診断するだけでなく、エンジニアが適切な是正措置を安全に講じられるよう支援する、ガイド付きの緩和策へと拡張することです。

また、インシデント間の学習にも投資しています。過去のインシデントのパターンを使用して将来の診断を改善し、ページングされる前に繰り返し発生する問題を表面化させ、チームがシステム的な信頼性のギャップを特定できるようにします。

チームに加わる

今後を見据え、AIが本番システムをどのように形成し、複雑なインフラをいかに容易に感じさせることができるか、その限界を押し広げ続けることに興奮しています。次世代のAI搭載の社内プラットフォームの構築に情熱をお持ちの方は、ぜひ私たちに加わってください！

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事