DevOps转型的柳暗花明：开发运维一体化PaaS平台建设

本文根据陈能技老师在〖2016 Gdevops全球敏捷运维峰会广州站〗现场演讲内容整理而成。

 

（点击底部“阅读原文”获取陈能技演讲完整PPT） 

 

讲师介绍

陈能技，DBAplus社群原创专家，新炬网络首席DevOps专家。14年开发测试与质量架构经验，擅长DevOps及APM、Docker、持续集成、持续交付在企业中的落地实施。著有《软件性能测试诊断分析与优化》、《软件自动化测试成功之道》、《深入浅出性能测试与LoadRunner实战》等书。

 

大家好，我是来自新炬网络的陈能技，很高兴能跟大家分享我对DevOps的一些思考和经验。最近几年我接触的很多传统企业，像移动运营商、航空、政府企业、电网等跟我们所说的全球化、国际化的DevOps之间还是有一定差距的。所以，今天也很高兴看到不少企业的同仁来到现场，一起探讨DevOps，探讨传统企业的转型，分享一些传统企业如何跟上主流研发模式和运维模式的建议。

 

本次演讲将包括以下几部分：

1. 什么是DevOps

2. DevOps能力融合四大核心实践

3. 开发运维一体化PaaS平台建设四要素

 

一、什么是DevOps

 

分享之前，先看几个数字。

 

 

这些是来自亚马逊Apollo平台的数据。过去一年中亚马逊推送了5000万个部署，每分钟达到95到100个。平均的部署时间是11.6秒，速度非常快，但光快也不行，还要快、准、狠，我们看到最后一项，部署失败停机率仅为0.001%，这些才是开发运维应该达到的一种高度。

 

当然有些企业可能会说，我们的速度不需要很快，但我觉得这是一个标杆。近日我看到一个Oracle的新闻，讲到Oracle目前在往云大量的落地。在我看来，Oracle的云相比亚马逊的云在IaaS这一层可能有它的一些优势，但如果从前端应用的部署、交付应用的效率上来说，也未必能达到刚才提及的那些高度。

 

因此，要怎样才能达到这样一个目标呢？这是我们今天要谈论的问题。

 

我们在不断地寻找一些方法、手段，以及工具和技术来尝试达到这个高度，以求快速地交付应用、快速地部署。早些年为了让开发跟上业务需求变更的速度，新炬网络当时找到了敏捷开发，这让传统的采用瀑布模式的企业通过敏捷转型，在应对需求变更上达到了一定的效果，但仍然不够，所以我们还在不断地寻找。

 

 

从上面这张图，可以看到近几年DevOps正处于技术发展曲线的顶峰，也就是说2015这一年，大家喊得非常多，都说要做DevOps、要做转型，但这是否又是一个概念的炒作呢？从历史的发展来看，云计算、大数据刚出现时，大家也认为是在炒作。确实，IT领域有一个毛病，就是每隔三五年就会更换一批概念或名词，然后各家的厂商也纷纷说我们在做这一块的东西，传统的工具厂商像做软件测试工具的、做开发工具的会说我们有DevOps平台，传统的做一些运维服务的也会说我们在搞DevOps，各家都有各家的一些说辞和想法，那究竟什么是DevOps呢？

 

 

我们认为DevOps不是一个简单的概念，要充分理解DevOps，得从开发、运维碰到的诸多问题出发去想。先前敏捷开发的出现，实际是弥补了业务需求频繁变更与开发、测试之间交付的差距。现在如果一个企业做的研发还是传统的那种瀑布模式的，都不好意思拿出来说了，他们都会说我们在做敏捷的转型，或者说已经有部分实现了敏捷开发的模式。但敏捷不能完全解决开发运维一体化的问题，这时离你快速地、无差错地交付应用还有很长的一段距离，所以DevOps的应运而生，正是用来弥补这第二个差距。

 

 

因此，DevOps不是单纯的敏捷开发和提高效率，也不是单纯把生产模式引进来。DevOps发展到了今天，有它的一些基础，像早先不断在发展的与敏捷相关的实践中的持续集成、持续交付，以及持续交付当中涉及到的自动部署，当然还有一些较新的基础，像Docker。这些基础在不断地完善之后，DevOps自然而然就出来了。我们认为，现在的DevOps会去整合已有的敏捷开发、持续交付、ITIL等东西，这当中也囊括了精益的管理思想。

 

下面谈谈我自己对DevOps的理解。

 

 

