到底应该如何理解 AIOps？又如何落地 AIOps？

近年来，人工智能技术备受关注，将 AI 引入 IT 运维领域，AIOps 的概念由此应运而生。Gartner 的报告宣称，到 2020 年，将近 50% 的企业将会在他们的业务和 IT 运维方面采用 AIOps，远远高于今天的 10%。尽管 AIOps 还是一个新名词，但并不代表它只是未来的一种趋势而已。在这个数字的年代，任何使用传统技术来管理机器数据的组织要么忽略了信息的价值，要么已经让他们的运维团队不堪重负。

那就当下而言，我们应该如何理解AIOps？AIOps 应该如何落地？能否通过AIOps 支持更好的运营？带着这些问题，我们采访了宜信技术研发中心高级架构师张真，请他从宜信近几个月落地AIOps 的角度聊聊他的想法和洞见。另外，张真也会在 CNUTCon 全球运维技术大会上分享他们的实践案例。

InfoQ：你是如何理解 AIOps 的？AIOps 的关键点是什么？

张真：我认为 AI 的生态体系与大数据类似，存在两种基本角色：AI 科学家和 AI 领域工程师（FE）。前者推动 AI 科学的发展，创造新的 AI 知识体系；后者是将 AI 知识运用到生产生活的某个领域，创造现实价值。AIOps 正是将 AI 技术应用到 IT 运维领域，帮助变革运维模式，提升效率和创造现实价值的“工程化”过程。

从实施角度，AIOps 这个词本身就体现了两个关键点。其一，Ops 代表运维的场景，这是主旨，识别什么样的场景存在哪些痛点，AI 可以帮助解决；同时也要清楚认识目前的 AI 技术擅长什么，不擅长什么，有哪些限制，切忌凡事尽 AI。其二，AI 作为前缀代表技术，这是手段，AI 技术门类很多，选择合适的，正确的技术去解决真正的问题，是需要切实履行的原则。此外，要从实际出发，考虑投入与产出。

从技术角度，也有两个关键点。首先 AI 的目标是系统类人化，而 AIOps 是将运维系统类人化。它的技术栈应该涵盖三个基本特征：类人交互，主动决策，理解执行。这是与自动化的本质区别。其二，与 DevOps 工具链深度集成是必由之路。我认为 AIOps 不是要替代现有的工具链，而是通过类人化提升“智慧”，实现 SRE 甚至超 SRE 的效果。要达成这个目标，AIOps 就要“学习，了解”这些工具，并且更好的“使用”这些工具，这个过程就是深度集成，它的核心是对这些工具 API 的自主认知和自主使用。

InfoQ：AIOps 和 DevOps 有什么关系吗？可否聊聊你看到的运维理念的演进过程？

张真：正如刚才提到的，AIOps 在技术层面要对 DevOps 工具链进行深度集成。另外，我也想从发展历程角度谈谈它们的关系，其实我也是伴随着这些发展阶段逐步成长起来的。这应该也是个人运维理念的演进过程吧。个人认为 IT 运维经历了 4 个基本的发展阶段：

1. 早期工具时代：这个时期是 IT 运维的软件工具，流程初始化的时期，工具的目标仅仅只是计算机化，流程尚属摸索阶段，还没有形成行业共识。
2. Pre-DevOps 阶段：ITIL，DevOps 等理念在这个时期提出，ITIL 强调流程管理质量，而 DevOps 强调打破开发，测试，运维的边界，One Culture as One Team with Closed Cycle，这个时期也开始了围绕如何落地 DevOps 工具链的技术研究，业内就 IT 研发与运维逐步达成了共识。
3. DevOps 阶段：DevOps 的工具链已经比较成熟，甚至出现了一些高级形式，比如 SRE，ChatOps 等，其中 ChatOps 通过对大量运维工具的封装，构建了一个代理，它认识人类定义的特定文本指令，并按照指令处理问题。这个时期自动化运维出现了，更加强调从运维流程，运维措施等层面实现完全的自动化，在特定情况下，甚至实现无人干预。
4. AIOps 阶段：自动化运维带来了很大进步，但毕竟系统软件是死的，只能 100% 按照人类制定的流程来运行，不能自主适应，甚至不能处理“相似”的“新”问题。于是 AI 被尝试运用到 IT 运维这个领域，这个阶段应该说才刚刚起步，行业对 AIOps 充满期待。

InfoQ：在运维过程中，有哪些技术痛点适合使用人工智能技术来解决？

张真：我认为有两类痛点可以关注：

