运维数据的统一治理问题是不是运维自动化的先行条件？

大多数企业的运维都是基于多年的历史发展形成今天的局面，不同年代的不同格局和技术发展导致我们没办法进行一刀切式的升级换代，在这种情况下，要想实现真正的运维自动化，是不是该先想好自己的运维数据治理问题才能往下进行?

本文中探讨解读来自多位领域内专家和运维老兵分享。

@赵海 技术经理：

运维自动化应该实现哪些目标?

个人认为运维自动化在现阶段来讲就是要实现运维数据的自动化采集，运维数据的自动化分析，运维监控的自动化和运维告警的智能化，运维工具和运维操作的自动化和智能化。要实现这一系列的事情我觉得必须得以数据为基准，首先就是关于数据采集的问题，不同的终端具有不同格式不容内容的日志数据，目前来讲还没有一个可行的标准来贯彻。接着，就是数据入库的问题，无论是CMDB还是其他的方式，总而言之要从采集过来的日志进行抽取入库，将有用的信息入库格式化，那么如何分清楚是否有用?以什么样的格式加工入库比较有意义，我想目前来讲CMDB算是比较合理的一种方式，但这是不是最合理的呢?再有，就是对数据的分析，有些数据需要实时报警，有些数据需要结合历史数据的惯性轨迹来进行分析，有些数据需要长时间积累之后抽取出有意义的性能曲线，有些数据需要结构化的分析，有些数据可能需要结合非结构化的分析。

总而言之，数据的分析也不仅仅是简单的条件查询或者累计，需要一种合理的方法和平台来实现。最后就是关于数据的利用，有了这些数据之后，我们可以根据数据的分析结果来判断后续的运维操作，无论是故障诊断和处理还是说日常的运维变更批量化，都需要数据的支持，根据不同的数据结果来判断下一步的精准运维操作，这个过程相信也是需要将逻辑和数据高度结合才能完成的更有意义。

说了这么多，其实贯穿始终的最重要的就是数据的处理，从原数据到不同层面的加工数据，从原始的采集积累到后续的数据分析和处理。对于大多数企业的运维来讲都是从好多年的历史发展形成今天的局面，不同年代的不同格局和技术发展导致我们没办法进行一刀切式的升级换代，在这种情况下，要想实现真正的运维自动化是不是该先想好自己的运维数据治理问题才能往下进行?

@jason2006xu 昆仑银行 技术经理：

运维自动化首先离不开运维对象(IP、网卡、端口等)准确信息以及运维对象之间的关系，这就是CMDB的CI和CI之间的关系。而CMDB建设过程通常会遇到以下几个问题：

CI信息分散，不同系统保持不同CI信息;CI信息重复，CI信息采集重复，存储重复。

CI信息不一致不同系统中的CI信息不一致，以哪个为准、其他系统是否可以更新以保证一致是个问题。

CI标准和规范缺失：导致CI模型、存取、识别等混乱无序，CI信息重复采集、无目的采集现象严重。

CI信息闭环管理缺失：CI信息的管理是一个循环往复的闭环过程，它的目的是建立CI信息的管理机制，保证CI信息质量的不断提升。

要想把CI治理好必须是一个长期的过程，伴随着边污染、边治理，所以CMDB建设不是一个项目(临时、独特、渐进明晰)，而是一个长期建设的过程，需要有管理长效机制，持续检查、规范、改造，一遍一遍的来过。

@zjwy82 银行系统架构师：

首先我表达个人观点，运维数据统一治理并非自动化的先行条件，需要先把运维数据概念的定义以及自动化运维的覆盖范围厘清。我更倾向于配置管理是自动化运维的先决条件。

先说说对运维数据的理解，我认为有几类，一类是描述生产资源的数据即我们常说的配置数据，另一类是生产资源运行过程中产生的数据。配置数据也可以理解为是数据中心内部的主体，都在围绕他开展各项工作。这如我们做一次运维需要知道是为哪个对象，是设备加电还是数据库打补丁或是应用程序版本升级，这里所提到的设备、数据库软件、应用都是配置信息的一份子。

自动化运维是一个有广度有深度的任务，可以有不同角度的细分。按技术架构分层可以有应用部署自动化，基础软件部署自动化，计算资源自动化，每一项之间都有互相联系，也都有特定领域实践。从深度上就需要考虑自动化串联、审计、效果度量。一如我们当前所熟悉的云平台，是一个典型的资源供给自动化/自服务，实现资源供给管理是最基础的自动化，这仅仅依赖于配置信息管理即可完成。那如果要对资源弹性供给则需要对资源使用、运行支撑业务、应用架构等都有详细的管理才能做好。所以在不同管理需求/成熟度要求的前提下，自动化对运维数据有不同范围的依赖。

