【重磅】百度智能运维工程架构

作者简介

运小艺    百度云智能运维架构研发负责人

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，概莫能外。

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