解构魅族CMDB运维自动化演进历程

梁鹏 2019-01-23 09:45:11
本文主要从运维自动化发展历程、CMDB运维的痛点、CMDB运维自动化实践、后续发展和演进四个方面介绍了CMDB运维自动化实践。

 

一、运维自动化发展历程

 

随着移动互联网的发展,运维平台的架构也在不断演进和优化,给运维人员带来了诸多挑战:

 

  • 首先从质量上看,不管是硬件还是架构,由于监控体系不完善,导致覆盖率低,监控易出现漏报、误报;

  • 从项目上看,业务的快速发展,导致对资源的需求量高,但由于未能将流程和自动化结合起来,人工参与较多,效率相对低下;

  • 从成本上看,平台不能记录交付资源及回收资源等,使流程不完善,工作变得不透明。

 

运维一直处在填坑、救火、背锅阶段。固此,今天我将从质量、成本、安全、效率四个维度来衡量运维人员的价值。

 

 

以价值为导向,我们建设了:

 

  • 资源管理平台:这其中包括CMDB、KVM云平台以及容器平台。

  • 配置管理平台:我们建设了DNS、LVS、CDN管理平台,提高配置操作的高效率。

  • 自动化平台:这其中包括发布平台、工单平台以及巡检平台。发布平台主要应对产品迭代发布的需求,提高效率;工单流程平台,主要是把生命周期所有的流程实现自动化;巡检平台,主要是做服务器初始化资源交付的巡检。

  • 监控容量平台:我们做了基础监控、业务监控、容量系统。容量系统主要数据来源是从监控取的,在年度预算或者季度预算时,把容量系统的数据拉出来,针对不同的业务判断资源利用率是否符合标准。

  • 安全平台:包括堡垒机、漏洞系统、自研WAF系统。

 

我们通过以上管理平台和自动化运维平台,来对我们线上的业务进行管控,提高业务可用性,提高工作效率,确保业务的安全。

 

二、CMDB与运维系统的关系

 

下图是CMDB与运维系统的关系图:

 

 

从图中我们可以看出,CMDB是周边所有运维系统的场景交互数据来源,所以确保CMDB元数据的准确率至关重要。

 

三、CMDB运维的痛点

 

1、权限管理混乱

 

运维人员以前都是超级管理员,他们对CMDB平台所有的资源属性有权限进行修改,自然会有数据不准确的风险。

 

2、生命周期没有流程化、自动化

 

这体现在早期所有流程的运转,包括CMDB数据的变更,因多数是使用邮件完成,没有流程把控,也没有实现自动化,效率比较低。

 

3、数据不准确,数据质量没办法保证

 

CMDB元数据早期录入不太完善且数据没有校验完整。

 

4、变更信息维护效率低,资产变更需要更多人为操作

 

主要表现在当服务器迁移的时候,需要删除CMDB数据再重新录入,主要带来的人工操作较多,效率低下。

 

5、异常数据的发现和修复

 

不论是手工录入还是自动化采集,数据肯定均会有不准确的情况发生。早期业务运维或者基础职能部门使用过程中都是自己发现异常数据,在进行修复,数据的准确性没法确保。

 

针对这些痛点我们总结出了三个维度:平台运维效率低、平台数据质量低、流程未标准化。

 

 

四、CMDB运维自动化实践

 

基于上文的痛点,CMDB做了如下事宜:

 

1、CMDB模型和标准

 

自动化的前提必然是标准,我们先看看定义的相关标准:

 

 

  • 设备分类:服务器、虚拟子机、路由器、交换机等;

  • 设备属性:型号、厂商、序列号等;

  • 业务标准:业务树模型:城市-机房-业务-容器-模块;产品树形态;

  • 设备操作:状态变更、业务变更、设备回收、设备下架等操作。

 

2、CMDB数据管理

 

数据管理分两个维度,设备的固定信息和设备的可变信息。

 

 

