#541 2010 · Etsy · Software
Etsy 每天几十次部署上线，让任何一次发布都毁不掉网站
问题
大型发布每次都搞垮线上
背景
整个 2000 年代，发布一个新版本的网站是一件大事：工程团队把数周的改动捆成一次推送、为它安排停机，并把上线那天当成一切可能同时崩掉的日子。Etsy 也是这么做的，一个专门的部署团队把守关口，每当捆绑发布出错就熬夜到很晚，因为没人能说清几十个同时的改动里到底是哪个造成了故障。
对付脆弱发布的常规解法，是发布前加更多流程——更长的 QA 周期、更多的签字、更大的预发环境——这只添了延迟，没去掉实际风险：一次发布还是同时带上四十个特性，于是单个 bug 仍逼着工程师要么全部回滚、要么在压力下翻遍整个批次找出有罪的那一行。
换别人会怎么做
加大发布前的流程——更长的 QA 周期、更多的签字、更大的预发环境。它之所以失败，是因为它只添了延迟而没去掉真正的风险：一次发布仍把几十个改动捆在一起，单个 bug 仍逼着工程师要么全部回滚、要么在压力下翻遍整个批次去找出有罪的那一行。
他们看到了什么
Etsy 看出真正的问题不是发布前把关不够，而是批次大小——把数周的改动捆进一次推送，任何一次失败都会被埋进一堆别的改动里，让它难以归因、修起来也贵。把批次拆到每次一到几个改动，而不是用更多流程去加固批次，反而让每一次个别失败都可轻松追溯、单个即可撤销。
那一手
持续部署：一天里进行几十次上线的小型部署，每一次都轻易可追溯、可回滚，取代了人人害怕的发布之夜。
为什么管用
一次大的捆绑发布包含许多同时发生的改动，一旦出问题，原因可能是其中任何一个，要找出来就得在压力下翻遍整个批次。改成部署小批次，每次发布出问题时至多只有一个可疑原因，归因几乎立即可成；又因为每个改动单独都很小，一次坏部署可以单独回滚，不必被迫在回滚整个多特性发布和线上调试之间二选一。部署频率提高得多，等于把风险摊到许多小风险、低风险的事件上，而不是把它集中到罕见的高风险时刻——这正是后来发现的最善于部署的顶尖工程团队拥有最低的变更失败率而非最高的原因——更小、更安全的部署降低了围绕上线的恐惧，进而鼓励更频繁、更小的部署。
值了多少
到 2010 年年中，Etsy 自己的工程负责人报告生产环境部署约每月 200 次且在上升（「7 月 204 次生产部署，比 6 月多约 30%」），每次小到能追溯到某一位工程师；到 2014 年公司公开援引约每天 30 次部署。
什么时候会失灵
这套做法只在底层系统和组织真的支持快速、自动、低摩擦的部署时才成立——没有自动化测试、监控和回滚基础设施的团队硬用小批量部署，只会把每一次发布的额外手工开销放大，而不是降低风险。它也依赖能否真正把工作拆成小而彼此独立可部署的单元；有些改动——比如数据库表结构迁移或一次重大架构转型——本质上就很大，不做真正的工程投入把它们改成分段式，就没法有意义地再拆。它还需要一种能容忍、并迅速响应那些必然会发生的小失败的文化——小批次策略假定失败会经常出现但单个都很便宜，而一个无论失败大小一律惩罚的组织，会破坏让工程师乐于频繁上线的那份心理安全感。
后来呢
Etsy 为记录这套做法而于 2010 年创办的 Code as Craft 博客，成为 DevOps 运动的奠基文本之一；小批次、按人可归因的部署成为行业正统，后来由 DORA 研究计划在规模化层面验证——它发现表现顶尖的工程团队部署最频繁，但变更失败率却最低而非最高。
资料来源
- [1]Scaling startupsChad Dickerson (Etsy CTO, personal engineering blog), 2010blog.chaddickerson.com
- [2]The Future Workplace Is Now: How Etsy Makes 30 Innovations Per DayForbes, 2014forbes.com