图片 7

火热的DevOps,你了解多少

听听第一个在Devops技术领域“吃螃蟹”者的心声

图片 1

今天,企业已经走进应用经济时代,在这个软件驱动业务发展的时代,以前每几个月交付一次应用的模式,已经无法满足企业的需求。如果企业希望继续保持竞争力,就必须做好持续交付创新的准备,同时还要满足企业和个人用户对高质量应用的要求。所以,企业要如何处理这一问题,尤其是在成本增加而预算又紧张的时期?Devops能否解决这一问题?

什么是DevOps?

DevOps这一术语出现已经有几年的时间了,但它究竟是什么?DevOps的出现是为了消除开发Dev)和运维Ops
)之间的沟通的障碍。众所周知Dev的重点在软件开发和快速创新;Ops的工作核心是业务稳定性、可控性和可预测性
;而两者结合的DevOps就是为了让这两个职能部门可以更加紧密地合作。DevOps的主要作用是提升新应用交付于市场的时间、质量和安全性;同时,把开发和运维紧密地连接起来从而达到减少成本的目的
。这在今天的应用生态系统中尤为重要。

DevOps已经显成效

你知道吗,这几年DevOps一直默默工作于企业之中。现在就让我们就跟随CA
Technologies中国区总经理陈光明的脚步,听听用户对DevOps的心声如何?

近日,CA
Technologies对全球13个国家,年收入在5亿美元以上的1,400多名高级IT和业务领导进行了调查,调查显示,那些第一次敢吃DevOps这只“螃蟹”的企业已经尝到了这只“螃蟹”的美味之处;也就是说,DevOps的先行者们已经感受到了DevOps的好处。下面这些数据足以说明企业采用DevOps策略之后的收益有怎样的变化。

下图是通过对每项收益的量化统计,以百分比为单位,部署DevOps后企业获得了多大程度的提升。

图片 2

由此可以看出,企业从部门间的合作能力提升到收入的增加,还有其它的一些方面,都提升了13%到23%不等。这是多么可观的一项收益提升。如果这份调查特别精准的话,那么企业就要对DevOps加倍重视了。

什么因素驱动企业采用DevOps?

这些企业为什么会选择DevOps呢?节省成本是所有企业都在追求的目标,这肯定是其中的原因之一,那么它是否也是主要或唯一的驱动力呢?有数据有真相,我们也还是来看看敢吃“螃蟹”的人是怎么回答的,毕竟他们才有真正的发言权。

图片 3

随着技术的发展,成本节约已经不是重要的驱动因素,同时底层基础架构也不再是问题。现在人们更关注的是企业的需求与用户的体验。应用经济时代下,快速的应用开发能力与高水平的用户体验,才是获得市场竞争力的关键。

另外,从图中我们已经了解到DevOps策略的采用,使用企业应用开发时间缩短了将近15%;应用恢复及维护时间缩短大约23%。在已经使用DevOps的案例中,我们可以自信地说DevOps采用确实解决了企业对应用开发时间的要求。那么节省下来的时间,企业完全可以进行应用体验的改进,让用户体验更上一层楼。

虽然DevOps已经默默走进企业中,而且也有不小的成效。但在它发展前进的道路上还是存在着一些障碍。不用太多思考,首先一大障碍就是安全性,无论哪项新技术的采用,这一问题肯定是谁也逃避不了的。那么除了这一“通用”障碍外,是否还有其它因素牵绊着DevOps的成长?

这里我们看看CA Technologies亲自接触客户后,他们发现了哪些真相?

图片 4

由调查数据可以看出,部门之间沟通是企业领导最关心的,同时也是DevOps更加努力的方向。此外,2014年还出现了一个新的值得注意的阻碍——就是ROI评估困难的问题。因此,DevOps要想在更大范围的企业中得到实施部署,首先就要扳倒这两块绊脚石。

正如陈光明总经理一再强调的那样,“现在所有的企业都是软件公司”。这对应用生态系统造成了重大的威胁,因此企业不能坐以待毙,需要立刻行动起来,加深对DevOps的印象,因为DevOps已经解决了企业的部分问题。不过,在采用DevOps策略之前,企业要结合自身的业务需求,从实际出发,才能更好的拥抱新技术、新设计方法和创新方式!


