DevOps 助力企业互联网 + 转型落地

主持人：很多企业一直探索如何互联网化，如何上云，接下来的老师是来自北京睿至大数据解决方案总监叫郑伟，给我们带来DevOps是如何助力企业互联网+的转型落地。

郑伟：我来自睿至，睿至主要是做我们大数据相关解决方案的一家公司，同时也会有自己的自有产品。我主要负责云跟DevOps相关的产品线。

今天跟各位讲的是基于我们睿至的客户实践，在传统企业的一些业务转型，跟DevOps相关的一些场景与各位做一些分享。

今天主要从三个维度与各位做整体分享：

• 第一个是我们对于DevOps的理解，它整体的诉求是什么。
• 第二个我们定位是传统企业DevOps的能力落地规划。
• 第三个是我们的一个实践场景。

相对于刚才雷老师讲的比较细节测试的内容，我讲的会偏宏观一点，有问题可以后续交流。

首先是我们需要一个什么样的DevOps？我们对于传统企业DevOps定位是什么？

其实我们从定位来讲，通过调研发现，现在DevOps应用实践在我们传统企业的实践分布来看，最主要的一个问题可能不是从技术上来看，我们发现从技术上的困难或实现的难度来讲，远远达不到当时的预期，更多的是从组织和人员上、流程上的困难。

所以，我们客户来聊的时候，一般会有这样的问题，DevOps到底能解决我们什么样的问题？我们为什么要基于互联网的最佳实践来提升我们业务发布的水平，还有我们在现有的平台下、体系架构下，如何能快速地实现我们的眼界，这也是我们跟客户沟通的时候碰到的很多问题。

我们去解释这些问题，通常会从我们的现状去看，其实我们传统企业的业务发布模式是有多样性的，不像互联网，因为它的业务特性是快速变现、快速试错，快速交付，我们对于它的理解跟传统企业有一些差别，传统企业可能更多的是保证我的业务连续性、稳定性，所以我觉得是有本质区别。

从我们业务交付或者软件发布的模式上也可以看出一二，第一是我们从软件发布的模式，通常会有几种，传统企业会在一二是大多数的模式，在座的各位都是类似这种模式。

• 第一个是我们基于固定版本的排期，这个熟悉IPD的都了解，因为我在华为做过很多年的IPD，类似于这种固定版本排期的开发模式，它能保证我们版本的稳定，而且每年可能一到两个版本比较稳定。而且，它是按照我们传统业务来讲，对于前端、后端整个协调能力也是比较优秀。

它带来的问题就是对于需求的反馈比较滞后，可能我们一个版本没有赶上需求，就只能到下一个火车把需求补上，这对于前端的反馈来讲是不够的。

• 第二个会基于我们固定的版本或者产品的单一模式来讲会有一些优化，会有项目的模式。它的特点就是多个产品在不同的项目交付里都有体现。这样好处就是我可以发多个产品版本在不同项目里实现我们需求的变化，但是同时带来的问题就会有多套生产环境的发布，造成了我们对于生产环境版本的压力，这也是造成的一个额外问题。
• 第三个是我们现在谈的最多的敏捷开发模式，我们当然希望我们所有的业务场景都是第三种，基于我们DevOps最佳实践就水到渠成的。

但是恰恰是第三种开发模式是一个相对有限，或者相对封闭的一个场景。就拿金融来讲，一些红包类的创新场景才会有这样的可以应用的场景，它的特点就是相对独立，跟其他的业务系统关系不大，而且它可以做相对独立的开发测试发布，就容易实现我们刚才雷老师讲的自动化实现方式。

所以，我们从软件发布的模式可以看到，传统企业跟我们互联网的企业还是从业务诉求上是有所不同，这是从我们的理解来看。

第二是我们从组织架构来看，本身我觉得大部分传统企业都是这样的竖井结构按照职能来划。

其实有一些创新的业务场景已经按这种产品的团队或者职能产品团队来做切分，这种切分的好处就是能够实现这种直接面向业务端到端，所以从企业组织的架构来讲，这也是有它的一个差异变化。

