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建设方案
我们曾服务过一家物流企业，他们有自己的监控系统、日志的分析平台也有一些工具，但是整体来看能力还是比较弱。他们所遇到的最大的问题是发布成本很高，每一次发布都需要停机，时间大概是2、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的那种简单决策模型找寻到有价值的信息。
标签：落地,运维,管理,标准化,DevOps,能力,案例,交付,CMDB 来源： https://blog.51cto.com/15127556/2663710