图片 5


今天,企业已经走进应用经济时代,在这个软件驱动业务发展的时代,以前每几个月交付一…

图片 6

说起DevOps有多火,相信大家在每天的朋友圈中就能够感受到。如此同时,另外一个佐证就是新鲜出炉的Gartner
2015 I&O Automation报告中,DevOps正处其技术发展曲线的在最高点(如下图)。

图片 7

当然,上面的图也同样说明DevOps在企业内部落实还有很多路需要走,需要落实到企业日常IT系统的开发、测试和运维,有效提升企业的IT服务能力。也正是因为如此,现在很多人可能对于DevOps的理念仍然充满怀疑。但是,不断出现的成功案例还是让大家对其充满期待。为此,由Puppet
Labs领导的年度DevOps发展报告也希望能够对此进行更全面分析和调研,其2014年DevOps发展报告则再次用具体调查数据揭示了组织绩效、IT服务绩效与DevOps实践之间的关系。其中的核心观点包括如下:

◆拥有强IT服务绩效的企业通常会双倍超过其市场及盈利目标。

◆企业的IT服务绩效和DevOps推崇的普遍实践(如持续交付等)有非常明显的正相关。例如,调查发现强IT服务绩效的团队比较差IT服务绩效团队的部署频率要快30倍,变更失败率要低50%。

由上可见,DevOps实践对于提升企业IT服务能力是有明显的正面作用,并且从实践中也得到广泛验证,值得企业关注和学习。

一、DevOps从哪里来? 

如果希望了解DevOps,就不可避免需要要展开这个词中的两个角色:Dev和Ops(注:这里的Dev包括我们常说的开发和测试人员,Ops则指服务运维人员,更多时候特指生产环境的服务运维人员)。回顾历史,Dev和Ops这两个角色从计算机诞生之日就已经存在,而且在诞生之初它们本身就是一体的。在最早期,计算机的使用范围非常有限。其硬件生产、软件开发和日常运维很多时候都是来自同样人员或者团队。所以,Dev和Ops这两个角色也就自然融合在一块。

随着计算机使用用途的扩展,越来越多的行业开始使用计算机来提升效率。尤其是个人电脑(PC)的出现,让计算机从传统的计算领域大大拓展开来。于是,PC时代其就诞生了许多独立的计算机软硬件供应商出现。进入这个阶段后,计算机软硬件研发就会和最终使用者自然分离。当企业普遍开始使用计算机及相关软件来提升日常运营效率时,会需要专职的IT系统运维管理人员来保证其正常运行,于是,最早期的专职运维人员(也称系统管理员)也就应运而生。

在这个阶段,系统的研发人员(Dev)和运维人员(Ops)其实是处在不同的组织中。他们之间的沟通和交互主要靠产品说明书,操作文档以及付费的Support完成。为保证企业内IT系统的稳定运行,以Ops为中心的运维管理体系(如ITIL)逐步形成。在这个时间段,企业运维管理体系以服务企业内部运营为主,并不直接面对企业最终用户。实际运维过程则以保证系统稳定为核心目标,对于系统自身的迭代速度要求并不高。一个最明显的例证就是这个时期软件及系统的交付周期一般都是以年为单位(甚至于Windows则以三年为单位更新版本)。同时,由于这个阶段的Dev和Ops完全分离在不同组织中,基本无法形成持续有效的沟通和交互,也就是无法相互了解。通常Ops团队对于软件的设计及实现思路缺乏最基本的了解,而Dev团队对于Ops在实际运维过程中的挑战和问题也知之甚少。

