2757com 10

Dev 和 Ops2757com 的核心矛盾,DevOps的出现是为了消除开发Dev)和运维Ops

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

2757com 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后企业获得了多大程度的提升。

2757com 2

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

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

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

2757com 3

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

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

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

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

2757com 4

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

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


2757com 5


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

◆稳定性指标:

在中国DevOps时代社区发布了中国IT企业DevOps持续交付流水线现状调查报告,几个数据印象比较深刻:

业务-用户反馈环(紫色箭头反馈环):

过程管理方面:

运维作为用户问题的第一个响应人:运维人员和销售人员一样,都可以作为处理用户的问题的一线,并反馈给业务部门。

○ 代码上线延时(Deployment lead
time):代码从提交到代码库到其上线运行的时间间隔。

在那个还没有云技术,大家把机器都部署在机房的时代,往往运维部门都需要提前三个月收集大家的资源需求,提前采购资源。一旦出现紧急上线的情况,就会很容易出现系统上线失败。但是用户上云后,这种情况发生的可能性非常小。在云上用户资源是按需申请,降低了运维难度,节省了成本提高了资源利用率。除了这一有优点,云还提供了各种自动化运维工具集,但实际上这些工具对于用户来说相互之间的使用是孤立的。而且对于用户来说,他最关注的是如何降低自身的运维成本,让应用从代码到系统上线完全自动化。

开发-测试反馈环(黑色箭头反馈环):

技术方面:

由非功能特性(扩展性,可用性)驱动的软件架构:用NO-SQL数据库或队列系统(Queue
System)增加系统的可扩展性,以及混合使用编程语言和memcache这样的缓存系统。

过程管理方面:

拉近软件开发和系统工程的交互:采用敏捷团队或者其它形式的多功能团队跨越不同的部门墙。

1.理清并打通团队从代码到服务的整个通道最为关键。例如,下图就是一个典型的从代码到服务的通道。需要提高团队持续交付和部署的能力就体现在是否能够打通这条通道,并让其尽可能高效的运转。

我们都知道在软件开发过程中应用程序的发布是整个开发流程中压力最高、风险最高的流程。这是需要开发与运营通力合作才能顺利完成的工作。而在传统的软件组织是将开发、IT运营和质量保障设为各自分离的部门。这就造成了他们之间有一堵沉重的墙,使得这些流程是相互割裂开的。

重新定义Ops的工作目标

在一个组织中,如果相关利益者的利益不一致,在既定流程的进行中一定会碰到诸多阻力。而在这一点上,首先做得就是把
Dev 和 Ops 的利益一致化,从而减少Ops对软件交付的阻力。在演讲中,John
Allspaw 和 Paul Hammond 首先挑战的是对 Dev 和 Ops 的传统观点。

传统的观点认为Dev和Ops的工作是不同的:

Dev的工作是增添新的功能

Ops的工作是保证站点的稳定和高性能

他们认为,保证站点的稳定和高性能不是 Ops 的工作目标。

Ops的工作目标应该是激活业务(enable the business
),而这一点和Dev是一致的。

理想往往是美好的,现实往往是残酷的。激活业务会带来更多的变更,而更多的变更会引起故障!

面对这样的问题,就需要做出一个选择:为了保障稳定性减少变更,还是及时按需变更?

阿拉伯有一个谚语:“你若不想做,会找到一个借口。你若想做,会找到一个方法。”

Flicker
并没有屈服于压力,他们选择让问题向目标妥协,而不是目标向问题妥协。他们的手段是:

2757com 6

3.
在整个项目开发期间,业务人员和开发人员必须朝夕工作在一起。与开发团队以及在开发团队内部要面对面的交谈。

参考链接:

http://cdn.oreillystatic.com/en/assets/1/event/29/10+%20Deploys%20Per%20Day\_%20Dev%20and%20Ops%20Cooperation%20at%20Flickr%20Presentation.pdf

2757com 7

http://www.jedi.be/blog/2009/12/22/charting-out-devops-ideas/

http://www.jedi.be/blog/2010/02/12/what-is-this-devops-thing-anyway/

https://www.devopsdays.org/

What Is DevOps?

◆团队缺少保证不同环境一致性的能力。如上图所示,系统交付流程需要涉及到开发、测试、验收和生产环境(简称DTAP),如何保证不同环境一致性并避免系统因环境不一致而导致事故是一个重要挑战。一般来说,使用统一的基础环境(如镜像)加统一的部署流程及工具是保障环境一致性的关键所在。