从刚才的这些分析，从我们业务发布的模式，从我们组织的架构，我们可以看到当今我们传统企业软件发布面临的主要挑战是什么。我大概做了一个总结，第一点就是传统企业也有快速业务发布的诉求，这是一定的。

因为现在整个市场的竞争对于前端需求的把握，快速去把握前端需求的一个变化，其实已经是这种不论是互联网还是传统企业一个核心的竞争力。

所以，这部分我们快速交付的业务需求跟我们已经设置好传统的这些开发测试的流程上的矛盾，我们已经固化了从开发到测试这样的标准流程，如何能适配现阶段的快速迭代的需求，这是第一点。

第二个就是我们对于稳定性的要求，因为现在企业内部大部分有大量的手工操作的存在，有些企业上了自动化工具，也只是在一些固化的一些非核心的应用场景去实现的。一些核心的变更、配置变更等等，它还是依赖于我们手工的操作。所以，手工操作与企业对于质量的一致性、稳定性要求的矛盾，所以这是第二点。

第三点是刚才雷总讲的，我们对于风控跟我们已经做好这种简单化、快捷化标准流程之间的矛盾，风控要求你尽量合规，满足我的各种监管要求，监管要求的满足就会有一定的流程去适配它，我们现在如果是做一些流程化的精简，或者是一些变更，势必会有冲击的产生。所以，我们觉得从整个的过程来讲，每个环节都会有我们去碰到的一些问题。我就提到一点，我们现在传统企业对于DevOps的核心诉求是什么？现在讲创新其实不是我们最终的目标，我们的目标是什么？是业务的发展，业务的稳定，这是我们的核心。

现阶段的业务现状是什么？不可能一步到位，我们也希望容器化为服务，希望尽可能少的人工干预。

所以，现在更多讲的是一个融合的过程，就是怎么样在你现有的基础架构的平台之下，实现你技术的平滑过度，整个的技术融合。

所以，这里面从几个维度来看，第一个是技术上我们其实是利用好你现有的工具平台，我们不是说我要重新再给你搭一套流水线平台，包括睿至的解决方案也是一样的，我们是基于你现有的平台基础上，帮你设计你的开发流水线整体的步骤。所以，我们是一个整合的过程。但是它一定是一个端到端的打通，不能说只到开发测试，或者是运维的一部分。

第二是我们架构上融合效益稳定的精益管理。我们更多大部分业务要求都是我的稳定性，或者是保持我们业务的连续性，还有一些互联网化的特性，就是能快速地去试错，快速地做创新的尝试。所以，我觉得这两个是我们从架构上是一个慢慢并存，最后逐渐融合演化的过程，这是从架构上来看。

流程上来讲，既然我们有一些监管的要求，我们有人员的现有组织架构的一些现状，其实我们就要在你不断优化人员架构基础之上做我们标准化业务发布的一个落地。

所以，从几个维度来看，核心我觉得就是融合，其实讲的就是一个平衡的过程，我们讲效率、稳定、标准三个维度的平衡，目标就是业务的稳定，业务的快速上线，就是我们这样的整体诉求。

第二个我们会接下来聊基于我们刚才融合的诉求，我们刚才讲的整个现状来讲，我们再去看我们整个能力落地的规划。

其实我们讲规划之前先把整个端到端的过程，业务交付也好，软件发布也好端到端的流程做整体的梳理。其实本身从产品到开发测试到运维，这是一个标准的过程，我觉得这个大家都比较了解，从产品的设计层面，包括一些需求、评审，有一些优先级的这些很多都是有管理流程合规性的要求。

对于我们产品来说有产品进度的把握、产品进度的跟踪是我们关注的一些点，到开发层面就会有排期，整个的评审，然后具体到开发测试的工作，然后到一些测试等等相关的工作，这里边有一些关键点，我们的一些规范，我们做一线开发任务的前提，或者先决条件是要做规范化的制定，所以说我们特别把开发规范的落地也拿出来。

我们在做DevOps项目的时候，一般都会推荐用户先做一次开发测试的一个咨询梳理，这个服务是基于你以后的这种产品化、工具化的平台落地，是一个基础。所以，这个层面我觉得是不可少的。

