ops-oncall-log

オンコールログ

監視プラットフォームからアラートを取得し、チームの Wiki に構造化されたオンコールログを作成します。

使用するタイミング

• オンコールシフトの終了時 — 次のエンジニアに何が起きたかを記録します
• 毎日または毎週のオンコールレビュー会議
• 時間の経過に伴うアラートパターンの履歴を作成するとき

プロセス

1. MCP サーバーの利用可否を確認する

2 つの MCP サーバーが必要です。

1. 監視 MCP — アラートイベントとモニターのステータスを取得します。推奨：Datadog MCP。
2. Wiki MCP — ログページを作成します。対応：Confluence（mcp__claude_ai_Atlassian__*）または Notion（mcp__claude_ai_Notion__*）。

いずれかが不足している場合は、次のエラーを表示して中止します。

Error: Missing required MCP server(s): <list>. このスキルには、監視 MCP と Wiki MCP の両方が必要です。 推奨：Datadog MCP と Confluence または Notion MCP。

2. 設定を収集する

ユーザーに次の項目を尋ねます。

1. ログの頻度 — 毎日ですか、それとも毎週ですか？（デフォルト：毎週）
2. オンコールローテーションのスケジュール — ローテーションは何曜日に始まりますか？（デフォルト：金曜日。毎週の場合のみ関係します）
3. 環境フィルター — どの環境を含めますか？（デフォルト：prod のみ）
4. Wiki のスペース／親ページ — ログページを作成する場所：
   • Confluence： スペースキーと親ページ ID
   • Notion： 親ページ ID またはデータベース ID
5. テンプレートページ（任意）— 書式の参考にする既存ページ

以前に実行したことがあり、設定が利用可能な場合（例：.spartan/config.yaml 内）は、その設定を再利用して、次のように確認します。

「以前の設定を使用します：、 アラート、Wiki の場所は です。よろしいですか？」

3. 日付範囲を決定する

ステップ 2 のログ頻度に基づいて決定します。

• 毎日： 今日（またはユーザーが指定した日付）
• 毎週： ローテーション曜日に基づいてオンコール期間を計算します（例：金曜日から金曜日）

ユーザーが日付範囲を指定した場合は、そちらを使用します。

ユーザーに確認します。

「 – のオンコールを記録します。よろしいですか？」

確認を待ってから続行します。

4. 監視プラットフォームからアラートを取得する

4a. 既存ページを確認する（差分更新）

この期間の既存ページを Wiki で検索します（ステップ 7 の命名規則を使用）。見つかった場合は、ページを読み込んで最終更新日時を確認します。ユーザーに「この期間のページはすでに存在します。更新しますか、それとも新規作成しますか？」と尋ねます。

• 更新する場合：期間の開始日時ではなく、最終更新日時を from 日付として使用します。これにより、記録済みのアラートを再取得せずに済み、トークン使用量を削減できます。
• 新規作成する場合：期間の開始日時全体を使用し、ステップ 8 で別のページを作成します。

更新のたびに、ページの先頭に **Last updated:** <timestamp> の行を追加します。

4b. 発生したアラートイベントをクエリする

利用可能な監視 MCP を使用して、アラートイベントを取得します。

• 環境と triggered／warn ステータスでフィルターします
• 時間範囲：最終更新日時（新規ページの場合は期間の開始日時）から現在まで
• タイムスタンプ順に並べ替えます

ページネーション： 結果が切り詰められている場合、すべてのイベントを取得するまでページネーションします。

4c. フィルターして正規化する

取得したすべてのイベントから、次の処理を行います。

• 対象外の環境のイベントを除外します
• 復旧イベントを除外します — triggered および warn イベントのみをカウントします
• モニターのタイトルを正規化します：ステータスのプレフィックスを取り除き、基本のモニター名を取得します

4d. アラートの概要を作成する

イベントを基本のモニター名ごとにグループ化します。各グループについて、次の情報を収集します。

