【转】DevOps的前世今生

转自:http://www.infoq.com/cn/news/2016/09/learn-devops-from-reports

目前在国外,互联网巨头如Google、Facebook、Amazon、LinkedIn、Netflix、Airbnb,传统软件公司如Adobe、IBM、Microsoft、SAP等,亦或是网络业务非核心企业如苹果、沃尔玛、索尼影视娱乐、星巴克等都在采用DevOps或提供相关支持产品。那么DevOps究竟是怎样一回事?在Puppet、RightScale分别DevOps出版的调查报告基础上,整理本文,以期为读者理清思路。另外,中国正在开展了一份自己的调查问卷,由南京大学发起,欢迎大家投票参与

DevOps是什么?从哪里来?

DevOps的概念

DevOps一词的来自于Development和Operations的组合,突出重视软件开发人员和运维人员的沟通合作,通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。

DevOps概念早先升温于2009年的欧洲,因传统模式的运维之痛而生。

DevOps是为了填补开发端和运维端之间的信息鸿沟,改善团队之间的协作关系。不过需要澄清的一点是,从开发到运维,中间还有测试环节。DevOps其实包含了三个部分:开发、测试和运维。

换句话说,DevOps希望做到的是软件产品交付过程中IT工具链的打通,使得各个团队减少时间损耗,更加高效地协同工作。专家们总结出了下面这个DevOps能力图,良好的闭环可以大大增加整体的产出。

历史变革

由上所述,相信大家对DevOps有了一定的了解。但是除了触及工具链之外,作为文化和技术的方法论,DevOps还需要公司在组织文化上的变革。回顾软件行业的研发模式,可以发现大致有三个阶段:瀑布式开发、敏捷开发、DevOps。

DevOps早在九年前就有人提出来,但是,为什么这两年才开始受到越来越多的企业重视和实践呢?因为DevOps的发展是独木不成林的,现在有越来越多的技术支撑。微服务架构理念、容器技术使得DevOps的实施变得更加容易,计算能力提升和云环境的发展使得快速开发的产品可以立刻获得更广泛的使用。

(注:上图摘自上月红帽副总裁Ashesh Badani的一次新闻分享会)

DevOps的几个关键问题

好处是什么?

DevOps的一个巨大好处就是可以高效交付,这也正好是它的初衷。Puppet和DevOps Research and Assessment (DORA) 主办了2016年DevOps调查报告,根据全球4600位各IT公司的技术工作者的提交数据统计,得出高效公司平均每年可以完成1460次部署。与低效组织相比,高效组织的部署频繁200倍,产品投入使用速度快2555倍,服务恢复速度快24倍。在工作内容的时间分配上,低效者要多花22%的时间用在为规划好或者重复工作上,而高效者却可以多花29%的时间用在新的工作上。所以这里的高效不仅仅指公司产出的效率提高,还指员工的工作质量得到提升。

DevOps另外一个好处就是会改善公司组织文化、提高员工的参与感。员工们变得更高效,也更有满足和成就感;调查显示高效员工的雇员净推荐值(eNPS:employee Net Promoter Score)更高,即对公司更加认同。

快速部署同时提高IT稳定性。这难道不矛盾吗?

快速的部署其实可以帮助更快地发现问题,产品被更快地交付到用户手中,团队可以更快地得到用户的反馈,从而进行更快地响应。而且,DevOps小步快跑的形式带来的变化是比较小的,出现问题的偏差每次都不会太大,修复起来也会相对容易一些。

因此,认为速度就意味着危险是一种偏见。此外,滞后软件服务的发布也并不一定会完全地避免问题,在竞争日益激烈的IT行业,这反而可能错失了软件的发布时机。

为什么DevOps会兴起?为什么会继续火下去?

条件成熟:技术配套发展

技术的发展使得DevOps有了更多的配合。早期时,大家虽然意识到了这个问题的,但是苦于当时没有完善丰富的技术工具,是一种“理想很丰满,但是现实很骨感”的情况。DevOps的实现可以基于新兴的容器技术;也可以在自动化运维工具Puppet、SaltStack、Ansible之后的延伸;还可以构建在传统的Cloud Foundry、OpenShift等PaaS厂商之上。

来自市场的外部需求:这世界变化太快

IT行业已经越来越与市场的经济发展紧密挂钩,专家们认为IT将会有支持中心变成利润驱动中心。事实上,这个变化已经开始了,这不仅体现在Google、苹果这些大企业中,而且也发生在传统行业中,比如出租车业务中的Uber、酒店连锁行业中的Airbnb、图书经销商Amazon等等。能否让公司的IT配套方案及时跟上市场需求的步伐,在今天显得至关重要。

DevOps 2016年度报告给出了一个运维成本的计算公式:
停机费用成本 = 部署频率 * 版本迭代失败概率 * 平均修复时间 * 断电的金钱损失

来自团队的内在动力:工程师也需要

对于工程师而言,他们也是DevOps的受益者。微软资深工程师Scott Hanselman说过“对于开发者而言,最有力的工具就是自动化工具”(The most powerful tool we have as developers is automation)。工具链的打通使得开发者们在交付软件时可以完成生产环境的构建、测试和运行;正如Amazon的VP兼CTO Werner Vogels那句让人印象深刻的话:“谁开发谁运行”。(You build it, you run it)

