基于CMDB与SALTSTACK的运维自动化之路
张延礼,现苏州蜗牛高级运维经理,就职于腾讯多年,熟悉基础架构运维及业务运维,在运维技术实施、流程及标准化体系建设、运维自动化架构设计及实现,运维支撑体系规划和执行团队管理等方面具有丰富经验。作者介绍
本文基于蜗牛从零开始建设运维自动化的一些实践,总结自动化建设过程中涉及的体系规划、实施路线、产品设计及架构设计等方面的经验。正文
1、自动化要解决什么问题 运维层面的工作可以归结为如下三大块 [attach]1719[/attach] 服务管理层面主要是从运维总体支撑的角度来管理运维质量、规范、成本等等,处在运维工作的最高层;技术决策主要是为实现管理目标去制定总体方案,实施路径;技术执行则是落地的最后一环,这一环工作往往呈现零散、杂乱、重复、频繁变更的特点,承接的需求量最多,但价值体现却是较低的一环。 当前运维自动化的首要目标还是在解决”技术执行”这一层面的问题:将大量重复低价值含量的人力实施变成自动化执行,最大化地降低人力依赖,提升运维效率及业务支撑能力。 2、自动化建设思路 对于如何建设自动化运维,个人认为首要的是要有建设思路与方法论,以下供参考: [attach]1720[/attach] [attach]1721[/attach] 3、自动化建设总体框架 自动化的建设水平在行业内差异化还是明显的,如果处于运维自动化起步的阶段,建议是组建运维开发团队,从整体规划,基于ESB思想,分层建设,让支撑平台从业务逻辑中解耦。比如就业务运维而言,整个操作工作面无非就是对业务运营环境的各种操作、配置,以及对业务应用程序的管理,简单来说就是OS层和应用层。 [attach]1722[/attach] 要做自动化实施首先得有准确对称的数据,然后需要一个统一的管控平台,能并发的控制和操作远程大量主机,这解决了OS层面的操作问题,但需要管理应用层面的东西还需要与应用的研发人员规范相关接口,这对于开源组件应用而言一般不会有什么问题。因此如果是从零开始做自动化,个人认为CMDB、管控平台、业务进程管理工具这三部分是地基。在此基础之上,可以针对运维各类场景和业务逻辑去做相应的垂直功能系统,再上一层,可以使用流程引擎之类的组件来实现业务运维流程的纵向整合,最终实现运维各类业务流程的纯线上自动化。一、自动化体系规划
业务发展往往带来运维块面的应用形态、运营环境、、部署结构、基础架构规模及组织流程等多样化、复杂化;如无统一的标准及规范,运维支撑工作将异常混乱,自动化也难以实施。因此自动化有一个基础:标准化,标准化是将一切杂乱无章、千头万绪的运维工作变得有序及可控,流程规范与执行标准的落地是自动化的一大基石。结合我司实际运维现状及需求,基于以上自动化体系建设思路,前期规划的建设线路如下 [attach]1723[/attach] 1、信息的标准化管理:CMDB 在运维工作中,信息的管理往往是难点,运维侧涉及的信息太多,且也与其他职能部门多点关联,信息流转于整个流程的多个职能部门、多个环节 [attach]1724[/attach] 中小型企业中,手工线下记录的方式居多,线上线下信息一致性保持、内部外部信息传递、共享、同步等均存在较大问题,经常出现:二、自动化实施路线
- 线下表格有,实际位置找不到,或信息不对称
- 不清楚设备状态,不清楚哪个业务在使用
- 一个部门做了变更,其他部门不知情
- 变更一条上联链路,无法及时判断影响范围及程度
- CI及属性需要贴合实际环境,同时考虑长期的运维规划
- 管理的不仅是CI及其属性,还有CI之间的关系,状态流转机制等等
- 充分考虑扩展性及灵活性,如引入自定义属性来满足未来或暂时不可预见的需求
- 良好的scale-up/scale-out,灵活扩展,支持复杂网络结构
- 轻量级、高效的后端通信机制,成千上万的管理规模
- 跨平台,支持windows、unix-like多平台,无需重复开发
- 全网统一的一套基于web的用户界面,将所有操作逻辑通过web层来调用salt-api,web前端提供与直接登录机器操作一样的灵活性和自由度,运维人员在web上完成所有操作。
- 对运维操作进行建模,将其分解为几大原子操作类型,一切复杂的序列化操作逻辑可通过原子的自由组合来实现,给用户提供自由灵活的操作方式
- 基于以上逻辑,再给salt加一层应用接口,便于后续其他系统平台可直接调用或整合UJOBS以建设更高层次的平台。
文章来源:微信订阅号"运维帮" 地址:http://dwz.cn/6c2Yqz