Databricks、AI を活用したインシデント調査の加速手法を公開

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

深夜 2 時に何かが障害を起こした場合、オンコール担当者が即座に答えなければならない問いは一つです。「何が変更されたのか？」

「AI SRE」は、インシデント発生と同時に調査を開始する AI 駆動のデバッグエージェントです。スタック全体から信号を関連付け、エンジニアが根本原因分析を行うための道筋を示します。

本稿では、「AI SRE」が形成されるまでのデバッグの歩み、その背後にあるアーキテクチャ、そしてインシデント発生時に LLM 駆動システムを信頼性のあるものとするために私たちが遵循したエンジニアリング原則について解説します。

AI SRE 以前：深夜 2 時の現場

典型的なオンコールアラートを想像してみてください。顧客向け API でレイテンシーの急上昇が発生しました。エンジニアは目を覚ますと、いつもの手順を踏みます。

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

これらのワークフローはそれぞれ単独では問題なく動作しますが、デバッグプロセス、つまりそれらのシグナルを相互に結びつける作業は、エンジニアの頭の中だけで完結しています。経験豊富なエンジニアなら数分で対応できますが、それは過去の類似パターンを知っているからです。一方、経験の浅いエンジニアは数時間を要したり、上級者にエスカレーションしたりすることになります。

ツール自体が主要な問題だったわけではありません。シグナルを結びつける負担は、SLA（サービスレベルアグリーメント）との戦いを強いられているオンコール担当者の肩にかかっていました。

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

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

数週間にわたり、数十チームにわたるオンコール担当者へのインタビューを行い、デバッグのプロセスをエンドツーエンドでマッピングしました。また、事後分析レポートや調査ドキュメントも読み込み、「時間を費やす場所はどこか」「どこでつまずくことが多いか」というシンプルな質問を投げかけました。

その結果、3 つの共通するパターンが浮かび上がりました。

インシデント調査において、最も時間を要するのはコンテキストの収集でした。根本原因を特定する「あ、そうか」という瞬間自体は、エンジニアが適切な信号（メトリクス、時間範囲、関連するデプロイメント、変更された上流依存関係など）を手元に揃えた直後であれば、比較的短時間で済むことが多かったです。しかし、そうした必要な情報を集める作業に調査時間の 60〜80% が費やされていました。

知識の偏りも大きな課題でした。各チームには「システムがなぜ失敗したか」を感覚的に理解している数人のエキスパートが存在しましたが、彼らが利用できないと調査は劇的に遅延しました。ランブック（手順書）は存在していましたが、多くの場合古かったり不十分だったりし、新しいタイプの障害に対しては対応できませんでした。

プラットフォームの健全性は、問題が顕在化するまで見えない状態でした。インシデントの多くは、クラウドプロバイダーやネットワークの広範な停止、あるいは認証（Auth）システムのような重要コンポーネントの故障といった大規模なインフラ上の事象に起因していました。しかし、アプリケーション層でデバッグを行っているエンジニアには、そうした下位レイヤーの信号を確認する簡単な手段がありませんでした。その結果、問題がインフラ層にあると判明するまで、アプリケーションレベルでの仮説検証に時間を浪費してしまうケースが多発しました。

デバッグを反復可能な調査手順と専門家の判断の組み合わせとして捉えたことで、AI エージェントがその作業を加速できることが明確になりました。しかし、すべてのサービス、シグナル、障害モードを理解する単一のエージェントを一つのチームだけで構築することは不可能です。そこで必要となったのは、コンテキストの収集やツールの実行、ランブックの実行、証拠の相関分析といった共通の基盤部分を処理しつつ、各チームが独自の運用知識で拡張できる共有プラットフォームでした。問いは「デバッグを自動化できるか」から、「すべてのチームに、より迅速かつ根拠のある診断と解決を実現する AI 搭載プラットフォームを提供するにはどうすればよいか」という方向へとシフトしました。

AI SRE の紹介

AI SRE は、2 つの補完的な体験をサポートします。1 つはインシデント発生時に始まる自動トリアージ、もう 1 つはオンコールエンジニアが仮説を検証し追加証拠を要求できる対話型調査です。

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

インシデントが発生すると、エンジニアがラップトップを開く前に AI SRE は即座に起動します。3 つの調査トラックを並行して開始し、補完的な証拠を集めて初期評価を生成します。

プラットフォームヘルスチェックでは、サービスが稼働している環境の状態を確認します。

• 基盤となるクラウドインフラは健全ですか？
• 関連するリージョンでネットワークの問題は発生していますか？
• 上流の依存関係（データベース、メッセージキュー、共有サービス）に劣化は見られますか？

これだけで、多くの誤った方向性（レッド・ヘリング）を排除でき、エンジニアがアプリケーションコードのデバッグに 30 分も費やした挙句、根本原因が大規模なインフラの問題だったと気づくという無駄な時間を省けます。

サービスレベル分析では、影響を受けたサービスとその直近の依存関係に関連するログ、メトリクス、トレースを抽出します。最近のデプロイメントや設定変更も調査対象となります。ここでは単に「CPU 使用率が高い」という事実だけでなく、「処理パイプラインのバッチサイズを変更したデプロイと一致して午前 2 時 47 分に CPU が 3 倍に急騰した」など、サービスのベースライン行動に対する異常を検出します。

