sre-reliability-governance

name	sre-reliability-governance
description	为服务或平台设计可审查的可靠性治理方案，覆盖用户旅程 SLI/SLO、错误预算政策、容量模型、依赖与故障域、韧性和恢复、事故准备、变更风险分级及验证门。用于新服务上线前可靠性评审、重大架构或迁移设计、SLO/错误预算建立与复核、容量和灾备规划、事故准备度检查；不用于直接排障、部署、修改监控或操作生产系统。

SRE 可靠性治理

目标

把“可靠”改写成用户可感知、团队可负责、证据可验证的工程承诺。只产出治理设计、评审结论和验证计划；不执行生产变更，不把模板目标冒充业务承诺。

工作边界

• 区分事实、测量、假设、估算和建议；为每个结论标注证据与信心。
• 从关键用户旅程定义可靠性，不从主机在线率或工具默认值倒推目标。
• 让可靠性投入与业务影响、风险容忍、成本和团队能力相称。
• 只建议可审查的变更和验证门。不得部署、改告警、切流量、使用凭据或触发故障演练。
• 不承诺“零故障”“绝对安全”或未经测量的可用性、延迟和容量。

收集输入

先请求最小必要信息；缺失项标为待确认，不自行编造：

1. 服务目的、关键用户旅程、消费者、业务时段和责任人。
2. 当前架构、依赖、数据流、信任边界、故障域和部署拓扑。
3. 流量、延迟、错误、饱和度、增长、季节性和成本基线。
4. 已有 SLI/SLO、事故、告警、运行手册、恢复演练和变更记录。
5. 可接受的降级、停机、数据损失、恢复时间和预算约束。
6. 计划中的发布、迁移、扩容或供应商变更及批准链。

优先使用聚合、脱敏和只读证据。不要索取凭据、生产写权限、个人资料或与评审无关的日志内容。

执行流程

1. 定义评审范围

• 列出服务边界、关键旅程、上游、下游、外部依赖和责任人。
• 明确本次评审的非目标、时间窗口和最大允许结论。
• 将未知项按“阻断决策 / 可带条件推进 / 不影响本次”分级。

2. 设计 SLI

为每条关键旅程选择少量、可测且能代表用户体验的指标：

• 成功率：正确完成的有效请求或业务结果占比。
• 延迟：从用户或消费者边界测量的分布，不只报平均值。
• 新鲜度或时效：批处理、数据和异步流程的可用时点。
• 正确性或耐久性：结果准确、状态持久、数据未丢失的比例。

为每个 SLI 写明事件定义、好事件、总事件、排除项、测量点、窗口、分位数、数据源、所有者和已知盲区。防止用容易测量但无法代表用户结果的代理指标。

3. 提议 SLO 与错误预算政策

• 根据用户伤害、合同、替代路径、历史基线和成本提出目标区间；不得套用固定的 99.9%。
• 检查目标是否可测、可负责、可负担，并说明更高目标的边际成本。
• 明确窗口、计算方法、低流量处理、计划维护和第三方依赖规则。
• 定义错误预算消耗后的动作：观察、限制高风险变更、暂停发布、优先偿还可靠性债务或升级决策。
• 防止团队通过缩小分母、扩大排除项或修改口径让报表变绿。

错误预算是决策机制，不是允许制造故障的额度，也不是自动部署或冻结发布的授权。

4. 建立容量模型

• 记录当前需求、峰值、增长、单位工作成本、关键资源和硬/软上限。
• 区分持续容量、突发容量、故障降级容量和恢复期间容量。
• 识别排队、连接池、限额、存储、网络、配额和供应商限制。
• 用范围和敏感性表达预测；给出提前量、扩容触发点和模型失效条件。
• 将容量建议与负载验证计划绑定，不把理论配置值当成实测能力。

5. 评审韧性与恢复

• 建立依赖图、故障域和单点清单。
• 对关键失败模式说明检测、隔离、降级、恢复和用户影响。
• 检查超时、重试、退避、幂等、背压、限流、熔断和负载削减是否互相一致。
• 为有状态系统明确恢复时间目标、恢复点目标、备份权威、恢复顺序和一致性检查。
• 区分“有备份”“能恢复”和“已演练”；只以时间戳、环境、结果和缺陷记录证明演练。

6. 检查事故准备度

