AIOps 中的四大金刚

标签: dev | 发表时间:2019-04-15 00:00 | 作者:
出处:http://itindex.net/relian

在传统的自动化运维体系中,重复性运维工作的人力成本和效率问题得到了有效解决。但在 复杂场景下的故障处理、变更管理、容量管理、服务资源过程中,仍需要人来掌控决策的过程,这阻碍了运维效率的进一步提升。而AI方法的引入,使得机器能够代替人来做出决策,从而让真正意义上的实现完全自动化成为了可能。

在AIOps的落地实施过程中,最关键的因素还是 ,即AIOps的建设者们。

AIOps作为一个全新的技术发展和应用方向,并不是简单地说具备某一种技能或招募一两个大牛就可以完成的,它需要不同角色、多个团队的配合才可以达成。根据近几年来整个业界对AIOps的理解和实践,AIOps参与角色的划分也越来越清晰。在百度4年的AIOps实践中,我们总结得出了如下四种不可或缺的角色:

  • 运维工程师

  • 运维研发工程师

  • 平台研发工程师

  • 运维AI工程师

可以看到,除了运维AI工程师外,其他角色并不是AIOps产生之后才出现的,他们在传统运维中也发挥了重要作用。我们今天主要想和大家探讨一下,在AIOps时代,他们的职责究竟发生了哪些变化。为了方便大家理解,我们会基于 百度AIOps的实践案例,来进行具体说明。

单机房故障自愈场景

单机房故障自愈是一个典型的AIOps落地项目。该方案主要解决的问题场景如下:某个业务由于网络、设备、变更、程序Bug、容量等原因造成故障,但故障范围仅局限在单个机房或单个Region内部。那么,我们可以基于流量调度等手段,将访问流量调度到非故障机房或Region,实现该类型故障的自动止损。

整个故障自愈过程分为如下几个阶段:

在这个过程中,需要AIOps四种角色分工明确、紧密配合,来完成整个AIOps解决方案的落地实现。在单机房故障自愈场景下,四种角色的关系如下图所示:

运维工程师

在单机房故障自愈项目中,运维工程师基于日常运维工作中所积累的场景、问题和经验,确定以单机房故障止损作为主要需求和突破口,通过定义单机房故障止损的 问题域解决思路以及 风险点,明确AI可以发力的领域。运维工程师的职责主要包括如下几个方面:

在完成问题域的定义后,运维工程师需要跟踪整个单机房故障自愈解决方案的 落地,包括在策略设计前期提供数据标注支持,在中期进行效果的验收,在后期将单机房故障自愈方案实际部署运行到生产环境。

AIOps时代的职责和技能变化

运维工程师承担线上 服务质量的责任,是服务质量的关键保证。在工作过程中,会与研发、产品、运营等各类角色、不同团队进行深度的沟通和协作。

传统运维中,运维工程师的主要职责分为三个方面: 质量、成本、效率

主要包含如下工作内容:

在AIOps落地实施中,运维工程师是处于中心的角色,也赋予了新的职责,他们是AIOps具体实施的 需求提出者成果验收者。具体职责包括:

在AIOps时代,运维工程师一方面需要熟悉运维领域的知识,了解运维的难题和解决思路;另一方面需要了解人工智能和机器学习的思路,能够理解哪些场景问题适合用机器学习方法解决,需要提供怎样的样本和数据,即成为 AI在运维领域落地实施的解决方案专家

运维AI工程师

在单机房故障自愈场景中,运维AI工程师将 机器学习的算法与实际的故障处理业务场景相结合,针对单机房故障场景的风险点,进行策略研发与实验工作。如下图所示:

运维AI工程师分别设计了如下算法策略来满足整个复杂故障场景的自动决策:

  • 异常检测算法:解决故障发现时指标异常判断问题,基于AI方法实现较高的准确率和召回率,作为整个故障自愈的 数据基础

  • 策略编排算法:基于当前线上的实际流量和服务状态,设计 损益计算模型,判断基于何种方式的操作组合或步骤,能够使整个自动止损带来收益最大,风险最小。

  • 流量调度算法:基于线上服务容量与实时流量情况,进行 精确流量比例计算,防御容量不足或不准风险,并实现流量调度收益最大化。

在完成策略设计与研发后,需要根据历史数据进行Case回溯,并进行仿真Case模拟,来验证策略效果,并进行逐步迭代调优,以达到线上运行的准确率和召回率要求。

AIOps时代的职责和技能变化

运维AI工程师是将AI引入运维的 核心角色。他们针对运维数据、运维经验进行理解和梳理,使用机器学习的方法将海量运维数据进行汇总、归纳,使得数据中的价值显现出来。

运维AI工程师首先需要具备AI工程师的技能,需要对数学及机器学习方法有足够的掌握程度,并能应用实践。如下图所示AI工程师技能表:

