# How We Debug 1000s of Databases with AI: Lessons from an AI-Assisted Database Debugging Platform ## 概要 Annie Zhou と Sophie Zhang(Databricks ストレージプラットフォームチーム)による SREcon26 Americas 2026 の講演。MySQL と TiDB を合わせて数千インスタンス、70以上のリージョン、3クラウドで運用する Databricks が、AI支援デバッグシステム(バックエンド: Storax)を本番導入するまでの道のりを説明する。調査時間最大90%削減を達成した3つの教訓(ユーザー共感・安全な基盤・テスト可能なフレームワーク)を中心に構成される。 ## 主要メッセージ - AI によるコーディング自動化は急速に進んでいるが、本番 SRE ワークフローへの AI 統合は依然リスクが高く、組織横断の採用実績は少ない。(Source: [[.raw/videos/youtube-ibJ-MUgJyS0/transcript.md]]) - Databricks が構築した AI支援デバッグシステムは、症状の記述とコンテキスト入力だけで根本原因・タイムライン・緩和策の候補を5分以内に出力し、調査時間を最大90%削減した。(Source: [[.raw/videos/youtube-ibJ-MUgJyS0/transcript.md]]) - 最初の数イテレーションはほぼ AI を使わず、バラバラなツールとコンテキストの集中化・標準化に取り組んだ。この作業なしに AI は採用されなかった。(Source: [[.raw/videos/youtube-ibJ-MUgJyS0/transcript.md]]) - インフラをプロダクトとして扱い、ユーザー(社内サービスチームのエンジニア)にインタビューし、オンコールを同行観察して課題を特定したことが、信頼と採用の土台になった。(Source: [[.raw/videos/youtube-ibJ-MUgJyS0/transcript.md]]) - セントラルファースト・シャーデッドアーキテクチャ、細粒度アクセス制御、統一ツールインターフェース(Storax)がエージェント統合の安全な基盤となる。(Source: [[.raw/videos/youtube-ibJ-MUgJyS0/transcript.md]]) - DSPy インスパイアのフレームワーク(Signature・Tools・Modules)でエージェントをモジュールとして構成・テストし、LLM プロキシ経由でモデルを Claude・GPT・Gemini と差し替えられる設計が、急速な反復を可能にした。(Source: [[.raw/videos/youtube-ibJ-MUgJyS0/transcript.md]]) ## 口頭説明・補足 ### 規模と背景 Databricks は65%超の年次成長率、2万以上の顧客、54億ドルの収益ランレートを持つ急成長企業であり、ストレージプラットフォームチームはその速度で MySQL と TiDB を70以上のリージョン・3クラウドにわたって運用する必要がある。エンジニアがすでにコーディングで AI を活用しているのに、SRE 運用は依然として手作業に頼っている——この非対称性が出発点になる。 ### デモ: AI エージェントによるデータベース障害調査 デモでは、データベースインスタンスで障害が発生した状況を想定する。ユーザーは症状・対象 DB・対象リージョンを自然言語で記述し、エージェントに調査と根本原因特定を依頼する。エージェントは社内ナレッジベースを検索しながら関連メトリクスとデータを引き出し、根本原因・タイムライン・裏付け証拠・緩和策を出力する。 緩和操作が必要な場合、エージェントはユーザーに承認を求める。リスクの高い操作(例: max_connections の変更)には2人目の承認が必要で、Temporal ワークフローが承認待ち状態を管理する。権限を持たないユーザーによる承認はシステム側で却下される。この全プロセスが5分以内に完了する。 ### 教訓1: ユーザー共感と反復 サービスチームのエンジニアにインタビューし、オンコールを同行観察した結果、以下のパターンが見えた: - ツールは多数あるが、SOP を開き CLI コマンドを手貼りし、フラグの打ち間違えなどが緩和時間を延ばしていた - インシデント前後のコンテキスト収集(直前に何が起きていたか)に時間がかかる - 担当者以外には「なぜこのシステムがこう振る舞うか」を知る人を呼ぶ必要があった - 前のインシデントと微妙に違うため、前回の緩和手順がそのまま使えない 最初の数イテレーションはこれらを解決するためのもので、ツールを一箇所に集めて発見しやすくするだけで、AI はほぼ使わなかった。この段階でサービスチームとの関係を築き、後の AI 統合への信頼の基礎が生まれた。 **教訓**: ユーザー共感とフィードバック反復は、技術設計と同等に信頼・採用の要件である。 ### 教訓2: 安全な基盤 — Storax の設計 スケールでの AI 統合には3つの課題がある: 1. **コンテキスト断片化**: デバッグに必要なデータが複数の場所に散在し、エージェントが一貫した全体像を描きにくい。 2. **ガバナンス境界の不明確さ**: 中央集権的な権限管理システムがなければ、エージェントが承認された操作だけを実行していることを保証できない。 3. **不統一な抽象**: リージョン・クラウドをまたぐ標準化がなければ、エージェントの機能拡張が困難になる。 Storax はこれらに対して: - **セントラルファースト・シャーデッドアーキテクチャ**: グローバルサービスインスタンスがリージョナルシャードを調整し、ユーザーへ単一エントリーポイントを提供しつつ、機密データをローカルに保ちコンプライアンスを維持する。 - **細粒度アクセス制御**: セキュリティチームと協力し、チーム・リソース・RPC レベルの3層で権限クラスを明示的に定義する。 - **統一ツールインターフェース**: 断片化した既存インフラサービスを単一の一貫したツールインターフェースの背後に標準化し、エージェントが推論しやすくする。 **教訓**: 安全な基盤(アーキテクチャ・アクセス制御・ツール抽象)の整備がエージェント統合の前提条件である。 ### 教訓3: テスト可能で反復しやすいフレームワーク DSPy にインスパイアされた宣言型フレームワーク(完全に DSPy ではないが同様の思想)でエージェントを構築する。中心となる3概念: - **Signature**: LLM へのシステムプロンプト。目標とルールを定義する。 - **Tools**: エージェントの「手」。メトリクス/ログ取得、DBの再起動、クエリ実行など。すべて Storax の安全な基盤の上に構築される。 - **Modules**: エージェントと LLM の対話パターン。Predict(ワンショット)、Chain of Thought(ステップ思考)、ReAct(ツール呼び出しと推論の交互)の3種がある。 LLM モデルは内部 LLM プロキシで抽象化されており、Claude・GPT・Gemini を差し替えられる。このためモデル非依存で推論とツール実装を分離でき、プロンプトとツールを独立して発展させられる。テスト可能性がエージェントの本番前の安全性検証を可能にした。 ## 概念・実体への接続 - [[Annie Zhou]]: 登壇者、Databricks ストレージプラットフォームチームのエンジニア。 - [[Sophie Zhang (Databricks)]]: 登壇者、Databricks ストレージプラットフォームチームのエンジニア。 - [[Databricks]]: 組織。Delta Lake・MLflow・Unity Catalog・Apache Spark の親組織。 - [[Storax]]: Databricks 内部の AI デバッグツールを支えるストレージプラットフォームサービス。 - [[agentic SRE]]: 本番 AI SRE の産業実装例として、読み取り→RCA→承認付き書き込みの安全なフローを示す。 - [[データベース O&M]]: 数千インスタンスのデータベース運用をエージェントが支援する具体的な産業実例。 - [[データベース自律診断]]: AI エージェントによるデータベース根本原因特定の産業実装。 - [[SRE AI Autonomy Levels]]: ユーザー確認→2人目承認という段階的な自律度の実例。 ## 限界・不確実点 - 動画の取得に失敗したため、代表フレームがなく、デモ画面・アーキテクチャ図・スライド上の具体的な数値は映像では確認できていない。 - transcript は YouTube の英語自動字幕から生成したため、固有名・数値に誤認識の可能性がある。特に「AGI agent」という表記は自動字幕の誤認識の可能性があり、「AI agent」が正しいと推測される。 - 「Storax」というサービス名は transcript で明確に言及されているが([12:18])、内部ツール名のため公式ページでの裏取りはできていない。 - 講演公開日(2026-03-24)は同じ SREcon26 Americas 開催日を他のソースから借用した推定値であり、この講演固有の公開日ではない可能性がある。