1.调查者中65%以上用户实现了一周一次以上的部署,在微服务的时代快速发布将成为常态。

总结

第一届DevOpsDays秉承着Velocity 09中 “Dev and Ops
Cooperation”的理念汇集了世界上所有关注于解决 Dev和 Ops
矛盾的有志之士。然而,通过大家的交流,发现软件交付的问题并不仅仅是 Dev
和Ops合作那么简单,通过文章我们发现:

◆团队缺少统一的制品库管理。现实环境中,团队构建出来的artifacts经常直接存在FTP、共享目录上,组织不规范而且也未集中管理。因此经常出现选择的版本不对,需要回滚时候没有老版本,不同环境版本选择错误等一系列问题。建议团队建立统一的制品库(例如开源的Nexsus,商业软件Artifactory等)并直接对接构建环境和部署系统。构建时候自动把构建结果打包上传到制品库中,部署时从统一制品库取部署包进行部署。

2757com 8

业务-运维反馈环(红色箭头反馈环):

技术方面:

基于云计算和敏捷基础设施的新系统架构:云计算和敏捷的基础设施可以获得更好和更先进的自动化部署手段和系统初始化手段。

过程管理方面:

业务部门应当同时关注功能和非功能需求:业务应当开始关注停机时间和数据丢失带来的影响。

运维团队参与过程上游而不是被动的角色:在运维中采用看板在项目阶段进行互动,甚至可以用在项目前的阶段(销售、服务水平管理)。

运维团队自组织以应对业务挑战:例如把敏捷引入运维(agile
operations)
或把精益引入运维(lean operations)

业务使用运维指标作为反馈:要了解用户喜欢什么,如何行动。为了做出更好的业务决策,性能降低或故障中断正在成为一个重要的反馈回路。

○ 变更失败率(Change fail rate):变更失败率。

由此可见Jenkins已经成为了大家实现devops流水线首选工具。但是Jenkins受限于时代的局限性,虽然在当时是跨时代的优秀产品,但是在当前技术迅速发展的时代,有些固有问题很难解决。首先master节点的高可用无法保证,其次当脚本越来越复杂时性能的消耗会非常严重,即使使用Master+Slave方式,随着集群规模的增大,网络维持的消耗都非常巨大,高峰期会严重影响开发和部署效率。

通过以上四个反馈环我们发现两个关键点:

1. DevOps
不仅仅是IT部门的事情,他涉及到IT部门以外的部门,包括最终用户。在脱离像
Flicker 这样的互联网公司这个大背景下。企业级IT部门采用 DevOps
还会遇到更多外部挑战。

2.
新的技术,尤其敏捷软件开发观念的深入和大规模基础设施(虚拟化,云计算,SDN)的不断发展让
Ops 以 Dev 的方式工作成为可能。

○ 部署频率(Deployment
frequency):团队代码部署的频率(包括所有环境的部署次数),一般以每天的部署次数计算。

  1. 要考量系统级别的整体效率,而不是某一个环节上的效率。

  2. 要确保能够提供持续不断的反馈循环。

  3. 要持续的学习和吸取经验,不停的提升。

前言

#DevOps的前世今生# 2. Dev和Ops矛盾缘何而来
一文中,通过Dev和Ops的历史发展总结出了Dev和Ops矛盾的历史渊源,以及
Dev 和 Ops 的核心矛盾:

Dev 和 Ops 的矛盾主要是面向适应性的敏捷软件交付和面向经验性的传统运维之间的矛盾。

但这个矛盾最先 John Allspaw Paul Hammond在 “10+ Deploys Per
Day: Dev and Ops Cooperation at Flickr

提出,并以“Cooperation”作为整个演讲的核心,讲述了他们解决这个矛盾的实践经验。这个演讲中:

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

2.
灵活:提供了多种Stage,客户可以灵活搭配自己的流水线。涵盖了源码下载、镜像构建、Jenkins构建、镜像部署、灰度发布等核心组件。满足用户多样化的需求。

DevOps的手段——技术升级和流程管理

于此同时,Patrick 发现, DevOpsDays
的所有话题都围绕着两条主线:技术(technologies)流程管理(process
management)
,而这些话题又相互交织在一起形成了四个不同的反馈环,如下图所示。其中蓝色气泡代表技术,黄色气泡代表过程管理: 

2757com 9

DevOps 反馈环

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

1.完善:从源码到部署的完整的一套流水线,满足客户各方面的需求。

