建设DevOps能力，实现业务敏捷

当软件行业进入互联网时代，市场对软件产品和服务的交付提出了更高的要求：不仅要快速实现需求，而且要快速发布上线，并且必须保证业务可靠、高效运行。为了满足这些要求，IT组织需要强有力的流程、技术和人员作为保障。

ThoughtWorks很早就认识到发布与运营对于成功交付的重要性。我们的创始人Roy Singham在《走完业务软件的“最后一公里”》^[1]一文中指出：

所谓[软件开发的]“最后一公里”，是指软件满足了功能需求之后，尚未投入实际运行并创造业务价值的阶段。软件开发者──尤其是面对交付压力的软件开发者──常常对“最后一公里”视而不见。但它确实正在成为业务软件交付中最大的压力点。

本文将分析大型软件组织在软件发布与运营维护阶段常见的典型问题，并介绍一种行之有效的解决对策。

问题

众多大型软件组织在软件的发布、运营和维护过程中体会到以下两方面的压力：

快速响应

传统观念中规模庞大、发布周期长达数月乃至数年的软件产品研发方式正在发生变化。在“快鱼吃慢鱼”的互联网时代，上市时间（Time To Market）成为衡量软件组织能力的重要因素：能快速接纳需求、快速完成开发、快速上线投入使用的软件产品，才能有效占领市场、吸引用户。

在以迭代式开发为特征的敏捷开发方法和以Ruby on Rails为代表的一批高效开发工具帮助下，很多软件组织在实现功能性需求方面的能力得到了显著提升。然而从业务负责人的角度来说，仅仅提升开发阶段的效 率还不足以实现端到端的快速响应。很多软件组织虽然以迭代方式进行开发，但发布和部署仍然按照从前的节奏，每隔几个月才进行一次。这时从客户与最终用户的 视角看来，这些软件组织的交付仍然是以瀑布方式进行：客户与最终用户并没有直接感知到开发能力提升所带来的利益（如图1）。

不能有效缩短部署上线的周期，就无法真正实现快速响应业务需求、快速实现业务价值。如何缩短发布和运维工作的周期，已经成为困扰很多软件组织领导者的问题。

图1：迭代式开发+瀑布式发布^[2]

质量

大型软件组织通常都很重视产品质量，并在开发/测试阶段投入大量成本与精力进行质量保障活动。但软件产品的质量问题不仅在开发阶段引入，靠传统意义上的测试工作也不能完全发现。有相当比例的质量问题是在开发/测试阶段之后引入或发现的。造成这一现象的原因有：

• 开发人员对生产环境缺乏了解，在代码中引入了只有在生产环境才会暴露的缺陷。
• 开发人员对非功能性需求缺乏关注，并且没有相应验证环境，导致非功能性缺陷。
• 生产环境和测试环境缺乏有效管理，因为环境差异引入缺陷。
• 部署和维护工作缺乏自动化，在发布过程中手工操作引入缺陷。
• 缺乏针对生产环境的回归测试，导致缺陷不能及时被发现。

通过引入自动化测试、测试驱动开发、持续集成等敏捷实践，开发/测试阶段的质量保障活动能够得到有效改善。然而对于客户和最终用户来说，不论哪个环节引入的缺陷都同样会给业务造成损失。如何在部署上线的紧迫压力下保证质量，这也是众多软件组织领导者关注的一个问题。

敏捷拉通的尝试

一些软件组织意识到这些问题的存在，并希望以敏捷开发方法为出发点，将下游的发布、部署、运维等工作环节拉通，从而提升整体响应能力。但由于软件开发与运营之间存在一些固有的差异，这样的拉通活动往往困难重重：

• 开发团队与运营团队的关注点不同。开发团队重视以功能性需求实现业务价值；运营团队重视以非功能性需求（稳定性、性能、安全性等）实现业务价值。
• 开发团队与运营团队的技能结构不同。开发人员通常缺乏服务器管理的技能，运营人员通常缺乏软件编程的技能。
• 开发团队与运营团队日常使用的工具不同。针对开发阶段引入的配置管理、IDE、测试工具等很少为运营团队使用。
• 开发团队与运营团队日常工作的环境不同。开发人员通常在公司内的桌面电脑上工作，运营人员经常在客户现场、在服务器上工作。
• 开发团队与运营团队通常属于不同的部门。

