作为工程基础设施的功能开关
· 7 分钟阅读
开关不是临时黑客手段。它们是现代团队将部署与发布分离的方式。
部署应当无聊
把代码运到生产与向用户暴露功能是不同决策。功能开关让团队持续合并,同时控制爆炸半径。结合可观测性,它们把发布变成可逆实验,而非二元事件。
这只有在开关被当作基础设施时才成立:命名清晰、有团队所有、默认安全,并按计划可移除。
为可运维性设计
每个开关在管理服务不可用时都需要默认值。关键路径应有意失败关闭或打开,绝不能随机。定向规则必须可测试、可审计,尤其对企业客户与受监管工作流。
避免把不相关行为包进一个开关。粗粒度开关造成纠缠清理。细粒度开关造成组合测试成本。按用户可见能力分组。
- 记录谁更改了开关以及原因
- 创建开关时设定移除日期
- 尽可能将开关求值移出紧循环
- 测试启用与禁用两条路径
实验需要卫生
当开关支撑实验时,在上线前定义假设、主指标与结束标准。不要让半成品实验无限运行;它们污染分析并增加认知负担。
仔细分段。同一旅程上重叠的实验可能使结论无效,并造成混乱的用户体验。
清理是交付的一部分
功能完全发布后仍长期存活的开关,会变成死配置与隐藏分支。以与上线同等的严肃性安排清理。删除未用路径,使代码库反映现实。
成熟团队用开关取胜,不是因为开关更多,而是因为能安全发布并在之后让系统更简单。
由 Berktug Berke Ates 于 2025年2月14日 发布。