告警与应急响应
用生活化的比喻，让你从"出了问题才知道"到"能在问题影响玩家前发现并处理"
前置知识：第06章 游戏性能监控（告警的数据来源）、第07章 游戏日志系统（日志异常检测）
阅读指南（初学者必看）
为什么你需要学习告警与应急响应？
没有告警 = 等玩家投诉才知道出问题 没有应急 = 出了问题手忙脚乱不知道怎么修
学完本章，你能回答：
- 告警怎么分级？P0/P1/P2 分别怎么处理？
- 告警渠道怎么配置？怎么避免告警风暴？
- 故障处理 SOP 是什么？怎么做到 30 分钟恢复？
- 降级策略有哪些？游戏怎么优雅降级？
- 混沌工程是什么？
本文结构
第一部分：告警体系
第二部分：告警降噪
第三部分：应急响应流程
第四部分：降级策略
第五部分：故障复盘与混沌工程
一、告警体系
生活类比：告警就像"火警系统"——烟雾传感器（监控）检测到异常 → 触发警报（告警）→ 消防队出动（应急响应）。
告警分级
| 级别 | 定义 | 响应时间 | 恢复时间 | 通知渠道 |
|---|---|---|---|---|
| P0（紧急） | 服务不可用，影响所有玩家 | 5 分钟 | 30 分钟 | 电话 + 短信 + 钉钉 |
| P1（严重） | 核心功能受影响 | 15 分钟 | 1 小时 | 短信 + 钉钉 |
| P2（一般） | 非核心功能受影响 | 1 小时 | 4 小时 | 钉钉 |
| P3（提示） | 需要关注但不影响功能 | 工作时间 | 下个版本 | 邮件 |
典型告警规则
P0 触发条件：
- 服务器宕机（健康检查连续失败 3 次）
- 数据库不可用
- 所有房间服务不可用
- 支付功能完全不可用
P1 触发条件：
- 登录失败率 > 10%
- API P99 延迟 > 2s
- 5xx 错误率 > 5%
- Redis 连接池耗尽
P2 触发条件：
- 排行榜查询延迟 > 1s
- 聊天消息发送失败率 > 5%
- CPU 使用率 > 80% 持续 10 分钟
P3 触发条件：
- GC 时间略长（P99 > 200ms）
- 内存使用率 > 75%
- 磁盘使用率 > 80%
二、告警降噪
生活类比：告警降噪就像"消噪耳机"——过滤掉不重要的声音，只让你听到真正需要关注的。
降噪策略
| 策略 | 说明 | 效果 |
|---|---|---|
| 聚合 | 相同告警 5 分钟内只发一次 | 减少 80% 重复告警 |
| 抑制 | P0 告警时，相关的 P1/P2 不重复发 | 避免告警风暴 |
| 升级 | P1 告警 30 分钟未处理 → 升级为 P0 | 防止告警被忽视 |
| 静默 | 计划内维护期间静默相关告警 | 避免误报 |
| 收敛 | 同一服务多个告警合并为一条 | 减少噪音 |
告警风暴案例
问题：数据库慢 → 所有服务超时 → 100+ 条告警同时发出 → 淹没真正重要的告警
解决：
1. 抑制：数据库 P0 告警发出后，抑制所有服务的 P1/P2 超时告警
2. 根因分析：标注"根因告警"和"衍生告警"
3. 只通知根因告警的负责人
Alertmanager 配置
route:
group_by: ['alertname', 'severity']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
receiver: 'default'
routes:
- match:
severity: p0
receiver: 'p0-team'
continue: true
- match:
severity: p1
receiver: 'p1-team'
inhibit_rules:
- source_match:
severity: 'p0'
target_match:
severity: 'p1'
equal: ['instance']
三、应急响应流程
生活类比：应急响应就像"消防演习"——平时练习过，真正着火时才不会慌。
故障处理 SOP
1. 发现（0分钟）
- 监控告警触发
- 或玩家反馈（客服转告）
2. 确认（5分钟内）
- 确认故障范围（全量/部分/单服）
- 确认影响（登录/战斗/支付）
- 通知相关人员（群内@负责人）
3. 止损（15分钟内）
- 降级：关闭非核心功能
- 限流：限制新用户进入
- 回滚：如果是新版本问题
4. 恢复（30分钟内）
- 修复问题
- 验证修复
- 逐步恢复流量
5. 复盘（24小时内）
- 根因分析（5 Whys）
- 改进措施
- 防止复发
5 Whys 根因分析示例
问题：玩家充值后没收到游戏币
1 Why：为什么没收到游戏币？
→ 充值回调处理失败
2 Why：为什么回调处理失败？
→ 游戏服务调用失败
3 Why：为什么游戏服务调用失败？
→ 服务超时
4 Why：为什么超时？
→ 数据库查询慢
5 Why：为什么数据库查询慢？
→ 缺少索引，全表扫描
根因：缺少数据库索引
改进：加索引 + 慢查询告警
四、降级策略
生活类比：降级就像"飞机遇到气流时降低高度"——牺牲部分性能/功能，保证安全。
| 降级策略 | 说明 | 游戏场景 |
|---|---|---|
| 只读模式 | 禁止写入，允许读取 | 数据库主库故障时切从库只读 |
| 排队模式 | 限制同时在线人数 | 服务器过载时排队进入 |
| 功能降级 | 关闭非核心功能 | 关闭聊天/排行榜/活动 |
| 数据降级 | 返回缓存数据 | 排行榜返回昨日缓存 |
| 服务降级 | 停止某些服务 | 关闭匹配服务，保留已开房间 |
| 质量降级 | 降低画面质量 | 关闭特效、降低帧率 |
游戏降级优先级
不可降级（核心）：
✗ 登录/注册
✗ 战斗逻辑
✗ 支付/充值
✗ 数据持久化
可降级（非核心）：
✓ 聊天系统
✓ 排行榜
✓ 成就系统
✓ 活动系统
✓ 皮肤/装饰
✓ 好友列表
五、故障复盘与混沌工程
故障复盘原则
复盘原则：对事不对人。聚焦"系统哪里可以改进"而非"谁犯了错"。每个改进项都要有负责人和截止时间。
混沌工程
混沌工程 = 主动注入故障（随机杀 Pod、增加延迟），验证系统的容错能力。Netflix 的 Chaos Monkey 是代表。
游戏团队可以先从"手动故障演练"开始：
- 模拟某台服务器宕机，看服务是否自动恢复
- 模拟数据库主库故障，看是否自动切换到从库
- 模拟网络分区，看游戏状态是否一致
自问自答
Q1：告警太多怎么办？
先做降噪：聚合 + 抑制 + 收敛。然后审查每条告警规则——3 个月没触发过的规则考虑删除。告警应该"少而精"，每条都是需要人工处理的。
Q2：P0 告警半夜触发怎么保证响应？
值班制度：轮值 on-call，P0 电话直呼。确保手机不静音。建议：凌晨 P0 自动触发扩容+降级，白天再人工复盘。
Q3：降级和熔断有什么区别？
降级是"主动关闭功能"（人为决策），熔断是"自动停止调用"（系统决策）。降级粒度更大（整个功能），熔断粒度更小（单个接口）。
Q4：故障复盘怎么避免"甩锅"？
复盘原则：对事不对人。聚焦"系统哪里可以改进"而非"谁犯了错"。每个改进项都要有负责人和截止时间。
Q5：混沌工程是什么？
主动注入故障（随机杀 Pod、增加延迟），验证系统的容错能力。Netflix 的 Chaos Monkey 是代表。游戏团队可以先从"手动故障演练"开始。
Q6：告警通知发到钉钉/企业微信怎么配置？ A: Alertmanager 支持 webhook，可以配置钉钉机器人的 webhook URL。或者使用 PrometheusAlert 这类开源工具，内置了国内各种 IM 的集成。
实践任务
- 制定告警规则：P0/P1/P2/P3 四级告警，每级 3~5 条规则
- 配置告警通知：Prometheus Alertmanager → 钉钉/企业微信
- 编写故障 SOP：为"服务器宕机"和"数据库故障"写应急响应文档
- 手动故障演练：手动 kill 一个服务，观察告警和恢复
- 复盘演练：假设一次线上故障，用 5 Whys 分析根因
- 配置告警降噪：聚合 + 抑制 + 静默，减少无效告警
与其他章节的关联
| 本节内容 | 关联章节 | 关联点 |
|---|---|---|
| 监控 | 第06章 游戏性能监控 | 告警基于监控数据 |
| 日志 | 第07章 游戏日志系统 | 日志辅助根因分析 |
| 降级 | 3_1 第14章 游戏实时通信优化 | 弱网降级策略 |
| 灰度发布 | 第09章 版本管理与灰度发布 | 回滚是应急手段之一 |
| SRE | 5_2 前沿技术 | SRE 实践方法论 |
⬅️ 上一章：游戏日志系统 | ➡️ 下一章：版本管理与灰度发布