インシデント管理

（セクション： 技術とインフラ）

概要

インシデント管理は、ユーザーの価値を迅速に復元し、ビジネスの損傷を最小限に抑えるための繰り返し可能なプロセスです。サポート-明確な役割（Incident Manager、 Tech Lead、 Comms）、 SLOゲート、エスカレーション、ChatOpsプロセス、準備されたrunabooks、および測定可能なアクションアイテムを使用した「innocuous」 post-incident parsing。

1）目標と原則

速度と安全性：迅速な診断→安全な安定化→持続的な回復。
唯一の所有者-割り当てられたインシデントマネージャ（IM）がプロセスの決定を行います。
製品としてのコミュニケーション：ステークホルダーとユーザーの予測可能なアップデート。
データ>意見：SLO/メトリック/トレイル/ログは真実の源です。
責任のない：個人的な非難のない理由の分析；システムの改善に焦点を当てます。

2）インシデントの分類（重症度/影響/緊急性）

• SEV1（重要）：収益/TTW/支払いに対する深刻な損害、>ユーザーまたは地域全体の20％；SLA 障害/PII脅威。
• SEV2（高）：キーフローの部分的な劣化（デポジット/ベット/ゲームの起動）、影響5-20％。
• SEV3（媒体）：二次サービスの顕著な劣化、バイパスがあります。
• SEV4（低）：マイナー、限られた効果、SLO/SLAへの影響無し。

影響：影響を受ける人（すべて/地域/テナント/チャネル）。緊急：劣化率（エラー予算での高速燃焼/スローバーン）。

3）インシデントライフサイクル

1.検出-アラート/SLO/合成/レポートからの信号。
2.承認-電話で受信を確認し、IMを割り当てます。
3.トリアージ-SEV/インパクトスコア、仮説コレクション、戦争部屋の発見。
4.軽減-安定化（ロールバック/ルートスイッチング/フィッシュフラグ/スケーリング）。
5.コミュニケーション-定期的なステータスの更新（内部/外部）。
6.リカバリ：完全なSLO/ビジネスメトリクスのリカバリ。
7.クローズ-年表の記録、アーティファクトのコレクション、PIR （RCA+アクション項目）。

4）役割と責任（RACI）

インシデントマネージャ（IM）-プロセスの所有者、役割の割り当て、時間の監視、プロセスの意思決定（R）。
テクニカルリード（TL）-診断/仮説/修正を行い、エンジニア（A/R）を調整します。
コミュニケーション（Communications）-ステータスの更新、サポート/ビジネス/PRとの接続、ステータスページ（R）。
Scribe-プロトコル（タイムライン、意思決定、リンク、アーティファクト）（R）。
利害関係者-製品/支払い/ゲームプロバイダ/セキュリティ（C/I）。

SEV1あたりの最小値：IM+TL+Comms+Scribe。SEV2上の役割を組み合わせることができます。

5） ウォールルームチャットOps

個々のチャンネル：'#incident-warroom- <id>'（作業中）、'#incident-status'（更新のみ）。
テンプレートコマンド：'/incident start'、'/status update'、 '/call <owner>'、'/rollback'、 '/freeze'、'/scale+N'。
ボットはコンテキストを引き上げます：最近のリリース、ダッシュボード、関連するアラート、トレースexemplars、依存性スキーム。
コミュニケーションのルール：簡単に、事実に、1人のスピーカー（TL）、 IMは緩和します。

6）トリガーおよびゲート

SLOゲート：高速/遅い書き込み、支払い変換ドロップ、TTW p95>しきい値、p99 API→、支払いキューが発火しています。
自動アクション：カナリアを停止し、ロールバックし、モードを低下させる（機能を制限）、高周波合成を可能にします。
フリーズ：安定化とPIR前のすべてのリリース/フット移行。

7）典型的なシナリオ（runabookパターン）

A）支払い： PSPでのタイムアウト/失敗の増加

1.プロモートを停止し、支払いループのリリースを凍結します。
2.PSPルートをスタンバイのルートに切り替え、ポリシーでタイムアウト/リトレイを上げます。
3.不完全なトランザクションの調整、idempotentキーによる繰り返し。
4.Comms Communication→Support：予約はできますか？ETAだ。

B）リリース後のAPI p99と5xx

1.ロールバック（青緑/カナリア→安定）。
2.キャッシュのヒット、キューの深さ、データベース/ゲームプロバイダのホットスポットを確認します。
3.一時的なスケーリング、フィーチャーフラグを介して重いフィーチャーを制限します。

C）ゲームプロバイダが利用できません

1.トラフィックを利用可能なスタジオ/ゲームに切り替え、ステータスバナーを表示します。
2.30〜60秒ごとに合成チェックをオンにします。
3.報酬/ボーナスに同意する（ポリシーによる）-PIRに追加します。

D）漏れ/疑われるPII

1.コンポーネントの分離、キー/トークンの失効、ログ収集（WORM）。
2.法的コミュニケーション/規制の調整。
3.事後アクション：秘密の回転、マスキング、アクセス。

8）コミュニケーション（内部/外部）

更新頻度：SEV1-15-30分毎、SEV2-30-60分。

• 何が壊れている：「PSP-X経由の預金：タイムアウトの上昇」。
• 影響を受ける：「TR/BR、 ~ストリームユーザーの18％」。
• それが始まったとき：「12：07 EET、 SEV1.」
• 私たちが行うこと：「PSP-Yへのルートの切り替え、リトレイ/レートキャップが有効」。
• 次のアップデート：「20分で」。
• お問い合わせ先：「IM@duty-im、 TL@oncall-pay」。

