[转载]逐步建设企业DevOps能力

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

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

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

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

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

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

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

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

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

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

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

2.敏捷拉通的尝试

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

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

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

3.对策

针对现代大型软件组织在软件发布、运营与维护过程中面临的种种挑战,ThoughtWorks建议在软件组织中建设DevOps[3]能力,从而提升整个组织的IT融合程度,改善软件交付“最后一公里”的质量和效率,为实现业务敏捷打好基础。
DevOps是一组流程、技术与工具的统称,用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合。“DevOps”这个名称即是指开发(dev)与运营(op)的无缝融合。具备DevOps能力的组织能够开展快速、反应灵敏同时又稳定可靠的业务运维,使其能够与开发过程的创新保持同步,从而使得敏捷开发的优势在组织层面上得到展现。

(1).精益运维
传统的软件运营人员通常倾向于尽量避免修改功能,从而降低满足非功能性需求的风险。但如果拒绝了小的修改,而给定时间段内需要修改的总量不变,那么每次变更的规模就会变大,从而增加每次发布的风险(因为变更涉及的范围更大)。
DevOps的指导思想是“精益运维”。精益生产的很多原则,例如缩短交付周期、消除浪费、重视价值流动、拉动式生产、质量内建等,在DevOps中都得到了体现。与传统的软件发布方式相比,DevOps主要通过以下几方面的改变来提升效率和质量:

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

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

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

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

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

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

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

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

4.案例

案例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%以上,从而使该网站能够实现全面的业务敏捷。

5.挑战

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内部数据



感谢张凯峰对本文的审校。

博客转自:InfoQ的作者 熊节发布于 2007年3月26日《建设DevOps能力,实现业务敏捷

另注:51CTO 关于DevOps专题:《DevOps,并非你想的那么简单

时间: 2024-11-03 21:55:32

[转载]逐步建设企业DevOps能力的相关文章

OpenStack建设企业私有云要解决五大问题

OpenStack已经成为一种趋势,但发行版OpenStack尚不完美,企业要建成私有云必须预先充分了解发行版OpenStack的缺点,并寻求专业OpenStack提供商的帮助与合作,才能扬长避短,真正发挥OpenStack的优势,建成最大化企业竞争优势的私有云. OpenStack在企业里如何用好?还有哪些问题需要着重解决?OpenStack在企业里怎么才能用好?开发人员认为是使用姿势的问题;用户认为要稳定可靠,不能老宕机;老板认为多招几个牛X的开发和运维就可以搞定. 其实OpenStack在

OpenStack 建设企业私有云要解决五大问题

OpenStack已经成为一种趋势,但发行版OpenStack尚不完美,企业要建成私有云必须预先充分了解发行版OpenStack的缺点,并寻求专业OpenStack提供商的帮助与合作,才能扬长避短,真正发挥OpenStack的优势,建成最大化企业竞争优势的私有云. OpenStack在企业里如何用好?还有哪些问题需要着重解决?OpenStack在企业里怎么才能用好?开发人员认为是使用姿势的问题;用户认为要稳定可靠,不能老宕机;老板认为多招几个牛X的开发和运维就可以搞定. 其实OpenStack在

基于Jenkins打造符合DevOps能力成熟度三级标准的持续集成流水线

DevOps的核心是自动化,自动化的核心是标准化.而DevOps最重要的一环节是持续交付,持续交付中建设的重点是流水线,所以如何打造标准的持续交付流水线则为DevOps建设中最重要的一环,也是评估DevOps能力的一个重要的打分点.本文内容参照<研发运营一体化(DevOps)能力成熟度模型 第3部分:持续交付>,基于jenkins,对持续集成流水线建设的一些关键点进行技术应答,带领大家把方法论落地到具体的技术点上. 文中涉及到的几个名词解释:1,流水线:pipeline,一个应用程序从构建.部

实战篇:如何建设企业的营销管理和分析平台

