DevOps与传统的融合落地实践及案例分享

内容来源：2017 年 8 月 26 日，优维科技联合创始人&COO彭鲤航在“精益运维与DevOps最佳实践 | 优维科技&又拍云技术沙龙”进行《DevOps与传统的融合落地实践及案例分享》演讲分享。IT 大咖说（微信id：itdakashuo）做为独家视频合做方，经主办方和讲者审阅受权发布。

阅读字数：6084 | 16分钟阅读

嘉宾演讲视频及PPT回顾： t.cn/RBSNmhJ

摘要

在DevOps日趋成熟的今天，传统该如何借助DevOps的能力实现变革与创新？本次主题分享讲从具体案例出发，谈谈企业在落地DevOps中遇到的问题。以及DevOps落地的一些具体方法和技巧。

DevOps体系架构

DevOps的核心思想就是对之前的软件研发管理过程的进一步延伸，它整合了敏捷管理、持续交付、IT服务管理，关注的是整个业务/应用/服务生命周期的管理和it战略进行了对齐。

下图是企业实现DevOps的总结原则：

产品的生产过程包含有三类角色：研发、测试运维，之前这三类角色基本上各自对立，如今DevOps的出现让他们都被整合到了一块，共享面向客户的价值、共享集成目标、共享质量责任。从这一层面来看，其实DevOps存在不一样实践，分别是研发方面的实践、测试方面的实践、运维方面的实践，咱们本次主要聚焦在运维方面。

国内互联网运维的DevOps之路

咱们对腾讯的IT能力发展进行了总结，将其分为五个阶段：事务化管理，流程化管理、自动化管理、可视化管理、智能化管理。

事务化管理只须要完成基本的系统搭建，完成指定任务就够了。但随着团队规模的增大，仅仅是作完是不够的，还须要作好，这就须要引入流程化管理。再下一个阶段对效率上又有了要求，自动化的管理被引入进来。当设备达到10万台的时候，想要提升效率就不怎么简单了，这时可视化管理就变的很重要。最后就是智能化管理，经过用户大数据行为就能够支撑不少的运维管理的工做。能够发现业务的迅速发展使机器数量增加迅猛，同时对IT服务管理的要求不断提升。

运维能力建设的最佳实践

运维能力的提高核心实际上是实现自动化运维和数据化运维，而想要实现这两个能力须要经历三个阶段，分别是标准化阶段、服务化阶段、平台化阶段。

DevOps之标准化实现

在解决运维场景或者生产场景过程当中的问题的时候，实际上存在两个影响因素，一个是标准化能力，另外一个是自动化能力，他们被用来支撑整个运维管理。当标准化能力较强时，作自动化就会轻松些，反之亦然，他们是一个互相 支撑的关系。

运维环境的标准化是一个分层结构，在动手实践标准化的过程当中要考虑到网络层的标准化、设备层的标准化、系统资源层的标准化、应用层的标准化和业务层的标准化。

标准化体系建设的方法论

对不少企业来讲标准化可能只是意味着一份文档、一句管理口号或者下发的规章制度，若是推行标准化的方法是这些 ，那么失败基本上是注定的。

那么什么是真正的标准化？

第一标准化是一种团队理念，看的是团队在业务规划的时候是否有将业务环节作标准的理念。第二标准化是一个生产过程，咱们要判断标准化生产规定是否嵌入到了交付过程当中，若是在没有标准化的状况下业务就没法上线，那么标准化就不光是一句空话。第三标准化是变动工具，实际上每一个落地的变动工具在作的就是标准化，只要用工具执行结果就必定是标准的。最后标准化是CMDB。

在推动标椎化的过程当中，核心是打造CMDB能力、流程能力和自动化能力，CMDB用于承载和检验标椎化的结果、流程让标准化融入管理过程、自动化让标准化融入生产过程。

