为了避免AIOps只是一句空话，我们认为要实现AIOps不仅需要一些自动化场景的实现、度量，还需要运维数据的管理。

01. 自动化运维的目标：端到端的自动化

首先让我们再来回顾一下之前提到的智能化敏捷运维体系的四个阶段：规范化运维、自动化运维、敏捷化运维、智能化运维。

所谓规范化运维，指的就是运维的基本要素该有的都有，比如操作、流程、数据等，但还比较杂乱，没有形成一定的规范。此时，可以通过引入运维PaaS平台、建设自动化场景和自动化运维流程，进入自动化运维阶段。如果企业是处在规范化运维阶段，并在逐步建设自动化运维的话，这个建设周期大概是1-3年左右。

如何进入敏捷化运维阶段将作为今天的重点讲述内容。当企业能够实现运维端到端的自动化、流程敏捷化、数据融合和全局度量，就可以认为该企业已经进入敏捷化运维阶段。其实要建设敏捷化运维存在一定的难度，因为敏捷化运维不再是各个部门割裂，而是通过运维整体融合来发挥价值，所以一般来说在自动化运维的基础之上要实现敏捷化运维需要3-5年。

最后，处在敏捷化阶段的企业由于各个方面都已经条件充分，只需等待AI模型和算法等各方面时机成熟后，方能进入智能化运维阶段。

接下来，我们开始讲述敏捷化运维需要具备的要素。完整的自动化运维是端到端的自动化运维，那么端到端的自动化又包括哪些方面呢？包括运维基础数据管理、日常运维监控管理、运维流程规范管理和科技管理提升四个方面。

• 运维基础数据管理：实现运维配置的自动化，比如设计态CMDB自动同步、资源CMDB自动读取、应用CMDB自动写入等。

• 日常运维监控管理：实现运维操作和监控告警的自动化，比如应用系统技术方案、系统关键指标的采集、自动告警收敛等。

• 运维流程规范管理：实现运维流程的自动化，比如问题自动化流转、缺陷管理线上闭环、发布管理自动化等。

• 科技管理提升：实现应急灾备和运维效能分析自动化，比如应急协作与支持、应急预案线上管理、紧急发布统计分析等。

示例1：标准变更自动化

需要明确的是，并不是所有变更都能自动化，标准的变更可以自动化，但是常规变更能实现的是部分自动化。那些暂时不能自动化的变更模块，可以等待时机等各方面成熟之后，再实现自动化。

示例2：变更自动化中的运维数据融合

所谓运维数据融合，指的是在运维实践过程中，为了进行某个分析、判断或者决策，将相关数据汇总、关联、分析和结构化呈现的过程。例如变更过程中需要做变更影响分析，过往靠人分析；在数据融合情况下，就需要能够结合CMDB、监控告警、应用日志、变更记录等数据信息，进行一定程度的综合的、自动化的判断。这就大大提升了决策的效率和准确性。

示例3：低成本外部场景集成

端到端的自动化也需要考虑到跟外部系统的集成，传统做法是做工具的两两集成，但这不是最优解，最好的做法是能有一个运维平台做支撑。因为当运维发展到一定阶段时，尽管工具和流程都已经完善，但运维体系却无法更进一步，正是因为两两集成的方法是难以持续保留的。同样，这也是目前很多单位都建设运维平台的原因。

02. 自动化运维的价值该如何呈现和度量？

1. 从运维语言转换成业务语言

当我们能实现端到端自动化之后，运维价值主要从业务和技术双维度进行呈现。运维人员岗位偏技术，因此在思考自动化运维价值时主要从以下几个方面考虑：

• 应用系统前台正常服务（业务服务提供）：系统可用性如何？系统连续性管理如何？服务目录是否清晰具体？系统服务级别是否满足？系统容量与性能能否充足？

• 应用系统后台技术服务（业务服务支持）：配置与资产是否完整、准确？故障与事件是否发现、处置及时？问题是否妥善管理，预防复发？发布是否快速、成功？变更是否可控，及时？服务请求处理能否及时，准确，高效？

用这些语言去描述价值本身没有任何问题，但当运维人员需要跨部门向业务端去沟通和对接需求的时候，建议切换到业务端更在意的业务语言进行描述。

那么怎么从运维语言转换成业务语言呢？建议从成本、成果、风险三个方面考虑，主要有用户的体验感、风险角度等。具体见下图：

2. 融入到具体的IT服务中进行度量

不管是工具本身也好、自动化这个过程也好，本身是没办法直接去度量价值的。例如，企业通过自动化的方式，把告警管理自动化闭环了，那么这件事有意义吗？有的，可是能度量吗？很难。因此，我们只能具体到过程中去度量，比如发现和处理问题的及时性：15min发现问题、30min解决问题。

当然，这种度量指标本身是依赖自动化和工具的。简单来说，自动化运维的度量要到融入具体的IT服务中，也就意味着需要有服务质量模型、服务价值评价体系，具体见下图：

03. 运维数据管理：过程融合与结果治理

我们认为，AIOps体系并不代表完全取代原有的自动化或敏捷体系，而是在原有体系基础上附加AI能力。因此在实现AIOps之前，企业需要先建设自动化运维体系和运维数据体系。

自动化运维体系相当于人的手跟腿，AI相当于大脑。由于AI是赋予的能力，并不能够把流程和工具自动化，因此如果很多机械的工作和流程还是需要人工操作，那么实现AIOps的价值就大大减少。运维数据体系的重要性不必多说，AI算法的成熟依赖数据，大量且准确数据才能训练出精准的AI算法。尽管可能外部已经有很多成熟的AI模型和算法，但对于企业内部建设来讲，这些算法和模型无法开箱即用，仍需要通过企业自身的运维数据训练。

1. 运维数据治理分享

在此，我们借用彭华盛老师对运维数据治理体系框架的总结，基本已经把所有方面都涵盖到位了：

当运维数据体系都搭建完毕后的架构是什么样的呢？底层是源端，通过软硬件和工具将数据采集至数据平台，再通过API网关连接到数据应用层面，详见下图。

尽管运维数据治理体系的方法论基本都是通用的，但是很多企业对于建设的范围难以把控，可能会把所有的数据都纳入体系中来。可是纳入进来后该怎么使用这些数据？这些数据是否有用？对于生命周期的管理是否有效？如果这些问题都无法回答的话，可能就没必要纳入全部的数据。

因此我们建议数据治理要强调场景驱动，而不是数据的范围驱动，这跟建设CMDB很类似

AIOps的前景十分广阔，但是在做到AIOps之前，我们前期需要做一些铺垫，包括构建端到端自动化的运维体系、将运营效能够通过数字化的方式进行度量，最后再是运维数据体系的建设。运维数据体系的建设又包含运维数据的治理、运维平台工具的建设以及运维场景的建设。建设完成后的企业已经基本实现敏捷运维体系，踏入国内运维第一梯队，为AIOps的演进打下坚实的基础。