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


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

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

三、DevOps的抓手在哪里?

【编辑推荐】

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

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

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

◆团队缺少基本的可落实部署规范(包括Artifact打包规范和部署流程规范)。规范是提高团队协作效率的重要一环。同时,这里的规范是必须要能够落实到部署流程并能够自动化实施。如果团队在此没有历史成功经验,建议直接采用已经广泛使用的现有规范(如AWS的CodeDeploy规范)加快落实。

【责任编辑:火凤凰 TEL:(010)68476606】

为帮助企业应对各种性能困扰,提升IT架构性能,Riverbed提供了最全面的平台,确保理想的应用性能,持续的数据可用性,并主动监测和解决性能问题。Riverbed助力混合型企业将应用性能转化为竞争优势,最大化员工生产率,借助IT创造新型运维灵活性。

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

◆稳定性指标:

在打通这个通道过程中,团队遇到的常见问题有以下几点:

◆产出指标:

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

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

讲师简介:徐桂林,当前在FIT2CLOUD负责公司的技术布道和生态合作。在此之前先后供职于意法半导体、Autodesk和阿里云。徐桂林热衷于云计算(尤其是公有云IaaS平台),有过多年云计算生产环境工作经历,是较早在国内分享云计算实践经验的作者之一。

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

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

2.关注团队部署效率并持续改进是深入提高团队交付和部署能力的法宝。在打通从代码到服务的通道后,团队整个交付能力会有一个质的提升。但是如果需要深入、持续地提升团队交付能力,还需要持续关注团队部署效率,找出影响团队进一步前行的潜在障碍,并有针对性改进。在这个方面,Puppet
Labs 2015
DevOps报告提出了一个定量的分析模型非常有帮助。具体来说,这个定量分析模型由如下几个关键指标组成:

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

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

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

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

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

Copyright @ 2015-2019 ca88 版权所有
网站地图xml地图