百度智能运维工程架构

本文做者：AIOps智能运维

背景：为何要作智能运维

 

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

 

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

 

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

 

这就比如从马车到汽车是为了提高运输效率，而到汽车已经接近饱和的时候，咱们又但愿用自动驾驶把驾驶员从开车这项体力劳动中解放出来，不只能够增长运行效率，同时也能够减小交通事故率，这也是咱们对智能运维的诉求。

 

发展：AIOps，从理念到落地

 

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

 

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

 

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

 

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

 

框架：新的运维开发模式

 

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

 

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

 

1工程化

 

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

 

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

 

2组件化

 

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

 

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

 

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

 

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

 

知识库：运维的知识图谱

 

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

 

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

 

因为知识库涉及的存储的内容篇幅太大，而且是相对独立的一块工做，因此这里就再也不展开了。

 

实践：运维机器人

 

单机房故障自愈是2017年咱们完成的重点项目，目标是将单机房范围的故障自愈水平广泛提高到L4级（整个处理过程，包括决策过程基本无人介入）。固然，另外一部分缘由是过去一两年发生的几回业界重大线上事故，咱们但愿能够防微杜渐，进一步提高MTTR水平。

 

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

 

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

 

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

 

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

 

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

 

总结

 

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

 

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

 

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

 

原文连接地址：https://developer.baidu.com/topic/show/290063