oodle-triage

Oodle Triage — 右側の可観測性

アラートを説明文ではなく、証拠に変えます。このスキルは本番環境のコンテキストを収集し、規律あるチケットを作成します。左側で始まったループを閉じるため、最近の PR にある O11y Change Context マニフェストを読み取り、発火したアラートを、それを引き起こした可能性が高い変更に結び付けます。

最優先の原則： すべてのステップで、証明されたことと推測されたことを分けます。確認済みの症状、有力な仮説、そして不足している具体的な証拠は、相関関係だけに基づく整った根本原因の説明よりも重要です。断定する前に証拠を示します。

モード

• モード A — トリアージのコンテキスト： 入力は単一のアラート、トラッカーチケット ID、または症状の説明です → コンテキストレポートを作成し、必要に応じてチケットを更新します。
• モード B — オンコールの自動トリアージ： 入力は期間（およびトラッカーの親課題）です → 発火したものをすべて列挙し、重複を除外して、サブ課題を作成／更新します。/loop の間隔で実行するよう設計されています。

入力でアラート／チケット／症状が 1 つ指定されている場合は、モード A を使用します。期間内のトリアージ、または「発火したものすべて」のトリアージを求められた場合は、モード B を使用します（アラートごとにモード A を再利用します）。

検出（最初に実行）

バックエンドは、ハードコードされたサーバー名ではなく、機能とツールの形状に基づいて特定します（名前は oodle-ai-us1、ap1、staging、dev、顧客ごとのカスタム名など、環境によって異なります）。

• Observability MCP — アラート／モニター、メトリクス（PromQL）クエリ、ログ、トレース用のツールを探します。ツール群が Oodle の形状に一致する場合は、最短経路を使います。サービスを管理する環境を選択し、問題に合った load_skill__* ワークフロー（Kubernetes のデバッグ、アラートノイズの分析など）があれば、低レベルの呼び出しを行う前に読み込みます。
• Issue-tracker MCP — 使用中のトラッカーを特定します。以下では Linear を例にします。Jira も同様で、課題 → サブ課題、状態、コメントは相互に対応します。
• バックエンドが利用できない場合は、利用可能なシグナルでできることを行い、不足している点を明記します。

モード A — トリアージのコンテキスト

1. 書面で事実関係を確定します。 チケットが提示された場合は、対象範囲を確認するためにチケットを取得します。 何かをクエリする前に、サービス／コンポーネント、クラスター／環境、Pod、コンテナ、そして正確な時間範囲を特定します。時間範囲はUTC と報告者の現地タイムゾーンの両方に変換します。両者を気付かないまま混在させるのは、よくある誤りです。
2. 推測する前に、確かなシグナルで症状を確認します。再起動／OOM の理由、エラー率、レイテンシー、リソース使用量と上限の比較、イベントログを確認します。確認できた症状を一行で述べ、それ以降はすべて説明とします。
3. コードから計装を把握します。 実際のメトリクス名、ログ文字列、スパン属性を確認するため、該当するサービスコードを読みます。推測で補ってはいけません。何が記録され、何が記録されていないかを明記します。欠けている情報を把握すると、テレメトリーでは答えられない質問が明らかになります。
4. 複数のテレメトリーを突き合わせます。単一の情報源に頼ってはいけません。責任箇所を特定できるすべてのディメンション（サービス、テナント、操作、Pod、ステータス）ごとにグループ化したメトリクス、経路上の呼び出し元と呼び出し先のログ（ERROR／WARN とアクセスログを読み、報告されたログが見つからない場合はフィルターを広げます）、エンドツーエンドのトレース、リソース関連のインシデントではプロファイルを確認します。
5. 最近の変更と関連付けます（ここでループを閉じます）。 GitHub または Linear MCP を使うか、GitHub MCP がない場合は gh CLI を使って、アラート対象のサービスに触れた最近の PR を見つけ、その O11y Change Context ブロックを読みます。watch 項目と type によって仮説の焦点が定まります（watch: N+1 ... は有力な仮説になります）。guarded-by はアラートとコードの関連性を確認し、gaps はテレメトリーがそもそも提供するように作られていない証拠を説明します。
6. すべての調査結果に Confirmed | Inferred | Unknown のラベルを付けて追跡します。設定された上限やデフォルト値は測定値ではありません。共起は因果関係ではありません。有力な仮説を一つの測定で積極的に反証します。候補を一つ除外することは、裏付けを追加するより価値があります。
7. 確認が不可能な場合は、そこで止め、証拠不足の項目を優先順位付きで提示します。各項目について、どの仮説を確認／反証できるか、どこにある可能性が高いか、アクセス可能かどうかを示します。そのうえで、推測を続けるのではなく、最優先の項目を確認できるよう依頼します。