实现DevOps需要什么?

硬性要求:工具上的准备

上文提到了工具链的打通,那么工具自然就需要做好准备。现将工具类型及对应的不完全列举整理如下:

  • 代码管理(SCM):GitHub、GitLab、BitBucket、SubVersion、TFS
  • 构建工具:Ant、Gradle、maven
  • 自动部署:Capistrano、CodeDeploy
  • 持续集成(CI):Bamboo、Hudson、Jenkins
  • 配置管理:Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail
  • 容器:Docker、LXC、Rkt、第三方厂商如AWS
  • 编排:Kubernetes、Apache Mesos、DC/OS
  • 服务注册与发现:Zookeeper、etcd、Consul
  • 脚本语言:python、ruby、shell
  • 日志管理:ELK、Logentries
  • 系统监控:Datadog、Graphite、Icinga、Nagios
  • 性能监控:AppDynamics、New Relic、Splunk
  • 压力测试:JMeter、Blaze Meter、loader.io
  • 预警:PagerDuty、pingdom、厂商自带如AWS SNS
  • HTTP加速器:Varnish
  • 消息总线:ActiveMQ、SQS
  • 应用服务器:Tomcat、JBoss
  • Web服务器:Apache、Nginx、IIS
  • 数据库:MySQL、Oracle、PostgreSQL等关系型数据库;cassandra、mongoDB、redis等NoSQL数据库
  • 项目管理(PM):Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker

