36.4 把行动项变成控制
复盘行动项的目标不是让团队“做过一些事”，而是改变下一次失效路径的概率、可见性、 影响或恢复质量。能否关闭一项 action，取决于控制效果证据，而不取决于 ticket 状态。
36.4.1 所有者、截止时间、验证方法与失效条件
合格 action contract
id: ACT-...
finding_or_theme: ...
control_objective: ...
control_type: prevent | detect | mitigate | recover
owner_role: ...
decision_owner: ...
priority: P0 | P1 | P2
due_at: ...
scope:
services: [...]
versions: [...]
environments: [...]
artifact: ...
verification:
procedure: ...
pass_condition: ...
evidence_to_close: ...
failure_condition: ...
rollback_or_disable: ...
dependencies: [...]
status: proposed
last_verified_at: null
revalidate_at: ...
exception: nullowner_role 保证组织结构变化后仍能路由；具体 assignee 可在工单中绑定。decision_owner
对资源、延期和 residual risk 作决定，不能把所有压力留给实现者。
关闭有四个阶段
implemented
artifact 已创建
deployed
control 已进入目标环境
operating
运行数据证明它持续执行
effective
反例或演练证明它在失效路径上产生预期效果例如新增一个 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。否则控制悄悄失效，直到下一次事故 才被发现。
到期、例外和重验
配置、版本、工作负载和依赖持续变化。每项控制应有：
revalidation interval
events that invalidate prior evidence
exception owner and expiry
replacement or retirement condition升级 PostgreSQL/Pigsty、改变 DCS/backup repository、迁移 region、重写事务边界、 修改 pool 或流量翻倍，都可能使旧演练证据失效。exception 不是永久豁免；到期时必须 重新接受风险、补充控制或完成修复。
36.4.2 自动检查、发布门、容量线与恢复演练
先选控制位置
越靠近错误进入点，通常越便宜：
design/static
schema、inventory、policy、compatibility check
release
target identity、preview、migration lock、canary、rollback gate
runtime
admission、timeout、quota、least privilege、safeguard
detect
user SLI、database/host evidence、integrity and backup checks
recover
PITR、failover、rebuild、reconciliation drill不能自动 prevent 的风险，用 detect + mitigate；无法可靠恢复的数据，必须更早 prevent。 不要为追求“全自动”让一个弱分类器直接执行不可逆动作。
自动检查同时测试反例
正向测试只证明一个正确样本通过。控制至少覆盖：
missing identity
wrong cluster / database / role
unsupported version
stale inventory
conflicting evidence
empty or partial result
timeout / collector unavailable
unsafe production flag
rollback unavailable对 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
required evidence complete
exact target resolved
risk/authority/rollback valid
DENY
predicate false
STOP_AND_ESCALATE
evidence missing, conflicting or outside classifier domain未知状态默认 allow，会把 collector 故障变成生产变更。默认 deny 也不是全部答案： 紧急 break-glass 需要独立身份、范围、期限、记录和事后 review。
容量线是多资源 envelope
不要把压测 TPS 单值写进 gate。容量合同至少包含：
workload_revision: ...
hardware_and_topology: ...
dataset_and_cache_state: ...
concurrency_and_arrival: ...
service_sli:
latency: ...
error: ...
resource_limits:
connection_and_queue: ...
cpu_memory_io: ...
wal_archive_replication: ...
xid_vacuum_storage: ...
safety_margin: ...
valid_until_or_invalidation: ...流量、数据倾斜、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 page 并附诊断链接 |
| 培训故障切换 | blind scenario 中先证明 fence/authority，再 reconcile unknown |
| 优化性能 | 固定 workload 下达到声明 SLI 且所有资源保留安全余量 |
| 更新文档 | 当前版本新值班者仅凭 runbook 完成演练，错误分支被 stop line 阻止 |
培训和文档可以是控制组件，但不能单独证明系统更安全。人会遗忘、轮岗并在压力下使用 默认路径；应同时改进工具、权限、界面、自动采集、guard 与平台默认值。
拒绝 solution-first action
从“升级版本”“增加节点”“换存储”“重写服务”开始，容易跳过控制目标。先写：
which failure edge must be cut?
how much risk reduction is expected?
what evidence would falsify the proposal?
what new failure modes does it introduce?
how will it be rolled back or retired?升级 PostgreSQL 或 Pigsty 可能修复已知 bug，也会改变扩展、配置、监控、backup 和 playbook 语义。它需要 ADR 与验证矩阵，不能作为通用复盘结论。
排优先级看风险，不看措辞力度
一种简单排序：
$$ \text{priority score} = \frac{ P(\text{recurrence}) \times \text{impact} \times \text{control coverage} \times \text{confidence} }{ \text{delivery cost} + \text{operational cost} } $$
数字不是客观真理，而是迫使团队公开假设。优先：
- 能切断多条 causal edge；
- 覆盖多个 service/incident theme；
- 在影响前 prevent/detect；
- 具备明确、廉价的 effectiveness test；
- 降低 on-call 认知负担；
- 不制造更大单点或不可逆自动化。
低成本并不自动优先。“再加一条 alert”容易交付，却可能增加 noise；一次 target- identity gate 可能需要更多工程投入，但能同时阻断多类破坏性误操作。
action review 的停止线
以下任一成立，不应进入“完成”：
owner or decision owner absent
scope/version unspecified
verification cannot fail
closure evidence unavailable
failure condition unobservable
production rollout lacks rollback/approval
action only changes wording or awareness
exception has no expiry复盘质量最终体现在控制 registry 里有多少 action 被有效验证，而不是文档里列了 多少 bullet。
上一节：证据质量与决策复盘 · 返回本章目录 · 下一节：回写 SLO、SOP 与架构 ADR · 查看全书目录 · 查看索引中心