How Honeycomb's Support Team Uses Honeycomb to Debug Honeycomb

可観測性企業で働く人々は、データ内のすべてがどこにあるかを正確に把握していると思うかもしれない。実際はそうではない。それでも、サポートエンジニアとして私たちは毎日テレメトリーを使って顧客の質問に答えています。私たちはHoneycombを自分自身に向けることでそれを実現しています。このブログでは、それが実際にどのように機能するのか、そしてCanvasとMCPの登場によってどのように変化したのかを説明します。

他者のテレメトリー

開発チームに所属している場合、一般的にはシステムの自分の担当部分を把握しています。フィールドに名前を付け、データセットを知り、何か問題が発生したときにどこを見ればよいかの感覚を持っています。

サポートは異なります。私たちは最前線にいて、チケットは文字通り何に関することでもあり、詳細がほとんどない場合もあります。例えば、グラフの見た目がおかしいスクリーンショットを送ってくる人もいます。または、「クエリに何か問題があるようです」とだけ書いてくる場合もあります。

私たちは必ず追加の質問をしますが、初期の情報をもとに、顧客からより多くの文脈を得るのを待つ間でもすぐに調査を開始できれば、かなりの時間を節約できます。

その上、Honeycombの内部テレメトリーには多くのデータセットがあります。システムは何年も運用されており、コンテキスト間で命名が一貫していないこともあります。チームIDを調べる場合、app.team_id、app.team.id、またはteam-idである可能性があります。これら3つはすべて別々のフィールドとして存在します。10年にわたるテレメトリーの決定を掛け合わせると、かなりの量になります。それぞれは当時としてはおそらく問題なかったでしょうが、仕事上そのすべてを（自分のチームの部分だけでなく）操作する必要がある場合、負担が大きくなります。

Canvas以前は、白紙のページの問題が常態化していました。クエリビルダーを開いて、どのデータセットから始めればよいかわからず、チームメイトに連絡していました。時折、クエリリンクを送ってくれることもありました。または、似たような問題や質問で使った記憶のあるクエリを説明してくれることもありました。私たちは人々がどこから始められるように共有ボードを構築したこともありました。クエリURLがSlackで一日中飛び交い、それなりに機能していましたが、なぜを解明する前に、クエリする方法の仕組みを理解するのに多くの時間を費やしていました。

Canvasが白紙のページを解消した

Canvasはこのプロセスを高速化しました。今では、正確なデータセットや正しいカラム名を覚えておく必要がありません。Canvasでは探している内容を記述すると、Canvasがクエリを構築し、実行し、必要に応じて洗練するための視覚化を返します。

健全な状態と比べて悪く見えた時間枠をBubbleUpする必要がある場合？ ただ尋ねてください。Canvasがクエリの構築を処理します。

私たちは依然として操作する側です。どの糸を引くか、何を除外するか、次にどこを見るかを決めるのは依然として私たちです。しかし、クエリ構文を正しくすることに費やしていたエネルギーのすべてが、今では実際の調査に向けられるようになりました。異なるデータセットにわたって3つまたは4つのクエリを実行し、データが導くところに従うことができ、1つのクエリを動作させることに全力を費やす必要がなくなりました。

調査スタック

CanvasはすでにHoneycomb内にある場合にはうまく機能します。しかし、チケットに必要なのはテレメトリーだけではありません。すべての調査の周りには調査レイヤーが存在します。

ここでMCPが役立ちます。MCP（Model Context Protocol）により、AIアシスタントが調査中に使用するHoneycombやその他のツールからコンテキストを引き出すことができます。興味深い点は、Honeycomb MCP単独ではありません。多数のMCPを連携させたときに起こることです。

例えば、顧客がトリガーに関する奇妙なことについて問い合わせたとします。内部で誰かがこれを以前に見たことがあるかどうか、エンジニアリングがすでにそれを知っているかどうか、そして機能が内部で実際にどのように動作するかを把握する必要があります。以前は多くのタブが必要でした：Slackを1つ、Linearをもう1つ、コードベースを別の場所に、ドキュメントをさらに別の場所に開く。データがテレメトリーの外にある場合はSnowflakeも必要かもしれません。それらの間で内容をコピーし、飛び回りながら全体のスレッドを頭の中に保持しようとしていました。

今では、ループ全体が1つの場所で発生します。「この顧客が説明していることは何か？」から始め、「OK、ここにコードパスがあり、エンジニアリングはすでにLinearチケットを持っており、テレメトリーで確認できた」というところまで、思考の流れを失うことなく到達できます。

エスカレーションの現在の形

以前は、顧客が報告した問題が事前に診断しにくいものであることが判明した場合、エンジニアを早期に巻き込んでエスカレーションするかどうかを決定し、共有する情報を決めることがありました。これは時間のかかるプロセスであり、チケットがより早く解決されるほど顧客体験が向上することは誰もが知っています。

今では、MCPとCanvasにより、エンジニアリングが関与する前にその調査のほとんどを行うことができます。この特定のチケットでは、コードベースを検索し、根本原因を見つけ、顧客のデータに問題がないことを確認し、同じパターンに対する以前の修正も見つけました。エスカレーションする頃には、エンジニアリングは修正に直行するために必要なすべてを揃えていました。再現も、やり取りも、「これがどのデータセットにあるか？」という質問もありません。

これが最も変化した部分です。エスカレーションは以前は調査の始まりでした。今では、調査の終わり近くになっています。顧客はより早く回答を得られ、エンジニアリングは探偵作業に費やす時間が減り、エスカレーションを受ける回数も減り、サポートエンジニアは力を得ます。すべての人に利益があります。

これはサポートだけの話ではない

自分が構築していないサービスをデバッグしたり、まだ学習中のシステムのアラートを調査したりしたことがあるなら、私たちが直面したのと同じ壁にぶつかったことがあるでしょう。CanvasとMCPはサポートチームだけのものではありません。見慣れない領域で何かを調査する必要がある人なら誰にでも役立ちます。本当の利点は、システム全体を暗記する前に有用な作業を開始できることです。