1. 错误预算：把“可靠性目标”翻译成“可消费配额”
假设 SLO 是 99.9% 可用性，那么一个月允许的不可用比例是 0.1%。这 0.1% 就是预算： 你可以把它理解为“允许试错的空间”。当预算消耗过快，发布策略应自动收紧； 当预算健康，团队可加速交付。预算不是惩罚工具，而是统一产品与平台决策语言的桥梁。
图 1：错误预算是发布油门与刹车的共用刻度盘。
2. 变更管理：可靠性交付的“节奏控制器”
变更管理的目标不是“减少变更”，而是把变更风险分层。常见做法： 低风险变更自动化直通；中风险变更走渐进发布并观察指标；高风险变更进入变更窗口和双人审批。 关键是把风险分类规则写成可执行策略，而非口头约定。
| Change class | Typical examples | Required controls |
|---|---|---|
| Low risk | UI copy, non-critical config | auto deploy + smoke checks |
| Medium risk | service logic change | canary + SLO gate |
| High risk | schema migration, auth path | change window + manual approval + rollback plan |
# Illustrative policy idea
if change_risk == "low":
deploy_mode = "auto"
elif change_risk == "medium":
deploy_mode = "progressive"
else:
deploy_mode = "manual_window"
底线：没有回滚预案的高风险变更，不应进入生产窗口。
3. 事件响应：值班不是英雄主义，是系统化协同
可靠的团队在事故发生前就定义好严重度（SEV）、升级路径、沟通模板和角色分工（Incident Commander / Operations / Communications）。 一旦告警触发，先止血（mitigate）再定位（diagnose），再恢复（recover），最后复盘（learn）。
图 2：事故响应是流程化系统，不是依赖“最懂系统的人恰好在线”。
4. 复盘（Postmortem）：从“追责文档”升级为“系统学习”
高质量 postmortem 关注系统条件和防护缺口，而非个人失误。建议包含： 事件时间线、影响范围、检测与响应延迟、根因链（5 whys）、改进行动项（owner + deadline + verification）。 复盘如果不能改变下一次系统行为，就只是形式主义。
# Postmortem action item template
- action: Add canary SLO gate for checkout-api
owner: sre-team
due_date: 2026-04-01
success_metric: rollback trigger time < 3 minutes5. 把 SRE 机制接回交付流水线
当 error budget 接近阈值，流水线应自动调整策略：增加人工 gate、缩小发布批次、提升回滚敏感度。 这意味着 SRE 与 CI/CD 不是两套平行世界，而是一套闭环： 观测 → 决策 → 交付 → 再观测。
图 3：SRE 的价值在于持续反馈，让交付每一圈都更稳。
建议：把“预算状态”和“变更风险级别”直接接入发布流水线，避免靠会议口头决定是否继续发布。
6. 本章清单
- 定义核心 SLO 并计算 error budget，形成可追踪的预算看板。
- 制定风险分级变更策略，把审批与发布模式绑定到风险等级。
- 建立标准化 incident response 流程（SEV、角色、沟通、升级路径）。
- 落实无责复盘机制，并把行动项绑定负责人、截止时间和验证指标。
- 将预算/风险信号接入 CI/CD，实现自动化发布节奏控制。
- 预告下一章：发布与故障联动（release markers、回归检测与自动止损）。