我认为DevOps存在着一些本质性的东西，把DevOps拆开来看，Dev是开发这一层的，而Ops是运维方面的，如果开发运维要走向一体化，首先这意味着原先传统的开发运维不是一体化的，是割离的。因为开发这边会有自己的一些诉求，同等的，运维这边也会有自己的需求。打个比喻就是，在足球场上踢足球，开发像是带球的前锋，不断地进球，不断地运动，不断地改变，它强调对业务需求频繁的响应。而运维，更像是正好一个球过来，挡住它不让它射，不让它上线，最好一年都不要有变更，这是运维固有的一些思维。反观现在，随着业务变更的速度越来越快，如果IT的能力跟不上，就会被竞争对手拉下一大截距离。因此就需要强迫我们的开发跟运维做到一体化，紧密地去做协调、协作，这样才能提高效率。以上是我个人对DevOps的理解。

 

二、DevOps能力融合4大核心实践

 

 

新炬网络通过这几年的实践经验发现，做DevOps的转型，很关键的一点就是能力的融合，对此我们提出了一个DevOps能力矩阵模型。它涉及到了三个角色，分别是开发、QA、运维，这三个角色加上管理的视角，比如说我要去度量，强调我的过程是可控的，同时也会运用到一些工具和手段。

 

 

从这两个维度出发，我们就会发现有些不同的能力出来了，这些能力按照传统的模式是一定要割离的。举个测试的例子，做一个单独的测试，像性能测试，传统的话会交给QA。QA测试完了交给运维时，发现开发的环境、运维的环境是不一样的，尤其资源是不一样的，就导致了QA做完的一些测试结果、性能的指标，到了运维这边不适用、不认可。

 

那要如何解决这些问题？必须做一些能力的融合。有没有一些工具或技术是两者能够去共享的，比如说环境是否能够达到一致，诊断分析性能的工具能不能通用，开发、测试这边用的一些术语运维这边能不能听懂，运维监控以及运维收集到的一些数据能不能及时反馈给开发这一层，这些能力都需要融合。并且，在这个融合当中，我们不断强调这个能力要能传递和共享，比如说我们从提出需求到开发、测试、部署、上线一直到运维，这些能力如何在这些流程中不断地流转、价值传递，减少浪费，提高效率，这就涉及到了精益管理的思想。

 

 

经过这两年的一些初步的摸索和实践，同时也借鉴了国外一些先进的理念，新炬网络提出了DevOps能力融合4大核心实践。

 

这4大实践总的分为两大块，一块是从开发往运维这一侧能力的传递，包括将开发延伸至生产中，这讲的是持续集成和交付、自动化部署。也包括将开发嵌入到IT的运维中，比如像APM这类工具，能让我们把一些性能诊断分析如业务流程代码和SQL的执行效率诊断、瓶颈分析等能力传递给运维，实现业务调用链的性能监控，快速定位瓶颈所在。

 

另一块是从运维到开发这一侧，也有两大实践，第一个是向开发中加入生产反馈，而且这个反馈应该是可视化的，要精准一些数据，像监控、运维的数据，而不像传统的方式，当运维暴露了一些故障，开发去要这些数据还要走什么流程，好像这些运维数据是什么秘密，从而降低开发排故的诊断分析难度，节省排故时间。第二个是将IT运维嵌入到开发中，例如在开发阶段就嵌入规范化的日志输出、存储的标准做法，运维过程中要看这些日志数据能不能及时地反馈给开发，并通过日志分析定位开发的代码问题，开发这边能不能嵌入一些日志的输出在生产环境做一些调试诊断。

 

 

 

 

这些实践都是企业在日常运维中可以选取的，你可以选取我现在的主要能力是建立持续集成体系，或者加快自动部署的能力。如果你认为性能对于企业的应用来讲是最关键的，那就把一些性能的数据在开发过程诊断出来，或者在运维过程中去收集和发现，同时还要实施实时的监控和日志的收集。

 

通过这种能力的融合，我们发现基本上都能够取到你想要的数据。开发能够通过一些日志分析和诊断程序缺陷，运维可以快速地去定位故障，降低故障恢复时间，提升SLA。而运营也能够综合地对业务日志进行分析及挖掘，有效实现产品及企业的运营，实现商业价值。安全人员可以通过对海量安全日志的分析，过滤出安全事件，查找隐患。

 

 

我们新炬网络提出的基于DevOps能力的矩阵模型认为，开发、QA、运维三者能力的融合是最为关键的。开发到运维的管理过程的交叉融合是基础，但要把DevOps真正的落地实施，工具化、平台化的东西也必不可少。有些传统企业其实已经有在用一些工具，像一些配置管理、项目管理、性能测试的工具，但往往都是零散的、没有去整合过的工具。没有整合就意味着你的能力是没有办法去传递。每个部门都有自己的一套工具和平台，但关键是这些数据能不能共享出来。

 

 

要建立一个DevOps平台，最终你要实现的肯定是一个可视化的、数据共享的，然后是自动化的，很多流程不需要人工干预，可以自动流转。比如一个应用包从代码编译到构建出来部署到一个环境中，经过自动的测试，再部署到准发布环境，这应该是一个自动的流程。最后，它还应该是一个智能化的，即能够很快地定位出整个生产的环节，包括代码交付到运维这整个环节，哪些地方是存在浪费的。

 

