复盘会开得不错，改进项列了十二条，责任到人，会议纪要发群里。三个月后回看：一条没落地，其余停在"已排期"。这不是执行力问题——复盘与跟进是两个不同的机制，前者的产物是共识，后者的产物是排期。用开会的办法管跟进，就会得到一堆漂亮的条目。
跟进要解决的问题是：谁在什么时间点、用什么证据，判断一条改进是否真的改变了系统行为。
1. 两个机制的差别
| 维度 | 复盘 | 跟进 |
|---|---|---|
| 触发 | 事故结束 | 日历，周期性 |
| 参与者 | 当事团队 + 相关方 | 条目 owner + 有权排期的人 |
| 产物 | 根因、条目、共识 | 状态变化、排期、验证证据 |
| 失败形态 | 开成追责会或走过场 | 条目静默腐烂，无人发现 |
| 需要的制度 | 心理安全、流程模板 | 固定节奏、超期规则、升级路径 |
第二行是关键：复盘靠一次会议就能完成，跟进没有办法靠一次会议完成，它必须挂在已有的节奏上。
2. 十二条为什么一条没落地
四个原因覆盖绝大多数情况，判断时先分清是哪一种，因为对策完全不同。
| 原因 | 识别信号 | 对策 |
|---|---|---|
| 没有 owner | 条目写"团队负责" | 必须落到一个具名的人，团队不算 owner |
| 没有排期 | 状态"待安排"，无迭代归属 | 要么进某个迭代，要么进专项，不存在第三种 |
| 不影响当前指标 | 与季度 OKR 无关 | 挂到可靠性预算上，或明确降级 |
| 跨团队 | 需要别的团队改，本团队无权限 | 升级到有共同上级的人裁定 |
第四条最容易被误判成"对方不配合"。实际是没有人有权要求另一个团队为他人的事故投入，这是权限结构问题，不是意愿问题。
3. 条目的质量判据
一条改进能否被跟进，取决于它写得是否可验证。四项缺一项，它就注定停在"进行中"。
| 字段 | 判据 | 反例 |
|---|---|---|
| 主张 | 改完之后，什么行为会不同 | "提升监控能力" |
| 验证方式 | 怎么证明它生效，谁去验 | "上线后观察" |
| 失败条件 | 什么现象说明它没生效 | 未写，于是永远不会失败 |
| 截止与归属 | 日期 + 一个具名 owner | "Q4 内"、"相关同学" |
"能失败"这一项最容易被跳过。一条无法失败的改进项，等价于一条不需要做的改进项，因为它永远处于"看起来在推进"的状态。
// followup/<incident-id>.yaml：字段为空说明还没想清楚，别进台账
- id: FU-07
claim: 慢查询超过阈值时，5 分钟内产生带 SQL 摘要的告警
verify:
how: 预发注入一条无索引查询，观察告警到达时间与内容
by: <具名 owner>
evidence: 告警截图 + 规则 diff 链接
fails_if: 告警到达但无 SQL 摘要，或超过 5 分钟
due: 2026-12-05
slot: iteration-42 // 迭代号 / 专项名，二者必居其一
4. 排期归属：进迭代还是进专项
改进项必须有归属，否则它既不在任何人的待办里，也不在任何人的考核里。
| 归属 | 适用 | 代价 | 风险 |
|---|---|---|---|
| 常规迭代 | 工作量小于一天、与当前需求同域 | 挤占需求容量 | 被需求挤掉，反复延期 |
| 专项 | 跨多团队、需要重构 | 需要独立预算与负责人 | 专项结束后无人接手 |
| 可靠性预算 | 每迭代固定留出比例 | 需求方不满 | 预算被"紧急需求"挪用 |
| 明确放弃 | 成本高于收益 | 需要向上说明 | 无，反而是诚实的 |
第三种是多数团队缺的一环：没有预留容量，改进项就只能靠个人自觉，而个人自觉在需求压力下必然输。
// 排期判据：先算容量，再决定条目能不能进
每迭代可用容量 = 总容量 × (1 − 需求占用率)
若 改进项工作量之和 > 可用容量:
按 fails_if 的严重度排序，取前 N 条
其余显式标记 downgraded，写清理由与复审日期
5. 跨团队条目：谁有权要求别人改
这类条目占比通常不高，但落地率最低。处理方式取决于依赖方向。
| 情形 | 谁裁定 | 可行做法 |
|---|---|---|
| 同一上级下的两个团队 | 共同上级 | 一次会议定排期，写进双方迭代 |
| 无共同上级 | 平台/架构委员会 | 走技术债立项，带影响面数据 |
| 供应商或外部系统 | 采购与合同 owner | 转成 SLA 条款或备选方案 |
| 对方也是受害方 | 双方共同 owner | 联合条目，共担排期 |
一条实用判据：如果这条改进的收益主要落在提出方，那么它很难被排进去。把收益说成对方的（减少他们的告警、减少他们的值班负担），落地率会明显不同。
6. 跟进要看三层，不只看一层
只盯条目状态，会得到"完成率 80%"这种看似不错却无意义的数字。
| 层 | 看什么 | 判据 | 采集方式 |
|---|---|---|---|
| 条目层 | 单条状态与超期 | 超期数应为零或已显式降级 | 台账扫描 |
| 根因层 | 当初认定的根因是否被移除 | 同类触发条件不再成立 | 根因对应的机制是否变更 |
| 复发层 | 同类事故是否再发生 | 同源复发率为零才是真改完 | 事故分类打标 |
中间一层最容易被绕过：条目做完了，但根因还在，只是换个形式触发。判断方法是对着当初的根因描述问一句"这个条件现在还成立吗"，答不上来就是没做完。
7. "做完"的定义
不是代码合并，不是上线，是验证过并留下证据。这三件事的差距，决定了台账是真账还是安慰剂。
// 台账扫描：找出该被处理却没人看的条目
$ jq -r '.[] | select(.status!="done" and .status!="dropped")
| "\(.due)\t\(.id)\t\(.owner)"' followup.json \
| sort | awk -v T="$(date +%F)" '$1 < T {print "超期:", $0}'
// done 的四个条件，缺一不算完成
done =
verify.how 已执行 // 不是计划执行，是执行过
AND evidence 可打开 // 截图、diff、查询结果任一种
AND fails_if 未发生 // 反证也被检查过
AND 状态由 owner 之外的人确认 // 自证不算
最后一条是防自欺的核心：提交者判断自己做完，与另一个人看证据判断做完，是两种可靠性。
8. 超三个月没动怎么办
不许它一直挂着。三个月是一个合适的分界线：足够长，能跨过一个季度；足够短，记忆还没丢。到期必须做三选一。
| 处置 | 适用 | 动作 |
|---|---|---|
| 重新评估 | 前提变了，成本或收益需重算 | 重写 claim 与 due，owner 不变 |
| 降级 | 有更便宜的替代手段 | 改写为监测项或 runbook 条目 |
| 明确放弃 | 成本高于收益，或根因已在别处解决 | 记录理由与复审日期，从活跃台账移出 |
最差的状态是"保留但不排期"——它占据台账、消耗注意力，且永远不产生结论。放弃一条并写清理由，比让它挂着更专业。
9. 节奏与度量
周会太密会形式化（没有变化可报），季度太疏会遗忘（人已经换岗）。
| 节奏 | 频率 | 内容 | 时长 |
|---|---|---|---|
| 状态扫描 | 每周，异步 | 只看状态变化与超期 | 零会议 |
| 评审会 | 每两周或每月 | 卡住的条目、跨团队升级 | 30 分钟 |
| 根因复审 | 每季度 | 根因层是否真被移除 | 一次专题 |
| 复发复盘 | 触发式 | 同源事故出现即开 | 按事故规模 |
// 跟进度量：四个数就够，多了会变成填表
followup:
completion_rate: done / (done + open) // 分母不含 dropped
mean_landing_days: done_at − created_at // 看中位数与尾部
same_origin_recur: 按根因分类统计的复发次数 // 唯一能证明"真改完"的
overdue_open: 到期未处置的条目数 // 应为零
完成率高但复发率不降，说明条目都在做表层修补；复发率降而完成率低，可能是条目本身定得太重。
10. 跟进与偿债是同一件事
多数改进项本质是技术债：改造成本落在当期，收益在未来。用债务的语言描述，排期讨论会容易得多。
| 改进项类型 | 债务类比 | 谈法 |
|---|---|---|
| 加告警、加校验 | 保险，非债务 | 按风险预算谈 |
| 补测试、补文档 | 利息支付 | 按迭代比例谈 |
| 重构触发路径 | 本金偿还 | 需要专项与截止日 |
| 放弃并接受风险 | 违约 | 需要书面接受方 |
把"补告警"和"重构"混成一张清单，会让后者永远排在前面几项之后，因为前者便宜且立刻可完成。
11. 症状对照
| 症状 | 根因 | 先动哪 |
|---|---|---|
| 条目全部"进行中" | 缺 fails_if，无法判定完成 | 补判据，砍掉不可验证项 |
| 每季度都能列十条 | 根因层没动，症状反复 | 做根因复审，别再加条目 |
| 跨团队条目永远最后 | 收益归属写错 | 改写收益方，升级裁定 |
| 复盘会开完就散 | 没有固定扫描节奏 | 挂两周一次的异步扫描 |
| 老条目无人认领 | owner 写成团队 | 全部改为具名，无主则放弃 |
12. 边界
| 场景 | 可降级到什么程度 | 理由 |
|---|---|---|
| 事故影响极小 | 单一 owner 盯一条，不做台账 | 制度成本高于风险 |
| 根因已在别处一并解决 | 记录关联，标 dropped | 重复投入无收益 |
| 团队处于重大战役期 | 只保留与安全/资损相关的条目 | 容量被挤占，硬推会全线延期 |
| 单次性系统、将下线 | 只做止损条目 | 长期改进无回收期 |
降级也要留痕：写清"降级到何时复审"。无声的降级和放弃的区别，只在于有没有人知道。
13. 自测
- 复盘与跟进最关键的制度差别是什么？
- 十二条改进项没落地，"跨团队"这一原因为什么不能归为意愿问题？
- 一条改进项缺少"失败条件"，会产生什么后果？
- 为什么"完成"要由 owner 之外的人确认？
- 完成率很高但复发率不降，说明什么？
- 三个月未动的条目有哪三种处置，最差的状态是什么？