然后涉及到我们自动化工具的引入，我们会有一些平台工具、自动化工具的接入，构建我们整个的一致性保障，从开发测试的流程来看。

到运维侧的更多的就是环境跟配置项目的一些准备，这也是运维侧比较重的任务，这里面就会有图形化的部署、自动化部署层面的东西。

所以说，最后会有一个监控分析，后面实践的时候会讲，从你的产品开发到运维它其实应该是一个闭环，最后再会有一些基于你运维侧，分析侧的产出物再给到我们产品侧做整个产品优化过程，所以这是我们整个端到端的融合分析。

我们分析的目的是找出我们的关键点做关键的设计。

我们需求目标主要的目的还是对于上层的业务交付，中间的是我们实现核心能力，环境管理、版本管理等等，最终是我们的平台落地，就是我们平台能力管理其实就是流程，最终是我们底层的产品。

我们总结起来就是三个维度。

第一个是可视，这一定是端到端的可视，对于业务发布场景，CI和CD全过程的可视化管理，基于我们现有工具场景，就是我们现在的一些测试化的工具，自动化测试的工具，我们一些代码管理的工具等等，其实更多的我们去体现的是一个更益于我们前端业务人员、开发人员运维人员去使用的平台化的工具，这是我们的定位。

第二是自动化，自动化的前提是要有统一的资源管理，这是要有一个共识，如果你要实现我们整个全站的自动化，统一资源管理是一定的，统一资源管理就需要在你的资源层，包括你云跟非云资源的打通你不同资源层面的关联，所以这里边就会有资源管理的诉求。

还有我们尽可能少，刚才雷总讲了我们一定会有人工干预的场景，我们希望我们把固化的一些流程走下来之后，这些流程里边的自动化场景我们都能使用它，而不是再有一些额外的干预。

智能化，我们从代码的开发到后续的产品交付，其实每个过程我们都可以用监控的手段实现，所以我们现在更多的一些实现场景是在你的运维侧，我们很容易实现一些监控的场景，而且基本上用户都会有这样的场景。

我们希望从你的产品代码设计阶段就会考虑我们的一些监控层面的一些东西，这也是后边要讲的端到端的分析，这是我们讲的目标分析。

然后是我们的平台架构，其实我们核心的东西就是流水线的工具平台，就是基于我们现有的应用工具平台场景做的设计，这个平台对上是我们有针对不同环境场景的管理门户，管理门户之上是我们对接不同的、现有的流程，现有的一些体系、项目管理、流程管理、发布管理等等，这些其实有一些是我们标准化的东西，我们可以直接对接它。所以说从上来讲，它是对接的一个动作，对中来讲是整合现有的，刚才已经一再强调了，而不是我们要做一套这样的东西，没有一个用户的场景，除非是一个初创企业，没有一个用户场景是推倒以前的工具平台我重新做一套的，这是不现实的。

对下就是我们刚才讲的采集、分析、调度、管理，现有的资源体系，所以这是我们的一个核心的理念，就是对于上中下的适配。基础层其实就是我们刚才讲的统一资源管理平台，这个平台为什么叫基础层？它既能实现我们的自动化调度，自动化的管理操作，还能实现我们对于底层的基础数据的一个监控采集，所以这是我们做整个的一些反馈分析的一个基础层面的平台。

然后基于我们的平台能力，我们的架构规划，我们看一下整个的典型实践场景。因为我要展开来讲，产品的层面就比较细、比较多，所以我就把整个东西大概用三四页幻灯片做了归纳，看看有没有大家需要的场景，或者哪些是我们现阶段在运维也好、开发测试阶段也好，我们比较迫切的一个需求场景。

大概分为几个维度，因为本身DevOps是一个融合的过程，我们其实就是开发到运维的融合和运维再反馈给开发的过程。

开发到运维理解的从我们开发延伸到生产中的一个过程，就是我们流水线打通的过程，我们提到的持续集成交付。