1. 発生回数 — 期間中にそのモニターで発生したトリガーイベントの合計数
2. 発生時刻 — 各トリガーのタイムスタンプと、監視プラットフォーム上のイベントへのリンク
3. 現在のステータス — 現在もモニターが Alert ステータスかどうか

アラートは発生回数の降順で並べ替えます。

4e. 現在アクティブなモニターを確認する

現在 Alert ステータスのモニターをクエリします。次のオンコール担当者がフォローアップする必要があるものとして、これらにフラグを付けます。

期間中にアラートがなかった場合は、「この期間のアラートはありません」と記載して続行します。

5. 追加メモの確認

「ログに記載する追加メモ、インシデント、またはアクションアイテムはありますか？」

入力内容を記録します。「なし」の場合は、メモを追加せずに続行します。

6. テンプレートの取得（設定されている場合）

ユーザーがステップ 2 でテンプレートページを指定した場合は、そのページを取得し、構成をフォーマットのガイドとして使用します。それ以外の場合は、ステップ 8 のデフォルト構成を使用します。

7. 保存先の特定または作成

オンコールログは、一貫した階層で整理します。

On-call Logs/
  On-call <YYYY>/
    On-call <MM>/<YYYY>/
      [On-call] <Start Date> - <End Date>

1. 年のフォルダーがあるか確認します。なければ作成します
2. 月のフォルダーがあるか確認します。なければ作成します
3. 該当期間のページがすでにあるか確認します。
   • 見つかり、ステップ 4a でユーザーが更新を選択した場合：ステップ 8 でこのページを更新します
   • 見つかり、ステップ 4a でユーザーが新規作成を選択した場合：ステップ 8 で新しいページを作成します
   • 見つからない場合：ステップ 8 に進みます

8. ログページの作成

Wiki プラットフォームにページを作成します。

# On-call Log: <Start Date> – <End Date>

## Alert Summary

| Alert | Count | Times | Cause | Resolution |
|-------|-------|-------|-------|------------|
| <monitor name> | <N> | <timestamp 1>, <timestamp 2>, ... | | Still active |

**Total alerts:** <N> across <M> unique monitors

## Currently Active Alerts
<list monitors still in Alert status, or "None — all clear">

## Notes
<additional notes from Step 5, or "None">

## Action Items for Next On-call
- <follow up on active alert X>
- <investigate recurring alert Y — triggered N times>

書式設定：

• アラート名を監視ページにリンクします
• タイムスタンプを該当イベントにリンクします
• 「原因」列は空欄にしておき、エンジニアが事後に記入できるようにします
• 現在アラート状態のモニターは「解決状況」を「対応中」に設定します。解決済みのモニターは空欄にしておきます（エンジニアが事後に記入します）

9. 結果の提示

## On-call Log Created

**Page:** <page title>
**URL:** <wiki page URL>
**Alerts logged:** <N> alerts across <M> unique monitors
**Active alerts:** <count or "None">
**Notes:** <summary or "None">

未解決のアラートがある場合：

次のオンコール担当者へのアクションアイテム： 以下のアラートはまだ有効です。関連チームにフォローアップしてください：<list>

対話スタイル

• 取得前に設定と日付範囲を確認します。推測で進めないでください
• 質問は1回にまとめ、何度もやり取りを繰り返さないでください
• 最終ページの URL は目立つように提示し、ユーザーがすぐ共有できるようにします

ルール

• アラートを取得する前に、必ず日付範囲を確認します
• ユーザーから他の環境を指定された場合を除き、本番アラートのみを含めます
• Wiki ページの重複作成を避けるため、必ず既存ページを確認します
• 「原因」列は空欄にしておき、エンジニアが事後に記入できるようにします。有効なモニターは「解決状況」を「対応中」に設定し、解決済みのものは空欄にしておきます
• すべてのページを取得し、アラートデータの一部だけを提示しないでください

出力

Wiki プラットフォーム（Confluence または Notion）にログページを直接作成します。会話内に URL と統計情報をインラインで提示します。