基于CMDB与SALTSTACK的运维自动化之路

Posted 2021-05-01 运维帮

作者介绍

张延礼，现苏州蜗牛高级运维经理，就职于腾讯多年，熟悉基础架构运维及业务运维，在运维技术实施、流程及标准化体系建设、运维自动化架构设计及实现，运维支撑体系规划和执行团队管理等方面具有丰富经验。

正文

本文基于蜗牛从零开始建设运维自动化的一些实践，总结自动化建设过程中涉及的体系规划、实施路线、产品设计及架构设计等方面的经验。

一、自动化体系规划

1、自动化要解决什么问题

运维层面的工作可以归结为如下三大块

服务管理层面主要是从运维总体支撑的角度来管理运维质量、规范、成本等等，处在运维工作的最高层；技术决策主要是为实现管理目标去制定总体方案，实施路径；技术执行则是落地的最后一环，这一环工作往往呈现零散、杂乱、重复、频繁变更的特点，承接的需求量最多，但价值体现却是较低的一环。

当前运维自动化的首要目标还是在解决”技术执行”这一层面的问题：将大量重复低价值含量的人力实施变成自动化执行，最大化地降低人力依赖，提升运维效率及业务支撑能力。

2、自动化建设思路

对于如何建设自动化运维，个人认为首要的是要有建设思路与方法论，以下供参考：

3、自动化建设总体框架

自动化的建设水平在行业内差异化还是明显的，如果处于运维自动化起步的阶段，建议是组建运维开发团队，从整体规划，基于ESB思想，分层建设，让支撑平台从业务逻辑中解耦。比如就业务运维而言，整个操作工作面无非就是对业务运营环境的各种操作、配置，以及对业务应用程序的管理，简单来说就是OS层和应用层。

要做自动化实施首先得有准确对称的数据，然后需要一个统一的管控平台，能并发的控制和操作远程大量主机，这解决了OS层面的操作问题，但需要管理应用层面的东西还需要与应用的研发人员规范相关接口，这对于开源组件应用而言一般不会有什么问题。因此如果是从零开始做自动化，个人认为CMDB、管控平台、业务进程管理工具这三部分是地基。在此基础之上，可以针对运维各类场景和业务逻辑去做相应的垂直功能系统，再上一层，可以使用流程引擎之类的组件来实现业务运维流程的纵向整合，最终实现运维各类业务流程的纯线上自动化。

二、自动化实施路线

业务发展往往带来运维块面的应用形态、运营环境、、部署结构、基础架构规模及组织流程等多样化、复杂化；如无统一的标准及规范，运维支撑工作将异常混乱，自动化也难以实施。因此自动化有一个基础:标准化，标准化是将一切杂乱无章、千头万绪的运维工作变得有序及可控，流程规范与执行标准的落地是自动化的一大基石。结合我司实际运维现状及需求，基于以上自动化体系建设思路，前期规划的建设线路如下

1、信息的标准化管理：CMDB

在运维工作中，信息的管理往往是难点，运维侧涉及的信息太多，且也与其他职能部门多点关联，信息流转于整个流程的多个职能部门、多个环节

中小型企业中，手工线下记录的方式居多，线上线下信息一致性保持、内部外部信息传递、共享、同步等均存在较大问题，经常出现

• 线下表格有，实际位置找不到，或信息不对称

• 不清楚设备状态，不清楚哪个业务在使用

• 一个部门做了变更，其他部门不知情

• 变更一条上联链路，无法及时判断影响范围及程度

根本问题及给运维工作带来的痛点如下

因此我们引入一套基于ITIL体系的配置管理数据库CMDB，旨在为运维团队建立线下与线上一致性的基础信息库，作为运维标准化、自动化、平台化的基础输入。重点解决IT基础架构信息化以及业务配置信息线上化，系统主要功能模块如下图:

系统本身主要功能可归结为2个方面：基础架构信息管理、业务信息管理。此两大方面的功能使用者为web-user，除此之外，对于API-user，此系统提供了一整套接口界面与其它任何需要信息的系统进行对接，这也是设计初衷，将信息从一个统一的、标准的源头输出给各垂直或水平业务功能系统，而运维需要做的就是维护CMDB本身基础数据的完整性、准确性，CMDB与各流程系统、垂直功能系统结合之后实现信息数据一处变更，处处同步。

