解密百度智能运维工程的架构建设

王艺 2018-05-22 18:31:05

作者介绍

王艺,百度云智能运维架构研发负责人。2010年加入百度,先后负责百度链接库、百度志愿计算、百度统一资源管理的研发,经历过千亿级网页链接的洗礼,也调度过数十万量级的服务器,热衷于直面架构技术挑战,在分布式计算、分布式资源和任务调度方面经验丰富。2015年转向运维方向,作为智能运维架构方向的技术负责人,致力于为百度智能运维平台和产品提供高性能、高可用、可扩展的系统架构和基础设施。

 

 

背景:为什么要做智能运维

 

百度云智能运维团队在运维工具和平台研发方向历史悠久,支撑了全百度数十万规模服务器上的运维服务,所提供的服务包括服务管理、资源定位、监控、部署、分布式任务调度等等。最近几年,团队着力于发展智能化运维能力以及AIOps产品化建设。

 

众所周知,百度除了搜索业务之外,还有很多其他的业务线,有像地图、百科、知道、网盘这样的老牌业务,也有诸如像教育、医疗这样的新兴业务,每个业务在规模上、服务架构上都有很大差异。业务本身对稳定性的要求很高,需要保持99.995%的高可用,同时在业务上云的背景下,虚拟化、混合云等都给我们带来了新的挑战。

 

图1:百度运维发展历程

 

百度运维经历了从脚本&工具、基础运维平台、开放可定制运维平台到我们现在的智能运维平台,这样四个阶段的转变。过去运维的核心目标是提升效果,比如持续交付的速度、服务稳定性、运营成本等。经过这么多年的建设,整个运维行业已经非常成熟,而我们所支撑业务规模仍在不断增长,越来越多的运维场景和问题无法用传统方法来解决,而运维效率也难以继续支撑业务规模的快速扩张,所以我们更加关注怎么样解放运维自身的效率,以及解决传统运维方法(人工、自动化)所解决不了的问题。

 

这就好比从马车到汽车是为了提升运输效率,而到汽车已经接近饱和的时候,我们又希望用自动驾驶把驾驶员从开车这项体力劳动中解放出来,不仅可以增加运行效率,同时也可以减少交通事故率,这也是我们对智能运维的诉求。

 

发展:AIOps,从理念到落地

 

2016年Gartner报告中提出了AIOps概念,也就是Algorithmic IT Operations;基于算法的IT运维,主要指用大数据、机器学习驱动自动化、服务台、监控这些场景下的能力提升。

 

我们从2014年开始做智能运维方面的探索,最开始也是集中在监控指标分析、报警分析、故障根因分析、性能和成本分析这些方面,到2016年我们已经完成将AI应用于完整的运维平台研发的论证。在我们语义下的AIOps,目标是将人的知识和运维经验与大数据、机器学习技术相结合,开发成一系列的智能策略,融入到运维系统中。用这样的智能运维系统去完成运维任务,是我们所认为的AIOps,也就是Artificial Intelligence IT Operations。有意思的是,2017年之后的Gartner报告也将AIOps的概念改成了Artificial Intelligence IT Operations。

 

图2:AIOps整体架构

 

我们认为AIOps中有三部分不可或缺,一个是运维开发框架,这个是我们后续智能运维研发的骨架;第二个是运维知识库,这是让骨架能与我们真实线上环境关联起来的关键因素,起到了血肉的作用,让骨架能动起来;而最后一个则是运维策略库,这是运维的大脑,控制着运维平台的行为。

 

使用运维开发框架实现的运维程序,我们称其为运维机器人。运维机器人可以在多种不同的运维场景下提供多样的运维能力,服务不同类型的业务和用户。

 

框架:新的运维开发模式

 

图3:运维开发框架

 

运维开发框架基于这样一个抽象,就是如果我们把线上环境看做一个黑盒服务,那么我们对它的操作无非读写两类。所谓的写也就是操作控制流,是那种要对线上状态做一些改变的操作,我们常说的部署、执行命令,都属于这一类;另一类是读,指的是数据流,也就是要从线上获取状态数据,并进行一些聚合统计之类的处理,我们常说的指标汇聚、异常检测、报警都在这个里面。通过运维知识库,可以在这两种操作的基础上,封装出多种不同的运维机器人,对业务提供高效率、高质量以及高可用方面的能力。

 

