双态运维下的自动化运维体系研究

Posted 2021-05-01 新华三技术服务解决方案

运维是目前最火热的话题之一，一大波新名词如敏捷、DevOps、NoOps、容器逐次登场，在互联网上引发了一场又一场关于运维的理念与技术的反思与变革。传统大型企业IT也在互联网、物联网、敏捷方面尝试创新，然而却遇到了从技术到管理、文化、人才引进等多方面的不匹配。2017年3月1日，由新华三、联想、DaoCloud、华为等12家IT企业联合成立的双态运维联盟（BOA）体现出了市场对大型关键业务企业对运维的敏态和稳态有机结合思考。基于ITIL稳态运维是否还适用当前运维，适合哪些运维场景；基于DevOps的敏态运维如何才能真正落地企业？

IT自动化内涵广泛

根据Gar t n er在“Best Practicesfor Implementing Automation in Data Centers With Cloud and Virtualized Environments”中的分析IT自动化技术范畴至少应包含如下4大领域，共10个维度：

基础设施层面：

◎云编排                ◎基础设施供应

运维管理层面：

◎IT流程自动化      ◎安全合规

◎脚本自动化         ◎工作负载自动化

敏捷层面：

◎DevOps

业务层面：

◎文件传输自动化  ◎作业调度自动化

◎其它（如业务流程自动化）

可以看出IT自动化范围非常广，从基础设施到业务逻辑，从开发测试到运维都涵盖，而目前缺乏一款产品能够满足所有维度的专业要求。实际上，由于其技术的专业性和复杂度，也不可能产生一款单独的产品能同时满足范围的广度和专业的深度。从而大型企业不可避免的采用多种不同的自动化技术满足特定业务、特定领域的自动化需求。根据Gartner的研究，大型企业有75%采用了4种及4种以上的自动化技术。这样的情况下又不得不面临自动化被割裂，无法统一调度，发挥更大的效用。

企业自动化之殇

自动化运维已经在企业谈论了10多年，也有部分落地案例，然而能持续发挥价值的案例少之又少，关键集中在下面几个问题：

◎业务十分关键，对自动化控制能力没有信心；

◎工具使用难度大，可扩展性差，随着硬件、应用架构的升级，很快被淘汰；

◎传统IT标准化水平差，自动化工具需要分别定制化研发脚本，从而导致了维护自动化工具成本高昂；

◎运维水平跟不上，自动化项目一结束，甲方无法自行持续改进与优化；

◎自动化没有对业务有直接的支撑，看不到系统的长期价值，从而平台逐渐被淘汰。

因此，绝大部分企业自动化基本停留在对系统无害的检查类运维操作自动化，比如安全合规，深度巡检，软硬件资产管理等。究其原因，在IOE时代，设备异构性大，数量较少，靠人来管理还不成问题，即使落地了一些自动化，也是锦上添花的功能，而非迫切需求。

云计算大大促进了自动化

云计算表面看来只是将基础设施做了虚拟化，但实际上深刻地改变了IT生态。主要体现在如下几个方面：

◎基础设施X86标准化程度越来越高，基础设施接口化、自动化诉求越高；

◎资源数量指数增长。基础设施资源更易获得，导致数量大大增加，而传统靠人手工运维已经不现实；

◎云平台对业务支撑越来越直接，与应用结合越来越紧密。简单的提供虚机已经远远不够，这一部分已经非常成熟，带来不了更多价值。一方面把部分能力下沉到IT层，如应用自动化部署，基于业务性能的弹性伸缩；另外一方面需要结合业务场景，例如开发环境的准备与编译，测试资源准备同时触发自动化测试；

◎必须通过自动化的手段来管理资源。人工管理IT的效率已经跟不上时代发展，无法迅速提供包含服务器、存储、网络和应用的整体服务，无法清晰绘制各个部门网络的拓扑与安全策略，人工管理无法快速恢复系统故障。

传统IT支撑平台重新定位与思考

