DevOps与传统的融合落地实践及案例分享 - 又拍云
彭鲤航 ,优维科技创始人兼COO,拥有十余年IT运维从业履历，曾先后在腾讯负责带队管理及维护Qzone/QQ秀/会员/相册/QQ音乐等国内大型社交平台，农牧场、乐斗、水浒等大型SNS页游平台，以及QTALK等大型及时在线类语音互动平台。
2017 年 8 月 26 日，又拍云第 35 期的 Open Talk 活动 “ 精益运维与 DevOps 最佳实践 ”落地广州，优维科技 COO 彭鲤航作了《 DevOps与传统的融合落地实践及案例分享 》，以下是分享实录：今天的演讲主要分为以下三个部分：第一个是DevOps全局的理解以及DevOps与ITIL的对比融合，第二个是DevOps落地经验14则，第三个是案例的分析。DevOps全局的理解其实讲DevOps特别的多，官方里面给了一个框架图，从计划需求、设计、开发、部署、运营、宗旨，持续交付到IT运营管理、经营管理，后来扩展了一下，大家看到这个全景图的时候的确有概念的认知，我觉得不够。做了以下几点改动：第一：& IT运营管理以前叫IT服务管理，因为IT服务管理带来很多ITIL的认知，今天看IT运营范畴变得很多了。面向IT运营管理的实践，ITIL延伸出来的IT服务管理只是其中一部分，还有运营管理、性能管理、监控管理、分析管理等等。第二：& 扩展上层的实践和工具部分同时给出一个从理念—工程与方法—过程—实践—工具的转换路径图。这样让我们更能清晰的看到DevOps的整体框架和落地实践及工具的关系。今天看DevOps整体框架，其实也是一连串工程实践组合，包括敏捷工程、持续交付和IT运营管理及其精益实践等等。在过去IT组织中，或多或少都有敏捷管理和IT运营管理的实践，但IT的效率依然不高，为什么？今天似乎在持续交付中可以找到答案——IT如何成为业务的核心竞争力。DevOps与ITIL的对比融合DevOps跟ITIL对比，其实两个不属于同一个范畴，DevOps是属于IT全局的，ITIL是属于运维这块的，IT服务管理的，其实聚焦的领域不一样，但是还是有必要做一个对比。因为我觉得在运维的行业，我觉得还是要把这两个理念做一个清晰的划分，比如说今天讲的以DevOps整个理念做平台，到底以ITIL做这个平台有什么样的不同。这里面是做一个对比。&首先ITIL是面向管理的过程，以这个目标规范优先，DevOps是面向IT运营过程，是执行的能力跟自动化，ITIL 是离线任务管理为主要特征，而DevOps是以在线服务的。可以看这里面有关键的作用力，我自己的理解把云计算、上层的框架模式拆分出来之后你会发现越接近上层应用，其实ITIL 对它的作用力越来越小。比如说之前大梁给我的数据，他的部门两个星期发布9000次，这个不可能针对每一次的发布建立强流程，这样流程太多带来成本非常高，达不到那种的效率。我们在底下可以看到，在底层基础设施这块的，硬件基础能力还没有达到软件定义这种SDX化，它的作用力依然存在的，但是未来随着软件定义化的能力越来越强，这波浪潮也会改变。NetDevOps的兴起就是一个极好的例子。DevOps自动化与ITIL规范之间的融合DevOps可以看到在线服务管理里面，可以兼顾质量效率和成本规划，上图就是DevOps自动化与ITIL怎么融合，极力避免形成OA流程在IT部门的应用。这是按照优维的实践，在传统的行业做交付的过程中我们的产品怎么跟ITIL流程思想对接得出来的模式：第一种模式：申请ITIL流程的时候可以直接调动DevOps的工具典型的特征，比如说第一种在线服务开通流程，我要把我的防火墙开通了，这时候申请一个表单，审核通过了立马调用DevOps的工具执行。但以前是离线的IT服务目录，我提一个表单、需求单，这个需求单审核通过同意之后，方案管理人员再跑去设备去开通，今天不一样，让流程变成立即可以执行的模式。今天举例：资源申请流程，在CMDB整个资源申请里，这是国信证券的典型案例，比如说以前资源申请，我从库房拿一个设备，这个设备拿出来我要分配网络重组，以前是各个角色分配完了填写回复，今天不是这样的，把这个流程在线化，所有的资源通过CMDB资源层拿出来直接在表单里执行。第二种模式：重大变更的流程这个流程在华南很大的银行总结出来的案例，我们把所有的变更流程、审批流程做完之后，立马启动执行流，对于高稳定性服务保障流程非常的重要。比如说对于银行基础设施的网络等等非常重要的，这里有一个问题，这个流程我在审批的时候是A方案，到审核之后方案有可能会被人为改变，怎么办？这种情形有改进的措施，我们把DevOps调度流作为审批流方案一部分，审批通过了这个流程可以去进行执行，这个保证了流程审批完了以后和在线的流程是一致的。第三种模式：敏捷发布的流程，或者是DevOps变更的流程因为今天很多的流程不再依赖ITIL 完成的，比如说敏捷的发布流程JIRA管理，这是一个新的研发管理工具，不可能再回到ITIL 提一个发布单，这里面我总结的是红绿灯机制。当我进入到某一个环节，比如说测试环节不符合的时候，我看到基于什么样的状态？如果通过了就开始的执行。今天讲的DevOps，还可以从另一个维度看，叫软件研发的模式去看。我们经历了几种模式的变化，第一种是waterfall 的模式，比如说研发、测试、运维间彼此是割裂的，独立的，中间有一个墙存在的，这里面有严格的输入输出在进行传递。往下面走就是敏捷研发的模式，这里面讲的TDD的测试研发，在每一次的版本可以做很多的小迭代，比如说今天我们做easyops平台，我们规定两个星期出一个小版本，这两个星期出一个小版本的时候，内部还经历一个小迭代，内部很多的小迭代做这个事情。但是这里面依然有问题，研发跟测试是一体化的，测试驱动研发，这块运维、operation 还是被隔离在外了，但是随着新的业务形态出现后，比如说互联网的模式出现了之后，要强调端到端能力的整合。DevOps 软件研发模式就出现了，在和客户交流的时候，不断的触发思考一个点，实施了敏捷和IT服务管理，为什么IT依然看成成本中心而不是业务的核心竞争力，为什么还是对业务需求响应很慢？在前面讲的持续交付就是来解决这个问题的。可以看在几种研发模式中，比如说这个Develop以前测试的时候占的70%，详细的设计占比重越来越大，但是到小迭代、小设计的时候Design工作变得越来越小，研发居多了，再往下看测试的工作量变得越来越少，变成自动化的工具。这是我们总结的数据，可以看到随着研发模式的变化，各个角色在里面承担了工作量的配比也在发生变化，研发越来越重要，很多工作也前置到研发阶段。DevOps落地经验十四则第一则：理念与价值先行第一、二点这里面一定不是简单谈文化的，一定谈工程实践落地的因素。第三点：端到端持续服务交付流程的改革这里面不是讲的结果而是讲的过程，process不是过去讲的IT服务流程，把过程的变革，一旦工具进来简化我的流程或者是自动化的流程都带来变革。第四点：对新的应用和服务，加快且缩短实现价值交付的时间。这里面讲的怎么样有一个想法，快速实现这个想法，把这个想法反馈回来，让我持续的改进，不影响安全性和持续性，这一点我觉得蛮有意思的，比如说在国内讲双态运维的理念，双态运维根源上有双态IT形态的存在，但是运维的本身没有所谓的双态的差别，你使用的方法论、工具自动化套路都是一致的，因为我管理的IT都是从本质上干几件事情，把命令传过去、文件传过去、数据采集回来，就干这三件事情，本质上这个流程该形成有效的设计，兼容安全和性能的要素。第二则：顶层设计、全局规划。这个是之前给一个物流行业做咨询的时候提出来一个模型，DevOps运维的体系分成6个维度＋一个文化，这里面包括组织、过程、架构、工具、基础设施、度量＋文化。第一点：组织DevOps首先必须打破组织之间的隔阂，其实DevOps团队建立面向产品而非项目的协作文化。第二点：过程过程不是流程，轻量级流程和自动化的工具完美结合，确保企业的高度敏捷性、自动化为先、而后再流程。第三点：架构架构是应用的架构、基础的架构和数据的架构，数据的架构谈起来虚一点，应用的架构和基础的架构是比较明确的，应用的架构更多讲微服务的架构，基础架构是标准化的基础设施，像Saas、paas平台。第四点：工具强调的平台层面上，怎么样把IT能力平台化，从DevOps整个过程构建持续交付的平台，到运营构建IT运营管理的平台，都是很重要的，只有它们能够把所有的质量成本和效率几者维度兼顾起来，具备可落地化。&回到顶层设计和平台层面来说，IT运营管理平台到底应该怎么样的设计？这里面讲到的云数据平台和iaas平台。在上面面向不同的IT管理过程，我做一些域设计的细分，比如说ITIL，分成基础、高级的、运维服务平台、研发的服务平台。第五点：基础设施对应的IaaS、PaaS部分，怎么样做持续反馈？监控，端到端的监控，从底层的基础设施，到上层的应用服务组建，从基础设施到接口、用户测量的监控这个端到端的能力怎么构建？这个构建成数据采集的基础。&第六点：度量今天看监控是面向数据化的思维做监控，今天数据的特征发生了变化，不仅仅是结构化还有非结构化的数据。比如说日志，怎么样把日志当成流式数据的处理？有了这样的数据采集基础，这里面有分析的平台，结合运维的场景，容量、可用性、业务连续性等等进行分析，结合IT的规模形态发生变化，所要看到的指标也会不一样，比如说基于云端要看成本和费用分析都不一样的，需求也不一样的。&IT服务中心是把整个IT服务能力怎么样的目录化，同时结合自动化的工具两者衔接起来。这个讲的变更中心，有一个梳理的方法，现在的传统企业，比如说国信证券，结合CMDB管理的对象，把这个管理的对象整理出来，通过IT服务中心给变更能力目录化，同时表达标准化，最后对接工具自动化。再往上可以提供各种的服务编排的能力，这种服务编排是跨越了各种工具的，再往上是构建运维的统一模库。这是顶层设计和全局规划。第三则：Start Small，从小做起。DevOps这么大的体系，大平台上又有这么多，是不是全都要落地？一定要Start Small，这个准则很好梳理，基于每个角色＋某个场景从小做起，一定要把IT部门的角色梳理出来，比如说到运维这边，有业务运维、系统管理员，网络运营。第二可以基于每个系统和每个功能实施导入，比如说今天就做监控库，我看传统的企业很多做CMDB导入，切忌贪大求全，给你画的图景是很美好的，很多人说DevOps很好，怎么样落地呢？一定要Start Small。第四则：构建元数据基础平台CMDB下一个阶段要把它名字改为IT资源管理平台，因为我觉得现在需要把CMDB的管理资源和职责范围缩小，其实在不同的阶段，我们管理也不能贪大求全，把所有的配置全部管理起来，最后发现自己转不动了。上面的场景又起不来，现在很难把场景构建起来，场景起不来的时候，结果把CMDB做死了，我们一直讲这个数据的鲜活性，结果做不起来。今天我把范围缩小了，只管基础设施的资源和应用的资源，基础设施是属于目前应用的，这个资产状况管理起来我从应用的角度看，到底用了哪些资源？把这两层的维度强关联起来，然后在应用上层构建应用的各种的管理场景，比如说应用的发布、应用的部署、应用的监控等等。应用的数据分析，由它来进行进一步的驱动CMDB的流转，因为在应用的维度上，才符合以前讲的高频的特征。今天到任何一个组织，其变更的场景来说，应用是最频繁的，比顶层基础设施更频繁。如果符合高频的特征可以理解场景化的能力最强的，场景化的能力强那驱动力就是最强的，今天把CMDB转化成IT资源管理，以应用的视角看资源。这个平台里它的核心作用是毋庸置疑的，应用是CMDB平台的元数据。&这里面怎么样的上层联动？CMDB这么多的数据，其实就是一类的实例的数据。比如说这里面到底有多少服务器、服务器有多少的虚拟机？这是实例的数据，然后就是拓扑的数据。我的服务摆在机柜上，介入的上面数据是什么。同样是根据顶层的资源拆出来的，一个基础资源一个是应用的资源，分成实例管理和拓扑管理。今天很多人讲自动化，其实资源有生命周期的状态，一定不能通过自动化来替代的。比如说这个IP地址从资源池里面分配出来给业务池使用，一定要通过一个流程申请出来，无论是自动化的还是以前离线流程的，这是一个生命周期的状态，IT地址退还不能保留业务使用，这个一定要有流程控制的，这里面自动化不能代替人工的流程，流程是聚焦在事前的管理。&再往上是场景应用，要找各种的场景应用，构建出来这一层做的形象的比喻就相当于今天的地图一样的，比如说百度地图，这个地图可以在不同的场景用，大众点评可以用，滴滴也可以用，今天的CMDB也起到这样的作用。这么多场景建设的时候，事件平台是一个很好的入口。因为今天看到传统的行业太多的监控系统，这个监控系统都要进行收敛，怎么收敛？把所有的监控实践发到统一事件系统，由统一事件系统根据底层的IT对象关系自己来进行收敛，现在老的监控系统基于CMDB收敛是很难的，基本上找不到监控厂商来修改，提一个需求要带来大量的成本。&为什么一直在讲CMDB核心的管理模型是应用的管理模型，IT形态发生变化了，这个模型不用改变的，不用调整的，比如说是公有云。CMDB模型的扩展力是把所有的资源管理起来，这个资源分成本地资源和第三方的资源，本地资源是应用部署在同一主机上的资源，比如说程序包、操作系统的版本，使用的内存，或者是这里面的配置的版本等等，甚至在本机占用了端口甚至是接口服务都是我们的资源。第三方资源如阿里云，这些资源都可以通过应用管理维度集中起来。第五则：痛苦的事情优先解决基于角色和产品如何梳理管理能力？运维的复杂度为什么复杂？在这儿，因为运维角色太多了，管理的对象太多了，产品太多了，最终出来的能力管理流程也可以太多。开发测试没有如此复杂，开发就开发，测试就测试。这里面一定要通过角色＋场景，最后导出我应该构建什么样的能力管理的平台出来，一定要有这样的思路。今天讲的运维自动化，最后我变成配置管理或者是工具的自动化或者是调度的自动化，这个远远不够，其实运维自动化弥漫在每一个角色、每一个场景里，今天说的基于容量的自动扩容不算自动化吗？CMDB的自动发现不算自动化？基于监控事件故障自愈不算自动化吗？都算。基于这个图把自动化的场景收敛一样，作业和调度的能力是底层平台化的能力，在各个子系统使用。第六则：工具也是一种文化这里面讲的作业管理和调度的管理应该是平台级的能力，不需要进行场景化的理解。在自动化的构成要素里有一个原子化的事务，同时有调度编排原子化的事务，有两个要素有够了。再往上是面向角色的场景化收敛和归类，工具可以把我们的能力拼装起来，在各个场景下使用。工具是真正推动变革的有效手段，好的经验一定是通过自动化的手段沉淀管理过程。
已阅读 1094 次
本期其它主题
云分发服务
(C) 2017 杭州又拍云科技有限公司DevOps Master国际权威专业认证培训
面对企业快速变化的业务需求以及飞速发展的IT技术，您的IT系统和服务是不是也在面临这些新的挑战：
?&&IT服务不能支持和满足业务部门在业务变化方面的需求？
?&业务应用系统新功能总是延迟交付?
?&IT变更不能成功实施，并且常常因为错误变更而导致业务系统失效?
?&&开发团队与运维团队的沟通协作亟待改进？
?&开发与部署及运维工作严重脱节？
?&新上线的业务系统与服务故障频繁，难以支持管理？
在这种情况下，DevOps 脱颖而出，受到越来越多的关注！
什么是DevOps？它是英文单词Development和Operations的组合。但DevOps并不局限于开发和运维之间的协作，而是一条贯穿了IT价值链每一个环节的工作流。
DevOps&的目标是帮助IT部门将开发、测试以及部署、运维更有效地整合在一起。
DevOps可以使产品发布的时间大大缩短，客户满意度大幅度增加，产品质量获得本质提升，部署发布更趋稳定，生产效率明显提高，从而确保企业获得更好的业务结果。
DevOps涉及到人员、流程和技术等各个环节，是一种文化的转变，在企业中实践与应用并不简单，需要专业人士点拨。
| 课程费用
优惠价：12800元/人[含认证费]
| 课程时间
2月一轮，北上广深循环开班，全国均可安排定制培训
| 课程介绍
为满足各方需求，“塔塔IT”最新推出原厂专业认证课程——《DevOps Master 认证培训》。本课程旨在帮助企业更有效地理解与实践DevOps 的核心理念与内容。
DevOps Master&是该领域第一个国际权威的专业认证。本课程将全面融合讲师讲授、案例讨论与沙盘演练等多种培训手段。在帮助学员系统化理解DevOps的理念与管理框架的同时，通过全球风行的凤凰项目的沙盘演练，帮助学员切身体会如何在企业环境中构建DevOps文化，从而更好地与客户互动，最终交付令人满意的IT服务。
DevOps Master认证：知识产权归EXIN所有
凤凰项目沙盘及本文课程纲要部分2张示例图片：知识产权归Gamingworks所有
联系我们：&
深圳塔塔咨询服务有限公司 &TATAIT &&
公司地址：深圳市南山科技园南区高新南一道13号赋安科技大厦A座4楼401（高新园地铁站C出口、公交：大冲站、中科大厦站）邮编：518057&
Adress：Room 401,4th Floor,Building A,Fu An Technology Building,Southern District of Scientific Park,Nanshan District,shenzhen City
网址：http://www.tatait.com&
咨询电话：0
新浪微博：@塔塔IT
微信：添加公众账号“塔塔IT”加关注！塔塔IT为迈瑞思旗下子品牌，专注高端IT培训。DevOps年度报告：部署频率提高200倍，宕机成本降低100倍
我的图书馆
DevOps年度报告：部署频率提高200倍，宕机成本降低100倍
此文由Kai@fit2cloud编译，未经许可，严禁转载。目录：一、内容摘要二、调查参与者三、IT 表现和员工忠诚度四、将质量根植于产品之中五、生产管理精益化六、改变组织文化及员工认同感七、DevOps的投资回报八、结论编者著：考虑到本文太长，因此节选精华部分，翻译的全文请点击文末阅读原文链接。一、内容摘要DevOps发展情况第五年度报告重点阐述了以下事实：优秀的IT和团队表现是跨开发和运维的团队协作的结果，对IT和团队的投资可以带来丰厚的回报。本年度DevOps报告展示了如何通过改进整个产品生命周期（从产品规划到质量和安全保障，再到客户反馈）来加速产品的交付，同时优化产品的质量、安全和业务成果。DevOps实践也可以改进组织文化，增强员工的参与感。在过去的五年里，我们调查了来自世界各地的25000多个专业技术人员。通过调查，我们更好地理解DevOps带来的技术实践、文化规范和精益管理是如何影响IT和团队表现的。去年我们调查了DevOps的几个维度，包括精益管理实践、应用架构、IT经理在DevOps转变中的角色、多样性、部署难题、工作倦怠等。最后我们证实，技术实践只是IT性能提升所有因素中的一小部分。为了创造持续的IT高性能表现，组织在对技术本身进行投资的同时，需要增加对人员和研发过程的投资。今年我们针对当前DevOps社区面临的最紧迫的问题进行了调查，这些问题包括：DevOps的投资回报率（ROI）DevOps实践的作用及价值如何将安全与DevOps进行整合员工投入和组织成功之间的关系关键发现1、高效组织的生产能力明显超越他们的低效同行。高效组织比低效者的部署频率高200倍，交付周期快2555倍。此外，高效组织的故障恢复时间比低效者快24倍，修改失败率低3倍，明显优于低效者。高效组织公布，他们从部署更改到生产的交付时间（例如，从代码提交到成功部署至生产环境）平均交付时间为60分钟，低效组织的平均交付时间为3.5个月，因此交付周期快2555倍。2、以员工净推荐值（eNPS）作为衡量标准，高效组织的员工具有更高的员工忠诚度。高效组织的员工更有可能向其朋友推荐本组织作为理想工作场所，其概率比低效组织高2.2倍。同时，高效组织的员工更有可能向其朋友推荐所在小组作为理想工作环境，其概率比低效组织高1.8倍。其他研究显示，员工忠诚度越高，业务产出越高。3、提高质量是每个人的工作。高效组织花在计划外工作和返工的时间比低效组织少22%，同时，高效组织能够比低效组织在新工作（新功能、代码）上多花29%的时间。他们之所以能够如此，是因为高效组织通过持续交付把质量融入到开发流程的每个阶段，而不是在开发结束时再对产品进行翻新。4、高效组织花在修复安全问题方面的时间比低效组织少50%。通过更好地将信息安全目标整合到日常工作中，团队可以实现更高层次的IT性能，并建立更安全的系统。5、改进产品研发流程可以提高您的IT和团队表现。产品开发周期在开发人员开始编码之前很久就开始了。产品团队需要的能力包括：分解产品和功能的能力。将从理念到产品的工作流程可视化的能力。收集用户反馈，持续迭代和改进的能力。根据团队能力的水平，可以预测其IT表现和部署难题。6、进行技术改造可以为任何组织产生相当大的成本节约。技术领导者都想知道投资技术改造后，可以获得什么样的回报。您可以使用本报告的关键指标和行业基准，并通过我们提供的准则来量化潜在的成本节约。潜在的成本节约可以使用您自己组织的指标来量化。节约的成本可以进行再投资，以提高IT和团队表现，本报告也对此提供了相应的建议。二、调查参与者今年我们调查了来自世界各地的超过4600名专业技术人员。与去年相比，从事DevOps相关工作的人数有所增加。但是令人失望的是，女性受访者的人数只有微小增加。我们在其他行业调查中也发现了相同的现象。我们仍然有很多工作要做来提高DevOps领域的多样性和包容性。点击可查看高清大图点击可查看高清大图点击可查看高清大图点击可查看高清大图三、IT表现和员工忠诚度我们发现高效组织中积极员工的比例明显高于低效组织。这是有道理的，因为只有忠诚度最高的员工才会把公司推荐给朋友，而只有高效组织才可以培养出忠诚的员工。历年IT表现：我们研究了过去三年有价值的数据，发现高效组织正在脱颖而出。DevOps带来的持续改进是实实在在，且令人兴奋的。DevOps正驱动公司向最好的方向发展，并把其他公司抛在身后。三年前的最高水平已经不能适应当前的商业环境。通过对DevOps投资回报率（ROI）的分析，我们发现宕机对公司有非常大的影响。客户、企业高管会深切体会到宕机的影响，在某些情况下，媒体对此也会很敏感。因此，宕机不仅会带来财政上的损失，也会造成声誉损失。四、将质量根植于产品之中DevOps的理念与组织融合越深，组织就越深刻的体会到：质量和安全是每个人的工作。我们想确定是否持续交付会改变产品质量的管控方式。更多内容请参见“阅读原文”链接。五、生产管理精益化精益化方法注重从产品的生命周期开始，通过频繁的用户研究来测试产品的设计和商业模式。我们发现当产品团队采用精益化方法来设计和交付产品时，组织的IT表现和文化都会有明显提升，其整体表现也会更好。经过统计分析，我们发现产品管理精益化可以提高IT表现，减少部署问题。有趣的是，前两个因素（将产品分解的能力、对产品开发和交付过程的理解）是共同起作用的。以上所述表明了一个观点：流程可视化和工作分解对产品生产至关重要。下图展示了以上因素产生的影响。点击可查看高清大图六、改变组织文化及员工认同感员工是组织最宝贵的资源，然而他们经常会被随意抛弃。当领导者对员工进行投资，使他们尽最大努力工作的时候，员工会对组织产生更强烈的认同感，员工也会更加努力来帮助企业成功。员工对所在组织认同，也可以带来注重成果、绩效导向的企业文化，并且提升组织表现（例如生产效率、市场占有率、利润）。七、DevOps的投资回报技术领导者都想知道投资技术改造后，是否可以获得良好的投资回报。通过使用一些关键指标和行业基准，我们对DevOps实践给组织带来的潜在成本节约进行了计算。根据计算结果，我们将组织分为高效组织、中等组织、低效组织。此外，我们还研究了怎样使用节约下来的时间和金钱进行再投资，才能给组织带来更大、更持久的价值。传统上，IT被看做成本中心，说服管理者对IT进行投资很难。直到最近，都没有有力的证据来说明，对IT的投资可以带来丰厚的回报。在过去的报告中，我们发现IT表现和组织整体表现有明显关联。从而证明了，IT可以带来真正的业务价值，提升组织的业务竞争力。今年，我们发现高效团队在计划外工作和返工上，花费的时间最少（21%）。因此，他们能够将49%的时间花在增加价值的新工作上。低效组织和中等组织的情况却恰好相反。低效组织比中等组织花在返工上的时间少（分别为27%和32%），花在新工作上的时间多（分比为38%和34%）。一种可能的解释是，低效组织会忽略产品中的严重缺陷，并不断推进新功能开发。但是缺陷的不断叠加，会使他们在以后付出惨重的代价。中等组织在返工上会比低效组织花费更多的时间，从而消除技术隐患，与此同时，中等组织也会有更高的修改失败率。但是，因为中等组织的部署频率高于低效组织，所以他们可以快速试错。过去，中等组织通过提高速度、优化投入产出来实现利益最大化。随着时间的推移，他们更有可能通过持续优化生产过程来实现利益最大化。这些有趣的发现强调了以下事实：每个组织都必须把钱花在刀刃上。我们再次强调，虽然低效组织的返工成本较低，但我们相信那是以掩耳盗铃为代价的。随着缺陷的不断叠加，他们以后会为此付出惨重的代价。点击可查看高清大图每年因宕机产生的成本（宕机成本）根据IDC的Steven Elliot的近期报告，对一家世界财富1000强企业来说，每小时宕机所产生的损失从12.5亿美元到22亿美元不等。关键程序故障所造成的损失平均为每小时50万美元到100万美元不等。当然，宕机所造成的损失随着业务的不同而不同。比如说，高容量的金融交易机构因宕机造成的损失，肯定比为写字楼管理清洁工的公司造成的损失大。另外，IT架构的不同，会导致宕机造成的影响和恢复的难度越会不同。从而导致宕机所造成的损失也不同。在今天的商业环境中，稍微复杂的业务都高度依赖软件和计算机网络，宕机会对严重威胁业务的健康。鉴于此，每个组织都应该根据自身的业务模型和架构，衡量宕机可能给自身造成的损失。本报告中，我们会提供给您计算宕机成本的方法。同时，我们也使用业内数据，对高效组织、中等组织和低效组织的宕机成本进行了计算。宕机成本 = 部署频率 *修改失败率 * 故障恢复平均时间 * 停产每小时造成的损失。部署频率。我们对此次调查的数据进行了平均。高效组织可以根据需求进行部署，Etsy每天部署80次，Amazon和Netflix每天部署数千次。我们更加保守的估计了高效组织的部署频率：每天4次，每年1460次。中等组织的部署频率从每年12次到每年52次不等，平均下来，中等组织每年部署32次。低效组织的部署频率从每年2次到每年12次不等，平均下来，低效组织每年部署7次。您可以根据您公司自身的部署频率进行计算。修改失败率。修改失败率是指导致停产的修改数量占总修改数量的比例。根据本次调查的数据显示：高效组织的平均修改失败率为7.5%（从0到15%）中等组织的平均修改失败率为38%（从31%到45%）低效组织的平均修改失败率为23.5%（从16%到30%）您可以根据您公司自身的修改失败率进行计算。平均故障恢复时间（MTTR）。根据今年的调查数据，高效组织的故障恢复时间小于一小时，中等组织和低效组织的故障恢复时间都小于一天。中等组织和低效组织故障恢复时间的中值是相同的，但其平均值不同。低效组织故障恢复时间的平均值明显高于中等组织。为了进行示例计算，我们采用了比较保守的数字：高效组织的MTTR为1小时中等组织和低效组织的MTTR为24小时您可以根据您公司自身的MTTR进行计算。停产损失。因为DevOps在一些组织的软件开发和核心程序交付中已经开始使用，为了避免误差，我们采用IDC较早前公布的数据。据保守估计，核心程序每小时的停产损失为500000美元。您可以根据您公司自身的每小时停产损失进行计算。点击可查看高清大图虽然低效组织的宕机成本较低，但是他们却为部署不频繁付出了隐藏的代价。一个公司如果不能高频次的发布产品，那么它就失去了不断获取用户反馈的机会。企业可以根据用户反馈不断进行实验，持续改进产品，从而提高客户满意度。这可以让企业领先竞争者，紧随市场变化进行创新，最终使企业鹤立鸡群。我们推测高效组织所获得的收入和利润，远远超出他们的宕机成本。对于部署频率较低的公司，虽然总体部署成本较低，但是单次部署成本很高。除了用美元进行衡量，我们可以其他角度进行分析。部署不频繁的必然结果是，每次部署都会将又大又复杂的代码包部署到生成环境中，导致集成和维护困难。而且，当故障发生时，很难定位。部署不频繁还会带来其他的负面影响。因为部署不频繁，每次部署都会将又大又复杂的代码包部署到生成环境中，此时会导致大量问题产生。工程师和运维人员必须匆忙的去修复这些问题，这时每个人埋头工作去找出问题所在和解决办法。这个过程无疑是令人沮丧的，其中必然充满抱怨。这些痛苦的部署场景是反面教材，不会教给团队正确的做事情的方法。勇于探索、不断学习、持续改进的良性循环不会再这个环境下出现。组织想要提升业务产出更是难上加难。DevOps带来的价值我们必须指出，对IT进行投资不能仅考虑成本节约。成本节约可以带来短期积极影响，但是大家对第二年节约的成本却习以为常。你必须能够说明节约下来的员工时间用来进行其他提高产量、增加价值的活动。重新利用节约下来的员工时间、创造力和激情，会取得丰富的业务产出。最好的组织深谙此道，他们在计算投资回报率（ROI）时，会考虑技术改造的价值。技术改造所带来的未来价值不能被低估。无论是将节约下来的时间用于开发新的产品和功能，还是改进生成过程，未来都会取得良好的收益。八、结论DevOps不再只是一个时尚用语，它已经成为一系列可以被理解的具体实践和文化模式。转向DevOps的人们不仅仅可以改善日常工作，给家人、朋友、同伴更多的时间，同时DevOps可以提升组织表现，增加收入、提高利润和其他可衡量的产出。五年前，我们就开始进行DevOps调查，并发布DevOps发展情况报告。我们已经明白了DevOps工具、实践和文化价值是怎样影响IT团队和组织的。今年，我们对DevOps进行了更广泛的数据收集，更深入的分析。我们希望通过今年的报告，能够使您更好的理解DevOps给您的组织带来的影响。
喜欢该文的人也喜欢