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

阅读数:950 2017 年 7 月 30 日

话题:DevOps语言 & 开发架构运维AI

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