目前市面上的CMDB方案不少聚焦的是基础资源层面的管理，包括机房管理、设备管理以及硬件的管理等都被存储到CMDB中。而在这样的状况下数据的使用可能还不如Excel，由于它的数据更新是须要人工录入的，有可能会出现忘记写入形成数据不许的状况。

真正的CMDB关注的不只是如何管理信息，更关键的还在于让数据去支撑应用和业务管理，这才是CMDB系统的边界。从这个角度来看，在现今这样的云时代实际上基础资源已经不重要了，更须要关注的是应用层的信息，好比应用的构建、应用包含的信息、应用管理方法、应用维护流程等。这些应用层的信息又依赖于底层的资源，因此在定义CMDB中存储的数据的时候，咱们视野必定要从应用层往下走。

另外一方面在设计整个CMDB时要考虑到消费场景，要考虑到要存储的数据价值、数据的具体用途等。

轻量级别的New ITSM vs 传统的ITSM

从CMDB的维度上能够发现最终咱们仍是要管理不少的基础资源信息，要想高效的管理和维护这些信息，靠人工干预确定不行。解决这个问题的方案有两个，一是构建自动化的能力；二是依靠流程化，好比对于设备的采购会有采购单、入库单，设备变动的时候会有审批流程和审批单等等，全部的这些信息均可以流转到CMDB中，再也不须要花费时间维护。

所以咱们最终的目的是将CMDB和ITSM的能力进行整合。但传统的ITSM更多的是面向管理能力，它强调过程标准规范以及分阶段持续完善。所以如今咱们还须要ITSM与运营和持续改善的能力结合，向自动化运营扩展，它重视运营大于建设。

DevOps之服务化实现

服务化的核心是自动化能力。原来运维有不少的业务管理场景，大部分的状况下都是手工操做，进一步的也仅是自动化的脚本。如今咱们但愿将这些须要手工和脚本完成的任务转化成服务化的能力。

服务化的要求其实很简单，它有明确的服务输入定义、职责以及最终交付的标准。从这个角度来看，咱们所须要的是经过做业平台或者调度引擎的能力去有机的梳理原来运维的各类场景，把它变成服务工具或者服务平台。这些服务平台对外又有着明确的交互、接口和要求，它的好处在于对外隐藏了复杂的部分只须要经过接口进行交互延伸。

服务化体系建设的方法论

在创建自动化能力的时候咱们不少时候都会纠结于完美的方案，可是实际上并无完美的方案，只有可用和不可用的方案。只要这个方案可以知足一部分的需求那么就先用起来，而后再慢慢优化，这就是快速尝试。

第二是实现闭环，原先在作系统能力建设的时候咱们每每想要向更深更全上去发展，而其实如今所须要的是可以面向完整的应用场景，并经过关联服务的协同来实现能力闭环。

运维场景很复杂，须要分而治之，每一个服务要尽可能简单和独立，同时必定要提供服务接口。

DevOps之平台化实现

服务化完成后，每一个不一样的能力和服务化场景都经过服务化能力有效的实现了，至此还须要有一个平台将这些能力进行整合。

整合平台的时候核心的考虑点在两个维度，一是应用管理，二是生命周期管理。

一个应用的构成包含主程序、配置、运行环境描述、管理脚本、日志清理、容灾备份等，全部的这些相关的内容实际上都是应用管理中须要考虑的，在构建面向应用的管理时关注的就是这些内容。

应用的生命周期管理如上图的闭环，实际上考虑的是从产品的设计、开发、构建、测试、交付、发布到维护和监控的这样一个完整闭环能力。

交付能力

DevOps强调的就是快速交付能力，从运维的角度来看有两层含义，一是资源的交付，二是应用的交付。对于国外的公司来讲可能不在须要考虑资源的交付，由于他们的DevOps都构建在云上，而以国内如今的IT环境很难去实现这一点。

在资源交付方面，咱们如今有不少的平台，包括私有云、公有云、物理平台等。针对这些不一样的平台所要作的就是构建一个集中的资源管理平台，经过资源的快速生产、分配能力来加快设备生命周期的循环，经过快速循环来淘汰过期和非标准的资源类型，同时资源的快速交付也意味着更低的成本。