企业每天都在制造大量的经营数据,这些数据反映了企业生成.销售状况.营销分析是在广泛收集信息资料的基础上,运用各种定性和定量的方法,帮助管理层决策分析,更好的为开展营销工作服务. 一般而言营销管理分析系统包含以下几个基本要求: ①灵活弹性的报表设计,适应各个地区.情况的报表需求,能迎合企业需要快速反应企业状况: ②可视化的数据呈现方式,帮助企业领导层快速解读报表内容: ③多元化的数据分析维度,帮助企业发现数据隐含的意义. 前述讲完了,下面就开始我们的实战: (一)企业介绍: 主角--青岛海立美达股

[转载]持续交付和DevOps的前世今生

作者/分享人:乔梁,20年IT老兵,腾讯公司高级管理顾问,敏捷和精益开发专家,持续交付领域先行者.曾就职于百度,国内多个知名互联网公司的企业教练. 历年QCon技术大会的讲师和专题出品人. 这是一个新概念风起云勇的时代. 就让我们从云端抓它几个名词下来,一起玩耍吧!!! “敏捷软件开发”,“增长黑客”,“持续集成”,“DevOps”,“精益创业”,“持续交付”,“大数据”... ... OK,就这四个啦: “敏捷软件开发”,“持续集成”,“DevOps”,“持续交付”. 先让我们在Wikiped

转载:中国企业的价值将面临重估

诸葛修车网230万被收购,最大败笔在哪? 2017-01-19 16:22:00来源:微信公众号:人和岛 摘要当聪明资本正在加速逃离,如王冉所言,中国企业的价值将面临重估.因此,账面独角兽现出原形,甚至变成"独脚兽"或"独角尸",瘦死的骆驼变成马,大鱼变小鱼,虾最后化作了泥巴等--这都不足为奇. ST诸葛1月16日公告,1月15日,原实际控制人祁庆与吴让生签订<股权转让协议>,该协议约定,祁庆将其持有的和创万通46%股权转让给吴让生,转让价格为230万元

一步一步建设企业信息化业务驱动系统系列-0

很久都没静下心来写文章了,最近在新公司,新环境,接触了一些企业信息化业务需求,由此产生了关于业务驱动的想法 特此申明:本文章所提内容均由个人经验转化和理解,与实际有偏差在所难免,请见谅! 为什么是业务驱动? 如果从企业业务层面讲,比如一个采购流程,采购申请->询价->合同->订单->交货跟踪->验收->入库.其实是一个完整闭环操作.既然是闭环,那么就有开始和结束.采购申请即是流程开始环节,而采购入库则是流程结束环节.然后当企业没有信息化手段时,这整个过程全需要人为干预,

[转载]反无人机企业DroneShield利用声音识别侦测无人机

原文:http://www.cnbeta.com/articles/495071.htm 无人机产业正在蓬勃发展,受益的不仅仅是那些生产小型飞行设备的企业.专家估计仅在澳大利亚就有5万架商用无人机以及消遣用无人机.然而这也意味着有5万 次无人机飞到禁飞区域的可能,执法部门将面临数量庞大的无人机所带来的挑战.DroneShield是一家率先推出反无人机商用产品的企业,他们于 2014年成立于美国,如今他们希望能在澳大利亚开辟出广阔的市场. 反无人机产品如何工作? 雷达.调频无线电以及摄像头科技都可

2.一步一步建设企业信息化业务驱动系统系列-系统结构

将上节中提到的系统架构转化成解决方案,如下图:  APP: WIN CE/Mobile 数据采集客户端,一般通过条码或rifd扫描完成,执行业务缓存与同步 安卓/IOS 报表,审批 MC: 基础数据配置,表单配置器,流程配置器,其他配置 WEB: 报表,审批 Win: 基础数据,权限管理,业务查询,业务引导和处理,客户端业务计算,业务缓存与同步 BLL: 插件化的业务组件,配合具体业务完成相应的业务操作,如下单,审核,更新,查询等,版本控制 DB: 可扩展的数据持久化组件,完成数据存储和执行,反