固定信息正常情况下不会改变,比如设备位置不变更,设备系统不进行重装等等;上图右侧为固定信息,包括设备硬件信息、网络信息、物理位置信息、系统信息等。上图中左侧是设备的可变信息,包括用户信息、状态信息、业务信息。

 

那么设备的固定信息和可变信息是怎样采集和维护的呢?

 

CMDB的数据管理,主要是通过自动化和流程化来实现数据的变更和维护操作。

 

例如硬件信息,可以使用自动采集识别;业务的状态变更,业务上线,可以通过流程进行实现,不用人为操作数据;人工协助操作进行数据的维护操作,这主要体现在初始化录入时,比如机房信息。

 

3、CMDB实现的目标

 

有了CMDB的相关标准和数据管理的脑图,我们看看我们CMDB需要实现的目标是怎样的?

 

 

CMDB要实现的目标,也是基于痛点写的目标:

 

  • 减少用户人工操作,提高工作效率;

  • 提高元数据质量,确保数据准确率;

  • 流程逐步标准化,操作尽可能流程化。

 

基于我们要实现的目标我们需要做哪些事情呢?

 

1)用户权限收敛

 

 

早期用户权限就针对功能模块进行授权,这样用户可针对此模块的数据进行变更操作,例如,服务器管理授权用户后,服务器管理模块就可以对所有资源状态和资源属性进行修改,那么就存在数据不准确的风险。

 

后续我们做了权限收敛,收敛后包括功能模块授权、子功能模块授权、属性操作明细授权等等,这样就可以把权限限制到最小,数据异常的风险降低到最小。

 

用户权限收敛后,那么用户怎么去变更数据呢?通过流程化更新或者维护CMDB的配置信息,便可以确保数据的准确性。

 

2)生命周期流程管理

 

 

这其中包括:

 

  • 资产需求和采购。包括需求的收集、需求的评估、需求的比对以及需求采购清单。

  • 资产部署和调度以及业务上线。例如,资产验收、系统安装、领用、业务上下线以及回收、备件调拨等。

  • 服务器生命周期流程末端。包括资产退役、资产报废。

 

生命周期流程管理所有的数据操作无论是查询还是更改,必须都覆盖CMDB。

 

3)流程管理自动化

 

 

上图是简单列举的七个基于生命周期管理的流程,从需求的收集一直到服务器退役,包括服务器采购流程、领用流程、业务日常申请、业务资源调拨、搬迁、回收、报废流程,包含了生命周期各个阶段。

 

黑色字体是对CMDB查询的操作,红色字体是对CMDB既查询又做更新配置的操作。

 

下面列举一个例子:

 

 

列举业务日常申请流程:

 

从业务日常申请流程发起时,会填写业务所属的部门、机房、机型、数量、业务树等,CMDB会自动判断所在部门在某机房的某个机型是否有更多资源可用:

 

  • 如果资源池不满足,就需要领用流程,到公共资源池领用,领用到相应部门资源池下。资源池的定义指某一个业务树下,状态是待运营或是待上线状态,都算作资源池。

  • 当资源池的数量满足后,便进入审批阶段,审批需要判断是否有季度预算,及容量池里的资源利用率是否都是平均或者达到某一个百分比。如果容量系统里资源利用率很长段时间都保持在30%以下,那这个资源也不能申请。

 

审批通过后,下一个节点是划拨资源交给开发,在这个审核节点里做了一些操作:

 

首先是查询,主要查询的是机房、机型、产品资源池数量、状态、IP地址;把资源划拨出去后,CMDB有些配置要更改掉,比如业务树,会自动修改为在需求提交阶段填写的业务树,状态会自动修改为由待运营或者待上线修改为运营中,产品资源池数量会减少。

 

通过上述图中的流程管理与自动化方法,我们做了十几个标准流程,实现了对CMDB多个字段的查询和配置更新操作。但这个流程后期也会根据业务需求,迭代、优化或新增。

 

4)数据自动采集

 

 