应用的持续交付是DevOps所涉及的部分，它从git或svn的源码库开始直接作快速的构建，而后生成UT测试、生成镜像、发布的测试环境测试、冒烟测试系统测试。目前构建这种能力业界用的比较多的是Jenkins持续集成平台，它能够帮咱们把前端的源码库对接和构建自动化能力衔接起来，可是在交付的运维层面上流水线的能力主要仍是依赖脚本管理。

上图是运营管理平台的总体架构，它的底层是各类硬件资源平台的整合，往上是CMDB，用来衔接资源层和服务能力层。再往上是各个不一样的能力域，里面的模块就是各个服务能力，每个服务化的模块都有一个接口，服务之间的协同经过统一的API网关实现，API网关会汇聚下方的各个服务能力提供的接口将服务进行整合对上层暴露，而后由服务编排系统将这些接口组织成不一样的逻辑场景，最后呈现给用户的是运维服务目录、研发者服务目录、我的任务中心以及业务的状态中心。

EASYOPS及企业实践

物流客户的EASYOPS建设方案

咱们曾服务过一家物流企业，他们有本身的监控系统、日志的分析平台也有一些工具，可是总体来看能力仍是比较弱。他们所遇到的最大的问题是发布成本很高，每一次发布都须要停机，时间大概是二、3个小时，最终在业务部署接入EasyOps后发布时时间被减小到10分钟。

项目建设的三个阶段

项目建设的三个阶段分别是标准化、服务化、平台化。原先的发布之因此须要2个小时，核心的问题在于程序的耦合性太强，而标准化中有一个很关键的应用程序解耦，它拆开了一些没必要要的模块，使得发布效率得以提升。服务化中应用程序的改造与标准化中的解耦有关，要想对非强制依赖的部分进行解耦，就须要向改造原先的程序。

挑战和机会

上图是这个过程当中遇到的挑战和机会。

这里简要说下挑战。一是没有标准化积累，不少东西都是乱的，好比不一样网段采用同样的IP，很难管理。二是内网环境管理严格，它内部分为生产网和办公网，咋看起来很安全，但有一个致命的问题——内部出故障时没法判断是网络仍是应用问题，同时因为内网审核时间很长，即便判断出问题所在也不能立刻变动。三是没有CMDB，所拥有的1000台以上的物理机都是经过excel维护，四是没有IT流程，基本上依靠的是邮件和电子流而且和IT维护脱节。

交付平台

咱们交付了两套环境，分别是测试环境和生产环境。测试环境主要用来作功能上线前的演示，每次的BUG修复或者新版本验证的时候都会事先在测试环境试运行。

集中仍是离散

在应用的快速交付过程当中之前不少公司的作法相似上图这样的流程。

某个程序发布以前都会在本地备份原先的程序，而后才将这个程序放进去。为了防止程序丢失在备份完成后，还要有一台专用的备份服务器存储备份。这种方案在集群足够大的状况下，可能没什么问题，可是在集群较小或者单机的状况下，一旦机器挂掉程序就可能丢失。这时候就须要在程序源码库中找寻原先的版本，为了保证必定能在源码库中获取到程序版本，不少公司都会在新版本发布到业务服务器后，再从服务器拷贝一份该版本到源码中。

上图是咱们采起的解决方案。

这里有一个制品库的概念，研发的源码有着版本管理，发布的制品也应该要有版本管理，而这个版本管理就被放在制品库中。所以在发布的时候就再也不须要在本地进行备份，由于制品库会集中管理每次交付的版本，要进行回滚的时候直接能够从制品库拿取须要的版本。

双制品仓库解决网路隔离问题

