Flickr“每天部署10次以上”演讲终结了开发与运维之间的战争

2009年，Flickr——雅虎旗下的照片分享网站——在不断更新其服务，而行业的默认分工——开发者发布功能，运维保持网站稳定——让每一次变更都变成一场争斗。变更是大多数故障的根本原因，因此那些“保护”网站最用力的团队，恰恰是发布最慢的团队。

让变更变得安全，而非稀少：共享工具——功能开关、一步式部署、共享指标、聊天机器人——加上无责文化，使每天10次以上部署成为常态。

运维侧经理John Allspaw和工程侧经理Paul Hammond围绕共同所有权重建了发布流程：自动化基础设施、单一共享版本控制主干、一步式构建与部署、功能开关、共享指标仪表盘和IRC聊天机器人——并配以明确的文化清单：尊重、信任、对失败的健康态度，以及避免指责。

他们2009年6月的Velocity演讲比会议上任何其他演讲都吸引了更多关注，而“工具加文化”的框架成为DevOps剧本的核心：几个月后，这场运动在根特首届devopsdays上为自己命名，“每日部署次数”变成了行业基准。

到2009年，Flickr——雅虎旗下的照片网站——一直在持续发布：在平常的一天里，它会将网站向生产环境进行十次或更多次完整部署。那年6月在圣何塞举行的O'Reilly Velocity大会上，负责Flickr运维和工程两侧的两位经理John Allspaw和Paul Hammond在一场题为“每天部署10次以上：Flickr的开发与运维合作”的演讲中解释了如何做到这一点。Data Center Knowledge从会议发回的报道称，这是整场活动中引发最多热议的演讲。

他们的论点抨击了行业的默认组织架构。刻板印象——开发者添加功能，运维保持网站稳定和快速——把变更变成敌人，因为变更导致了大多数故障。Allspaw和Hammond将其颠倒过来：运维的职责是赋能业务，业务需要变更，所以真正的工作是通过工具和文化降低变更的风险。工具包包括：自动化基础设施、共享版本控制主干、一步式构建与部署、让代码以暗发布方式上线的功能开关、共享指标，以及让任何人都能观看发布过程的IRC机器人。

另一半是文化：尊重、信任、对失败的健康态度，以及避免指责——包括消防演习，让即使初级工程师也在真实事故之前演练过生产事故，因为失败终将发生。那年10月，Patrick Debois在比利时根特组织了首届devopsdays；从那次活动得名的这场运动，将Flickr演讲的框架——由共享工具、不指责他人的团队进行小规模、安全、频繁的发布——带到了各地的工程组织中。

它指出了真正的约束：在网络业务中，发布列车就是业务本身，一个能每天安全部署十次的团队，就是比每月发布一次的团队学得更快。

共享工具制造了共同的命运——一个主干、一个仪表盘、一个部署按钮——因此任何一方都无法通过让另一方失败来获胜。

它将运维从稳定性的守护者重新定义为变更的赋能者，让自动化和文化可以用一个问题来评判：我们能多频繁地安全发布？

它将指责视为工程缺陷，而非性格缺陷：如果人们隐藏错误，风险会无声地累积；消防演习和无责复盘让信息保持流动。

吞吐量来自让变更变得安全，而非稀少。共享工具创造共同命运；指责教会工程师隐藏风险；运维赋能业务，而不是防范业务以守护正常运行时间。

该演讲的录像至今仍在线，仍被作为DevOps的奠基性文献展示。那年10月，Debois在根特的首届devopsdays给了这场运动它的名字，“每天部署多少次？”既成了基准也成了挑战。Allspaw将这一方法带到了Etsy，在那里它的近亲——无责事后复盘和持续部署——各自声名鹊起。十五年多后，部署频率已成为标准工程指标，而“开发对运维”的对立主要作为这场演讲所摧毁的稻草人而存续。