由于存在这些固有的差异，单纯从开发团队的角度出发、将敏捷软件开发的实践推广到运营团队，很难有效帮助运营团队改善。需要从运营维护工作本身的特点出发，引入符合客观情况的流程、技术和工具，才能有效改善运营维护工作的质量和效率。

对策

针对现代大型软件组织在软件发布、运营与维护过程中面临的种种挑战，ThoughtWorks建议在软件组织中建设DevOps^[3]能力，从而提升整个组织的IT融合程度，改善软件交付“最后一公里”的质量和效率，为实现业务敏捷打好基础。

DevOps是一组流程、技术与工具的统称，用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合。“DevOps”这个名称即是指开发 （dev）与运营（op）的无缝融合。具备DevOps能力的组织能够开展快速、反应灵敏同时又稳定可靠的业务运维，使其能够与开发过程的创新保持同步， 从而使得敏捷开发的优势在组织层面上得到展现。

精益运维

传统的软件运营人员通常倾向于尽量避免修改功能，从而降低满足非功能性需求的风险。但如果拒绝了小的修改，而给定时间段内需要修改的总量不变，那么每次变更的规模就会变大，从而增加每次发布的风险（因为变更涉及的范围更大）。

DevOps的指导思想是“精益运维”。精益生产的很多原则，例如缩短交付周期、消除浪费、重视价值流动、拉动式生产、质量内建等，在DevOps中都得到了体现。与传统的软件发布方式相比，DevOps主要通过以下几方面的改变来提升效率和质量：

• 减少每次发布的变更范围。与传统的瀑布式开发模型相比，采用迭代的工作方式意味着更频繁的发布、每次发布包含的变化更少。 由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长（如图2）。与传统开发方法那种大规模的、不频繁的发布（通 常以“季度”或“年”为单位）相比，具备DevOps能力的组织大大提升了发布频率（通常以“天”或“周”为单位）。
• 加强开发与运营协调。通过强有力的发布协调机制来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电话会议、即时消息、企业 门户（wiki、sharepoint）等协作工具来确保所有相关人员理解变更的内容；使用统一的流程和工具，例如故事墙、燃尽图、在线项目管理工具（ 例如Mingle、JIRA）、配置管理工具（例如Subversion、Git、Mercurial）等。
• 自动化。借助强大的部署自动化手段和标准化的环境管理来降低部署操作的成本、确保部署任务的可重复性、减少部署出错的可能性。例如：
  • 用VMWare或Xen等虚拟化技术标准化生产环境，实现生产环境的快速复制和快速恢复。
  • 用Puppet或Chef等工具自动化环境设置、软件安装/配置等操作，将配置信息转化为源代码，实现环境配置的版本控制。
  • 用Capistrano等工具自动化软件产品的部署，实现部署过程的版本控制。
  • 用dbdeploy等工具自动化数据库变更，实现数据迁移的版本控制。
  • 用Selenium、Cucumber等工具自动化生产环境的冒烟测试和回归测试。

图2： 应用程序­以平滑的速率逐渐生长^[4]

从工作流程、协调机制、技术工具等几个方面同时着手，就能在软件组织中建立起DevOps能力，从而将精益运维变成现实。

敏捷开发

DevOps与敏捷软件开发同样具有精益的指导思想，在实践层面也有很多共通之处。可以把敏捷软件开发看作精益思想在需求、研发阶段的实 施，DevOps则是精益思想在发布、运营阶段的实施（如图3）。尽管建设DevOps能力并不必须要求软件组织具备敏捷软件开发能力，不过以下敏捷实践 会对DevOps能力建设产生尤为明显的帮助：

图3：DevOps与敏捷既相关又不同^[5]

• 迭代式开发。已经习惯于固定的短周期迭代的开发团队能够更好地融入快速交付的整体节奏。
• 自动化测试。有效的自动化测试套件能在软件生命周期的各个环节保障系统质量，避免引入缺陷。
• 持续集成。拥有成熟的项目自动化机制和能力，开发团队能帮助运营团队更快地建立发布与维护过程的自动化体系，从而实现软件价值的持续交付。

