cx-incident-management

インシデント管理スキル

インシデントのトリアージ、SLO の監視、通知の検証を行うための入り口として、このスキルを使用します。検出から解決までのトリアージワークフロー全体を調整し、詳細なアラート管理には cx-alerts を、根本原因の調査には cx-telemetry-querying を参照します。

---

CLI コマンド

コマンド	サブコマンド	目的
cx incidents	list, get, acknowledge, resolve, close, assign, unassign, events, aggregations	インシデントの管理とトリアージ
cx slos	list, get, create, update, delete	SLO 定義の監視と管理
cx alerts	list, get	発火中のアラートを確認（詳細なアラート管理については cx-alerts スキルを参照）
cx notifications connectors	list, get	通知コネクターの設定を検証
cx notifications routers	list, get	通知ルーティングルールを検証
cx notifications presets	list, get	通知プリセットテンプレートを確認
cx notifications test	connector, destination, preset, routing-condition, template-render	通知の配信をテスト

主なフラグ：

• cx incidents list は繰り返し指定できるフィルターに対応しています：--status（TRIGGERED、ACKNOWLEDGED、RESOLVED）、--severity（INFO、WARNING、ERROR、CRITICAL）、--state（TRIGGERED、RESOLVED）、--assignee、--application-name、--subsystem-name、--contextual-label key=value、--query、--muting muted|unmuted、--start/--end、--duration-start/--duration-end
• cx incidents list は、デフォルトでプロファイルごとに最大 100 件のインシデントを返します。プロファイルごとの結果数に上限を設定するには --limit <n>、手動でページネーションするには --page-size <n>/--page-token <token> を使用します。すべてのページが明示的に必要な場合に限り、--all を使用してください。
• すべてのコマンドは、構造化出力の -o json とプロファイル選択の -p <profile> に対応しています
• cx slos create/update は --from-file <path>（または標準入力の場合は -）を使用します

---

インシデントのトリアージワークフロー

ステップ 1：アクティブなインシデントを確認する

cx incidents list -o json
cx incidents list --status TRIGGERED -o json
cx incidents list --severity CRITICAL -o json
cx incidents list --status TRIGGERED --start now-24h --limit 50 -o json

現在の状況を把握します。すぐに対応すべき項目を特定するには、重大度でフィルタリングします：

cx incidents list --severity CRITICAL --limit 50 -o json | jq '[.[] | {id, name, state, severity, created_at}]'

ステップ 2：インシデントの詳細を取得する

cx incidents get <incident-id> -o json
cx incidents events --incident-id <incident-id> -o json

インシデントの範囲と進行状況を把握するため、タイムラインと関連イベントを確認します。

ステップ 3：関連アラートを確認する

cx alerts list -o json

現在発火しているアラートを確認します。詳細なアラートの調査には、cx-alerts スキルに切り替えます。

cx alerts list -o json | jq '[.[] | select(.is_active == true) | {id, name, severity, last_triggered}]'

ステップ 4：SLO のステータスを確認する

cx slos list -o json
cx slos get <slo-id> -o json

SLO に違反しているか、エラーバジェットが消費されているかを確認します：

cx slos list -o json | jq '[.[] | {name, status, remaining_budget_percentage}]'

ステップ 5：通知を検証する

cx notifications connectors list -o json
cx notifications routers list -o json
cx notifications presets list -o json

適切なチャネルを通じて、適切な担当者に通知されたことを確認します。

ステップ 6：根本原因の調査に移る

ログ、トレース、メトリクスを使用して根本原因を調査するには、cx-telemetry-querying スキルに切り替えます。

---

インシデントへの対応

確認応答

cx incidents acknowledge <incident-id>
cx incidents acknowledge <id1> <id2> <id3>

解決

cx incidents resolve <incident-id>
cx incidents resolve <id1> <id2> <id3>

割り当て

cx incidents assign <incident-id> --user-id <user-id>

クローズ

cx incidents close <incident-id>

---

SLO 管理

SLO の作成

既存の SLO をテンプレートとして使用します：

cx slos get <existing-slo-id> -o json > slo-template.json
# Edit slo-template.json with new service/threshold
cx slos create --from-file slo-template.json

SLO の健全性を監視

# All SLOs with their status
cx slos list -o json | jq '[.[] | {name, status, target_percentage, remaining_budget}]'

# SLOs that are breaching
cx slos list -o json | jq '[.[] | select(.status != "OK")]'

---

通知のデバッグ

通知が適切な担当者に届かない場合：

1. コネクターを確認する

cx notifications connectors list -o json | jq '[.[] | {id, name, type}]'

想定されるチャネル（Slack、PagerDuty、メール）が存在し、設定されていることを確認します。

2. ルーターを確認する

cx notifications routers list -o json | jq '[.[] | {id, name, entity_type}]'

ルーティングルールで、適切な種類のアラートが適切なコネクターに割り当てられていることを確認します。

3. 通知の配信をテストする

cx notifications test connector --from-file test-connector.json
cx notifications test destination --from-file test-destination.json
cx notifications test preset --from-file test-preset.json
cx notifications test routing-condition --from-file test-condition.json

---

インシデントの集計

インシデントの傾向を概観します：

cx incidents aggregations -o json

これを使用して、インシデントの発生頻度、MTTR の傾向、重大度の分布を把握します。

---

主な原則

• 詳細な調査の前にトリアージする - テレメトリデータをクエリする前に、インシデント、アラート、SLOを確認します
• ステータスだけでなくSLOのバーンレートを確認する - 徐々に消費が進むSLOは、違反する前に対応が必要です
• 通知チェーンをエンドツーエンドで検証する - コネクターが存在する → ルーターが正しくマッピングされている → テスト通知が配信される
• テレメトリと相互参照する - トリアージ後の根本原因調査には cx-telemetry-querying スキルを使用します
• 速やかに確認応答する - インシデントに確認応答して担当する意思を示し、再通知を停止します
• タイムラインにはインシデントイベントを使用する - cx incidents events でインシデントの全ライフサイクルを確認できます

---

関連スキル

• cx-alerts - アラート定義の作成、更新、確認など、アラートを詳細に管理します
• cx-telemetry-querying - ログ、メトリクス、トレース、RUMを使用して根本原因を調査します
• cx-observability-setup - アラートの通知チャネルとルーティングを設定します