インシデントと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
Ошибочная доля 5xx > SLO sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01

Burn-rate быстрый (пример)
(sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m])))
/ (1 - SLO) > 14.4

7）プレイブック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: <ФИО>
comms_lead: <ФИО>
scope: regions: [eu-west-1], tenants: [prod], services: [api, payments]
impact: "5xx=12% (обычно <0.5%), конверсия депозитов -20%"
mitigation: "откат на 1.23.4, включен rate-limit 2k rps, фича X выключена"
timeline:
- "17:42: алерт SLO burn-rate быстрый"
- "17:46: назначен IC, открыт war-room"
- "17:52: найден релиз 1.24 как кандидат"
- "18:02: откат завершен, 5xx вернулись к 0.3%"
artifacts:
dashboards: [...]
logs: [...]
traces: [...]
risk: "возможен очередной всплеск при включении фичи X"
next_steps: "канареечный релиз, тесты, постмортем до 2025-11-05"

9） SREプレイブックテンプレート（Markdown）

markdown
Плейбук: <название>
Область/симптомы
Список детекторов, сигнатуры в метриках/логах/трассах.

Быстрая стабилизация (Triage & Mitigation)
- [ ] Ограничить трафик/включить WAF-правило/фичефлаг OFF
- [ ] Роллбэк/канареечный релиз/выкатить фикс конфигурации
- [ ] Включить деградационный режим (read-only, кэш-форс)

Диагностика (RCA hints)
- Метрики: … Логи: … Трассы: …
- Частые первопричины/чек-лист гипотез

Риски и коммуникации
- Внутренние/внешние апдейты, SLA-обязательства

Верификация
- [ ] SLO восстановлено (порог/время окна)
- [ ] Нет регресса по смежным сервисам

Последующие действия
- CAPA, задачи в backlog, обновление алертов/дашбордов/плейбука

10）典型的なプレイブック

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
Верификация:
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/誤った予算の測定、検出器とプレイブックの継続的な改善-これにより、ダウンタイムのリスクとコストが直接削減されます。