1. 时效类问题：运维的本质是提供稳定可靠的服务，而达成这个目标的关键是足够好的时效。时效类的场景还是很多的，例如更短的 MTTR（平均故障恢复时间），特别在服务规模很大的情况下，监控数据的获取 / 集中 / 分析，问题的跟踪 / 定位，恢复的执行规划，如果再加上海量数据和状态频繁变化，AIOps 时效都会远高于有经验的人 + 工具。此外，人类有“工作时间”和“工作活力”的限制，自动化依然离不开人的决策，但智能化可以自主决策，当然目前是在经过检验的人类经验范围的扩展学习。“无中生有”的经验创造依然是个难题。

2. 协作类问题：人类的生产离不开协作。尽管有了自动化运维平台或工具链，运维很多场景还是需要许多人工协作。一个经典的例子：业务发现了问题提交工单给 IT 服务台，IT 服务台根据经验初步判断可能与哪些系统相关，再通知相关团队，相关团队判断是否是自己的问题，如果是自己的问题则考虑的修复方案，然后修复，再反馈给 IT 服务台，通知业务。这是典型的 ITIL 流程。

可是实践表明，科学的流程未必带来理想的结果。因为这个过程中人既是参与者，也是驱动者，人可能懈怠，可能 miss 信息，可能误解，可能情绪化。

另一个例子：自动化运维系统能够通过报警通知系统团队，比业务更快发现问题从而解决问题，甚至直接通过重启等自愈手段自动的解决问题，这是自动化运维带来的价值。但同样也要看到这里的问题判断与恢复规划仍然是人做的，自动化自愈等也只是人把某种情况下的问题识别，判断和处理的经验封装成执行代码而已，如果情况发生改变，系统将“不知所措”；而且系统团队也可能不了解业务影响，还是要找业务团队确认，如果业务团队太多，还是要通过 IT 服务台。那么这里的问题是什么呢？其实是缺少一个“全知”（掌握业务，系统，基础，组织的各种信息）能够客观的，全面的“协调”人，系统，业务的角色。

InfoQ：可否谈谈宜信 AIOps 探索情况？你觉得什么样的团队适合来落地 AIOps？

张真：首先，来谈谈背景和原则。在规划 AIOps 项目之初，我们确立了几点原则。目标是从实际痛点入手，找到适合场景以及正确的问题来试点，而不是“大而全”的 AIOps 解决方案。技术选型上充分利用已经比较成熟的开源 AI 技术，可以做必要改进，但尽量不重复造轮子。充分使用我们现有的 DevOps 工具链，而不是全面推倒重来。

AI 技术还不是“平民技术”，尽管已经发展了很长时间，也有人说我们处于第二次人工智能革命，但它的投入产出比可能并不像使用 Spring、Tomcat、RabbitMQ 这些开源技术栈那样的直接。所以先做“点”的事情，再考虑“面”。而且确实并不是所有场景都适合。前面也提到了，要避免凡事尽 AI。

其实问到什么样的团队来搞 AIOps。这个事与技术选型相关，也与团队定位相关。我们团队的定位是 AI FE，是将 AI 技术工程化的团队，这样的团队应该具备几个特征：

1. 对现有 AI 技术充分了解和掌握。
2. 选择较成熟的开源 AI 技术是必由之路。
3. 对运维领域的技术（比如监控、容器技术、CI/CD、问题诊断等）是清楚的，最好是专家。
4. 对运维领域的场景是熟悉的，明白运维的标准，逻辑，原则。

另外，尽管 AIOps 会带来颠覆性的运维思维和效应，但是否也要对现有系统软件来一把推倒重来呢？这里的考虑是我们的 DevOps 工具链已经比较成熟且运行稳定。同时正如前面提到 AIOps 并非是要取代现有系统，而是赋予现有系统智能。所以与 DevOps 工具链深度集成是必由之路。复用现有 IT 优良资产，最大化资产价值也是必要的考量。

再来谈谈进展。我们目前 AIOps 落地的形态是任务机器人，相关技术也围绕它展开，涉及自然语言处理、搜索技术、知识图谱、监督学习、在线学习、深度学习等。现在处于实验落地阶段，有三个基本场景。

1. DevOps 的一个典型场景：系统上线。上线的几个痛点是时机选择，上线条件判断，部署验证，功能验证。这些部分有的是需要人工判断的，有的通过工具进行，但都是人工驱动的逻辑判断。这是个时效类场景，如何上线更快，更可靠。
2. 另一个场景是运维的日常工作：巡检。尽管监控系统已经可以掌握全方位的数据，比如应用性能，日志，调用链，基础设施等，还是需要有人值守；而当报警出来的时候，往往又滞后了；此外微服务架构下，人工也跟不上规模的增长和状态的快速变化。而任务机器人是可以正真全天候运行的。这也是时效类的场景，对问题的及时发现，甚至预判。特别值的一提的是，这是主动行为，而系统上线是被动触发，这两个场景正好体现了类人化智能的两面。
3. 我们相信运维的价值在于更好的业务价值转化，Better ITOps for Better Business。这个场景是协作类的，涵盖运维和运营。从业务同事来看他们有两个痛点：一方面他们不懂 IT 术语，玩不转运维系统，但也想时刻掌握系统运行状况；部门以及团队在运营过程的信息不对称，不能随时快速同步，造成运营效率下降。任务机器人作为中间协调者，所有人有问题就找它，它会“不厌其烦”的，“孜孜不倦”的予以解答。

