id: “9169ed88-3b44-4f92-9d19-10f031a8c320” name: “基于严重程度的回滚和缓解检查点” description: “一种可重复使用的事件响应能力，定义了明确的、基于严重程度的回滚和缓解行动的通过/不通过标准——确保决策客观、及时，并独立于个人判断。” version: “0.1.1” tags:
- “事件响应”
- “站点可靠性工程”
- “待命”
- “回滚”
- “缓解”
- “决策门”
- “可观察性”
- “升级” triggers:
- “定义回滚通过-不通过标准”
- “设置缓解决策阈值”
- “添加客观事件行动门”
- “强制执行时间限制恢复检查”
- “将回滚与可观察指标绑定”
- “压缩待命事件手册”
- “生成简洁事件响应速查表”
- “提炼回滚和升级规则”
- “创建待命工程师事件检查清单”
- “使手册在压力下可快速浏览”
基于严重程度的回滚和缓解检查点
一种可重复使用的事件响应能力，定义了明确的、基于严重程度的回滚和缓解行动的通过/不通过标准——确保决策客观、及时，并独立于个人判断。
提示
目标
在服务事件期间强制执行客观的、基于严重程度的回滚和缓解检查点——每个检查点都有基于实时指标、时间限制和影响阈值的可验证通过/不通过标准。输出清晰的决策日志条目，指示每个检查点的’通过’、‘不通过’或’待定’。
约束与风格
- 所有标准必须可观察、可测量且工具就绪（例如，Prometheus查询、Datadog监视器、SLO燃烧率）——避免主观短语如’似乎稳定’或’看起来更好’。
- 仅使用事实性、中立语言：陈述观察到什么和采取什么行动，从不陈述谁决定或为什么失败。
- 对于每个严重级别（SEV-0到SEV-2），定义恰好一个主要回滚检查点和一个主要缓解检查点——两者都包含： • 触发条件（例如，“错误率 > 5%持续90秒”） • 验证方法（例如，“通过/health端点 + 延迟直方图验证”） • 时间限制（例如，“必须在触发后4分钟内完成”） • 通过/不通过阈值（例如，“如果行动后60秒内95%+请求成功，则通过；否则不通过”）
- SEV-3没有正式检查点——通过积压工作流程处理。
- 从不包括指责、推测、根本原因断言或不可验证状态（例如，‘调查中’、‘正在修复’）。
- 输出格式：一个markdown表，列：严重程度 | 检查点类型 | 触发 | 验证 | 时间限制 | 通过/不通过阈值 | 决策日志示例。
- 将输出压缩成单个、可快速浏览的文档，少于300字，仅使用粗体标题、项目符号和紧凑表——无段落、解释、代码块、标注、表情符号、链接或脚注。
- 仅保留基于指标或工件的标准（例如，‘错误率 > 1.5%’、‘回滚工件签名并测试’、‘72分钟稳定性验证’）。
- 用通用、去标识化的术语替换所有实例特定引用：‘服务’、‘组件’、‘API’、‘数据库’、‘域’。
- 强制执行严格基于角色的所有权（例如，‘技术负责人’、‘SRE’、‘IC’）——从不使用个人或团队。
- 语言：仅英语；祈使语气；现在时。
触发器
- 定义回滚通过-不通过标准
- 设置缓解决策阈值
- 添加客观事件行动门
- 强制执行时间限制恢复检查
- 将回滚与可观察指标绑定
- 压缩待命事件手册
- 生成简洁事件响应速查表
- 提炼回滚和升级规则
- 创建待命工程师事件检查清单
- 使手册在压力下可快速浏览