三、开发运维一体化PaaS平台建设4要素

 

下面按照一般的实践，简要地看一下建立这样一个有持续交付能力的PaaS平台，具体要完成哪些事情。首先，我觉得第一个要考虑的一定是工具的整合，因为人很多时候能力的实现需要依赖工具，开发的能力需要开发的工具，测试的能力需要测试的工具，同样，运维如果缺少了工具，就没法干活了。

 

 

这个图是国外的一个厂商仿照元素周期表制作的一张DevOps周期表，非常庞大。在这样一张表中，有各种各样的工具，比如一些源代码配置管理、持续集成、测试的工具，也有数据库、CI、日志、安全、监控、云服务等工具，一共分为15个大类120个工具。面对纷繁众多的工具，建立一个适合自身企业开发运维一体化平台时，工具的融合变成了首要考虑的前提。况且现在很多的传统企业，本身已经有一堆的工具了，这时是把它全部替换掉，改用一些开源的，或者是重新买些商业的或是基于它再做些整合，所有这些都需要考虑到。

 

 

第二点，要考虑到三大核心基础架构设计。第一个是配置管理的架构设计，这里包括两个方面，一个是源代码配置管理，一个是环境配置管理。第二个是自动化架构的设计，包括从开始的代码编译一直到能够部署环境这个流程如何让它实现自动化，这里通常会借鉴持续集成的做法。接着，整个制度的流程做好了之后，结合你的环境配置管理，就可以生成一个MOF。MOF算是一个通用的标准，对不同的平台来讲，云平台、做自动部署的平台或者Docker，它都是以一些标准的描述好的方式做好。以上三点是做PaaS平台时必须考虑的。

 

 

另外，除了工具，做一个平台的建设，还需要考虑流程规范化的问题。按照我目前所接触到的大多数传统企业，其实他们的配置管理、测试、环境的部署、数据的管理等大部分都还是在比较初级的状态。所以，首先我们自己要找准本身处于哪个位置，我该整合哪些工具，整合哪些能力，往高一点级别的能力又该如何去发展。

 

 

最后还有一个大家尤其是传统企业或多或少会忽略的问题。回想一下，传统企业相比互联网企业，是否在DevOps转型以及早先的敏捷开发转型中碰到了更多问题？这其中的原因很大程度是因为传统企业往往有N多个部门，这些部门之间又是割离的，因为没有部门会搅乱自己的利益关系或利益诉求。在这种情况下，缺乏了一些通用的平台能够跨越部门的流转。

 

这里有个所谓的康威定律，也就是说你最终的产品架构好坏，是由你的组织架构的沟通模式决定的，不能是割离的，否则无论产品也好，事情也好，都很难高效率地完成。所以，DevOps平台的建设里面，还必须考虑的一点，就是团队组织架构。拿角色来说，有些角色可以是沿用之前的，有些则可能需要做一些适当的转型。再比如传统的测试，应该更敏捷一点，应该更加往自动化的方向去发展。

 

 

 

当然了，不同的企业应该有不同的组织架构，诸如小型的企业，扁平化的组织可能会更加适用。而大型的组织架构，矩阵型结构会较为合适，得有业务条线、开发运维以及多种不同服务的能力。

 

当你有了人，有了团队，流程能够自动地流转，也借鉴了一些新的技术、工具，那是否就搞定DevOps的问题了呢？还不一定。

 

 

这个图是刚刚讲到的关于DevOps转型必须考虑的几个维度，总结一下：

 

• 从人的角度来看。必须考虑清楚开发、QA和运维这三个角色的能力融合，以及在一个平台上做沟通协作的事情。

• 从流程的角度来看。流程很多，在转型时要先考虑比较容易实现、关键的流程，比如持续集成、自动化测试、技术架构（像代码的质量管控）这些关键而易行的流程，不要一上来就说我要做单元测试。

• 从技术的角度来看。很多传统企业都是比较怕接触一些新的技术和工具，像Docker出来的时候，这是个什么东西，我要不要去用，都很犹豫。有时候甚至连要不要去尝试都没有去想。

• 最后从文化的角度来看。关于DevOps，每个人都有自己的看法，好比盲人摸象一样，各家都各有成言定论，但要往DevOps成功转型，文化是一定要建起来的。所以我们在一些企业推行这件事情时，也会去组建DevOps的推行小组，就像先前我们做敏捷开发的时候，会有敏捷教练这些的诞生。当DevOps发展到一定的阶段，也一定会有这些东西。

本文来自云栖社区合作伙伴"DBAplus"，原文发布时间：2016-10-14