随着互联网和移动互联网的出现,人们重要找到了一种更好的软件及服务交付方式,即在线服务。在这种模式下,用户无需再承担软件及服务的运维工作,而是直接
“开箱即用”。系统的开发和运维工作再次回到一个组织内部,即在线服务提供商。但是,由于遗留系统(很多在线服务提供商在早期并没有自研能力,而是采购外部技术来搭建自身服务系统)及传统运维思路的影响,很多在线服务供应商仍然是按照传统模式组建自身的运维团队。于是,很多组织内部的运维团队和研发团队虽然是在一个公司,也服务于同一个产品。但是他们在组织架构上仍然是独立向上汇报。甚至,这种组织架构在很多公司内部还作为一种均衡各方势力的法宝。由于这些原因,所有原来Dev和Ops相互分离而造成的问题并未由于他们重新回到一个组织内而得到根本改观。同样存在内Dev和Ops相互不了解,互不信任,上线流程异常缓慢等很多老问题。于是,人们就会思考一个问题:既然都在一个组织内,而且是服务于同一个产品,为啥不能让两者走向融合,变成一个以给最终用户交付最大价值为目标的团队呢?于是,DevOps思潮开始涌现,并从理论研究逐步成为目前非常主流的软件生产方式。在这其中也诞生了很多非常优秀的DevOps践行者,如Facebook、Netflix等。

回顾发展历史,我们可以看到随着系统交付及使用方式的不断演变,Dev和Ops两者也经历了由合到分,又重新走向融合的过程。在其中可以看出,系统的生产方式其实和系统交付及使用方式息息相关。有什么样的交付及使用方式,就会诞生与之匹配的系统生产方式。而现在,以互联网和SaaS为代表的交付及使用方式已经成为主流趋势,与之相对应的软件生产方式也必然会向全新的DevOps方向发展。

二、DevOps包括什么? 

尽管DevOps在现在这个阶段重新走向融合,但是这个阶段的融合已经和最早期Dev和Ops来着同一个团队有本质的差别了。无论从系统的复杂程度,面对的用户规模,还是采用软件工程思路都有天壤之别。具体来说,个人认为现在的DevOps应该包括如下三个层面的内容:

1.从组织文化角度上,DevOps应该成为组织文化上的一个内在要求。首先,企业关注的产出应该转向最终交付价值(即交付给最终用户的产品功能、用户体验)以及响应用户和市场变化的能力。其次,企业需要从组织架构上解决遗留下来的Dev和Ops隔离的状态,为他们走向融合提供组织制度上的保障。最后,DevOps文化强调跨部门协作和直接主动沟通,而不是流程导向的流水线模式。总结来说,需要在组织内部树立“you
build it, you run it”的行为准则。

2.从方法论角度上,DevOps包括一系列最大化交付价值的最佳实践。例如,持续交付来提高交付的频率,保证Dev的每一个改进能够尽快交付给最终用户,并能够快速得到真实用户的反馈,以便及时调整产品方向。持续构建和自动化测试保证Dev能够尽快得到反馈,发现代码中潜在的问题并及时修复。自动化一切的原则尽可能避免人为失误并且保证整个流程的高效,可重复。

3.从工具角度上,DevOps指一套适应DevOps组织架构需求,能够帮助团队落实DevOps最佳实践的工具。这其中包括代码管理工具、持续构建工具、代码部署工具、系统监控与运维工具等。在工具选型中,用户即可以基于开源软件自己搭建,也可以考虑购买商业软件(如FIT2CLOUD)来快速落地。

总结而言,DevOps团队需要在组织文化层面能够得到保证和支持,团队成员能够接受并践行DevOps各种最佳实践,并配套相应工具帮助落实。只有这样才能比较完整的落实DevOps实践,并最终让团队和业务都从中收益,最大化交付给最终用户的价值。而不是流于形式和炒作概念,并无法最终在实践中见成效。

三、DevOps的抓手在哪里?

如果一个组织希望推进DevOps实践的落地,从哪里入手可能是很多组织内一线经理最为困惑的地方。网络上关于DevOps的分享涉及的内容非常多。那DevOps的抓手到底在哪里?来自Puppet
Labs 2015
DevOps发展报告的结论则能够很好回答这个问题。其报告结论中包括如下观点:

如果需要了解一个团队的DevOps状况,只需要问一个简单的问题,那就是“团队部署一次服务有多痛苦”。这个问题的答案会告诉你很多细节。

同样,DevOps最好的抓手也在于此。提高团队持续交付和部署的能力在绝大部分情况下都是落实DevOps实践最好突破口。在落实这个突破口时,团队需要关注如下几点: