PM视角

背景 我做了 3 年技术产品经理，最近在排一个关于「静默死亡窗口」的修复任务。这个窗口指的是连接池或类似机制中，链路故障后，应用感知到故障的时间间隔。当前窗口是 2h11m，这意味着最坏情况下，应用要等 2h11m 才能发现链路故障。 现象

«结论先行：联调返工里最阴的一类，不是字段名写错、也不是枚举漏值，而是「单位/量纲」没约定——同一个字段，前端理解成元、后端吐的是分；同一个时间戳，这边按毫秒、那边按秒。它比"字段缺失"更危险，因为每个环节都"看起来对"：接口 200、字段

«结论先行：发布决策只问「能不能上」，不问「回滚要多久」，等于把事故恢复时间交给了运气。 我在 8 人后端团队推行的「可逆性分级 + 回滚成本预算」机制，把 12 个月内 14 次发布事故的平均恢复时间从 38 分钟压到 9 分钟，最坏情况

43 条验收标准全绿，第一条用户旅程还是挂了：跨模块主流程的 5 项旅程级验收与状态机不变量清单 «结论先行：每个模块的验收标准写得再漂亮，也拦不住"合法状态 + 合法状态 = 非法组合"这类跨模块缺陷。单需求验收回答的是"这个功能对不对"

«作者：沈望舒-936｜技术 PM 5 年｜习惯把原理拆成能算、能抄的步骤 关键词：SLO、错误预算（Error Budget）、burn rate、变更冻结» 一、现象与背景：目标喊得越狠，团队越不诚实 先给一组我经手的真实数字。我们一条

先说背景，免得大家各说各话。 我做了 5 年技术 PM，带过两个 8 人以上的后端团队。每次迭代评审，最让我头疼的不是"这个需求要不要做"，而是下面这个反复出现的拉锯： 工程师说"现在不做，后面要还三倍的技术债"；我说"用户下个月就要用，先

«结论先行：feature flag 不是"代码里的布尔值"，它是"一条没被任何人正式退役的执行路径"。我们团队 18 个月里 feature flag 从 47 个涨到 312 个，其中 194 个（62.2%）实际上已经没有任何流量走旧

«结论先行：我们以为"功能上线"的判据是主路径 100% 通过，但真正出事故的几乎全是降级路径——因为降级路径平时不跑，代码在腐化，验收单上也没人验证它。这篇文章给一份可以直接抄进验收单的"降级链路验收清单"，并附上我踩过的 4 个坑。»