公開ステータス（ページ/ソーシャルネットワーク）-略称、PIIなし、不要な詳細、ETAとさらなる更新へのリンク。

9）アーティファクトの収集と監査

イベントタイムライン（分精度）、サービスバージョン、フィーチャーフラグ、設定変更。
ダッシュボードの写真、おおよそのルート（trace_id)、ログ「前/中/後」。
チケット、PR、リリース、runabooksへのリンク。
通信レポート（when/to/what）。
それはすべてインシデントカードに追加されます。

10）閉鎖とPIR（事後レビュー）

• 概要：何が起こったのか、スケール、期間、SEV。
• 影響：ユーザー/リージョン、SLO/SLA、 Fin。エフェクト。
• タイムライン：詳細は、分単位で。
• 根本原因：テクニカル+組織（以前に検出されなかった理由）。
• 検出と防御：助けられたもの/失敗したもの（アラート、合成、フィッシュフラグ）。
• アクションアイテム：特定のタスク、所有者、期限（および効果を確認する方法）。
• 教訓：プロセス/アーキテクチャ/オブザビリティの変化。

ルール：無料、最大の事実、完了したアイテムをチェックする2-4週間後に必須のフォローアップ。

11）プロセス信頼性の指標

MTTD-検出する平均時間

MTTA（……承認）-オンコール確認の前に。
MTTR（……復元）-SLOが復元されるまで。
Change Failure Rate：インシデントが発生するリリースの％。
SEVによるインシデントレート、ドメイン別ディストリビューション（Payments/Games/Infra）。
アラート品質：騒々しい/falseの割合、アラート後のアクション時間。
Comm-SLA：ステータス更新の頻度に準拠しています。

12） SLOおよびリリースとの統合

Gates in CD： canary promotion only with green SLO proxies （availability、 p95、 conv、 TTW）。
凍結手順：fast-burn/SEV1時-PIRの前にリリースを停止します。
グラフの自動注釈：リリース/フラグ/マイグレーションはダッシュボードに表示されます。

13）規制とコンプライアンス

PII：ログ/トラック、WORM監査ストア、アクセス制御のマスキング/エイリアシング。
地域：許可された管轄外でユーザーデータを取得しないでください。
レポート：規制当局への正式な手紙/通知-テンプレートとエスカレーションプロセス。

14）学習と準備（ゲームデー）

四半期ごとの演習：「PSPドロップ」、「ゲームプロバイダが利用できない」、「p99サージ」、「キーリーク」。
MTTA/MTTRのタイマー、練習のレトロ。
runabooksと連絡先を更新し、ChatOpsコマンドをチェックします。

15）準備チェックリスト（インシデント前）

1.SEV規則とエスカレーションマトリックスは合意した。
2.通話中の回転、IM/TL/Comms/Scribeが割り当てられます。
3.主なシナリオ（支払い、ゲーム、データベース、キャッシュ、キュー）のためのRunabooks。
4.SLOカードとバーンレートアラート、ステータスページ。
5.ChatOpsボット：コマンド、自動コンテキスト、ステータステータステンプレート。
6.PIRテンプレートとインシデントカード。
7.定期的なゲームデーと連絡先/権利の改訂。
8.フリーズポリシーと「赤いボタン」（ロールバック/キルスイッチ）。

16） Antipatterns

単一のIMはありません、「群衆がリード」→混乱と遅延。
SLOゲートの欠如→遅れ検出、騒々しいアラート。
フリーズ→カスケードクラッシュのないインシデント中のリリース。
ログとトレイルでは十分ではなく、アーティファクト→弱いPIRがありません。
告発文化→隠された間違い、エスカレーションの恐怖。
感動的なコミュニケーション→ビジネス/ユーザーの信頼の喪失。

17）テンプレート（Wikiにコピー）

A）インシデントカード（YAML）

yaml id: INC-2025-11-005 title: PSP-X timeouts in TR/BR sev: SEV1 start_at: 2025-11-05T12:07:00+02:00 status: active impact: "Deposits via PSP-X failing for ~18% users (TR, BR)"
im: "@oncall-im"
tl: "@oncall-pay"
comms: "@oncall-comms"
scribe: "@oncall-scribe"
mitigations:
- "Reroute to PSP-Y"
- "Enable retries and raise timeouts"
next_update_in: "20m"
links:
grafana: "<dashboard-url>"
traces: "<tempo-link>"
logs: "<loki-query>"
runbook: "payments/psp_timeout"

B）ステータス更新（内部）

[12:25] SEV1 PSP-X timeouts — TR/BR
Impact: ~18% deposits affected. SLO fast-burn active.
Mitigation: Rerouting to PSP-Y; retries enabled; release freeze.
ETA next update: 12:45 EET
IM: @oncall-im      TL: @oncall-pay

C） PIR（キャップ）

Summary, Impact, Timeline, Root Cause (tech+org),
Detections/Defenses, Action Items (owner+due), Lessons Learned.

概要

強力なインシデント管理は構造+規律です。事前に合意された役割、SLOゲート、作業中のrunabooks、透明なコミュニケーション、および「無邪気な」PIR。このループは、MTTA/MTTRを削減し、ダウンタイムのコストを削減し、ユーザーの信頼を構築し、大胆なリリースを可能にします。