事件管理

（部分： 技术和基础设施）

简短摘要

事件管理是快速恢复用户价值并最大程度地减少对业务造成的损害的可重复过程。支持-明确的角色（事件管理器,技术领导,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，降低了停机时间，增强了用户信心，并允许更大胆但更安全的发布。