4. 事故响应体系概述：SRE事故响应金字塔、告警、升级、复盘流程
在SRE实践中，事故响应不是临时救火，而是一套从检测→响应→恢复→改进的闭环体系。本章围绕SRE事故响应金字塔，拆解告警、升级、复盘三大核心流程，并与质量门禁的阈值卡点建立关联。
4.1 SRE事故响应金字塔
SRE事故响应金字塔将响应活动按优先级和频率分层，底层高频、低影响，顶层低频、高影响。每一层都对应不同的响应策略和自动化程度。
核心原则： 金字塔底层靠自动化与自愈，顶层靠人工专家与结构化复盘。质量门禁的阈值卡点主要作用于底层和中层，提前阻断或降级事故。
4.2 告警体系：从指标到通知
告警是事故响应的第一道触发点。一个成熟的告警体系需要解决三个问题：告什么、怎么告、告给谁。
4.2.1 告警类型与阈值设计
| 告警类型 | 触发条件 | 响应要求 | 质量门禁关联 |
|---|---|---|---|
| P0 (紧急) | 核心服务不可用 / 数据丢失 | 立即响应，≤5分钟 | 门禁阻断部署，自动回滚 |
| P1 (严重) | 功能严重受损 / 延迟飙升 | ≤15分钟响应 | 门禁暂停发布，触发降级 |
| P2 (一般) | 非核心功能异常 / 错误率上升 | ≤1小时响应 | 门禁记录，允许继续但标记 |
| P3 (警告) | 资源接近阈值 / 慢查询 | 下一个工作日处理 | 门禁仅记录，不阻断 |
最佳实践： 告警阈值应基于SLI/SLO设定，避免“告警风暴”。质量门禁的阈值卡点可以复用告警阈值，但门禁更强调事前阻断，告警更强调事中通知。
4.2.2 告警生命周期
- 检测： 监控系统采集指标，与阈值比对。
- 抑制： 去重、静默、依赖关系分析，避免重复告警。
- 通知： 通过PagerDuty、钉钉、Slack等渠道触达On-Call人员。
- 确认： 响应人Acknowledge，表示已接手。
- 解决： 修复后告警自动恢复或手动关闭。
4.3 升级机制：当告警未被及时处理
升级是事故响应体系的“安”。当一级响应人未能在规定时间内确认或处理告警，系统自动将事故升级到更高层级。
4.3.1 升级路径设计
| 层级 | 角色 | 升级条件 | 升级动作 |
|---|---|---|---|
| L1 | 值班SRE | 告警触发 | 立即响应，尝试自愈或回滚 |
| L2 | SRE团队Lead | L1 5分钟未确认 | 电话+IM强提醒，协调资源 |
| L3 | 值班经理 / 架构师 | L2 10分钟未解决 | 跨团队协调，启动War Room |
| L4 | VP / CTO | P0事故持续30分钟 | 业务决策，对外公告 |
常见陷阱： 升级路径不清晰或升级时间过长，会导致事故响应延迟。建议在质量门禁中预设升级时间阈值，当门禁阻断后长时间未人工干预，自动触发升级流程。
4.4 复盘流程：从事故到改进
复盘（Postmortem）是SRE事故响应金字塔的顶层，也是持续改进的核心。复盘不是追责，而是系统性学习。
4.4.1 复盘五步法
- 时间线重建： 精确记录事故从检测到恢复的每个关键时间点。
- 根因分析： 使用5 Whys或因果图，找到根本原因而非表象。
- 影响评估： 量化事故对用户、业务、系统的影响。
- 行动项制定： 每个根因对应一个可执行的改进措施，明确负责人和截止日期。
- 跟踪闭环： 在后续Sprint中跟踪行动项完成情况，更新门禁阈值。
4.4.2 复盘与质量门禁的联动
复盘产生的行动项应直接反馈到质量门禁的阈值卡点中：
- 新增阈值： 如果事故由某个未监控的指标导致，则在门禁中增加该指标的阈值卡点。
- 调整阈值： 如果现有阈值过于宽松导致事故漏过，则收紧门禁阈值。
- 新增规则： 如果事故由特定变更模式引发，则增加Argo CD PreSync/PostSync钩子检查规则。
4.5 事故响应体系与质量门禁的集成点
| 事故响应阶段 | 质量门禁卡点 | 集成方式 |
|---|---|---|
| 预防 | PreSync钩子、部署前阈值检查 | Argo CD PreSync Job执行健康检查，不通过则阻断 |
| 检测 | 实时指标监控、告警规则 | 门禁阈值与告警阈值共享配置，保持一致性 |
| 响应 | 自动回滚、降级策略 | 门禁触发后自动执行Argo CD Rollback或Scaling |
| 恢复 | PostSync验证、健康检查 | 恢复后门禁自动验证服务健康，确认恢复完成 |
| 改进 | 阈值调整、规则更新 | 复盘行动项通过GitOps提交门禁配置变更 |
核心观点： 质量门禁不是独立于事故响应体系之外的工具，而是嵌入在金字塔每一层的自动化防御节点。通过阈值卡点，将事故响应从“被动救火”转变为“主动防御”，最终降低MTTR、提升系统韧性。