根据操作流和数据流的不同,我们把框架分成了两部分,最基础的是运维执行框架,在这之上,加上分布式计算组件的支持,我们还建设了用于运维大数据计算的计算框架。

 
1
工程化

 

运维开发框架给开发者提供一系列的开发套件,除了包含了一系列的基础能力,还包含了一个标准的运维工程研发流程。

 

在过去,运维研发采用简单的开发-使用方式,缺少必要的测试维护。而现在,在代码开发阶段,可以通过执行框架,用统一的操作接口库提升研发效率。在测试阶段,开发套件提供了单测和仿真系统,简化测试环境搭建。在上线后的阶段,通过状态服务和托管系统,可满足在各灾难场景下的运维机器人的自维护。

 
2
组件化

 

运维开发框架通过三种不同的组件功能组合成运维机器人。分别是感知器、决策器和执行器。这三种组件针对各自使用场景,提供了多种架构能力。

 

图4:运维开发框架的组件

 

  • 感知器是运维机器人的眼睛和耳朵,就像人有两个眼睛和两个耳朵一样。运维机器人也可以挂载多个感知器来获取不同事件源的消息,比如监控的指标数据或者是报警事件,变更事件这些,甚至可以是一个定时器。这些消息可以以推拉两种方式被感知器获取到。这些消息也可以做一定的聚合,达到阈值再触发后续处理。

 

  • 决策器是运维机器人的大脑,所以为了保证决策的唯一,机器人有且只能有一个决策器。决策器也是使用者主要要扩展实现的部分。除了常见的逻辑判断规则之外,未来我们还会加入决策树等模型,让运维机器人自主控制决策路径。

     

  • 执行器是运维机器人的手脚,所以同样的,执行器可以并行的执行多个不同的任务。执行器将运维长流程抽象成状态机和工作流两种模式。这样框架就可以记住当前的执行状态,如果运维机器人发生了故障迁移,还可以按照已经执行的状态让长流程断点续起。

 

知识库:运维的知识图谱

 

知识库是智能运维架构中非常重要的一部分:所有要处理的数据都来自知识库,以及所有处理后的数据也都会再进入到知识库中。知识库由三部分组成,分别是元数据、状态数据和事件数据。持续的数据建设,是智能运维建设的关键。

 

图5:运维知识库概览

 

考虑到未来需要对接不同的内部云平台和公有云平台,所以我们的运维数据也需要从底层的多种不同的运维平台中抽取,清洗和做数据的整合。并以尽可能高的时效性提供给平台用户使用。因此我们知识库建设遵照这四个能力指标进行,分别是全、准、新、稳。

 

由于知识库涉及的存储的内容篇幅太大,并且是相对独立的一块工作,所以这里就不再展开了。

 

实践:运维机器人

 

单机房故障自愈是2017年我们完成的重点项目,目标是将单机房范围的故障自愈水平普遍提升到L4级(整个处理过程,包括决策过程基本无人介入)。当然,另一部分原因是过去一两年发生的几次业界重大线上事故,我们希望可以防微杜渐,进一步提升MTTR水平。

 

相比较原有的单机房故障处理方式,在感知、决策、执行三个方面,L4级的单机房故障自愈系统效果显著:

  1. 感知方面,智能异常检测算法替代过去大量误报漏报的阈值检测方法;

  2. 决策方面,具备全局信息、自动决策的算法组件替代了过去“老中医会诊”的人工决策模式;

  3. 执行方面,状态机等执行长流程组件的加入,让执行过程可定位、可复用。

 

目前L4级的单机房故障自愈,已经覆盖百度大多数核心业务线,止损效率可做到分钟级,最快秒级止损,较人工止损效率提升60%-99%。

 

图6:单机房自愈效果

 

图6所示,在过去的一次case中,北京某处机房掉电,受影响业务线2min内即完成止损,对比之前的故障处理方式,止损效率提升非常显著。

 
总结

 

随着AIOps逐渐走向成熟和产品化,必将有越来越多的运维场景被AIOps所变革,而我们百度云智能运维团队,也希望秉承着这个方向,为行业贡献更多的创新理念、技术和产品,欢迎大家一起加入探讨。

 

最后,用一句话来总结下工程架构对于智能运维的意义:

 

框架在手,AI我有:智能时代,框架会越来越重要,从机器学习框架TensorFlow到自动驾驶框架Apollo,概莫能外。

最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告