为什么要做智能运维
百度云智能运维团队在运维工具和平台研发方向历史悠久,支撑了全百度数十万规模的服务器上的运维服务,所提供的服务包括服务管理、资源定位、监控、部署、分布式任务调度等等。最近几年,团队着力于发展智能化运维能力以及 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,概莫能外。
作者介绍:
运小艺,百度云智能运维架构研发负责人,2010 年加入百度,先后负责百度链接库、百度志愿计算、百度统一资源管理的研发,经历过千亿级网页链接的洗礼,也调度过数十万量级的服务器,热衷于直面架构技术挑战,在分布式计算、分布式资源和任务调度方面经验丰富。2015 年转向运维方向,作为智能运维架构方向的技术负责人,致力于为百度智能运维平台和产品提供高性能、高可用、可扩展的系统架构和基础设施。
本文转载自公众号 AIOps 智能运维(ID:AI_Ops)。
原文链接:
https://mp.weixin.qq.com/s/aVOX97Q6k1W6EyH5PI1XkA
评论