• 定义按用户影响分级的事故严重度和升级链。
• 检查告警是否可行动、是否指向用户症状、是否有明确所有者和运行手册。
• 要求运行手册包含影响确认、止损、诊断、恢复、回退和沟通步骤。
• 明确事故指挥、技术处置、沟通和记录职责，避免多人同时无主修改。
• 将复盘定位为系统学习：时间线、促成因素、控制缺口、行动负责人和验证日期。

7. 评估变更风险

按爆炸半径、可逆性、数据影响、依赖、权限、经验和观测能力分为低、中、高风险：

• 低风险：可逆、局部、有成熟验证和清晰责任人。
• 中风险：跨边界或状态变化，需要分阶段发布、兼容窗口和加强观测。
• 高风险：不可逆、数据迁移、核心依赖、权限边界或大范围切换，需要独立评审和具名批准。

为适用变更定义预检、灰度/分批、健康判据、停止条件、回滚触发、回滚可行性验证和观察窗口。没有回退并不自动禁止变更，但必须升级并明确替代恢复策略。

8. 设置验证门

为每项建议指定证据、责任人和截止点：

• SLI 口径校验：样本事件与人工判定一致。
• SLO 基线：历史窗口和用户影响支持目标。
• 容量验证：代表性负载、瓶颈、资源曲线和失败点已记录。
• 韧性验证：在安全隔离环境或获批演练中证明降级和恢复。
• 告警验证：用历史回放或合成信号证明触发、路由和解除。
• 变更验证：兼容、分批、停止、回滚和观察标准可重复。

不得把计划、配置存在、单元测试或一次成功演示描述成生产验证。

交付模板

按以下结构产出“可靠性治理包”：

# 可靠性治理评审｜<服务>

## 结论
- 建议：通过 / 有条件通过 / 暂停
- 决策期限：
- 具名责任人：
- 关键未知：

## 服务与用户旅程
| 旅程 | 消费者 | 用户伤害 | 责任人 | 依赖 |

## SLI/SLO 提案
| SLI | 事件定义 | 目标区间/窗口 | 基线 | 数据源 | 盲区 | 所有人 |

## 错误预算政策
| 消耗状态 | 判定方法 | 必须动作 | 可批准例外 | 批准人 |

## 容量
| 工作负载 | 当前/峰值 | 增长假设 | 限制点 | 触发点 | 验证 |

## 故障与恢复
| 失败模式 | 影响 | 检测 | 隔离/降级 | 恢复 | 剩余风险 |

## 事故准备
- 严重度与升级链：
- 告警与运行手册缺口：
- 演练与复盘计划：

## 变更风险与验证门
| 变更 | 风险级别 | 预检 | 停止条件 | 回退/恢复 | 证据 | 批准人 |

## 决策记录
- 已验证事实：
- 假设与信心：
- 待办、负责人、期限：
- 不在本次证明范围：

停止与升级

遇到以下情况，停止在建议层并升级给相应负责人：

• 请求操作生产、注入故障、切流量、部署、改告警、读取凭据或绕过审批。
• 没有服务所有者、用户旅程或可验证数据，却要求承诺具体 SLO。
• 变更不可逆、可能损坏数据、扩大权限或没有可接受的恢复策略。
• 事故正在发生且继续评审会延误止损；转交事故指挥流程。
• 合同、安全、隐私或监管含义不清；转交 CLO、Governor 或具名人类负责人。

角色边界

• CTO：批准技术方向、质量属性和重大投资取舍。
• PE：实现、测试和交付已批准的可靠性控制。
• CPO/业务负责人：确认关键旅程与可接受用户伤害。
• CFO：评审可靠性成本、风险暴露和重大资源投入。
• Governor/CLO：独立审查证据、安全、合规与例外。
• 本 Skill：形成评审材料和验证门，不替任何角色批准或执行。

触发校准

正向触发：

• “为支付服务设计 SLI、SLO 和错误预算政策。”
• “上线前评审容量、降级、恢复和告警准备度。”
• “给数据库迁移做可靠性与变更风险评审。”

负向触发：

• “线上接口报错，帮我定位代码根因。”应使用调试流程。
• “现在把 Grafana 告警改掉并部署。”属于生产执行。
• “告诉我行业默认可用性是多少。”应先收集业务和基线，不应套模板。