在工具的选择上,需要结合公司业务需求和技术团队情况而定。(注:更多关于工具的详细介绍可以参见此文:51 Best DevOps Tools for #DevOps Engineers

软性需求:文化和人

DevOps成功与否,公司组织是否利于协作是关键。开发人员和运维人员可以良好沟通互相学习,从而拥有高生产力。并且协作也存在于业务人员与开发人员之间。出席了2016年伦敦企业级DevOps峰会的ITV公司在2012年就开始落地DevOps,其通用平台主管Clark在接受了InfoQ的采访,在谈及成功时表示,业务人员非常清楚他们希望在最小化可行产品中实现什么,工程师们就按需交付,不做多余工作。这样,工程师们使用通用的平台(即打通的工具链)得到更好的一致性和更高的质量。此外,DevOps对工程师个人的要求也提高了,很多专家也认为招募到优秀的人才也是一个挑战。

DevOps的采用现状

哪些公司在用?

DevOps正在增长,尤其是在大企业中:调查发现,DevOps的接受度有了显著提高。74%的受访者已经接受了DevOps,而去年这一比例为66%。目前,在81%的大企业开始接受DevOps,中小企业的接受度仅为70%。

那么具体而言都有些公司在采用DevOps呢?Adobe、Amazon、Apple、Airbnb、Ebay、Etsy、Facebook、LinkedIn、Netflix、NASA、Starbucks、Target(泛欧实时全额自动清算系统)、Walmart、Sony等等。

他们怎么实施的?

首先,大企业正在自下而上接受DevOps,其中业务单位或部门(31%)以及项目和团队(29%)已经实施DevOps。不过,只有21%的大企业在整个公司范围内采用了DevOps。
其次,在工具层面上,DevOps工具的用量大幅激增。Chef和Puppet依然是最常用的DevOps工具,使用率均为32%。Docker是年增长率最快的工具,用量增长一倍以上。Ansible的用量也有显著增加,使用率从10%翻倍至20%。

并且调查还发现不到半数(43%)的公司在使用诸如Chef、Puppet、Ansible或Salt等配置工具;然而使用配置工具的公司更有可能同时使用多个工具。25%的受访者使用两种或更多配置工具,只使用一种工具的比例为18%。其中Chef和Puppet是最常用的组合:使用Chef的组织中有67%同时也使用Puppet,类似的,使用Puppet的组织中也有67%同时使用了Chef。

中国也在准备一份DevOps的报告

文中的统计数据来自于国外的DevOps调研报告。其中由Puppet发起的DevOps年度国际调查报告已经连续出版五年,先后收集了2.5万技术人员的答卷;2016年收集的有效答卷为4600份,不过仅有10%来自于亚洲。我们并不认为这样的采样率和采样数量可以充分地反映中国的DevOps行业现状。

目前,依托DevOps中国社区成员的积极参与支持,由南京大学发起开展《DevOps中国2016年度调查》活动。期望通过本次问卷调查,收集DevOps的率先实践者们关于DevOps实践及经验的相关信息,从而了解DevOps在中国推广应用的状况,并汇总在DevOps实践中可能遇到的障碍、挑战和最佳实践,最终通过调查报告进一步促进DevOps在中国的认知和推广,同时为DevOps的每一位实践者提供有价值的参考信息和帮助。

调查问卷的设计主要参考了国际上2014-2016年度的《State of DevOps Report》及《State of Agile Report》的调查问卷设计,以实现信息数据在国内和国际之间的可比性,并根据业内专家意见经过多轮修改。目前问卷中英文版已上线,点此可进行中文版调查。本次问卷调查为学术公益性质,所形成的年度调查报告将免费公开。

期待大家能填写调查问卷,支持中国DevOps的发展!

时间: 2024-11-11 06:37:10

【转】DevOps的前世今生的相关文章

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

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

分布式技术一周技术动态 2016-09-18

searcher 分布式纵向方向主要涵盖的范围包括分布式系统理论和设计实践, 资源管理和虚拟化技术, 大规模服务稳定性技术, DevOps和自动运维技术等方面, “分布式方向一周技术动态"是我每周总结和整理的关于分布式方向的精选技术文章, 希望以此让大家能够跟踪业界相关的技术动态, 培养大家对分布式系统的兴趣, 学习分布式系统理论和设计思路, 辅助大家的日常工作. 每周的技术动态会在hi群和邮件组里同步发布, 欢迎大家阅读. 对于后续 分布式技术动态 有任何意见或者建议, 大家可以随时联系我.

基于Jenkins,docker实现自动化部署(持续交付)

前言 随着业务的增长,需求也开始增多,每个需求的大小,开发周期,发布时间都不一致.基于微服务的系统架构,功能的叠加,对应的服务的数量也在增加,大小功能的快速迭代,更加要求部署的快速化,智能化.因此,传统的人工部署已经心有余而力不足.持续集成,持续部署,持续交互对于微服务开发来说,是提高团队整体效率不可或缺的一环.合理的使用CI,CD能够极大的提高了生产效率,也提高了产品的交互质量.本文不对三个概念做过多的介绍,有兴趣可以读读这篇文章:The Product Managers' Guide to

DevOps is dirty work - What's the deal

什么是DevOps?终于又回到这个最初的问题. 第一次看到这个词的时候,还身陷于各种敏捷概念轰炸中.用“身陷”这个词其实并不准确,因为那个年代的我也是那些热情洋溢地无处不宣传敏捷的热血文艺青年中的一员.就像天生的一样,我从未接触或真正实践过瀑布模型.瀑布开发对我来说一直是书里的概念,各种流程背得滚瓜烂熟都是应付考试用的东西.打从第一脚踏入老东家N记,Scrum Master骄傲地带着我各楼层领略五颜六色的进度小纸条和大小各异的手写燃尽图的那一刻开始,我就被敏捷浸淫而无法自拔.N记也不愧为国内敏捷

DevOps - Development And Operations

简介: 研发运维一体化 相关资料: 关于DevOps你必须知道的11件事 我眼中的DevOps DevOps 门户 docker for dotnet系列 docker4dotnet #1 前世今生 & 世界你好 docker4dotnet #2 容器化主机 docker4dotnet #3 在macOS上使用Visual Studio Code和Docker开发asp.net core和mysql应用 docker4dotnet #4 使用Azure云存储构建高速 Docker registr

docker4dotnet #1 – 前世今生 & 世界你好

作为一名.NET Developer,这几年看着docker的流行实在是有些眼馋.可惜的是,Docker是基于Linux环境的,眼瞧着那些 java, python, node.js, go 甚至连php程序员都可以docker了,自己还在苦哈哈的装虚拟机,实在是急啊!所以对于.NET Core的发展格外关注,因为它的跨平台,意味着.NET Developer也可以docker了. 前世今生 .NET core 1.0并不是对原有的.net平台的升级,而是一次全新的重写,这个开发过程微软也史无前

为 DevOps 提供专业级、全栈式性能监控服务

相信大家都清楚,深谙 DevOps 的公司做起事情来更加高效.相较于竞争对手而言,他们的代码重用率更高,错误率更低.但是,成功取决于多种因素,其中就包括:是否能够准确监控应用在不同环境下(可能是多语言环境)的所有变化.所以,运维团队还需要一个支持连续开发与测试的软件分析方案,同时加强与其他部门的协作.沟通. 国内应用性能管理领军企业 OneAPM 提供的数据既能检测和监控开发团队提交的新性能,也能确保运维的稳定性.作为一家 DevOps 为导向的公司,OneAPM 完全理解软件团队所面临的诸多挑

Git前世今生-版本控制软件的发展

版本控制软件发展至今已有40多年的历史. 最早的版本控制软件是1972年由Marc J. Rochkind开发的SCCS (Source Code Control System),通过将不同版本下的文件单独保存的形式完成,将同一版本的所有文件打包保存.SCCS使用了长达10年的时间,直到1982年RCS的问世. 1982年,Walter F.Tichy 发布了RCS (Revision Control System),提供了较SCCS更多的功能,并作为GNU项目的一部分. 1986年创建的CVS

NetScaler SDWAN 的前世今生

                                                   论 NetScaler SDWAN 的前世今生 首先知道Citrix 思杰公司的人都知道Citrix 的网络产品线 有两款产品 ADC 应用交付平台产品-NetScaler 另外还有一款广域网优化的产品 这个名字可就变化频繁了 – 从WANScaler – Repeater – CloudBridge 到NetScaler SDWAN 平台产品.有很多人也许会产生一些困惑,是不是思杰公司有一个"