那有问题说我要做一个最完善的自动化，所以我要做好全运维数据的统一治理。这个问题很复杂，运维数据有很大一部分是由应用程序产生，需要有各种依赖，与组织分工、技术标准以及规划管理都有很大关联，可以在分步推动运维数据治理和自动化。

@he7yong 研发工程师：

运维数据统一治理、运维自动化都是非常大的话题，因此，我不赞同运维数据统一治理是运维自动化的先行条件。

建设一个良好的CMDB是运维自动化的先行条件!我是赞同的。

@杨文云 数据库管理员：

也许问题的意思是运维数据要集中处理，个人经验觉得这种实现在实践中不容易实现。运维数据治理确实至关重要，但是集中处理并不合适运维管理平台化在一个平台做系统维护，要实现系统的定制，批量管理，日志的标准化，数据分析，量化，还是要定义一些数据分类的，这需要根据应用业务需要分类，量化，个人觉得这样更靠谱，更有实现的可能性。所以运维管理平台是自己作为一个系统维护，但是运维数据应该是各个应用系统自己维护治理。

按照标准去做本身没有什么问题，但是实施起来十分困难，系统的差异性已经存在了，生产上再去标准化不容易实施，就像IPv4到IPv6，是没办法一次性完全舍弃ipv4的。需要的是兼容，逐步标准化。而且运维的问题千差万别，很理想化的场景是设置一些规则能够通过日志或告警识别出问题 然后采取对应措施，但是我觉得能做到用一个小机器人准确的派发工单就不错了。主要是综合和复杂的情况太多了，如果是系统比较稳定，可能自动化运维还比较有效，如果是运维新的比如云项目之类的特殊情况太多了，可能要慎重。

@yujin2010good 大型零售巨头 系统工程师：

运维自动化和数据治理是两个方向。

运维自动化是将人为的，重复的劳动用工具简化，提高生产力。

数据治理重点在数据，没有自动化运维就做做数据治理了吗?就不做分析，不出报表了吗?难道就不要求报表准确了吗?

当然有统一的数据治理，有统一的标准，这样可以快速完成工作，并且能做到一些我们更高标准和要求的事情，比如会员画像，精准营销等。

@wh85 某大型保险公司 系统工程师：

涉及CMDB和自动化，简单说几点拙见：

1、这两个概念都很广，做此类项目切忌求大求全。

2、运维自动化要用到的数据是否有机制或工具保证准确?如没有，则数据治理需要进行。

3、运维自动化范围如何?数据治理的最小范围相同。

4、有些运维数据，即便自动化不用，企业或者管理层也需要，这种情况下也需要进行数据治理。

举几个例子：

1、应用集群的主机清单，应用部署路径直接影响到应用自动化的开展，这类数据必须一直准确且有机制保证。

2、应用的干系人有哪些?这些数据也属于广义上的运维数据，但也需要保证准确。

3、变更自动化是否需要服务器的机柜信息?机房信息?不需要。但企业资产管理需要。

@zhaogao22 某大型互联金融安全和运维总监：

哈哈，言论自由哈，个人认为数据化采集和自动化运维并不存在严格依赖关系，数据采集是数据采集，自动化运维是自动化运维，两码事。

通常自动化运维主要是代替运维工程师来执行某些运维工程师需要干的活，比如上线发布，服务监控，日志采集，数据归纳，故障定位等，可以使用自动化工具，脚本，插件等。

@老同志lawso 企业IT负责人：

不一定。运维自动化是个比较大的话题，很多重复完成的工作都可以通过运维自动化工具来替代，这些工作不一定需要做运维数据治理才能够实现，可能需要的数据只是和要做的事情有关系。所以有统一治理后的运维数据肯定是很好，如果没有也没关系，先将你希望要实现的自动化工作列出来，然后看一下涉及到哪些运维数据，对这些数据做一下梳理和整合，能够满足工作的需要就可以了。

@gongpu 某小型城商行 数据库架构师：

同意，就像大数据要想得出新知识，需要很好的数据治理一样，运维领域本身的工作量，如果能够界面可视化，通过脚本或程序大幅度降低人工手动操作已经很好了，至于偶发的故障排查，因为毕竟相对工作量有限，到底是通过案例知识库，还是沉淀大量数据，找规律自动解决，我觉得是需要评估成本收益的，当然数据治理如果能做好，那是最好的。