解构魅族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年后，其实也是服务器换代完成后，则走服务器下线报废流程即可。

 

五、后续发展和演进

 

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

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

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

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

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