框架在手，AI我有

“

编者按：近日，百度云智能运维架构团队负责人王艺（本文作者）受邀在QCon北京2018全球软件开发大会发表了“百度智能运维的工程架构”的主题演讲，分享了百度云在运维开发方面的历程与实践，以及在智能运维研发方面的探索和成果。他重点介绍了如何将智能运维的理念融入到百度云的运维平台研发中，提升运维效果和效率。与会人员对百度云智能运维的开发框架、知识库、仿真系统等架构组件表现了浓厚的兴趣，反响热烈。

”

本次邀请王艺撰写，从头梳理百度云智能运维所提供的服务、历经阶段；重点谈论百度云在智能运维架构方面的一些经验和落地建议。本文有3500字，建议收藏后阅读。

以下是正文。

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

百度云智能运维团队在运维工具和平台研发方向历史悠久，支撑了全百度数十万规模的服务器上的运维服务，所提供的服务包括服务管理、资源定位、监控、部署、分布式任务调度等等。最近几年，团队着力于发展智能化运维能力以及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：运维开发框架

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

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

a：工程化

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

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

b：组件化

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

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

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

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

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

知识库：运维的知识图谱

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

图5：运维知识库概览

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

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

实践：运维机器人

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

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

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

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

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

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

图6：单机房自愈效果

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

结语

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

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

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

关于作者

王艺，百度云智能运维架构研发负责人。

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