BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 郭蕾 关注 9 他的粉丝 发布于 2017年7月31日. 估计阅读时间: 15 分钟 | ArchSummit北京2018 共同探讨机器学习、信息安全、微服务治理的关键点

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT