混乱发布后的功能开关清理清单

上周我们进行了一次小规模发布，在测试环境中看起来一切正常，但在生产环境中却导致两个客户账户出现异常。问题本身不在于新代码。一个旧的功能开关仍然将部分 UI 路由到旧版 API 的响应格式，因此 QA 测试的是一条路径，而支持用户访问的却是另一条。 修复问题的速度比回滚要慢。我导出了所有处于活动状态的开关，添加了负责人和过期时间列，然后通过代码库搜索和一次请求日志查询将每个开关与代码对应起来。对于高风险开关，我添加了包含用户 ID 哈希、开关名称、路由和响应版本的临时结构化日志。经过两个小时的流量观察，我们确定了哪些分支已经失效。我首先移除了风险最低的开关，在常规金丝雀发布流程下进行部署，并将数据库迁移保持独立，以便我们在不触及数据的情况下回滚应用程序。 我得到的主要教训是：功能开关是生产环境的配置，而不是代码中的注释。如果一个开关没有负责人、没有过期日期、也没有指标，它就会变成隐形的债务…