标签:
当软件行业进入互联网时代,市场对软件产品和服务的交付提出了更高的要求:不仅要快速实现需求,而且要快速发布上线,并且必须保证业务可靠、高效运行。为了满足这些要求,IT组织需要强有力的流程、技术和人员作为保障。
ThoughtWorks很早就认识到发布与运营对于成功交付的重要性。我们的创始人Roy Singham在《走完业务软件的“最后一公里”》[1]一文中指出:
所谓[软件开发的]“最后一公里”,是指软件满足了功能需求之后,尚未投入实际运行并创造业务价值的阶段。软件开发者──尤其是面对交付压力的软件开发者──常常对“最后一公里”视而不见。但它确实正在成为业务软件交付中最大的压力点。
本文将分析大型软件组织在软件发布与运营维护阶段常见的典型问题,并介绍一种行之有效的解决对策。
(1).快速响应
传统观念中规模庞大、发布周期长达数月乃至数年的软件产品研发方式正在发生变化。在“快鱼吃慢鱼”的互联网时代,上市时间(Time To Market)成为衡量软件组织能力的重要因素:能快速接纳需求、快速完成开发、快速上线投入使用的软件产品,才能有效占领市场、吸引用户。
在以迭代式开发为特征的敏捷开发方法和以Ruby on Rails为代表的一批高效开发工具帮助下,很多软件组织在实现功能性需求方面的能力得到了显著提升。然而从业务负责人的角度来说,仅仅提升开发阶段的效率还不足以实现端到端的快速响应。很多软件组织虽然以迭代方式进行开发,但发布和部署仍然按照从前的节奏,每隔几个月才进行一次。这时从客户与最终用户的视角看来,这些软件组织的交付仍然是以瀑布方式进行:客户与最终用户并没有直接感知到开发能力提升所带来的利益(如图1)。
不能有效缩短部署上线的周期,就无法真正实现快速响应业务需求、快速实现业务价值。如何缩短发布和运维工作的周期,已经成为困扰很多软件组织领导者的问题。
图1:迭代式开发+瀑布式发布[2]
(2).质量
大型软件组织通常都很重视产品质量,并在开发/测试阶段投入大量成本与精力进行质量保障活动。但软件产品的质量问题不仅在开发阶段引入,靠传统意义上的测试工作也不能完全发现。有相当比例的质量问题是在开发/测试阶段之后引入或发现的。造成这一现象的原因有:
通过引入自动化测试、测试驱动开发、持续集成等敏捷实践,开发/测试阶段的质量保障活动能够得到有效改善。然而对于客户和最终用户来说,不论哪个环节引入的缺陷都同样会给业务造成损失。如何在部署上线的紧迫压力下保证质量,这也是众多软件组织领导者关注的一个问题。
一些软件组织意识到这些问题的存在,并希望以敏捷开发方法为出发点,将下游的发布、部署、运维等工作环节拉通,从而提升整体响应能力。但由于软件开发与运营之间存在一些固有的差异,这样的拉通活动往往困难重重:
由于存在这些固有的差异,单纯从开发团队的角度出发、将敏捷软件开发的实践推广到运营团队,很难有效帮助运营团队改善。需要从运营维护工作本身的特点出发,引入符合客观情况的流程、技术和工具,才能有效改善运营维护工作的质量和效率。
针对现代大型软件组织在软件发布、运营与维护过程中面临的种种挑战,ThoughtWorks建议在软件组织中建设DevOps[3]能力,从而提升整个组织的IT融合程度,改善软件交付“最后一公里”的质量和效率,为实现业务敏捷打好基础。
DevOps是一组流程、技术与工具的统称,用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合。“DevOps”这个名称即是指开发(dev)与运营(op)的无缝融合。具备DevOps能力的组织能够开展快速、反应灵敏同时又稳定可靠的业务运维,使其能够与开发过程的创新保持同步,从而使得敏捷开发的优势在组织层面上得到展现。
(1).精益运维
传统的软件运营人员通常倾向于尽量避免修改功能,从而降低满足非功能性需求的风险。但如果拒绝了小的修改,而给定时间段内需要修改的总量不变,那么每次变更的规模就会变大,从而增加每次发布的风险(因为变更涉及的范围更大)。
DevOps的指导思想是“精益运维”。精益生产的很多原则,例如缩短交付周期、消除浪费、重视价值流动、拉动式生产、质量内建等,在DevOps中都得到了体现。与传统的软件发布方式相比,DevOps主要通过以下几方面的改变来提升效率和质量:
图2: 应用程序以平滑的速率逐渐生长[4]
从工作流程、协调机制、技术工具等几个方面同时着手,就能在软件组织中建立起DevOps能力,从而将精益运维变成现实。
(2).敏捷开发
DevOps与敏捷软件开发同样具有精益的指导思想,在实践层面也有很多共通之处。可以把敏捷软件开发看作精益思想在需求、研发阶段的实施,DevOps则是精益思想在发布、运营阶段的实施(如图3)。尽管建设DevOps能力并不必须要求软件组织具备敏捷软件开发能力,不过以下敏捷实践会对DevOps能力建设产生尤为明显的帮助:
图3:DevOps与敏捷既相关又不同[5]
(3).收益
通过建设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能力建设是一项系统工程,很多方面的因素可能对其造成影响。以下列举几项最常见的风险:
软件的发布过程是一个整体系统,需要对其进行端到端的流程优化。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内部数据
感谢张凯峰对本文的审校。
博客转自:InfoQ的作者 熊节 发布于 2007年3月26日《建设DevOps能力,实现业务敏捷》
另注:51CTO 关于DevOps专题:《DevOps,并非你想的那么简单》
标签:
原文地址:http://www.cnblogs.com/SanMaoSpace/p/4805260.html