ランブック実行では、AI SRE がチーム固有の役割を演じます。各チームは、ドメインの専門家が実施するチェック項目や確認すべき閾値、講じるべき緩和措置といったデバッグ手順をコード化しています。これらのスキルを活用すれば、既存のランブックをエージェント型ランブックに変換できます。このスキルはコードベース、観測データ、過去のインシデント履歴を参照し、より精度が高く文脈を理解したランブックを実現します。その後、オンコール担当エンジニアに代わってこれらの手順を実行し、ドメインの専門家が行う調査と同じ内容を数秒で完了させます。

エンジニアがインシデントの詳細を初めて目にする頃には、AI SRE はすでに包括的な診断サマリーを作成しています。「何が壊れたか」「何が変わったか」「チームのランブックでは何をチェックすべきか」——すべての信号、相関関係、次のステップが一つのビューにまとめられています。

対話型デバッグによる深掘り調査

すべてのインシデント調査が自動トリアージで終わるわけではありません。時には根本原因が微妙な場合や、エンジニアが仮説を検証したい場合もあります。AI SRE UI は、エンジニアが自然言語で追加質問を行ったり、必要な信号を要求したり、特定の時間範囲やコンポーネントに深く掘り下げたりできる、対話型のデバッグ環境を提供します。

ここで重要なのは、構造化されたヘルスチェックと会話型 AI の組み合わせが力を発揮する点です。エンジニアは「このアラート発生前の 10 分間に、Kafka コンシューマーのラグに異常はありませんでしたか？」と質問できます。AI SRE は関連するメトリクスを取得し、インシデントタイムライン上に重ね合わせて表示するとともに、発見した内容を解説します。

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

顧客インタビューから得た核心的な洞察は、デバッグは単一の課題ではなく、複数の課題が積み重なったものであるという点です。これらを解決するには、意図的な抽象化が必要です。私たちは AI SRE を、各レイヤーに明確な責任を持たせ、上位のレイヤーがより高次な課題に集中できる階層型プラットフォームとして設計しました。

プリミティブ（Primitives） はその基盤を形成します。これはすべての調査が最終的に依存する生データです。メトリクス、アラート、ログ、リリース情報、コードに関するプリミティブは既に存在しますが、インシデント発生時にこれらにアクセスするには、5 つの異なるツールを行き来し、それぞれ固有のクエリ言語を使用する必要がありました。プリミティブ層はこれらのシステムを置き換えるものではなく、それらを「真実の源」として認識するものです。

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

コアエンジンには知性が宿っています。ボットフレームワークはデバッグワークフロー構築のためのオーケストレーション層を提供し、エンジン自体は並列実行の仕組みや結果の相関付け、LLM を活用した合成処理を担当します。これは自社製ボットが動作するプラットフォームであると同時に、独自のツールを構築したいあらゆるチームにも開放されている共通基盤でもあります。

アプリケーションレイヤーこそが、実際のデバッグが行われる場所です。ここではプラットフォームレベルのインシデントトリアージボットが稼働しています。また、サードパーティ製の 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つの知見：

チームが専門性を自ら持つようにする

あらゆるチームのドメイン知識を一つの集中型エージェントに詰め込もうとすれば、それは必ず古くなり、脆いものになります。そこで私たちは、アジェンティック・ランブック（runbook）を各チームが所有し維持できる「組み換え可能な基本要素」として位置づけました。これにより、AI SRE はプラットフォーム自体がボトルネックになることなく、成長するにつれて賢くなっていくシステムへと進化しました。

モデルの最適化よりも先に文脈層を整備する

私たちが費やした時間は、プロンプトエンジニアリングよりもむしろ、エンジニアが実際にインシデントを調査するプロセスをマッピングすることに多く割かれました。この問題理解への先行投資があったからこそ、私たちは「正しいもの」——つまり、文脈を組み立てて既知のチェックを実行するエージェント——を構築できたのです。もしこれが「 obvious なもの」、すなわち観測性システムにチャットボットを無理やり組み合わせたものであれば、結果は違っていたでしょう。

追跡可能な証拠によって信頼を獲得する

オンコール中のエンジニアはプレッシャーの中で働いており、誤った手がかりを追う時間などありません。AI SRE が提示するすべての推奨事項には、必ず追跡可能な根拠が伴います。この透明性が、懐疑的な初期採用者を日々の利用者へと変えたのです。

エージェントにとってのガバナンスは、人間よりも重要である

エージェントに観測性データへのアクセス権を与えることは、単に API を公開するだけでは不十分でした。API レイヤーを再設計する必要がありました。なぜなら、エージェントのクエリ方法は人間とは異なるからです。彼らはバースト状にエンドポイントを叩き、並列でチェックを実行し、疲れることもなければ自ら手を引くこともありません。そのため、ビジネスに不可欠なアラートや監視機能も支えるインフラをダウンさせずに、高速に動作できるようなガバナンス（安全装置）をシステム内に組み込む必要がありました。

今後の展望

現在の AI SRE は、インシデント対応における「調査フェーズ」に焦点を当てています。つまり、「何が」「なぜ」起きたのかを理解することに注力しているのです。

次の自然なステップは、ガイド付きの緩和措置への拡張です。単に問題を診断するだけでなく、エンジニアが安全かつ適切な是正措置を講じるのを支援します。

また、インシデント間の学習にも投資を進めています。過去のインシデントからパターンを抽出し、将来の診断精度を高めるほか、アラート発令前に recurring な課題を早期に発見したり、チームがシステム全体の信頼性ギャップを特定したりする手助けを行います。

一緒に働きませんか

未来を見据え、AI がどのように生産環境を形作り、複雑なインフラを直感的で扱いやすいものに変えるか、その境界を広げ続けることにワクワクしています。次世代の AI パワー型社内プラットフォーム構築に情熱を持つ方は、ぜひ私たちと一緒に働いてください！