第二个开发嵌入到运维中，我们讲的监控或者是应用分析一般都是从运维侧来入手，运维侧有一个问题，有时候在我们技术架构层面很难去找到问题，反馈给应用端也说它整个产品和代码层面也没有问题。其实我们更希望于我们在开发层面，或者说在我代码的每个层级之间能看到整个的应用端到端的监控管理，而不是只在运维侧的基本诉求，这是从开发到运维的角度来理解。

反过来从运维到开发，就是我们可以在开发中加入一些生产反馈，就是有一些针对开发人员有益的一些监控，或者可视化的监控视图，比如说一些自动化的测试场景，能够帮助它去做一些判定。所以，我觉得这不只是在运维侧有这样的定位。

还有我们会有一些运维侧的一些运维分析的反馈再反馈给我们的产品和运维开发，这是我们一直提，但是很少有去实践的内容。因为我觉得这应该是一个联动的过程，就是我们要有一些运维侧的大数据分析也好，我们的预测也好，给我们开发人员做平台的东西。

所以，这是我们从几个场景来看，针对每个场景我们展开来做细化的分析。

第一个是我们持续集成的体系建立，其实我们已经讲了很多了，基本上DevOps每个主题都会有这些内容，更多的是从开发测试到整个运维端到端流程的管控。具体到睿至来讲，包括你的开发工具平台，我们都会帮你预制，包括统一代码管理，你的统一开发测试环境的准备，这都属于在我们开发测试构建的环节。

到生产，到运维之后就会有部署、版本管理、自动化部署的能力，所以这就是很传统的一个流水线平台。

我们最终要实现的还要有一个优化的过程，所以这种监控，其实今天我觉得我们大会也是以AIOps作为一个主题，其实DevOps是它的一个子选项，或者说是一个包含的过程。我们希望整个过程是一个AIOps的过程，所以这个监控跟反馈也是一个核心的内容。

这是我们刚才讲的端到端，讲持续集成的流水线过程。这里面实施的过程也会有一些建议，从我们睿至的角度来看有一些建议，刚才有一个咨询的过程，针对我们用户侧现状的咨询，你开始测试运维的基本情况，基于你基本情况做流水线的设计，然后制定我们基本的一些流程，然后我们的一些自动化，包括一些测试，一些部署。这个过程其实还是在我们开发测试阶段会多一点。运维是基于我们的部署之后会有应用体系的一些监控，然后再反馈给我们做一些运维大数据的分析，所以整个的过程来讲，我觉得是一个端到端的过程。

这张图讲的就是我们一直在讲的CI和CD全过程，流水线的过程。这部分恰恰就是我们DevOps里面最容易实现的内容，可能有一些同行不太同意，恰恰是最容易实现的。

因为你其实只是利用了客户现网的实际一些情况，而不是你去做一些你对于用户现网的一些创新或者变革，这是有本质区别的。

第二个我觉得是透明化应用交易过程，这对于开发人员的要求会更高一点，我们实现交易过程的追踪和记录，我们其实实现的过程还是基于我们整个的监控体系，但是这样的好处不是在我们测试，或者说不是在我们运维侧去实现这样的内容，而是在我们测试或者开发侧预制的能力。所以本身的相关数据过程需要我们在代码级做设计，我们从面向2B的业务发布场景，我们也倾向于跟客户一起来做这样的尝试，有这样的一些方法。当然，我们监控的手段也会去适配它，更多的是在我们整个端到端过程有这样一个基于应用侧的能力而不是纯运维侧。

场景3是所谓的立体化监控，我们一般都是讲运维侧的东西，我们其实监控体系是给我们整个业务线来用的，其实我一直强调我们业务的人也可以用监控，开始测试运维都可以用监控，其实我们现在更多的是把它定位于一个领域，就是运维侧。

所以，这里边我们希望在我们整个的立体化监控体系里，以应用为维度，展现不同的应用视角，可能是我们应用的一个加高层面端到端的视图，或者是应用层的连接数的分析、反馈时间的分析等等，它应该是一个针对我们开发测试运维一体化的一个监控平台。

所以，这里边我们讲的一个是我们运维侧要在生产环境，保证我们生产的稳定运行。第二，我们测试人员也需要这样的平台去保证我们测试性能的合规。所以，我觉得这是一个融合的过程。