ITIL 2007年从V2升级成V3版本，但是在实际的运维落地实践来看，还是V2版本影响最大。其中落地最多的是耳熟能详的配置管理、事件管理、问题管理、变更管理、发布管理及服务台。传统运维落地架构示意图：

然而在实际操作过程中，虽然过程规范，甚至建设了相应的软件平台来支撑，但是其实施效果却往往不尽如人意。主要有几个问题：

◎流程流于形式。流程均采用管理推动，具体执行很大程度上依赖运维人员的专业性。实际操作过程中，大部分技术人员均对流程文档抱有排斥态度，觉得活都干完了，还写什么文档啊？导致系统中记录的有价值信息很少；

◎信息缺失严重。为了掩盖日常运维过程中发生的小问题、小故障，通常不会将这些信息记录到流程系统中，极端情况就是只填写领导关心的故障、问题；

◎信息准确率、及时率低。以CMDB为例，依赖流程推动配置信息更新，而且没有合适技术手段验证正确性，往往其准确率低于70%，及时性更加难以保障，如此低的信息准确率无法对决策及其它管理需求起到及时有效的支撑。

自动化的持续演进的CMDB

在服务器、集群飞速增长的云时代，IT系统软硬件的变更愈发频繁，清晰了解当前IT系统的现状、哪些系统需要打补丁、更换一台主机到底对哪些业务有影响都是一件困难的事儿。有必要建设一个CMDB来支撑，但是又对其心存忌惮，失败的CMDB项目比比皆是。

分析这些失败的项目，主要趋于如下几个原因：

◎CMDB配置项（CI）粒度控制不佳。想要的没有，不想要的一大堆；

◎数据准确性和及时性低。CMDB依赖大量人工流程支持，平时就没人维护，有人维护也无法保证数据准确性；

◎CMDB平台演进跟不上各部门需求，倍受诟病。各个部门对CMDB各种粒度需求，经过几次无序扩展，CMDB中的数据已经复杂到无法维护程度。

破解之道无非下述几种方法：

自动化、自动化、自动化（重要的事情说3遍）

充分利用虚拟化、云化、自动化技术，将配置信息实时同步到CMDB中，同时避免人工维护数据。在业务支撑关系等场景下会涉及到人工维护的信息，建议人工维护的部分与自动化维护的分离开，一个是业务CMDB，一个是基础设施CMDB。企业应从网络安全策略等方面为CMDB自动更新提供支持，优化防火墙策略，允许CMDB扫描网络上的设备。

清晰的定位

不要将CMDB作为所有IT、财务、资产、机房等等系统“万能”的配置信息支撑平台，过于宽广的范畴必然将导致信息复杂，并难于维护。

推荐定位CMDB到如下场景：

◎IT资产管理：软硬件资产、设备型号、维保信息统计，为领导采购决策提供信息支撑；

◎应用及关联关系：支撑告警系统、支撑故障根因判断；

◎基础设施与应用支撑关系：支撑告警系统、支撑故障根因判断。

以演进心态看待CMDB

随着IT新技术不断地涌现，企业管理职责的不断变化，CMDB也需要持续演进。虚拟化、混合云、大数据、多数据中心管理、容器技术等都会对CMDB提出新的要求，通过重建/重构实现跨越式提升也是必要举措。

流程审批的弱化

作为稳态运维的重要产物，各种复杂的流程审批实际上已经阻碍了业务及运维效率。自动化已经将IT操作的时间大大压缩，几乎可以忽略不计，这时流程效率的低下凸显出来，与敏捷文化格格不入。流程优化不可避免，通常采用几种方式来优化流程：第一种不改变当前流程，通过将部分流程自动审批策略来加速流程运转；第二种方式采用逐级授权方式优化流程，避免事事都需要高层审批；第三种方式通过组织流程重构，来精简组织及流程环节。

应用配置管理

