事件管理

（部分： 技術和基礎設施）

簡短摘要

事件管理是快速恢復用戶價值並最大程度地減少對業務造成的損害的可重復過程。支持-明確的角色（事件管理器,技術領導,Comms）、SLO門、升級、ChatOps流程、準備好的工具包以及帶有可測量動作項目的「無罪」事件後分析。

1）目標和原則

速度和安全：快速診斷→安全穩定→持續恢復。
唯一所有者：指定的Incident Manager （IM）做出流程決策。
通信作為一種產品：可預測的升級到堆放者和用戶。
數據>意見：SLO/度量/traces/logi是真理的來源。
Blameless：無個人指控的原因分析；專註於系統改進。

2）事件分類（Severity/Impact/Urgency）

• SEV1（危急）：對收入/TTW/付款造成嚴重損害，>20%的用戶或整個地區；SLA被PII破壞/威脅。
• SEV2（高）：關鍵流的部分退化（存款/賭註/遊戲啟動），影響5-20％。
• SEV3（平均）：二級服務明顯退化，有繞行。
• SEV4（低）：小調,效果有限,不影響SLO/SLA。

影響：誰受到影響（全部/地區/特南特/頻道）。Urgency：降解率（錯誤預算中的快速燒傷/慢燒）。

3）事件生命周期

1.Detect 是來自警報器/SLO/合成/報告的信號。
2.Acknowledge-呼叫確認接收,指定IM。
3.Triage-SEV/Impact評估，假設的收集，戰爭室的開放。
4.Mitigate-穩定（回滾/路線切換/ficheflagi/縮放）。
5.Communicate是常規的升級狀態（內部/外部）。
6.Recover-完整的SLO/業務指標恢復。
7.Close-年表固定，文物收集，PIR（RCA+動作項目）。

4）角色和責任（RACI計劃）

事件管理器（IM）-進程所有者、分配角色、監視時間、做出處理器決策（R）。
技術領導（TL）-維護診斷/假設/假設,協調工程師（A/R）。
Communications （Coms）-狀態升級、支持/業務/PR通信、狀態-頁面（R）。
Scribe是協議（時間線，做出的決定，鏈接，工件）（R）。
Stakeholders-產品/付款/遊戲提供商/安全性（C/I）。

最低SEV1：IM+TL+Comms+Scribe。SEV2允許角色組合。

5) War-Room и ChatOps

單個頻道：'#incident-warroom- <id>'（工作）、'#incident-status'（僅限更新）。
模板命令：'/incident start'，'/status update'，'/call <owner> '，'/rollback'，'/freeze'，'/scale+N'。
機器人拉動上下文：最新版本，dashbords，相關的alerta，trace exemplars，依賴方案。
溝通規則：簡而言之，根據事實，一個演講者（TL），IM主持。

6）觸發器和門戶

SLO門：快速/慢燃燒,支付轉換下降,TTW p95>閾值,p99 API ↑,支付隊列「燃燒」。
自動輔助：停止金絲雀,滾回,啟用階梯模式（功能限制）,啟用高頻合成器。
Freeze：所有在穩定和PIR之前停止的發布/遷移。

7）類型方案（runabook模式）

A）付款： PSP的時間限制/拒絕增加

1.停止促銷並凍結支付回路版本。
2.將PSP路線切換到備用路徑，在政策上提高taymout/retrai。
3.對未完成的事務進行核對，重復使用等效密鑰。

4.Comms → sapport溝通： 儲備金在運作嗎？ETA.

B）API p99↑和5xx發布後

1.回滾（藍綠色/金絲雀→馬able）。
2.檢查高速緩存命中率、隊列深度、數據庫熱點/遊戲提供商。
3.臨時縮放，通過特征斑塊限制重型幻影。

C）遊戲提供商不可用

1.將流量切換到可用的工作室/遊戲,顯示狀態橫幅。
2.每30-60秒啟用合成檢查。
3.同意補償/獎金（根據政策）-向PIR捐款。

D）泄漏/懷疑PII