收益

通过建设DevOps能力，软件组织能够明显软件产品发布和运营过程中的质量与效率。具体而言，可感知的收益包括：

• 缩短交付周期，新需求能更快投入使用并创造业务价值。
• 增加软件发布的可靠性，减少上线后的质量事故。
• 减少发布和运营中的浪费，提高运营团队的工作效率。
• 可视化度量软件交付过程，以便快速识别问题、持续改善。
• 在开发与运营团队之间建立更加高效的协作关系。

案例I：Flickr

Flickr是全球最大的图片共享网站。根据2007年的统计数据^[6]，Flickr拥有超过850万注册用户，存放了超过30亿张照片，每秒钟响应4万个照片访问请求。

通过自动化基础设施、共享版本控制、自动化构建和部署、共享度量体系、强化沟通机制等手段，Flickr在保证网站稳定性和性能的同时，达到了每天能部署10次以上的需求响应水平，同时在开发团队与运营团队之间建立起互相尊重、彼此信任的协作关系。

图4：全球最大的图片分享网站Flickr每天有超过10次部署上线^[7]

案例II：某在线社交网站

该网站从2000年开始运营，目前拥有超过3000万注册用户。随着业务发展，该网站的运营团队感受到来自业务负责人和最终用户的压力。根据 ThoughtWorks所做的价值流分析，该网站从接纳一个需求到最终将其上线投入使用需要15～40天，其中超过50%时间是被浪费的。

图5：通过价值流分析发现浪费^[8]

ThoughtWorks帮助该网站进行了DevOps能力建设，尤其加强了基础设施自动化、环境自动化、测试自动化和部署自动化能力，并改进了开 发和运营团队的工作流程，使得典型需求的交付时间缩短50%以上，有效工作时间比达到90%以上，从而使该网站能够实现全面的业务敏捷。

挑战

DevOps能力建设是一项系统工程，很多方面的因素可能对其造成影响。以下列举几项最常见的风险：

• 跨部门协作。很多大型软件组织都将开发与运营划分为不同的部门，而DevOps需要开发人员与运营人员无缝融合、紧密协作，这必然涉及部门之间的协调。如果处理不当，部门墙有可能严重损害软件组织交付业务价值的能力。
• 高层领导投入。相比传统的瀑布式发布，DevOps是工作方式的变革，涉及到技术、流程乃至团队文化的改变。如果缺乏高层领导的关注，或者如果高层领导只把DevOps看作小范围、技术性的改善，DevOps建设将很难收到预期的效果。
• 团队稳定性。传统意义上的“运维”是技术含量较低的岗位，人员流动率也相对较高。DevOps要求开发团队和运营团队（尤其是运营团队）掌握更全面的技能，尤其是项目自动化技能。如果不能保证团队相对稳定，学习投资就会被浪费。

软件的发布过程是一个整体系统，需要对其进行端到端的流程优化。ThoughtWorks采用精益价值流改善（Lean Value Stream Improvement）作为DevOps建设的框架，并在其中嵌入针对软件构建、发布、运营的知识和实践，以迭代方式管理改善活动，全程以可视化形式直 观展现工作进展状态，从而最大程度地保障改善得以成功实施。

---

[1] 《软件开发沉思录》，人民邮电出版社2009年，第二章

[2] 图片来源：Damon Edwards的博客“什么是DevOps”（http://dev2ops.org/blog/2010/2/22/what-is-devops.html，或http://article.yeeyan.org/view/139515/170072）

[3] Wikipedia的“DevOps”词条：http://zh.wikipedia.org/wiki/DevOps

[4] 图片来源：Wikipedia的“DevOps”词条（http://zh.wikipedia.org/wiki/DevOps）

[5] 图片来源：Damon Edwards的博客“什么是DevOps”（http://dev2ops.org/blog/2010/2/22/what-is-devops.html，或http://article.yeeyan.org/view/139515/170072）

[6] 数据来源：April 2007 MySQL Conf and Expo和Flickr网站。

[7] 图片来源：10+ Deploys Per Day: Dev and Ops Cooperation at Flickr（http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr）

[8] 图片来源：ThoughtWorks内部数据