出力 — 簡潔で誠実なレポートを作成します。確認済みの症状（UTC と現地時刻のタイムスタンプ付き）、原因の特定（立証できた範囲で、誰が／何が／どこで）、有力な仮説（立証済みか推定かを明確に記載）、除外した可能性（測定結果を添付）、不足している証拠（優先順位付きリスト）を記載します。トラッカーチケットへのコメントとして投稿することも提案します。

モード B — オンコールの自動トリアージ

アラートごとにモード A の調査を実施し、列挙 → 抑制 → 重複排除 → 登録の順に処理します。作成前に必ず照合することで、再実行時の二重登録を防ぎます。

1. 対象期間に発火したものを列挙します — 発火中状態に達したアラートインスタンスを列挙します。**条件が未達成で保留中のものを発火として扱ってはいけません。**通知は送られず、トリアージや登録の対象にもなりません。アラート状態のシグナルまたはトリガー履歴で、実際に発火したことを確認します。
2. 各アラートを補足調査します：現在もアクティブか、ノイズのカテゴリ（フラッピング／ストーム／継続的／自動解消／境界）と約 7 日間のトリガー回数、ミュートされているか（このアラートのモニターとスコープにすべてのマッチャーが一致する、有効なミュートルールがあるか）、ルーティングされているか（モニターが誰かにページを送信するか、ルーティングされていないか）。
3. ミュートされたアラートとルーティングされていないアラートを抑制します — オンコール対応が必要なシグナルではありません。登録しないでください。現在ミュートまたはルーティングされていないアラートに古いチケットがある場合は、その理由（ミュートルールの ID とマッチャー、またはルーティングされていないモニターの ID）をコメントに記載してクローズします。アラートクラス全体ではなく、該当するインスタンスを抑制してください — ルーティングはモニターごと、環境ごとに行われます。
4. ストームをまとめます — 1 つのモニターで多数の系列が同時に発火した場合は、論理アラートを1 つとして扱い、チケットも N 件ではなく 1 件にします。
5. 発火したアラートごとに、深刻度に応じた深さでモード A に従って調査します。マニフェストとの相関情報を、推定原因と推奨修正に活用します。
6. トラッカー内のチケットと指紋を基準にしたセマンティックな一致で重複排除して登録します（環境 + モニター + スコープ）：一致なし → 作成、一致するチケットがオープン中 → 新しい発生についてコメント、一致するチケットがクローズ済み → 再オープンしてコメントします。深刻度に基づいて優先度を設定します。書き込みに失敗した場合は 1 回再試行し、作成途中の重複を決して残さないでください。同じ期間を再実行しても、結果は冪等になります。

指紋ブロック

登録するすべてのチケットに、今後の実行で照合できる安定した指紋を付けます。形式は固定してください：

## Fingerprint
- env: <env>
- monitor: <monitor id/name>
- scope: <key=value scope labels>
- links: <deep links to the backend>

汎用性と Oodle に特化した仕組み

基本方針はベンダーに依存しません。確認済みと推定の区別、発火したアラートのみの列挙、ミュートまたはルーティングされていないノイズの抑制、ストームの集約、指紋による重複排除、マニフェストとの相関は、どのバックエンドにも適用できます。具体的な仕組みはバックエンドごとに異なります。Oodle には ALERTS スタイルの状態メトリクス、型付きマッチャーを持つ muting_rules、モニターのルーティングフラグがあります。他のベンダーの MCP では、それぞれに相当する仕組みを使用します。相当する仕組みがあれば使用し、その概念が本当に存在しない場合は手順を省略してください — バックエンドにない仕組みを決して作り出してはいけません。

より詳しいクエリが役立つ場合は、Oodle CLI のパスでここに内容を重複して記載するのではなく、 oodle-metrics、 oodle-logs、および oodle-tracesを参照してください。