1.組件隔離、密鑰/令牌重寫、日誌收集（WORM）。
2.協調法律交流/監管。
3.事後活動：秘密輪換，掩蓋，訪問。

8）通訊（內部/外部）

上升頻率：每15-30分鐘SEV1分鐘，SEV2-30-60分鐘。

• 打破了：「通過PSP-X的存款：時間表的增長。」
• 誰受到影響：「TR/BR，~流用戶的18%」。
• 當開始：「12：07 EET，SEV1.」
• 我們做什麼：「我們將路線切換到PSP-Y，包括轉發/投註限制。」
• 下一個更新是「20分鐘後」。
• 聯系人：「IM@duty-im，TL@oncall-pay。」

公共狀態（頁面/社交網絡）-縮寫，沒有PII或多余的細節，具有ETA並引用了進一步的更新。

9）文物收集和審計

事件時間線（分鐘精度），服務版本，幻燈片，配音更改。
Dashbords快照，大致軌跡（trace_id)，logi「之前/期間/之後」。
Tikets，PR，發行版，runabuki鏈接。
通信報告（何時/何時/何時）。
一切都加在事件卡上。

10）關閉和PIR（事後評論）

• 摘要：發生了什麼，規模，持續時間，SEV。
• 影響：用戶/地區，SLO/SLA，吹風機。效果。
• 時間線：細節，每分鐘。
• Root Cause：技術+組織（為什麼以前沒有指定）。
• Detections&Defenses：幫助/失望的原因（Alerts,合成,ficheflagi）。
• 行動項目：具體任務，所有者，時機（以及如何驗證效果）。
• Lessons Learned：我們在過程/架構/可觀察性方面的變化。

規則：無指控，最高事實，在2-4周內強制追查已執行的項目。

11）過程可靠性度量

MTTD（平均檢測時間）-平均檢測時間。
MTTA (…Acknowledge）-在電話確認之前。
MTTR (…還原）-在SLO恢復之前。
Change Failure Rate是導致事件的發行版的百分比。
SEV的事件率，域分配（Payments/Games/Infra）。
警報質量：噪音/虛假的比例，警報後的行動時間。
Comm-SLA：遵守狀態升級的周期性。

12）與SLO和發行版集成

CD中的門戶：僅在綠色SLO代理下（可用性，p95，conv，TTW）進行金絲雀促銷。
Freeze例程：fast-burn/SEV1時-在PIR之前停止發行。
圖中的自動註釋：在行車記錄板上可見版本/標誌/遷移。

13）監管和合規性

PII：在邏輯/跟蹤中掩碼/別名，審計的WORM存儲，訪問控制。
區域性：不將用戶數據帶到允許的管轄範圍之外。
報告：正式給監管機構的信/通知-模板和升級過程。

14）培訓與準備（遊戲日）

季度演習：「PSP下跌」、「遊戲提供商不可用」、「p99激增」、「鑰匙泄漏」。
MTTA/MTTR上的計時器，復古練習。
更新符號和聯系人,檢查ChatOps命令。

15）準備就緒清單（事件發生前）

1.商定了SEV規則和升級矩陣。
2.已分配電話輪換IM/TL/Comms/Scribe。
3.關鍵場景（付款，遊戲，DB，緩存，隊列）的Runabuki。
4.SLO卡和burn-rate alerta，狀態頁面。
5.ChatOps-bot：命令、自動對比、狀態模式。
6.PIR模板和事件卡。
7.定期的遊戲日和聯系人/權利修訂。
8.freeze策略和「紅色按鈕」（rollback/kill-switch）。

16）反模式

沒有一個IM，「人群領先」→混亂和延誤。
沒有SLO門→檢測遲到，噪音異常。
事件中無凍結釋放→級聯故障。
博客和跟蹤還不夠，沒有人工制品→ PIR薄弱。
指責文化→隱性錯誤，害怕升級。
「靈感」通信→失去商業/用戶信心。

17）模板（復制到您的維基）

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門戶，工作的runabook，透明通信和「無罪」PIR。這樣的回路減少了MTTA/MTTR，降低了停機時間，增強了用戶信心，並允許更大膽但更安全的發布。