如果说我们通过 AIOps 有什么收益，从前面提到的场景的痛点出发，收益是显而易见。在此次大会的分享中会对这三个场景做深度解读。

关于下一步计划，主要会考虑三个方面：

1. 不断提高基本意图理解，系统 API 理解以及个性化交流语义理解的正确率。
2. 加强自主问题诊断分析上的研究和应用，希望从离线方式逐步转变为在线方式。
3. 尝试在更多时效类，协作类场景中应用。

InfoQ：AI 的前提是数据，那你们数据是怎么来的？

张真：关于数据来源，诚如我提到的，深度集成 DevOps 工具链是必由之路（重要的事情说三遍），因为它们就是数据的来源。当然其中监控系统是主要的数据提供者，我们的监控系统代号 UAV（含义：无人机），它提供了几种主要数据：应用画像，服务图谱，应用性能，基础设施性能，日志，调用链，业务指标。

比如通过对应用画像的学习，提取 API 模型，让系统可以使用 API，这是一种新的系统关联方式。又比如通过对服务图谱的学习，让系统掌握应用之间的关联关系，这是自主跨应用问题跟踪和影响分析的基础。还可以通过对应用性能指标的特征提取，找出异常点等。

此外，UAV 会在 9 月份正式开源，与 CNUTCon 2017 大会共襄盛举，它不但能够帮助大家实现三维一体（业务，应用性能，基础）的监控，也能如同我们一样便捷的，集中的获得 AIOps 的机器学习数据来源，欢迎大家的关注。

InfoQ：任务机器人落地过程中，难点是什么？

张真：从我们的实践经验来看，实现任务机器人有三个主要难点：

1. 基本意图理解：就是要理解人想做什么，这是类人交互的体现。目标是能够从自然语言中提取目标信息，并与可识别目标进行匹配，从而理解意图。我们采用了词向量与句型匹配相结合的手段，并对词向量的实现方法做了一些改进，以大幅缩减词向量空间，提高词向量的匹配速率。这个部分会介绍词向量与句型匹配相结合的基本意图理解的原理。
2. 系统 API 理解：除了需要理解人的意图，任务机器人也同样需要像人一样去理解与之交互的系统 API 的含义以及如何使用，而且要自动适应系统 API 的变化，这是自主决策，理解执行的体现。我们采用了“微智能”（自动发现，自我维护，自动适应）与半监督学习类算法相结合的手段，让它能够认识并使用系统 API。这个部分会介绍我们的 API 模型库如何建立以及如何应用。
3. 个性化交流上下文构建及语义理解: FreeStyle 的交流方式是不限制人必须记住某个指令或特定关键词（与 ChatOps 的区别），这是我们的基本目标。

在金融运维 / 运营的垂直领域，尽管比广义领域的词量范围要小，但仍需要解决以下问题：

• 由于每个人的认知差异（不同专业背景，不同的个体说话习惯），所以会用不同的词汇与句式来描述同一个事物。例如 SRE 会说“贷款系统是否健康”？应用研发会说“贷款平台有没有线上 bug”？业务同事会说“城市信贷业务运行得怎样”？实际上都是指贷款系统的服务运行情况，有没有系统或业务异常。
• 提取调用系统 API 的参数。NLP 只是按照人的语言习惯来提取语素信息，而任务机器人还需要从自然语言中，识别要调用的系统以及相关 API 的实际参数。例如说“告诉我电签的运行状况”，从基本意图识别来说“运行状况”指的目标服务是监控平台，“电签”是要提取的监控信息的参数。

这些问题我都会在 CNUTCon 上和大家分享我们的解决方案，当然也欢迎大家一起交流探讨。

InfoQ：在 CNUTCon 全球运维技术大会上，你会为大家重点分享哪些技术点？

张真：本次分享的议题是《AIOps 的核心技术之一：任务机器人如何在金融运维 / 运营中落地》。我将会介绍任务机器人的构建理念是什么，采用什么样的架构原理，然后从难点问题出发剖析实现原理，也会介绍前面提到的典型应用场景以及如何落地。