而当前敏捷开发的要求巴黎人澳门官网:,DevO
分类:巴黎人-服务器

听听第一个在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


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

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

3.全连接:提供多种notification方式,方便客户原有系统的接入,以轻量化的形式去使用流水线。

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

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

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

◆稳定性指标:

于2013年初诞生的Docker,它能够快速的交付和部署、高效的虚拟化、轻松的迁移和扩展,简单的管理,更加敏捷。使得它天然的拥抱敏捷开发,与微服务开发结合起来。云原生开发的概念甚嚣尘上,尤其当K8S成为容器编排的事实标准之后,云原生越加火热,而它天然包含了devops流程。

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

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

巴黎人澳门官网 6

DevOps 反馈环

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

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

技术方面:

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

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

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

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

过程管理方面

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

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

巴黎人澳门官网 7

三、华为云是如何实践ContainerOps的

前言

#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”作为整个演讲的核心,讲述了他们解决这个矛盾的实践经验。这个演讲中:

【编辑推荐】

本期实战营汇聚华为云众多记述专家,包含K8s、Docker、Istio等大热技术,并且零门槛,全免费!快来加入吧!

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

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

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

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

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

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

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

巴黎人澳门官网 8

参考链接:

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

巴黎人澳门官网 9

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/

https://theagileadmin.com/what-is-devops/

如您想了解更多关于Riverbed的信息,可以扫描下面二维码关注Riverbed官方微信:

2.64%的受访者已经引入持续交付流水线,其中86%都在使用Jenkins。看来Jenkins基本都已经成为交付流水线的代名词了。

重新定义Ops的工作目标

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

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

Dev的工作是增添新的功能

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

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

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

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

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

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

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

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

二、容器给Devops带来了什么?

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

技术方面:

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

过程管理方面:

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

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

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

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

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

DevOps就是这样的一个方法论,它是来思考如何让Dev和Ops进行合作与协同,它要求我们:

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

技术方面:

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

过程管理方面:

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

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

华为云DevCloud&云容器服务联合出品——21天转型容器实战营限时招募中!

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

降低变更风险的关键就是在于提高可靠性,这不仅仅是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 吸引了更多关注于这一领域的人群,它们甚至都不具备技术背景。

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

4. 安全:基于镜像仓库的权限管理,客户完全不用担心镜像的安全性,保障用户的使用。

DevOps的目标——提升软件交付的质量內建以加速流程

在第一次 DevOpsDays 会议后,作为 DevOpsDays 活动的发起人和 DevOps 这个词的创始人,Patrick Debois 随后总结并写下了“Charting out devops ideas”一文,他把第一届 DevOpsDays 这也成为后续 DevOps 运动的理念基石。在这篇文章里,Patrick从第一届DevOps活动中有了两个重要的观察,分别是:

1. DevOps 是在业务、交付流程和运维之间反馈环中增加了一个反馈环。

2. 因为有了这样一个环节,我们可以提升质量以加速流程。

简而言之,DevOps 是把运维(Ops)加入到了价值流的反馈环中。并且通过提升软件交付的质量內建以加速价值链端到端的反馈效率。

而要实现这一目标,要通过一些手段。

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

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

总结

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

本文由巴黎人手机版发布于巴黎人-服务器,转载请注明出处:而当前敏捷开发的要求巴黎人澳门官网:,DevO

上一篇:系统可以逐步建立并完善、巴黎人手机版:达到 下一篇:了解您企业IT基础设施的性能无疑是一项相当艰巨
猜你喜欢
热门排行
精彩图文