通过自动化配置平台,把提前写好的自动采集Agent推送到每一台服务器,同对服务器是否有部署这个Agent进行巡检,定时推送和拉取,确保所有上线资源都有数据采集的操作。最后上传到CMDB中,进行配置比对。

 

每个厂商服务器的采集工具都不一样,针对服务器采集,魅族主要用了以下工具:

 

 

我们采集的数据较详细,比如内存插槽、SN号、配置主频等等;采集这块遇到较多的坑就是raid卡和磁盘的数据采集了,要判断cpu架构、raid卡、直连卡、品牌等等,根据条件使用不同的采集工具;通过自动采集,我们提高了数据准确率及工作效率。

 

目前魅族已经实现了30多个数据的自动采集,采集Agent端的自动巡检以及数据采集信息定时监测操作。

 

5)数据异常巡检-规则

 

人工录入或者流程化管理、自动采集,并不代表数据的准确率都很高,所以我们继续做了一个数据的异常巡检。

 

 

6)数据异常巡检-进阶之路

 

 

早期数据异常通过人工发现,人工修复;然后做了数据异常巡检自动化,自动发现异常,人工修复;此时我们发现人工修复的效率太低,陆续做了异常数据的自动修复。

 

现阶段我们做了13种异常巡检规则,5种数据异常修复,后续还会持续的定义巡检标准和修复方案;另外还做了元数据录入CMDB规则化,这个作为数据初始化录入关口,一定要标准化,如果这里没有标准化,没有强制性,后续数据必然就不准确。

 

最终我们要实现的目标就是实现异常数据巡检更全面,异常修复更自动化。

 

7)资源池管理-资源入池流程

 

 

资源入池的流程,首先是需求申请阶段,需要填写部门信息、机房、机型、数量、业务树等,然后是需求评估阶段,此时就需要评估预算是否合理,资源利用率是否正常等,评估通过后就是采购和交付阶段了。

 

在资源交付完成后,此时资源就会根据需求申请阶段的部门信息,自动的写入到相应部门的资源池中,此时对应的业务和开发就可以进行业务的上线操作了。

 

在资源入池的过程中,公共资源池的数量会减少,产品资源池的数量会增加。

 

8)资源池管理-策略

 

 

公共资源池即某个业务树下,状态为某几种的资源的总和;部门资源池即是通过上述的“资源入池流程”,根据入池后打的tag来自动统计;虚拟机资源池的数据跟云平台API实现,主要是确保数据的一致性。

 

资源池认领率,主要是通过申请阶段填写的数据和最后认领的数据的比对,得出资源认领率。假如认领率较低,那么下次预算申请时,此业务的信用度会降低,需求审核严格一些。

 

9)维保管理-策略

 

 

我们默认服务器采购完毕后3年维保,当服务器上线使用3年后,服务器进入待续保状态,此时的续保策略可以按两个维度来评估,首先按部件维度,这个维度需要考虑部件的故障率,比如磁盘故障率高,内存故障率低,那么在做续保的时候,考虑磁盘的备件多采购,内存的部件少采购一些。

 

另外一个维度就是整机续保维度,这个维度的成本预算可能会稍高一些,当然还需要考虑服务器的使用价值等等,比如采购时候针对A业务,3年后A业务的性能要求高,此机型满足不A业务了,那么就需要考虑给测试环境或者其他性能要求不高的业务使用了,测试环境则就不需要续保了。

 

当服务器使用4年后,服务器为待换代状态,则会推送邮件清单至业务运维侧,让业务运维提前规划,后续做预算的时候考虑换代的这批服务器;当服务器使用5年后,其实也是服务器换代完成后,则走服务器下线报废流程即可。

 

五、后续发展和演进

 

  • 权限进一步优化,提高数据准确率

  • 数据采集方案更完整和智能

  • 流程化管理数据,效率提高的同时数据更准确

  • 元数据异常巡检的规则更详细和完整

  • 元数据异常修复更自动化

活动预告