传统服务器在应用部署和变更时通常较为随意，运维工程师由于性能优化、故障排除等原因随手更新配置文件，有时也更改执行脚本，甚至二进制补丁文件也随手就完成了。这些更改往往不受控制，随意性较大，也没有人做充分评估。很难有人清楚这些更改应该是临时性的，还是永久性的。这一行为在专人负责的情况下一般也不会出什么问题，而一旦人员有变动，或者在大规模集群的情况下，就会遇到麻烦，很可能出现配置错误，配置不完整等错误。

对于传统应用应合理控制所有关键的应用及配置文件，并做版本化方式保存，通过探测，发现变更、控制变更、恢复错误变更的能力。

而对于容器技术部署的应用做得更充分，一般要求生产上的Docker是不能做任何部署和配置文件的变更的，需要变更一定重新创建一个新容器，新容器来自对应的容器镜像和配置文件。

自动化的可视

自动化可能带来潜在的无法预知的操作风险。自动化必然需要同过程可视化、状态可视化、业务可视化相结合，才能防止自动化成为脱缰野马。

目前，云平台提供的可视化相对较好，能展示出云运维相关操作的状态。而传统IT则较为困难，比如对于复杂网络的拓扑及通信流量的展示、服务器状态、存储的状态、应用承载业务的状态等。

只有高度的自动化可视，即自动操作能及时准确地展现在界面上，才能将高深的自动化工具变成一个普通操作人员可以运维的工具。

自动化需兼顾敏态与稳态

在传统IT自动化领域有四大传统厂商：HP、IBM、BMC、CA，这些产品出现较早，主要用于稳态运维场景下，它们都试图适配尽可能多的异构厂商软硬件产品，具备灵活的编排能力，能较好的支撑运维自动化、合规检查、容灾切换甚至云。

然而随着开源软件的冲击，国外商业软件的采购成本高昂，实施费用不菲的问题凸显。开源领域适时地涌现了四大开源产品：Puppet、Chef、Ansible和SaltStack，能满足客户绝大部分的运维操作场景的需求。但是它们更像开发人员试用的工具，其易用性、界面整合还有所欠缺，商业软件及解决方案也纷纷集成这些开源软件，并在易用性、可配置性、界面等方面做了优化。

敏捷以及DevOps理念在其中主要落地技术CI/CD被热炒，Jenkins、Maven、Ansible、Docker等技术在该场景下被广泛使用、优化，如Jenkins基本形成事实的标准。而商业软件在此范畴基本也没有大的作为，停留在集成这些开源工具、统一门户、报表视图、敏捷项目管理层面。

通过详细分析当前大型企业客户的IT系统，新华三认为敏态运维适用于以下几个场景：

◎业务变更频繁、海量业务访问；

◎业务允许微量有损服务；

◎技术上是分布式架构，主要适合在负载均衡层、Web层、缓存层、中间件层。

简而言之，业务属于类互联网业务，架构为分布式架构。而以下场景适合稳态运维：

◎业务异常关键，不允许有损。例如银行核心业务系统，每一笔交易都与钱有关，不能容忍任何错误；

◎技术上是集中式架构，无法拆分的应用。任何变更都可能对其它功能造成影响和破坏；

◎无法拆分成分步实施的大型复杂需求。敏捷讲究小步快跑、快速迭代、快速试错，以保证结果如预期。不能拆分成多次迭代的需求更适合传统瀑布模型，即在需求、设计阶段充分评估；

◎关系型数据库。数据库的自动化发布、版本更新与回退是DevOps落地的难点。究其原因，缺乏鲁棒的方式对数据库中的数据版本和表结构变化进行升级与回退。每次的数据库的升级都是一次特殊的变更，采用自动化方式代价过高，建议采用手工操作。

虽然上述场景更适合瀑布式研发，ITIL流程推动，手工部署，但依然可以在开发测试阶段引入持续集成来加速开发测试。

下图为双态运维自动化体系架构建议，通过自动化编排引擎有机粘合各种复杂场景，满足多种运维场景需要：