インシデントとSREプレイブック
1）事件とSLOとの関係
インシデントとは、SLO/サービス機能に違反したり、違反のリスクを作成したりするイベントです（誤った予算は容認できないほど迅速に焼却されます）。
古典的な指標：MTTD、 MTTA、 MTTR、 MTBF。
予算エラーとバーンレートが優先度とエスカレーションウィンドウを決定します。
2）重大度レベル（SEV）と基準
SEVトリガ：5xx％、 p95>しきい値を超え、支払い減少スパイク、Kafka-lag>しきい値、NodeNotReady> X分、TLSの有効期限は<7日、DDoS信号/リークです。
3）役割と責任（RACI）
インシデントコマンダー（IC）-唯一の意思決定、タスクフロー管理、SEVステータス変更。
Ops Lead （Tech Lead）-技術戦略、仮説、修正の調整。
Communications Lead （Comms）-ステータスの更新（内部/外部）、StatusPage/chat/mail。
Scribe （Chronicler）-タイムライン、ソリューション、アーティファクト、グラフ/ログへのリンク。
通話中のエンジニア/中小企業-Playbookアクションの実行。
セキュリティ/プライバシー-セキュリティまたはPIIインシデントで有効。
FinOps/Payments-請求/PSP/コストに影響を与える場合。
4）インシデントライフサイクル
1.検出（アラート/レポート/合成）→インシデントカードの自動作成。
2.トリアージ（IC割り当て、SEV割り当て、最小コンテキストコレクション）
3.安定化（軽減：フィーチャー/ロールバック/レート制限/フェイルオーバーをオフにします）。
4.調査（RCA仮説、事実の収集）。
5.サービスリカバリ（SLOの検証、観察）。
6.コミュニケーション（内部/外部、最終報告）。
7.死後（無料、CAPAプラン、所有者、期限）。
8.予防（テスト/アラート/プレイブック/フラグ、チームの追加トレーニング）。
5）コミュニケーションと「戦争の部屋」
Unified Incident Channel（'#inc-sev1-YYYYMMDD-hhmm'）、事実と行動のみ。
ラジオプロトコルスタイルコマンド： "IC：ロールバックバージョン1を割り当てます。24→ETA 10分"
ステータスアップデート：15分ごとにSEV-1、 30〜60分ごとにSEV-2します。
Status Page/external communication（ステータスページ/外部通信）-Commsを介してテンプレートでリードします。
禁止：平行「静かな」部屋、テストされていない仮説は、共通のチャネルに。
6）アラートとSLO-burn（ルール例）
速いチャネル（1-5分）および遅いチャネル（1-2 h）バーンレート。
マルチシグナル：予算誤差、5xx％、 p95、 Kafka-lag、支払減少率、合成。
症状を安定させた後にのみ、根本原因を検索します。
promql
Error rate 5xx> SLO sum (rate (http_requests_total{status=~"5"..}[5m]) )/sum (rate (http_requests_total[5m]))> 0. 01
Burn-rate fast (example)
(sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m])))
/ (1 - SLO) > 14. 47）プレイブックvsランブック
Playbook-インシデントの種類（分岐、条件、リスク）によるアクションのシナリオ。
Runbook-ステップ/コマンド（チェック、修正、検証）の特定の「マップ」。
ルール：Playbookは複数のランブック（ロールバック、フィーチャーフラグ、フェイルオーバー、スケーリング、トラフィックのブロックなど）を指します。
8）インシデントカードテンプレート
yaml id: INC-YYYYMMDD-XXXX title: "[SEV-1] Рост 5xx на API /payments"
status: active monitoring resolved sev: 1 reported_at: 2025-11-03T17:42Z ic: <ФИО>
ops_lead: <name>
comms_lead: <name>
scope: regions: [eu-west-1], tenants: [prod], services: [api, payments]
impact: "5xx = 12% (usually <0. 5%), deposit conversion -20%"
mitigation: "rollback to 1. 23. 4, rate-limit 2k rps on, feature X off"
timeline:
- "17:42: alert SLO burn-rate fast"
- "17:46: IC appointed, war-room open"
- "17:52: release 1 found. 24 as a candidate"
- "18:02: Rollback complete, 5xx back to 0. 3%"
artifacts:
dashboards: [...]
logs: [...]
traces: [...]
risk: "another surge is possible when turning on feature X"
next_steps: "canary release, tests, postmortem until 2025-11-05"9） SREプレイブックテンプレート（Markdown）
markdown
Playbook: <title>
Area/symptoms
List of detectors, signatures in metrics/logs/traces.
Triage & Mitigation
- [] Restrict traffic/enable WAF rule/OFF feature
- [] Rollback/canary release/roll out configuration fix
- [] Enable degradation mode (read-only, cache force)
Diagnostics (RCA hints)
- Metrics:... Logs:... Trails:...
- Common Root Causes/Hypothesis Checklist
Risks and communications
- Internal/external updates, SLA obligations
Verification
- [] SLO restored (threshold/window time)
- [] No recourse for related services
Follow-up
- CAPA, tasks in backlog, updating alerts/dashboards/playbook10）典型的なプレイブック
10.1 API 5xxスパイク
安定：問題のあるficheflagをオフにします。Boost API replicasリリースのロールバックを有効にします。
Diagnostics：差分リリース、ログのエラー（最上位の例外）、p95の成長、圧力DB/キャッシュ。
リスク：支払い/バックエンドにカスケード。
10.2。レプリケーションラグ/ロックストーム
安定：重い仕事/レポートの停止；リダイレクトすると、ウィザードのwal_buffers/replika-slotyが増加します。
診断：長いトランザクション、要求のブロック、変更の計画。
固定：インデックス/ヒント、ジョブの再開発、分割クエリ。
10.3カフカ消費者の遅れ
安定：一時的に消費者を拡大します。重要でないサービスからの生産を削減する。パーティー/クォータを増やす。
診断：リバランス、遅いシリアライゼーション、GCは一時停止します。
検証：目標値にラグ→ドロップなし。
10.4 K8s NodeNotReady/リソースストーム
安定：cordon+drain；ロードの再配布；CNI/オーバーレイをチェックすると、ノイズの多いDaemonSetがオフになります。
診断：ディスク圧力、OOM、スロットリング、ネットワークドロップ。
予防：ポッドの中断予算、リソース制限/要求。
10.5 TLS/証明書の有効期限
安定化：秘密/侵入の強制更新。一時的なオーバーライド。
診断：信頼の連鎖、時計スキュー。
予防：アラートT-30/T-7/T-1、自動リニューアル。
10.6 DDoS/異常トラフィック
安定化：WAF/ボットルール、レートリミット/ジオフィルター、上流の小屋の負荷。
診断：攻撃プロファイル（L3/4/7）、ソース、傘。
予防：プロバイダとのanycast、 autoscaling、キャッシュ、play-nice。
10.7支払いPSP停止
安定化：代替PSP/メソッドへのスマートルーティング。ジッタでリトライを上げます。「ソフト」UIの劣化。
Diagnostics：コードによるスパイク障害、API ステータス/PSPステータスページ。
コミュニケーション：ビジネスとサポートのための透明な更新、正しいND/変換統計。
10.8安全インシデント/PIIリーク
安定化：ノード分離/シークレット回転、exfiltrationブロッキング、Legal Hold。
Diagnostics：アクセスのタイムライン、影響を受けるサブジェクト/フィールド。
通知：管轄要件による規制当局/パートナー/ユーザー。
予防：DLP/セグメンテーションの強化、「最小権限」。
11）プレイブックの自動化
ChatOpsコマンド：'/ic set sev 1'、'/deploy rollback api 1。23.4'、'/feature off X'。
Runbook-bots：半自動ステップ（ドレインノード、フリップトラフィック、パージキャッシュ）。
セルフヒーリングフック：検出器→標準緩和（レート制限、再起動、スケール）。
アラートとコマンドからカード/タイムラインを自動作成します。
12） Playbookの質： チェックリスト
- クリア症状と検出器（メトリック/ログ/トレース）。
- リスクアセスメントによる迅速な安定化ステップ。
- コマンド/スクリプトは最新で、ステージングでチェックされます。
- SLO回復の検証。
- コミュニケーションテンプレートと外部更新基準。
- 死後の参照および閉鎖の後のCAPA。
13） Postmortem （blameless）およびCAPA
目標は、犯人を見つけることではなく、学ぶことです。
内容：何が起こったか、何が良い/悪いことが判明したか、要因の貢献（それら+プロセス）、防止するための行動。
言葉：SEV-1-48時間以内に；SEV-2-3仕事日。
CAPA：特定の所有者、タイミング、測定可能な効果（MTTRの削減/MTTDの増加）。
14）法的側面と証拠の基盤
法的保留：ログ/トラック/アラートのフリーズ、書き込み1回のストレージ。
アーティファクトの保管チェーン：役割によるアクセス、整合性制御。
規制通知：管轄区域のタイムライン/テンプレート（特に影響を受ける支払い/PII）。
プライバシー：解析中のPII最小化とマスキング。
15）インシデントプロセスパフォーマンスメトリック
四半期とドメインによるMTTD/MTTA/MTTR。
SEV精度（過小評価/過大評価）。
インシデントの自動緩和の共有。
トップNシナリオのプレイブックのカバレッジ（>90％）。
時間通りにCAPAを実行します。
16）段階別の実装
1.週1： SEVマトリックス、オンコールの役割、一般的なカードテンプレート、戦争部屋の規制。
2.第2週：トップ5の症状のためのプレイブック（5xx、 DB lag、 Kafka-lag、 NodeNotReady、 TLS）。
3.第3週：ChatOps/bot、カードの自動作成、コミュニケーションテンプレート/StatusPage。
4.週4+： 安全プレイブック、PSPの停止、法的保持、通常のドリル/カオスゲーム
17）「高速」ランブック（断片）の例)
ロールバックAPI （K8s）
bash kubectl rollout undo deploy/api -n prod kubectl rollout status deploy/api -n prod --timeout=5m
Verification:
kubectl -n prod top pods -l app=apiドレインノード
bash kubectl cordon $NODE && kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --timeout=10mフィーチャーフラグOFF（例）
bash curl -X POST "$FF_URL/toggle" -H "Authorization: Bearer $TOKEN" -d '{"feature":"X","enabled":false}'18） ミニFAQ
いつSEV-1を上げるのですか？
主要なSLO/ビジネス機能（支払い、ログイン、ゲーム）が苦しみ、バーンレートが数時間前に予算を「食べる」とき。
より重要なのは、RCAまたは回復ですか？
常に安定化し、その後、RCA。安定化までの時間が主な指標です。
すべてを自動化する必要がありますか？
頻繁で安全なステップを自動化して下さい；まれ/危険-半自動およびICの確認によって。
合計
堅牢なインシデントプロセスは、明確な役割とSEVルール、自動化された質の高いプレイブック/ランブック、そして責任のない死後の文化の3つの柱にかかっています。キャプチャパターン、通話中のトレーニング、MTTR/誤った予算の測定、検出器とプレイブックの継続的な改善-これにより、ダウンタイムのリスクとコストが直接削減されます。