incident-status-page-ops-review

インシデントステータスページ運用レビュー

このスキルを使用すると、インシデントステータスページ、公開コミュニケーション、購読者への通知、メンテナンス、コンポーネント、インシデント後の対応に関する質問を、担当者、ゲート、メトリクス、復旧手順を含む具体的な成果物にまとめられます。

ワークフロー

1. 製品コンポーネント、顧客セグメント、インシデントの重大度、検出元、SLO／顧客への影響、コミュニケーションの担当者、サポートへの負荷、法務／セキュリティ上の制約、ステータスページの現状の不足点を特定します。
2. references/incident-status-page-ops-patterns.md を読みます。
3. コミュニケーションを、調査中、特定済み、監視中、解決済み、予定メンテナンス、パフォーマンス低下、一部停止、セキュリティ上の機密情報を含むもの、インシデント後のフォローアップに分類します。
4. コンポーネント分類、宣言のしきい値、更新頻度、テンプレート、承認経路、購読者への通知チャネル、サポートとの連携、履歴／事後分析との関連付けを定義します。
5. ステータスページ運用計画、ステートマシン、判断表、イベントスキーマ、コミュニケーションチェックリスト、インシデント訓練計画を作成します。

使用しない場合

• このスキル固有の成果物要件がなくても、ベースモデルが対応できる一般的なアドバイスには使用しないでください。

ガードレール

• 根本原因が完全に判明するまで、顧客に見える形でのインシデントの確認を遅らせないでください。
• コンポーネントの性能低下、地域への影響、一部停止を隠して、稼働率を実際より高く見せないでください。
• 承認を得ずに、機密性の高いセキュリティ情報、顧客データ、推測に基づく根本原因を公開しないでください。
• サポート、ステータスページ、アプリ内バナー、営業、アカウント担当チームが、矛盾するインシデント情報を発信しないようにしてください。

出力形式

Status-page context:
Audience / source of truth / risk boundary:

Incident communication plan:
| Area | Decision | Evidence | Risk | Owner |
| --- | --- | --- | --- | --- |

Components, updates, subscribers, and follow-up:
- <trigger> -> <policy, metric, edge case, support note>