DevOps 本质是一场以提升质量內建为手段,以加速软件系统价值流反馈为目标的技术提升和管理变革。

但是,DevOps 运动后续的发展却并不顺利:

一方面,由于 DevOps
这个很短的单词中包含了太多的概念,又缺乏足够的限定,使得 DevOps
的概念很模糊。让不同的人对于 DevOps 的理解千差万别。

另一方面, 来自传统运维对 DevOps
的批评也让这种基于社区(集市)而非基于专业性组织(大教堂)产生了质疑。由于缺乏系统化的方法论,使得更多的企业在实践
DevOps 中处于观望或低水平的软件工具升级阶段。

然而,DevOps 的实践者们仍然在不断总结和完善。使得 DevOps
的文化价值体系渐渐成型,使得大家能够更好的理解和实践
DevOps。请期待下篇#DevOps的前世今生# 4. DevOps的文化和原则

感谢ThoughtWorks 高级咨询师
马博文,伍斌,黄博文
给本文提出的宝贵意见。

2757com 10

最后,你是不是希望真实的体验一把华为云容器呢?现在机会来了!

开发-运维反馈环(绿色箭头反馈环):

技术方面:

系统管理员采用软件开发技术:使用代码仓库、持续集成、测试工具、设计模式来自动化的处理系统的初始化操作。

部署的配置管理:采用配置管理以及自动化配置工具(Chef,Puppet)用于部署和生产环境的变更。

测试和监控相互辅助:在监控系统中复用自动化测试逻辑(比如:cucumber-nagios),在测试环境中使用监控手段验证测试场景。

运维团队开发新的系统管理工具:工具也是技术水平差距的重要体现,很多系统管理员开发新的工具用来处理大规模的部署,变更以及监控。

过程管理方面

拉近软件开发和系统工程的交互:敏捷项目或者其他形成多功能团队的方法替代不同的部门墙。

项目从运维中学习:架构在项目中不断获得反馈,从而知道哪些可以用,哪些不能用。这样可以得到更好的架构设计。

通过关注上面这些指标的变化趋势,团队可以定量衡量整个应用交付的效率和质量,并能够始终保证对于应用交付的关注。当然,为了更方便统计如上指标,需要记录团队所有的部署操作及结果,不过这应该是一个好的部署系统需要支持的基本功能之一。

华为云在实践ContainerOps的时候,不是简简单单的把它视作流水线,一个简单的工作流。我们更愿意从用户的视角去看待为什么选择上云,上云给他们带来了什么好处。

构建相互合作的工具和文化

降低变更风险的关键就是在于提高可靠性,这不仅仅是Dev在软件开发中,也需要Ops把可靠性通过非功能性需求(性能要求,扩展性,安全性等)注入到软件开发过程中。通过系统交付过程中的质量內建而不是事后检验来提升交付质量。

而 Dev 和 Ops 的具体矛盾点表现在以下两方面:

在价值流下游的 Ops 评审认为价值链上游的 Dev
软件非功能质量不满足要求,因此阻止变更。

在价值流上游的 Dev 无法获得价值链下游的 Ops
的真实运行环境,因此无法提升交付质量。

于是,逐渐陷入了“无法提升质量”和“ 非功能质量不满足要求
”的死循环中。

由于在 Dev 环节关心的是功能性需求,往往忽略了非功能性需求,而 Ops
更关注的是非功能性需求。所以通过质量內建,把运维加入开发反馈环。在开发环节中增加非功能性的需求的实现和验收,让
Ops 担任最终的 QA 的角色。从而提升了交付质量,也提升了反馈速度。

首先,他们通过基础设施自动化(Automated infrastructure
提升了基础设施准备的质量和效率。

其次,他们搭建了Dev和Ops 交付的桥梁:共享版本控制(Shared Version
Control )
并且通过功能开关(Feature flags )管理功能发布。

然后,通过一步构建和部署(One step build and deploy
以及频繁进行小变更(Small frequent
changes)
提升单向价值流速度并降低部署风险。

最后,采用共享运维指标(Shared metrics ),和即时消息工具集成(IRC
and IM robots )
提升沟通效率以做到及时反馈并进行改进。

但仅仅有这些是不够的,还需要构建出合作的文化。合作的文化的构建关键在 Dev
和 Ops 之间的尊敬,相互信任,以及面对失败的改进而非指责的态度

第一届 DevOpsDays 在继承了这些思想的方向上则走的更远。第一届 DevOpsDays
吸引了更多关注于这一领域的人群,它们甚至都不具备技术背景。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

相关文章