如单机房故障自愈场景中的介绍,运维AI工程师需要具备机器学习知识并在运维领域落地的能力。运维AI工程师的职责如下:

平台研发工程师

在单机房故障自愈场景中,平台研发工程师需要关注三类平台的建设。如图所示:

  • 基础运维平台:提供单机房故障自愈场景中的 依赖平台,如:监控平台和流量调度平台。在日常运维中提供标准化运维数据获取和运维操作的基础,而在AIOps中,这部分接口需要能够同时支持人工和自动的数据获取和运维操作。

  • 智能运维平台:提供对AI能力的 支持,如:统一的数据服务(运维知识库)、运维开发框架,以及给AI策略实验和运行的运维策略框架等。

  • 故障自愈机器人:针对单个业务场景进行 平台化抽象,使之成为一个基础服务,基于AIOps平台研发和运行。

AIOps时代的职责和技能变化

平台研发工程师负责运维平台及基础组件的研发与建设。

在传统运维场景中,平台研发工程师负责平台、基础组件、类库和工具的研发工作。在针对运维的场景中,会覆盖运维相关的服务管理、监控、变更、流量调度等相关平台。

这部分平台是运维的基础,在AIOps时代仍然需要依赖于这些平台的建设。

同时在AIOps场景中, 数据成为了中心,运维各种状态信息转换为大数据,机器学习则作用在大数据上进行分析。在百度AIOps的实践中,运维开发框架、运维知识库、运维策略框架共同组成了完整的智能运维平台,三大平台的建设和实施离不开大数据、机器学习架构的引入。这就要求平台研发工程师具备大数据、机器学习平台架构师的 多重身份,具备流式计算、分布式存储、机器学习平台、算法策略平台等一系列大数据和机器学习平台架构能力。

运维研发工程师

基于多个业务线场景抽象出的单机房故障自愈解决方案,能够满足大部分场景需求,但并不意味着可以直接提供给各个业务线来使用。原因如下:

  • 策略和参数需要进行调整

流量调度、容灾策略等策略,针对不同的业务线,配置并不相同。例如某些业务对响应时间敏感,跨地域的调度会带来较大的延迟,影响用户体验,这时就需要根据业务情况配置机房之间的跨机房流量调度延迟系数,来实现流量优先调度到延迟系数最低的机房。

  • 通用框架无法满足所有需求

部分业务线需要对原有的策略进行部分重写才能够满足需求。例如,部分业务在流量调度时,需要联动服务降级来满足容量需求,这就需要额外增加服务降级联动的逻辑。

那么,就需要运维研发工程师出手来解决这个问题。根据 业务线的实际情况,对策略和参数进行配置和调优,对通用框架无法满足的需求,进行定制化研发,使得单机房故障自愈方案能够实际应用在不同业务线上。

AIOps时代的职责和技能变化

运维研发工程师负责基于业务线特征的运维研发工作,在传统运维中,是运维自动化的实施者,实现了针对业务场景的自动化运维实施落地。其职责如下:

在AIOps时代,运维研发工程师承担了AIOps智能化运维解决方案在业务线实施落地的职责。他们是AIOps场景的 实践者,将AIOps解决方案与业务架构特征相结合,实现AIOps在业务线的落地。

一方面,他们会与运维工程师紧密配合,对业务问题进行深度分析,理解业务的特点。另一方面,他们与平台研发工程师、AI工程师相配合,基于AIOps解决方案的策略和框架,进行定制化开发,使其适合自身业务线的特征。

总结

本文介绍了运维工程师、运维AI工程师、平台研发工程师、运维研发工程师四种角色在自动化运维时代和AIOps智能化运维时代,其职责和技能的拓展和变化。AIOps技术为运维技术的发展带来了更多的机遇,对于每个参与到AIOps实施的个人或团队也是如此。四种角色既有术业专攻,同时又紧密协作,共同将AI能力引入为运维赋能。那么,你的选择是什么呢?

↓↓↓ 点击"阅读原文" 【了解更多精彩内容】 


相关 [aiops 四大金刚] 推荐:

AIOps 中的四大金刚

- - IT瘾-dev
在传统的自动化运维体系中,重复性运维工作的人力成本和效率问题得到了有效解决. 但在 复杂场景下的故障处理、变更管理、容量管理、服务资源过程中,仍需要人来掌控决策的过程,这阻碍了运维效率的进一步提升. 而AI方法的引入,使得机器能够代替人来做出决策,从而让真正意义上的实现完全自动化成为了可能. 在AIOps的落地实施过程中,最关键的因素还是 人,即AIOps的建设者们.

AIOps 核心技术和算法要点

- - IT瘾-dev
AIOps已经逐渐兴起,AI算法已较为成熟,使之与运维结合到了一起,下面列出AIOps相关技术和算法要点,有空了再展开写,懂大数据和机器学习的基本都知道各个组件及算法的作用. elasticsearch(支持时序). clickhouse(支持时序). -------------推荐阅读------------.

