36.4 把行动项变成控制
复盘行动项的目标不是让团队“做过一些事”，而是改变下一次失效路径的概率、可见性、 影响或恢复质量。能否关闭一项 action，取决于控制效果证据，而不取决于 ticket 状态。
36.4.1 所有者、截止时间、验证方法与失效条件
合格 action contract
owner_role 保证组织结构变化后仍能路由；具体 assignee 可在工单中绑定。decision_owner
对资源、延期和 residual risk 作决定，不能把所有压力留给实现者。
关闭有四个阶段
例如新增一个 replication lag alert：
- rule 合并：implemented；
- VMAlert 已加载：deployed；
- evaluation 和 notification 正常：operating；
- 注入受控 lag 后按 SLI/route 触发且未误触其他场景：effective。
只有最后一步及其证据满足 closure contract，才标 effectiveness-verified。若控制只在
部分 service/version 上部署，状态也只能按该 scope 关闭。
写失效条件
没有 failure condition 的控制无法监控自身：
| 控制 | 失效条件示例 |
|---|---|
| backup | 最近可恢复点超 RPO，或隔离 restore 失败 |
| failover | 旧 writer 未围栏，unknown outcome 无法对账 |
| capacity gate | 未知 workload 绕过 budget，queue 无上限 |
| release gate | exact target/system identifier 缺失仍可执行 |
| checksum review | 扫描未覆盖全部声明对象或结果不可追溯 |
| runbook | 当前版本/拓扑不适用，参与者只能靠 hidden answer |
同时规定 control telemetry 的 owner 和 retention。否则控制悄悄失效，直到下一次事故 才被发现。
到期、例外和重验
配置、版本、工作负载和依赖持续变化。每项控制应有：
升级 PostgreSQL/Pigsty、改变 DCS/backup repository、迁移 region、重写事务边界、 修改 pool 或流量翻倍，都可能使旧演练证据失效。exception 不是永久豁免；到期时必须 重新接受风险、补充控制或完成修复。
36.4.2 自动检查、发布门、容量线与恢复演练
先选控制位置
越靠近错误进入点，通常越便宜：
不能自动 prevent 的风险，用 detect + mitigate；无法可靠恢复的数据，必须更早 prevent。 不要为追求“全自动”让一个弱分类器直接执行不可逆动作。
自动检查同时测试反例
正向测试只证明一个正确样本通过。控制至少覆盖：
对 migration，不只验证 SQL syntax；还验证 lock path、rewrite、replica lag、old/new application compatibility 和 rollback。对 restore，不只验证 PostgreSQL 启动；还验证 source lineage、target cutoff、business manifest、archive/backup 恢复和 route 未误切。
发布门要有明确 deny
未知状态默认 allow，会把 collector 故障变成生产变更。默认 deny 也不是全部答案： 紧急 break-glass 需要独立身份、范围、期限、记录和事后 review。
容量线是多资源 envelope
不要把压测 TPS 单值写进 gate。容量合同至少包含：
流量、数据倾斜、query mix、checkpoint、vacuum 和 backup 会改变 envelope。容量 gate 既可阻止超预算发布，也要在运行中检测 headroom 消耗；指标缺失时不能宣称有余量。
恢复演练验证整条链
周期演练不是每季度运行同一 happy-path 命令：
| 能力 | 至少验证 |
|---|---|
| backup/PITR | source、target、candidate、业务 delta、archive continuity |
| failover | authority、fence、client unknown、timeline、rejoin |
| overload | blind classification、scope、stop route、post-cleanup |
| integrity | preserve、checksum/amcheck、source selection、business invariant |
| secrets/access | break-glass、审计、到期回收 |
轮换 seed、故障点、参与者和 hidden truth；保留可比较指标，但不把单次练习排名成个人 绩效，否则参与者会优化剧本而不是暴露控制缺口。
36.4.3 不能验证的“加强意识”不是合格行动项
把愿望改写成系统行为
| 不合格 | 可验证改写 |
|---|---|
| 加强备份意识 | 每 90 天从随机 retained backup 隔离恢复；业务 manifest 全过 |
| 以后谨慎执行 | target 缺 system identifier、scope 或 rollback 时 gate 必须拒绝 |
| 完善监控 | synthetic user failure 在规定窗口触发 SLI 值班告警并附诊断链接 |
| 培训故障切换 | blind scenario 中先证明 fence/authority，再 reconcile unknown |
| 优化性能 | 固定 workload 下达到声明 SLI 且所有资源保留安全余量 |
| 更新文档 | 当前版本新值班者仅凭 runbook 完成演练，错误分支被 stop line 阻止 |
培训和文档可以是控制组件，但不能单独证明系统更安全。人会遗忘、轮岗并在压力下使用 默认路径；应同时改进工具、权限、界面、自动采集、guard 与平台默认值。
拒绝 solution-first action
从“升级版本”“增加节点”“换存储”“重写服务”开始，容易跳过控制目标。先写：
升级 PostgreSQL 或 Pigsty 可能修复已知 bug，也会改变扩展、配置、监控、backup 和 playbook 语义。它需要 ADR 与验证矩阵，不能作为通用复盘结论。
排优先级看风险，不看措辞力度
一种简单排序：
数字不是客观真理，而是迫使团队公开假设。优先：
- 能切断多条 causal edge；
- 覆盖多个 service/incident theme；
- 在影响前 prevent/detect；
- 具备明确、廉价的 effectiveness test；
- 降低 on-call 认知负担；
- 不制造更大单点或不可逆自动化。
低成本并不自动优先。“再加一条 alert”容易交付，却可能增加 noise；一次 target- identity gate 可能需要更多工程投入，但能同时阻断多类破坏性误操作。
action review 的停止线
以下任一成立，不应进入“完成”：
复盘质量最终体现在控制 registry 里有多少 action 被有效验证，而不是文档里列了 多少 bullet。
上一节：证据质量与决策复盘 · 返回本章目录 · 下一节：回写 SLO、SOP 与架构 ADR · 查看全书目录 · 查看索引中心