如上为CMDB业务管理模型，作为运维统一信息库，与其他系统平台数据互通，深度整合后实现信息的管理、维护、展现全部线上化。

产品设计过程中涉及的几个关键点：

• CI及属性需要贴合实际环境，同时考虑长期的运维规划

• 管理的不仅是CI及其属性，还有CI之间的关系，状态流转机制等等

• 充分考虑扩展性及灵活性，如引入自定义属性来满足未来或暂时不可预见的需求

2、通用型作业平台

对于运维执行工作而言，绝大部分的实现均是对运营环境的各类操作，在业务体量上去后，需求导致的运维操作密集度不断增加，如公司内某款游戏业务部署在近上百台主机上，一次维护要对此上百台逐一进行相应的操作，如通过人工去完成则费时费力、效率低下、且影响业务可用性。由此运维面临的问题是：

我们决定做一个通用型运维操作平台来解决这些问题，为运维人员提供一个可以批量控制和操作大规模主机的通道，运维人员在web界面中可以定制所有的运维操作，指定执行的对象，通过平台下发执行并返回结果，例如 批量shell脚本执行，大量文件传输，发布变更，数据备份等等各类场景。对于产品设计上遵循以下几点

技术实现上，基于公司运维环境，我们对后端系统有如下需求

• 良好的scale-up/scale-out，灵活扩展，支持复杂网络结构

• 轻量级、高效的后端通信机制，成千上万的管理规模

• 跨平台，支持windows、unix-like多平台，无需重复开发

运维门槛低，使用运维熟悉的命令操作及脚本语言即可完成一切作业，无需学习众多的特定模块或yaml语法,为此我们迅速找到了saltstack作为后端系统；前端系统涉及到的交互逻辑及业务逻辑自主研发，自研部分需实现的逻辑如下：

• 全网统一的一套基于web的用户界面，将所有操作逻辑通过web层来调用salt-api，web前端提供与直接登录机器操作一样的灵活性和自由度，运维人员在web上完成所有操作。

• 对运维操作进行建模，将其分解为几大原子操作类型，一切复杂的序列化操作逻辑可通过原子的自由组合来实现，给用户提供自由灵活的操作方式

• 基于以上逻辑，再给salt加一层应用接口，便于后续其他系统平台可直接调用或整合UJOBS以建设更高层次的平台。

后端salt的逻辑这里不赘述，由于实际网络环境的特殊性，我们采用了二层架构，即master-syndic-minion,公网与内网相结合的方式最大限度提升系统性能。

权限控制、执行对象等等与CMDB打通，可以非常灵活的适应各类业务，各种场景。

如运维人员可以在界面定义好一个版本发布作业：xx业务发布，分解整个发布流程中到每一步骤，并写脚本或调用外部接口来实现具体的操作，最终线上操作只需在页面点击开始执行就可：

当然用户自定义作业可以复用，通过传参的方式实现实例化，避免必要每次发布都建作业。

3、建设过程中的问题总结

做好产品设计及架构设计

充分解析运维内部需求，各具体平台或产品业务区分明确，产品定位一定要清晰，不要想着让微波炉具备电冰箱的功能，自动化整个体系不是一个产品能解决所有问题，需要自顶向下分层设计，产品之间相互解耦且又对外提供接口，能方便的整合与被整合。

组建运维内部开发团队

运维自动化的建设，最好是组建运维内部团队来进行开发，直接丢给业务研发部门往往做出来的东西不是运维侧想要的，因其不易理解运维侧的需求场景、痛点，操作方式等等；如实在没有运维开发团队，那就找个深度理解运维场景的PM去跟开发团队吧。

推动业务开发侧的标准化

其实产品开发团队的研发管理水平及标准化程度直接决定了运维人员爽与不爽，绝大多数研发人员往往只考虑产品功能实现，而很少关注可维护性设计，导致业务给运维人员带来很大的无价值工作量，更有甚者直接是将运维人员当成代码逻辑的一部分。让运维人员参与产品研发的可维护性设计是很多必要的，运维侧需形成可维护性标准规范，推动业务开发遵循将非常利于运维自动化的建设。

 

运维帮精选

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

QQ技术讨论群：542812110

同城微信群：上海、广州、深圳、杭州、成都

快乐分享，快乐生活