Oxynote

長い間、私の会社で最も信頼できるドキュメントは、自分宛てに書いた Slack のチャットでした。そうなった経緯は、ダッシュボードから始まります。Grafana、Sentry、なぜか少しだけ Datadog、そしてチャートを載せたセルフホスト型のカスタム HTML ページがいくつかあり、たくさんのダッシュボードがありました。それに加えて、担当するデプロイのヘルスチェックを自分で実行するよう勧められていました（なぜ Grafana などでできないのか、誰にも説明できませんでした）。そのデプロイ対象は、WebSocket 経由で金融市場データを取得するサービスでした。負荷が高いとメモリリークが起き、OOM で強制終了されていました。原因不明のバグをしばらく追っていましたが、その間、強制終了のたびにイベントが取りこぼされ、取りこぼされたイベントを補うために手動でバックフィルスクリプトを実行していました。そうした状況は、どのダッシュボードにも表示されませんでした。そこで、cron と各サービスのステータスエンドポイントへの curl を使い、その結果を Slack で自分だけに送っていました。まったく便利ではありませんでした。

ほかにも、いろいろありました。終了した試験製品のデプロイ手順をいまだに記載している社内 Wiki、秘密情報の保管庫、サーバー管理コマンドや curl リクエスト。情報はどれも一か所にまとまっておらず、アクセス権の管理も問題でした。それぞれに権限を付与できる別々の担当者がいたため、その担当者が誰なのかを調べて、さらに連絡を取ることに多くの時間を費やしました。Slack でやり取りしていたので、すべて Slack で尋ね、回答もそこで受け取っていました。ときには認証情報がそのまま送られてくることもありました（恐ろしいことです）。情報を失わないよう、それらのメッセージを自分宛てのチャットに転送していました。こうしてそのチャットは、長い間、私にとって信頼できる唯一の情報源になりました。たくさんある中で重要な Grafana ダッシュボードへのリンク、連携時にレスポンスを照合できるようにした他チームのサービスへの curl リクエストの例（リクエストもレスポンスもどこにも文書化されていませんでした）、そして何がどこにデプロイされているかを記したサーバーの IP アドレスなどです。 当然、私も解決しようとしました。Notion のドキュメントを書き、そこから Grafana のグラフにリンクしていました。しばらくはそれで問題ありませんでしたが、 やがて内容が食い違うようになりました。あるドキュメントでは、取り込みレートのグラフにある market、region などのラベルを説明していましたが、新しいラベルが次々に追加されても、 誰も記録せず、その半分はそもそもグラフで使われていませんでした。しかも、ラベルが一つ増えるたびに Prometheus の時系列も一つ増えます。ドキュメントとグラフを同期させるには、 Notion と Grafana の両方にリンクを置く必要があり、私には面倒すぎました。 説明とグラフの内容が今も一致しているかを確かめるだけなのに、 ブラウザーのタブを切り替える必要もありました。そして、これはオブザーバビリティの話にすぎません。 そのほかにも、管理操作には特定の curl リクエストが必要で、 機能フラグはほかのすべてから切り離されたサービスにありました。どれも GitHub のように、テキスト、メトリクスのグラフ、その他の視覚的な構造に対応した差分を使って 適切にレビューできるワークフローが必要でした。ところが、そうした仕組みは 何もありませんでした。

私と一緒に Oxynote を始めた David（@davseby、 @swithek）は、別の会社で初めてオンコールを担当したとき、 システムとそのドキュメントを一通り把握しなければなりませんでした。Grafana と社内ドキュメントの経験が 何年もあった彼は、いつもどおりに済むと思っていました。ところが実際に使うことになったのは、 一度も使ったことのない Datadog と、まったく異なる構成の Notion でした。そして最初の当番で、 画像メタデータを補完するサービスが停止しました。ユーザーがアップロードした画像の検索精度が落ち、 そこから製品全体に影響が広がりました。モニターは発火しましたが、どれもリンクがなく、 どのサービスが故障し始めたのかも示されていませんでした。そのため、手作業で情報をつなぎ合わせる、 神経のすり減る夜になりました。あるサービスが過負荷で応答しなくなっていることを示すメトリクスは、 ずっと存在していました。しかし Datadog の UI は複雑で、どのグラフが何を追跡しているのかを 説明するものもなかったため、David はそのメトリクスを見つけられませんでした。Datadog の MCP サーバーに接続した AI エージェントは見つけました。

私たち二人が求めていたのは、グラフ、説明、コマンド、フラグが一つのページにまとまり、 一緒に編集でき、コードのようにレビューでき、夜中に疲れた人にもエージェントにも 読みやすいものでした。私たちが使っていたツールはどれも、特定のことには優れていても、 ほかのツールに目を向けることはありませんでした。Oxynote は、そのギャップを埋めるためのものです。 まず、私たちが最も必要としていた要素、つまり Notion のようにライブで使えるドキュメント、 メトリクスのグラフ、レビューのワークフロー、そしてリアルタイムシステム向けの Stripe のような分割ドキュメントから始めます。パズルのほかの要素も、順次追加していきます。