Pylixm bio photo

Pylixm

To be a better man.

Email Google+

一. 介绍

作者介绍

本文作者是吴秀民 联系方式:autohomeops@autohome.com.cn,主要负责汽车之家资产管理系统和配置管理系统的开发工作。 个人Blog http://pylixm.cc/

团队介绍

我们是汽车之家运维团队,是汽车之家技术部里最为核心的团队,由op和dev共同组成。我们的目标是为汽车之家集团打造一个高性能,高可扩展,低成本,并且稳定可靠的网站基础设施平台。 团队技术博客地址为 http://autohomeops.corpautohome.com

image

联系方式

可以通过邮件或者在官方技术博客留言跟我们交流。

二. 前言

随着私有云及公司各自动化系统对CMDB数据依赖的加深,CMDB已变为公司服务器维护的基础数据源,一旦cmdb的数据有问题,可能造成不可预估的后果,

严重的可能导致线上业务的瘫痪。我们CMDB开发之初,制定了“高度准确性,高度可用性,高度自动化”的建设方向,而维持这个方向的核心是“流程管控”。

而“流程管控”是个长期建设的过程,某些时候很可能会赶不上业务流程的发展,这个时候为了不影响日常工作的顺利进行,免不了需要按照约定的规范流程来手动处理, 如果时间一长,就可能造成机器数据不准确。

数据的准确性,一直是CMDB建设的一大难题。接下来,说下我们除了“流程管控”外保证数据准确性做的一些探索,欢迎交流。

三. 我们遇到的问题

随着私有云及各自动化系统的建设,CMDB各种数据的维护都已实现自动化处理。但是上面已经提到过,“流程管控”和“业务流程发展”是一个相互博弈的过程,会有人工介入的机会。 在其中,我们遇到了许多问题,几个比较常见问题如下:

问题 1. 资产各字段数据不准确的情况;

公司私有云平台从CMDB中抓取IP使用时,是根据机房和业务线来抓取事先分配好的IP段。当业务线和机房出现问题时,则会抓取错误。

之前有同事在CMDB中创建了个机房用来划分IP,创建机房时,没有安照规定好的格式命名,且是从后台添加没有校验。

造成私有云在装机时拿不到可用的IP而工单流程走不下去。像这种数据不准确的情况,是非常危险的。这次只是一个机房命名,一旦私有云分配错了IP,有可能

把线上的服务器业务给覆盖掉,后果严重。

问题 2. 某个资产状态下,该为空的字段还有值,造成其他私有云工单流程入库时出现数据唯一性错误;

有业务线的同事申请云主机,各级领导批示通过后,迟迟没有收到云主机申请的结果邮件。于是便联系运维查看,运维又联系云主机管理员,

管理员再联系云主机开发人员,开发人员发现机器在自动入CMDB资产库的时候出错,找到我们。我们经过日志排查,发现一台服务器下线后

ip 没有清空,导致数据入库时报唯一性错误。经过多个系统的开发人员的合力排查,最后发现是数据问题。这种问题耗时耗力,还不可预见。

问题 3. 由于没有私有云上线工单而手动修改状态,造成时间有误,统计上线资产时数据不准确。

在对CMDB数据进行分析时,依赖各种事件变化的时间,但是人为修改数据时,有可能不去修改变更时间。这样当我们分类统计资产数据时,和

私有云的工单数据对不上,需要进一步核对明细。此时,就令人崩溃了。

四. 我们的审计方案

4.1 概述

基于以上问题,我们翻阅了大量资料,很少有资料对资产的自审计这块做很详细的介绍。

我们根据自身的问题,制定了以“盘”、“审”、“罚”为核心的自我审计方案,来保证cmdb数据的准确性。

4.2 盘 - 日志回算,外部核对

4.2.1 记录数据源

我们的CMDB是基于Django构建的,我们重写了Django的model,在数据保存变化时,同时记录数据的变化日志。

将数据记录变化前和变化后的值都保存下来,作为以后回算的数据源。

4.2.2 回算

有了资产的最详细的数据变更日志,这样只要我们遍历数据的变更日志,便可以知道历史任意时刻资产的状态信息。

例如,我们要计算上个月某个业务线申请了多少台机器。我们只要遍历上月CMDB的数据变更日志,将业务线和状态同时变更的记录累计起来,

便是我们需要的数据了。

4.2.3 外部盘态

根据回算处理,可以得到一些汇总性的数据。我们也可以从工单系统等外部系统拿到一些汇总性的数据。根据这2个数据我们可以判断出

CMDB 的数据记录是否有错误,是多资产了还是少资产了。

外部盘态的流程,如下图:

4.3 审 - 定期审查,自我修正

除了盘库外,我们还定制了自审查后台任务。每天会对CMDB资产的各字段准确性及是否为空做校验,找到数据有问题的资产。

将资产列入黑名单,并以邮件的形式发送给相关运维人员,提醒他此资产什么地方有问题需要修正。先于外部调用系统发现问题,争取主动权。

邮件样式:

除了邮件,我们还开发了黑名单的核实功能-“黑名单列表”,来督促运维人员做数据的修正。运维将修改过的资产在“黑名单列表”中做确认 操作,等下午发第二封邮件时会公布大家的修改进程,这样起到大家相互督促监督的作用。

4.4 罚 - 划分责任,落实到人

执行力,也是数据准确性的一大保证。以上我们通过自动盘库找到了有问题的资产,能够及时有效的修正数据也是一个大问题。

4.4.1 可视化规则条例

为了解决“执行力”的问题,我们制定了规章条例,并将它可视化,在cmdb中以资产的形式管理起来,供各运维查看学习。

页面原型如下:

4.4.2 将黑名单和条例结合

将黑名单和条例可视化后,便有条可依。当资产数据再出现问题时,先给予运维时间去自行修正,如数据错误仍然存在, 便可进行不同程度上的小小惩罚。

页面原型如下:

奖罚条例事件流程图:

五. 经验总结

在CMDB的整个构建过程中,数据的准确性一直是一个大难题。我们在这个方向上的一些经验总结:

  1. 将责任角色划分到人,减少扯皮的麻烦。出了什么问题,就找什么角色的人。
  2. 私有云工单流程控制中各资产的数据变更时间记录要详尽,便于满足各种统计需求。
  3. 将超级管理员和开发人员分开,解放开发人员,避免开发过多的参与错误数据的核对耽误正常开发。

六. 未来的Roadmap

  1. 基于黑名单的资产锁定处理
  2. 部分问题资产的自我修正

七. 参考资料

CMDB理解

华为cmdb

蓝鲸

优云软件

更多精彩技术文章,欢迎大家访问汽车之家系统平台团队博客http://autohomeops.corpautohome.com

简历请发送autohomeops@autohome.com.cn, 期待你的加入!