メインコンテンツにスキップ
Clinford Jordano Valencia
すべてのプロジェクト
AIプラットフォーム

フロントエンドのアラートと AI 支援トリアージ Bot

テレメトリの相対変化に基づくアラートと、アラートを推定原因に変える LLM 支援のチャット Bot。チームがすでに使っているスレッドの中で動きます。

技術スタック
SQL · Alerting service · LLM API · Kubernetes · Internal chat bot

課題

サードパーティとの受け渡しで起きる静かな離脱は、数日後にカスタマーサポート経由で見つかっていました。アラートはしきい値ベースでノイズが多く、人々は無視することに慣れていました。

アプローチ

  • 固定しきい値ではなく相対ベースライン。 アラートサービスはテレメトリストアに SQL を実行し、各指標を先週の同じ時間帯と比べます。20% の低下は、ある地域の午前3時でも別の地域の正午でも意味を持ち、世界規模のトラフィックの変動で誤報が出ることもなくなります。
  • 文脈つきで届くアラート。 アラートが発火すると、チームのチャットにインシデントカードが投稿されます。続いてバックグラウンドワーカーが直近のフロントエンドのエラー、有効な設定バージョン、デプロイログを集め、構造化プロンプトとして LLM API に送ります。
  • スレッドに返る要約。 Bot は推定原因を返します。例えば、特定のステップのコンバージョンが1つの地域で低下、ネイティブラッパーで null ポインタエラー、15分前に設定変更がリリース済み、下流サービスがタイムアウト、といった内容です。

結果

検知までの時間は数時間から数日だったものが数分になり、対応までの時間も短縮され、アラートは信頼できるものになりました。アラートの S/N 比(実際のインシデントに対応するアラートの割合)と、フロントエンドモジュールの平均故障間隔も追跡しました。

この方法を選んだ理由

通常のアラートは何かが壊れたことしか教えてくれません。データを自動で集めて要約することで、指標と人間の理解のあいだにある隔たりが埋まります。対応時間の大半は、そこで消えていました。