第四点是我们整合现有的运维数据，实现我们运维大数据的分析。这块现在也比较火，相关做运维大数据的也比较多，我们也是希望于在整个的数据层面，我们尽可能地提供完整的运维分析场景。

还有我们针对于整个不同的人员会有不同的运维数据的一些导入。

比如说对于运维人员更多的是我想定位关键的问题，或者是核心根源问题的分析。开发人员刚才已经讲了，应用程序的一些缺陷、代码质量。

可能对于安全人员更多的对于我们日志层面，对于一些系统日志来看有没有一些不合规的地方。

所以，针对不同的应用场景，我们希望于，借助于运维侧采集的数据，不管是我们的监控数据还是日志，实现我们统一的监控或者分析。

最后看我们讲的现状能力规划，一些典型的应用场景，再去看所谓的落地。我们到底需要怎么去实现典型应用场景，或者是我们的一些规划。

其实从我们刚才讲的，我们如果要实现完整的DevOps，它其实单靠技术是行不通的。我觉得现阶段从现有的组织体系架构来看，也没有必要形成完整的DevOps，因为我们不可能改变我们的体系，我们的运维体系，我们的开发流程，这个也很难。所以我们讲的是又回到刚刚的问题，是慢慢融合演进的过程。

第一个首先容易实现的技术改造，实现我们自动化，消除我们手工的干预，构建我们垂直交付的流水线，这是现阶段基本大部分用户都在尝试，或者有意向去尝试的内容。

第二个刚刚有朋友在问微服务容器化，我觉得这部分内容是慢慢的过程，首先要有业务场景支持它，第二个主流的核心架构要支持它的演进过程，这也不是我们现有的技术人员统一去把握的，我觉得还需要时间。

第三个需要整体流程组织的一些变化，所以我觉得这部分也是需要时间，需要我们至少有这样的消化过程。

所以，第一步一定是先在我们既有的平台架构上做好整合工作，基于实际情况做架构或者产品的优化，慢慢带动我们整个流程，我们人员架构的一些变革，我觉得这个不是一蹴而就的，是一个逐渐演进的过程。

谢谢大家。

===================================

提问环节

提问：我现在有一点监控和优化，因为会涉及到线上只有两个点，如果政策流量突然增加很多，我想在线扩五个点，怎么样通过DevOps去监控到流量已经爆了已经扩容到三个点？

郑伟：这里有一个误区，我们用容器化的目的就是想要实现它的伸缩性，实现它的快速响应能力，对于容器化的前期设计就是要保证我们有弹性的度，这个度我觉得是不应该我们人为干预的，而是应该在我们整个包括我们的容器化规划层面上去解决的。

也就是您刚刚提的问题，我们到底多少个点能支持我们的业务，应该是由它本身的调度平台，或者是KBS来实现这样的能力，而不是我们指定它，那样还达不到我们的目标。

提问：因为会设置内存和CPU，这时候业务过来了，开发就是要了解它能承担多大的流量。监控层面，因为监控是一个反馈，我们怎么通过监控的机制，能够适当让我们调整一些策略，比如说给我们去创建的时候给一个参考值，或者是给我们运维，或者给研发，或者给建议，这一点是个问题。

第二点就是灰度发布，线上线下第二次升级的时候，怎么样用一个文件去实现这个功能？

郑伟：我们现在容器监控其实也是有很多产品，这块具体到您刚才讲的怎么样通过我理解的应该是预先的一些监控、告警来实现我们后续别撑爆的场景。第一步做前期的规划很重要，你业务承载压力的规划应该是有的。

第二就是我们对于你整个内容器的监控我们也有，我们不推荐人工干预是因为我们基于有一个平台规划去做这个事情，但如果我们确实有一些基于我们实践确实有一些突发性的东西，我们需要手工调整它，我觉得这是没问题的。

第二个改变我们所谓的灰度发布，具体是用一个压缩文件来实现整个的多场景的灰度发布，这我们还没有实现，我们更多的还是不同的应用发布场景，还是有一套单独的来支援。

提问：你们是怎么实现测试或者UAT环境怎么去实现的呢？因为会有开发环境、测试环境。

郑伟：我指的是一套或者分套当然是一个业务场景是一套，这是肯定的，而不是多个业务场景共用一套。我们一个业务系统，刚才您讲的，如果没有一个文件支持，它不可能做到端到端流水线的操作，但是我们因为有一些场景是多业务场景的，这是我们把它分离开的，整个一个流水线还只对于一个产品线我们这样来做。

提问：我们公司有多个产品线，很多产品都各自有自己的DevOps流水线还有一套落地的方案，对于整个公司是否要去统一DevOps的方案，或者需要统一如何去做这些有什么建议吗？郑伟：传统企业这种情况还是很多见的，我们其实也不能叫它DevOps流水线，因为人家还没有DevOps流水线的概念，就是有不同的发布流程。这个层面，我们建议你如果确实业务场景是相关联的，或者有一些相似度的，我们建议把它做一个规整和整合。 如果我们有一些是完全传统的体系跟一些新形态的敏捷的业务场景，我觉得这就没必要去做整合，我觉得这部分的内容，可能留待我应用架构上做一些调整，然后再做后续DevOps的工作。

提问：是不是理解为传统的非云产品以及新兴的云产品，对于云这部分的产品，我们可以做这样的尝试整合？

郑伟：就睿至来讲，我们既有传统的互联网化的DevOps完全一套的敏捷架构，其实也支持刚刚您讲的传统的，对于我们这种传统体系，我们如何来去基于你现有的需求，而不是做大的动作的解决方案，所以这两个应该是并存的。

提问：我们认为整个DevOps转型是一个融合，而不是整个推倒重来的创新。

所以，您说的端到端流程的对接和管控是很重要的。因为我们也面对这个问题，想问一下郑老师，对于在实践过程中，肯定会遇到一些技术上和组织上的问题，您那边是怎么解决的？或者对于我们这种体量比较大的传统企业做转型有什么方案和建议？

第二个问题是刚才您在第四个场景，大数据或者智能运维的场景，对于我们做运维分析反向去给开发都是有很重要的帮助，您那边是怎么落地实施，还有它的应用场景是怎么实现它的价值？

郑伟：第一个是转型的问题，您是哪家公司？

提问：四大行之一。

郑伟：我们是五大行做相关的咨询服务，包括一些产品化的东西，其实我觉得我们很多东西也都是金融客户交给我们的，金融场景是整个新技术的阵地，我觉得如果同金融角度来谈 DevOps 的话，我觉得一定是先从一些试点的场景来做，所谓的试点场景就是相对独立的，比如说以前在上海的客户是保险做的一些抢红包的业务，他在做这个业务场景的梳理，他们也希望先通过一个简单可控，影响范围较小的业务来尝试我们的流水线动作，这个尝试过程我们可以灵活一点。一旦固定下来之后，我们后续的一些可以做流程化转化的，我的前提是可以。

因为一些核心的东西永远做不了，可以做了之后，我们再去尝试做一些推广的动作，基本上我们在金融的场景一般都是这样的，用户先指定一些特定的业务场景，我们跟他一起来把这个场景做通做透，然后再去做其他的可以推广的一些场景，影响范围尽量控制，这是我们的一些经验。

第二个您讲的是我们运维大数据的应用场景，其实我觉得运维大数据都把它固化在运维侧，这个没问题，因为它本身就是我们运维侧发起的，我们做一些运维数据分析，做一些前瞻性的预测，这个没问题。

但是，我们希望睿至的角度希望于有一些测试场景，它也需要有一些很类似于运维侧的诉求，这些数据的来源，我们可以通过监控来统一做采集，我们肯定是希望用一套运维大数据的平台架构来实现我们既给运维侧，也给我们开发测试侧做支撑的分析。

所以，我觉得基本上像您这种体量的用户，或者部门规模稍微有一定体量的都可以有这样的诉求，因为它需要标准，而不是测试人员自己给的标准，我觉得应该是统一的标准，运维大数据的平台是一个最好的实践平台，所以我觉得是这样的定位。