前面提到过不少企业会有研发网和生产网的隔离，为了解决制品库的发布被专线隔离的问题，就须要选择是搭建一套平台仍是两套平台。对此咱们的建议是搭建一套平台，由于若是搭建了两台平台，全部的CMDB的信息就是离散的，须要人工从新汇聚信息。另外一方面代码是从制品库拉出来传到服务器上，中间因为有着专线隔离存在带宽上的问题，若是研发网的制品库要链接生产网传输效率就很低，对此的应对方案是每次上传制品的时候进行数据同步。

设计配置项的管理和维护过程

为了使用CMDB的收集的大量信息，咱们设计了不少流程，好比网络设备上架，网络设备采购及下架、应用的上线及下线，这些流程会和整个流程平台结合。

上图是流程平台，在这里填写的有用信息会流转到CMDB中去，而自动化平台中所作的任何变动也会和流程平台进行交互，因此最后的信息都会落入到CMDB中。

测试

原先瀑布流的软件管理测试作的很是完整，可是现今互联网都在追求敏捷，使得不少有需求的测试都被省略。现今大多数公司单单只聚焦在功能性测试上，性能和可靠性测试会有一部分，安全性、可维护性、可运行性测试则彻底没有。

测试的过程通常都是这样的：单元测试、功能测试、预发布测试、生成灰度、生产全量。

整个过程当中咱们发现不少客户没有预发布测试环境，功能测试完后直接在生产环境中作灰度和全量。功能测试的交付制品中包含程序和配置，且在研发环境和生产环境中配置不一样，因此在没有预发布测试的状况下每每没法验证交付制品。

灰度

上图是个关于灰度测试的例子。A和B都是集群化部署，A功能依赖B功能，这时若是对A、B分别灰度，那么A就有可能会调度不一样的B。另外一方面升级的时候A能够灰度一台，B则须要所有升级，这种状况下灰度就没法进行下去。

针对以上问题的一种解决方案是蓝绿部署，经过蓝绿部署将A、B配置的设置彻底区分开，这时对其中一个集群作升级的时候，老的集群能够继续保留。这种方案的灰度只有一半，也就是按蓝绿的灰度。

更好的解决方案是调度网关，当B要升级的时候，有几个核心理念：一是B`须要兼容旧版本的A的请求，二是经过调度网关识别请求，而后调度到合适的目标中去。

从文件交付到程序包交付

之前的交付是将文件和脚本放到机器上，而后人工运行脚本对文件进行发布以及相关操做。这种方案存在一些问题，首先是没有完整的运行环境，其次机器若是出现故障，要想扩容一台机器的时候，就须要到原来的机器中将程序、环境变量以及脚本都拷贝出来。

最后咱们提出了程序包的概念。全部的应用都有独立的程序包，包含程序、配置、管理方法，而且有本身的运行环境，能够自我监控自我管理，咱们须要作的只是将程序包发到机器上运行就够了。这个时候作扩容就很是简单了，只须要从制品库中将所要的包发到新的机器上就。

上图所列出的就是程序包中具体所包含的东西。

工具和平台都是为人服务的

咱们不少时候都会思考如何将AI或者大数据应用到运维的场景中来。

为了便于理解这里先来对比下Deep Blue和AlphaGO，这二者实际上是彻底不一样的解决方案。

前者将国际象棋的整个算法抽象成25条规则，用来判断每一步棋的好坏，这里的难点在于如何定义那25条规则。

因为围棋的下法太多很难根据一些简单的规则定义每一步棋的好坏，因此AlphaGo使用的是深度学习的方案。深度学习有两个核心的概念，一是对原始的数据集进行抽象提取有价值的数据，二是对这些有价值的数据分类最终得出想要的结论。

时至今日当咱们想要实现智能化运维的时候，就会发现其实咱们连最基本的数据归类都没作到。因此说当下更重要的是经过流程平台、CMDB以及持续反馈的能力将有价值的数据承载起来，将来基于这种数据，即便不用AlphaGo的深度学习算法，也能够采用Deep Blue的那种简单决策模型找寻到有价值的信息。