大部分企业的运维都是经过多年的历史发展才形成今天的局面。不同时代的不同模式和技术发展，使我们无法进行一刀切的升级。在这种情况下，如果我们想要实现真正的运维自动化，是否应该先思考一下自己的运维数据治理问题再进行下一步呢？本文的讨论和解读来自多位领域专家和运维老手的分享。@赵海技术经理：运维自动化要达到什么目标？我个人认为现阶段的运维自动化就是要实现运维数据的自动采集、运维数据的自动分析、运维监控和运维告警的自动化、运维的智能化、自动化和智能化。维护工具和运维操作。要做到这一系列的事情，我觉得一定要以数据为基准。首先，它是关于数据收集的。不同的终端有不同格式和内容的日志数据。目前尚无可行的标准可实施。接下来是数据存储的问题。不管是CMDB还是其他方式，总之就是要把收集到的日志提取出来存储起来，对有用的信息进行格式化。那么如何区分是否有用呢？以何种形式加工入库更有意义。我觉得CMDB是目前比较合理的一种方式，但是是不是最合理的呢？再说就是数据分析。有些数据需要实时报警，有些数据需要结合历史。分析数据的惯性轨迹。有些数据需要长期积累才能提取出有意义的性能曲线。有些数据需要结构化分析，有些数据可能需要结合非结构化分析。总而言之，数据分析不仅仅是简单的条件查询或积累，需要合理的方法和平台来实现。最后，是关于数据的使用。有了这些数据，我们就可以根据数据的分析结果来判断后续的运维操作。无论是故障诊断处理，还是日常运维批量变更，都需要数据支持。根据不同的数据结果来判断下一步的精准运维操作，这个过程如果对逻辑和数据的要求很高，相信会更有意义。说了这么多，其实贯穿始终最重要的就是数据处理，从原始数据到不同层次的处理数据，从原始的收集积累到后续的数据分析处理。对于大多数企业的运维来说，在多年的历史发展过程中已经形成了现状。不同时代的不同模式和技术发展，使我们无法进行一刀切的升级。在这种情况下，如果我们要实现真正的运维自动化，是否需要思考自身的运维数据治理再进行？@jason2006xu昆仑银行技术经理：运维自动化离不开运维对象的准确信息（IP、网卡、端口等）以及运维对象之间的关系，这就是CI与CMDB的CI。CMDB建设过程中通常会遇到以下问题：CI信息分散，不同系统维护不同的CI信息；CI信息重复，CI信息采集重复，存储重复。CI信息不一致不同系统的CI信息不一致，以哪个为准，其他系统能否更新保证一致性是个问题。CI标准和规范缺失：导致CI模型、接入、识别等混乱无序，重复无目的采集CI信息严重。缺乏CI信息闭环管理：CI信息管理是一个循环的闭环过程。其目的是建立CI信息管理机制，确保CI信息质量的持续提高。管理好CI一定是一个长期的过程，同时伴随着污染和治理，所以CMDB的建设不是一个项目（暂时的、独特的、逐渐清晰的），而是一个长期的建设过程，需要一个长效管理机制，不断检查，规范化，改造一次次。@zjwy82银行系统架构师：首先说一下个人的看法。运维数据的统一管理并不是实现自动化的前提。需要明确运维数据的概念定义和自动化运维的覆盖范围。我更喜欢将配置管理作为自动化操作的先决条件。先说对运维数据的理解。我认为有几种类型。一种是描述生产资源的数据，也就是我们常说的配置数据，另一种是生产资源运行过程中产生的数据。配置数据也可以理解为数据中心内部的主体，各种任务都围绕着他进行。这就好比我们做运维的时候，需要知道它是针对哪个对象的，是给设备上电，还是给数据库打补丁，还是升级应用版本。这里提到的设备、数据库软件、应用程序都是配置信息的一部分。自动化运维是一项有广度和深度的工作，可以从不同的角度进行细分。按照技术架构的分层，可以有应用部署自动化、基础软件部署自动化、计算资源自动化。每个项目都相互关联，并有特定的现场实践。深入来说，有必要考虑自动化系列、审计和效果测量。就像我们现在熟悉的云平台，就是典型的资源供给自动化/自助服务。实现资源供应管理是最基本的自动化，只有配置信息管理才能完成。要想提供灵活的资源供给，就需要对资源使用、运营支撑业务、应用架构等有详细的管理才能做好。因此，在不同管理需求/成熟度需求的前提下，自动化对运维数据的依赖范围不同。问题是我想做最完整的自动化，所以我想做好所有运维数据的统一管理。这个问题很复杂。运维数据很大一部分是由应用产生的，需要各种依赖，与组织分工、技术标准、规划管理密切相关。可以逐步推进运维数据治理和自动化。.@he7yong研发工程师：运维数据统一管理，运维自动化是很大的课题。所以，我不认同运维数据的统一管理是运维自动化的前提。搭建好CMDB是运维自动化的前提！我同意。@杨文云DBA：可能问题的意思是运维数据要集中处理。个人经验感觉这种实现在实践中并不容易实现。运维数据治理确实很重要，但是集中处理不适合运维管理平台在一个平台上做系统维护。为了实现系统定制化、批量化管理、日志标准化、数据分析和量化，部分数据还需要定义Classified，需要根据应用业务的需要进行分类和量化。个人觉得这个比较靠谱，也比较容易实现。因此，运维管理平台本身作为一个系统进行维护，但运维数据应该由各个应用系统维护和管理。遵循标准没有错，但是执行起来非常困难。制度上的差异已经存在，生产上要实现标准化并不容易。就像IPv4到IPv6一样，没有办法一次性完全放弃ipv4。需要的是兼容性和逐步标准化。而且运维问题千差万别。一个理想的场景是设置一些规则，通过日志或者告警来识别问题，然后采取相应的措施。不过，我觉得如果能用一个小机器人来准确派工单就好了。主要是综合的、复杂的情况太多了。如果系统比较稳定，自动化运维可能会更有效。如果云项目等特殊情况太多，可能需要谨慎。@yujin2010good大型零售巨头系统工程师：运维自动化和数据治理是两个方向。运维自动化就是用工具来简化手工和重复劳动，提高生产效率。数据治理的重点是数据。数据治理是不是没有自动化运维就完成了？没有分析，没有报告？您不需要准确的报告吗？当然，还有统一的数据治理和统一的标准。这样可以快速的完成工作，也可以完成一些我们有更高标准和要求的事情，比如会员画像，精准营销等。@wh85某大型保险公司的系统工程师：涉及到CMDB和自动化。这里提几点浅见：1.这两个概念很宽泛。不要在此类项目中寻求完美。2.是否有机制或工具保证运维自动化所用数据的准确性？如果没有，则需要进行数据治理。3、运维自动化的范围是什么？数据治理的最小范围是相同的。4、对于一些运维数据，即使不用自动化，企业或管理层还是需要的。在这种情况下，还需要数据治理。举几个例子：1、应用集群的主机列表和应用部署路径直接影响应用自动化的发展。此类数据必须始终准确并有机制保证。2.谁是应用程序的利益相关者？这些数据也属于广义上的运维数据，但也需要准确。3、变更自动化是否需要服务器的机柜信息？机房的资料？没有。但是企业资产管理需要。@zhaogao22某大型互联网金融安全运维总监：哈哈，言论自由。我个人认为数据采集和自动化运维之间没有严格的依赖关系。数据采集??就是数据采集，自动化运维就是自动化运维。他们是两个不同的东西。通常，自动化运维主要是代替运维工程师完成某些运维工程师需要做的工作，比如上线发布、服务监控、日志收集、数据归纳、故障定位等，以及自动化工具、脚本、插件等都可以使用。@老式lawsoCorporateITLeader：不一定。运维自动化是一个比较大的话题。很多重复性的工作可以被运维自动化工具代替。这些任务不一定需要运维数据治理才能实现。可能需要的数据只与要做的事情有关。.所以，有统一治理后的运维数据肯定是非常好的。如果没有，没关系。首先列出你要实现的自动化工作，然后查看涉及到的运维数据，对这些数据进行梳理整合。刚好可以满足工作的需要。@gongpu某城市商业银行数据库架构师：同意，就像大数据需要良好的数据治理才能获取新知识一样，运维领域本身的工作量，如果可以通过界面可视化，可以大大改善脚本或程序减少手动操作是有好处的。至于偶尔的排错，因为相对的工作量毕竟有限。我觉得还是要评估成本效益，当然数据治理能做好最好。