AIOps 需要翻越的「三座大山」

- - OneAPM 博客
最近 AIOps 火热的就像8月里的盛夏,运维圈子里的每一个人都在讨论着 AIOps,仿佛不聊点AIOps的东西,就透着那么out. 原来做运维产品的一众厂商也像打了鸡血似的,纷纷推出花样繁多的AIOps产品,仿佛AIOps是什么传说中的灵丹妙药,一试就灵、包治百病一样. Gartner 更是推波助澜,颇为大胆的预测到2022年,将有超过40%的企业会采用 AIOps 平台技术.

微软亚研院的AIOps底层算法: KPI快速聚类

- - 运维派
智能运维中存在海量时序数据(KPI)需要监控、检测异常、关联, 而AIOps的一个底层算法就是把大规模时序数据快速准确地聚类成有限的若干类别,从而大大降低后续数据分析与挖掘工作的开销.  其应用场景包括自动适配异常检测算法、辅助标注、辅助构建故障传播链等.  本文介绍的案例是由微软亚洲研究院发表在数据库领域顶级会议VLDB 2015的文章《 Yading: Fast Clustering of Large-Scale Time Series Data》.

AIOps在美团的探索与实践——故障发现篇

- - DockOne.io
【编者的话】AIOps,最初的定义是Algorithm IT Operations,是利用运维算法来实现运维的自动化,最终走向无人化运维. 随着技术成熟,逐步确定为Artificial Intelligence for IT Operations——智能运维,将人工智能应用于运维领域,基于已有的运维数据(日志、监控信息、应用信息等),通过机器学习的方式来进一步解决自动化运维无法解决的问题.

在数字化转型中挖掘AIOps的应用潜力

- - 机器之心
「AIOps」是IT的AI增强版,利用AI优化IT运营. 基于IT团队管理开发环境中的数据和信息训练AI,由此重构运营模式. AIOps可以为宕机和IT故障提供敏捷解决方案,从而缓解IT部门面临的问题,并降低解决问题的成本. AIOps平台利用大数据,机器学习和数据分析功能,使用多种数据源和数据收集方法,通过AI信息流监控和自动化服务平台,为决策者提供可行性建议,主动增强IT运营,AIOps的应用优势也正在加速这种技术落地企业.

谷奥: 施大爷称 Google、Apple、Amazon 和 Facebook 是 “新四大金刚”

- Levi - 谷奥聚合——谷奥主站+谷安 aggregator
每个年代都可在技术领域找出四个引领技术和创新的公司,上世纪90年代是微软、Intel、Cisco和Dell,而当今的新“四大金刚”则是Google、Apple、Amazon 和 Facebook──这是施大爷(Eric Schmidt)在接受D9采访的时候总结出来的. 施大爷说这新四大金刚加在一起的市值超过5千亿美元,他们都拥有自己的平台,并都在利用自己的力量杯葛到之前一家独大的微软,而微软却没有驱动起消费的变革(尽管他们在企业市场做的还不错).

Elasticsearch对垒8大竞品技术,孰优孰劣? - 运维 - dbaplus社群:围绕Data、Blockchain、AiOps的企业级专业社群。技术大咖、原创干货,每天精品原创文章推送,每周线上技术分享,每月线下技术沙龙。

- -
Elasticsearch当前热度排名很高. 入行Elastic-Stack技术栈很久很久,为了免于知识匮乏眼光局限,有必要到外面的世界看看,丰富自己的世界观. 本篇内容从Elastic的竞争产品角度分析探讨. 哪些应用场景下使用Elasticsearch最佳. 哪些应用场景下不使用Elasticsearch最好.

Redis高可用详解:持久化技术及方案选择 - Redis - dbaplus社群:围绕Data、Blockchain、AiOps的企业级专业社群。技术大咖、原创干货,每天精品原创文章推送,每周线上技术分享,每月线下技术沙龙。

- -
本文将先说明上述几种技术分别解决了Redis高可用的什么问题,然后详细介绍Redis的持久化技术,主要是RDB和AOF两种持久化方案. 在介绍RDB和AOF方案时,不仅介绍其作用及操作方法,同时还会介绍持久化实现的一些原理细节及需要注意的问题. 最后,介绍在实际使用中持久化方案的选择以及经常遇到的问题等内容.

ES既是搜索引擎又是数据库?真的有那么全能吗? - 更多 - dbaplus社群:围绕Data、Blockchain、AiOps的企业级专业社群。技术大咖、原创干货,每天精品原创文章推送,每周线上技术分享,每月线下技术沙龙。

- -
经常遇到很多朋友询问,如何学好Elasticsearch. 这个问题本质上很不好回答,但我一直又很想好好回答,所以本文就以我个人的经验视角,跟大家探讨一下如何正确的拥抱Elasticsearch. Elasticsearch是什么,不同的人有不同的理解定位,之前写过Elasticsearch对比其它数据产品的文章.