功能上线了就算 Done 吗？「Definition of Done」之争：shipped 即 done，还是 observed 才算 done？

楼主沈望舒-136

工程管理Definition of Done交付流程产品可观测性测试

【背景】我做了 5 年技术 PM，见过两个极端，都有惨痛代价：

团队 A 把「代码合并 + 集成测试通过 + 全量上线」当 done。结果一个埋点字段写错，数据看板悄悄错了 3 个月，直到大促复盘才被发现——上线后到发现前，这个功能一直挂在「已完成」状态，没人再回头看它。
团队 B 把「上线 + 指标达标 + 无关键负反馈」当 done。结果观察期一拖再拖，排期窗口被「观察中」的功能占满，新需求进不来，季度目标悬空。

争点就在这：done 的边界到底画在「交付动作完成」还是「效果被观测确认」？

【几种常见做法】

研发视角：done = 合并 + CI 绿 + 发布成功。上线后的一切归 SRE 和产品，研发只认「交钥匙」。
QA 视角：done = 用例全过 + 无 P0/P1 + 回归稳定。指标和数据不在 QA 的责任面里。
产品/数据视角：done = 上线 + 核心指标达到预设阈值 + 无关键负反馈。
SRE 视角：done = 监控覆盖 + 回滚预案 + 未超 error budget。

四套标准各自都对，但没有任何一套被写进团队的共同承诺时，就会演变成「上线即甩锅」——每个角色都觉得自己已经 done，而功能实际处在无人认领的灰色地带。

【我的倾向与踩坑理由】我倾向 done = shipped + observed，但 observed 必须轻量、可证伪、有时限，而且三条全部要在立项/需求评审时就定下来，而不是上线后补：

观察阈值量化：比如「点击率不下降超过 5%」「P99 不升 10ms」「客诉工单 3 天内为 0」。禁止「用户反馈看起来还行」这种无法验证的表述——这是我踩过最深的坑，模糊阈值等于没有阈值，最后观察期变成无限期。
观察窗口限时：3 天或 1 周，窗口到期必须二选一：达标关闭，或未达标升级（回滚/修复/降级），不允许长期挂在「观察中」。
不做全量数据化：不是每个功能都要埋点验证。低风险功能（改文案、调样式）用「无异常 + 无 P2 以上工单」即可，观察成本和功能风险要匹配，否则 DoD 会膨胀成没人愿意执行的清单。

最大的坑是 DoD 事后补：每次出事故就加一条「下次必须 XX」，三个月后清单 20 条，没人看、没人执行、没人删。DoD 应该是一个 5 条以内、立项时就冻结的短清单，而不是事故日志的合集。

【想听大家说】

你们团队的 done 定义画在哪？上线后「观察期」是制度还是口头约定？
观察阈值是立项时定，还是上线后补？补出来的阈值执行率如何？
「观察中」的功能占排期的比重，你们有统计过吗？怎么处理的？
有没有人试过把「未关闭的观察期」直接算进研发的技术债/欠账里？效果如何？

1赞 1收藏 2楼层

楼层 2 条

谢星河

从测开视角补一个「observed 的测试侧落地形态」，正好踩坑过：

我们有一条支付链路功能，QA 定义 done = 集成用例全绿 + 回归通过。上线当天一切正常，两周后数据团队发现：该功能写了一条「订单标签」字段，但下游 ETL 的解析规则没跟着改，导致 3 周里所有标签数据被静默丢弃。没有 P0/P1 工单，没有异常日志，看板「看起来正常」。

复盘时我把「done」拆成了两层：

交付 done（研发+QA 共担）：用例全绿 + 回归通过 + 回滚预案验证过。这层你贴的「shipped」基本覆盖。
效果 done（产品+数据共担，QA 提供验证手段）：在观察窗口内跑一次「端到端数据校验」——不是看接口返回 200，而是去下游存储里断言关键字段值符合预期。

第二条很关键：我们后来在 DoD 清单里加了一条硬性项——「涉及数据写入的功能，QA 必须在上线后 24h 内跑一次 data-assert 脚本（从源表取 10 条样本 → 到目标表断言字段一致），结果贴到上线 checklist」。成本约 15 分钟，但直接堵住了「接口 200 ≠ 数据正确」这个盲区。

另外回应楼主第 2 问（阈值立项时定 vs 事后补）：我们的实践是阈值在需求评审时定、在测试用例里落为断言、在上线 checklist 里落为检查项——三处引用同一个数字，避免「口头说 5%，看板配 10%，告警写 3%」的漂移。事后补的阈值执行率确实极低，因为没有人记得为什么要补。

江清和-725

从 5 年后端全栈的角度补一个「observed 阈值怎么定才不吵也不漏」的具体做法，正好呼应楼主第 1 问：

我们团队对「效果 done」的阈值采用两段式判定，避免单阈值要么过松要么过紧：

硬熔断线（立项冻结，不可事后改）：如 P99 恶化 >20%、错误率 >0.5%、核心转化字段为空的样本 >1%。触线即自动升级，不做人工判断。
软观察线（窗口内评估）：如 P99 恶化 5%~20% 区间，窗口到期时由 owner 给出「接受 / 回滚 / 继续观察一次」三选一结论，并留书面理由。

为什么拆两段：单阈值（比如 P99 升 10ms 就回滚）在大促前的高噪声期会天天误报，团队会训练出「告警疲劳」，最后真出事时没人看；而阈值定太宽（50ms）则漏掉真实回归。两段式把「确定性灾难」交给机器，「灰色地带」交给人但强制留痕——这解决了帖子里说的「观察中功能占排期」问题：软观察线到期必须三选一，不允许无结论地续期，我们统计过引入这个机制后「观察中」状态的平均滞留时间从 11 天降到 2.3 天。

另外回应楼主第 4 问（未关闭观察期算不算技术债）：我们试过，把「超窗未关闭的观察项」直接进技术债看板并计入下个迭代的容量预留（按 0.5 人天/项估）。效果是前两个月有效——欠账显形了；但第三个月开始有人把观察项拆细来稀释单项成本（一个观察拆成 3 个），机制被博弈了。后来改成「观察项超窗 7 天自动冻结该功能 owner 的新需求排期」，才真正堵住。教训：DoD 的牙齿必须挂在 owner 的短期利益上，而不是挂在看板的美观度上。

举报该内容