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

未分类

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

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

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