百度云曲显平：AIOps时代下如何用运维数据系统性地解决运维问题？

本文是根据百度云智能运维负责人曲显平10月20日在msup携手魅族、Flyme、百度云主办的第十三期魅族技术开放日《百度云智能运维实践》演讲中的分享内容整理而成。

内容简介：本文主要从百度运维技术的发展历程、如何作智能运维、故障管理场景、服务咨询场景和面对的挑战等几个方面介绍了百度云智能运维实践。

百度运维技术的三个阶段

第一阶段：基础运维平台 2008年~2012年

2008年，在百度运维部创建以前，尚未一个标准而统一的运维平台。例如，搜索、广告、贴吧都有各自的运维平台。

存在的问题：

技术和平台能力没法复用，业务之间须要交互时比较复杂。

解决方法：

①为帮助业务解决问题，咱们把各个分散在不一样业务的运维平台整合起来作成一套标准化运维平台；

②有了统一运维平台后，运维部门内的角色就分为了两个，即标准的运维工程师和运维平台研发工程师。

第二阶段：开放的运维平台 2012年~2014年

第一阶段仍然存在的问题：

①个性化需求不少，统一平台很难所有解决

②PaaS出现以后，运维平台和PaaS的关系

解决方法：

①开放运维平台，即所有API化。

②经过提供标准化的监控数据的采集、计算、报警能力，最基础的程序分发、数据分发、任务调度能力，解决自身平台的需求。

③利用PaaS方法，把一些研发的技术平台和运维技术平台整合在一块儿，解决重复造轮子的问题。

第三阶段：AIOps阶段 2014年开始

百度从2014年就开始了智能运维的实践。最先的时候，咱们更可能是经过完善底层的大数据平台能力，提供一些数据分析和挖掘的算法和工具，解决运维数据没有获得合理运用，运维人工效率低等问题，这是偏大数据的方法。

百度对于AIOps的理解

在2015年，AI变得异常火热，百度也是想将自身先进的机器学习算法应用到运维领域之中，因而咱们和百度的大数据实验室、深度学习实验室进行了合做。运维研究人员把需求和归整好的数据提交给实验室的人员，而后他们会根据数据训练模型，最终提供一些库和方法供业务使用。2016年，Gartner提出了AIOps这个词，也就是咱们说的智能运维，这和百度的实践是不谋而合的。

三个核心内容

随着智能运维的发展，百度也是把数据、工程和策略三个，做为最核心内容来系统地解决运维行业的应用。从数据角度来说，首先要构建一个完整的数据仓库，接着要建设运维知识库。知识库是在数据仓库上抽象进行的。从工程角度，一方面，分析数据和训练算法模型须要大数据平台和框架，另外一方面，运维业务研发人员还作了一套运维工程研发框架，用以解决标准化、可扩展和复用的问题。这个框架十月份刚刚开源，感兴趣的朋友能够看下。

在百度内部，一致的运维“语言”很是关键。咱们要统一不一样的工具和平台，造成一致的运维模式。因此无论是故障感知、故障诊断决策、弹性伸缩决策仍是运维操做和执行，只有统一块儿来才能解决这个问题。一致不只是数据一致、工程一致，还须要策略自己的一致性。

自动驾驶分级

在构建整个百度智能运维体系的过程当中，咱们重点参考了自动驾驶里的分级理论。百度是有这样两个部门的，一个叫L3，一个叫L4。L3部门重点在作相似于辅助驾驶或者高度辅助驾驶；L4部门作的是高度彻底自动驾驶。下图是关于自动驾驶的分级。

运维能力分级

自动化运维能力分级

当时咱们团队参照这个自动驾驶分级，构建出了一个自动化运维能力的分级标准，用以评估咱们各个方向的自动化水平，一共分为六个能力等级，即人工、工具辅助、部分自动化、有条件的自动化、高速自动化和彻底自动化。

关键点：决策规划由运维系统作出，而不是人

人负责：制定优化目标（好比，可用性、效率、成本等）

运维系统负责：根据其对待处理的需求、待解决的问题的理解，以及对运维对象的认知（经验），自主作出解决方案（规划）并在控制执行过程当中根据目标和运维对象的状态反馈来适时调整执行规划。

智能化运维能力分级

在自动化能力分级之中，咱们还细化出了一个智能化运维能力分级（咱们始终认为智能运维是实现彻底自动化运维的一种手段）。实现智能化能力，重点解决的是在运维感知和决策过程当中，人工效率低和准确率不足的问题。

关键点：决策规划由运维系统作出，而不是人

人负责：制定优化目标（好比，可用性、效率、成本等）

运维系统负责：根据其对待处理的需求、待解决的问题的理解，以及对运维对象的认知（经验），自主作出解决方案（规划）并在控制执行过程当中根据目标和运维对象的状态反馈来适时调整执行规划。

如何作运维

咱们但愿每个运维工具都像一个小型的运维机器人同样，解决运维的问题。运维工程师须要把每个运维工具抽象化，同时也要像一个标准框架同样，能够在代码库里克隆，把框架代码复制下来。经过三个基本核心，感知、决策和执行来进行编写执行器，接着能够经过配置实现一些具体任务调度的配置或者并发执行的配置；每个运维工程师要实现感知逻辑、决策逻辑、执行逻辑，利用运维核心解决可靠性的问题。在测试方面，要在线下创建看代码的逻辑去验证。结合这个看代码，把比较核心的运维故障抽象出来，再把一些常见的故障模拟出来，具体的状况能够在这里面运行；写完一个运维工具或者算法，须要直接在上面运行，从而检测出是否有效。

故障处理场景

百度内部如何解决故障处理场景

故障处理场景通常分四个主要阶段：故障发现、服务止损、服务恢复、故障总结。

在服务止损方面，核心是如何让用户感知不到这个故障，对于运维来说，更多用的方法是隔离、降级，而非从代码BUG入手解决的问题。

在服务恢复方面，这个通常是在服务止损或者说故障被隔离以后，很大程度上须要运维和研发共同合做，好比定位代码的BUG，最终要决定如何把线上的问题真正解决掉。恢复，更多用的是修复来解决。在百度，大多数的故障都是能够用隔离和降级解决的，只有那些极特殊的case，才会经过程序回滚来恢复。回滚风险很大，并且效率很低。

在整个解决故障处理场景的阶段，每个阶段均可以结合智能运维的方法。从开始服务部署、监控添加、故障发现、止损决策、止损操做、根因诊断、恢复操做，最后报告自动生成。

把AIOps应用到故障处理最核心的基础是，全面覆盖监控。在百度，作的最全面的是云上的监控，因此包含这四个维度的监控：系统监控、业务监控、内网监控和外网监控。

系统监控主要的监控对象是机器/容器和服务的动态内容；业务监控针对业务和用户的访问日志等；内网监控则针对IDC内网设备和内网链路；外网监控为了保障用户、运营商链路到百度IDC中间的状态。

有了全面的监控以后，才能开始如今业界常提到的一个智能运维技术，自动异常检测。

典型的异常检测场景

有关异常检测场景，我为你们举三个典型的例子，第一个，周期波动的数据。

上图中的蓝、绿、黄三条线分别表明着今天、昨天、上周的时间线，蓝线比较明显，后面还有绿线和黄线。它们相对来讲周期性体现得特别强。这种数据很难用传统的计算方法设置阈值。针对这种场景，咱们会使用不一样类的算法，专门解决这种问题。

第二个，关心突变的数据。

突变的数据也是一个比较典型的场景，周期性数据更多参考的是天级和周级的数据，而这个场景更多说的是某一个细节层面，能够理解为它是对一小块数据的放大。

第三个，关心是否超出了必定波动范围的数据。

这种场景是咱们用普通的监控方法很难覆盖的，不少状况下，其均值或基线不会有特别明显的变化，但系统如今确实出现了很大的不一样状态，可能仅仅是波动更剧烈了，对于这类场景，咱们更多的是去看波动的状况，就是除基线之外的一些特征。

今年八月份，百度云开源了一个数据标注的工具－Curve 。咱们始终以为算法虽然很重要，但远没有数据自己重要。作机器学习时，数据的建设才是最须要花时间解决的问题，百度的运维工程师也是重点在解决数据标准和数据获取的问题。

如何应对报警风暴

当出现大规模报警时，手机可能会直接被打爆。异常检测重点解决的是故障感知的问题。当故障被感知后，须要通知给运维工程师。首先，作逐级通告，对报警进行分级。接着作数据的整理，整理出每个数据，最后抽象化数据的特征，按照每一个维度或特征进行报警的归并。

完成前两步以后，报警会有必定改善。最后要用数据分析方法或者机器学习的方法处理。数据的特征已经被抽象化，因此有不少方法能够解决，第一种方法是传统数据挖掘，好比关联分析，频繁项集挖掘是最被普遍使用到的方法，它能够有效将同类报警进行合并。第二种方法是机器学习，由于前面抽象出了特征，那作分类聚类都是比较直接的事情。从咱们的实践状况看，最后的效果二者相差不大，你们均可以尝试。

报警产生后，就至关于感知阶段结束，以后就到达故障处理阶段。接下来，我分享几个百度内部以为效果最好的处理方法。

第一个方法，多维度定位。这个更多偏业务问题的定位。业务都有访问日志，日志由各个不一样维度的数据组成。一个故障的出现可能有不一样维度，运维工程师须要经过访问日志的数据进行计算分析，分析出真正影响故障的维度。

在这个基础上，能够作可视化。这是一类结合业务特征的可视化方法，如上图，这是一个模块拓扑图，不少圈圈，不少研发，这里有健康度、响应时间等等各类维度的展现。像模块响应时间，又可能会分不少类、不少维度或者不少模块，底下是每个不一样的模块，均可能产生对应的一些状况。

接下来，百度如今大部分在用的是基于信息熵的维度特征推荐。例如，一个出现故障问题的指标，大的流量降低，可能有不一样的维度。运维工程师会对每个维度里的子维度数据进行分析，分析降低的程度，以及对于如今整个流量整体的降低程度的不一样占比，而后作一个排序，就能够获得故障影响较高的某几个维度，从而帮助工程师尽快定位到这个问题或者缩小问题的范围。

第二个方法，基于服务拓扑或者服务关联作定位。这是内部比较重要的故障判断基础和指导意见。百度运维倾向于把一个问题的分析分红六个维度：

①时间维度，缩小时间范围；

②网络拓扑模型，缩小空间范围，区分总体和局部故障；

③服务管理模型，推导异常集群、实例或者机器；

④变动关联模型，定位程序、配置、数据、运营活动上线；

⑤模块关联模型，上下游关联服务的异常传播链；

⑥多维度模型，维度关联层级分析，缩小业务范围。

上图是一类典型的故障诊断框架。咱们可能有不少故障的分类，好比有网络故障，细分一点是有交换机故障、链路故障，可能有系统故障，业务问题、操做问题等各类各样的，都是属于假说生成，可能都是备选故障问题。中间有一个证据评分，至关于基于前面的模型拓扑关系，对不一样的故障作评分，把拓扑关系的线作权重，而后作置信计算和排序，最后给出最优决策判断。

有关自愈的问题

· 故障自愈

经过自动化、智能化处理故障节省人力投入，经过预设定的处理流程和只能化判断策略，提升故障处理可靠性，同时下降故障时间，为业务可用性保驾护航。

· 智能自愈

①感知：经过监控系统获取业务运行指标、智能异常检测、网络异常事件多种触发方式

②决策：根据不一样感知方式能够配置不一样决策模型

③执行：在单机执行基础上，提供集群级别、分布式的处理方式

在执行故障自愈过程当中，并不止是一个工具的执行，而是包括了调度、伸缩、隔离预案处理甚至多个不一样业务的联动。自愈自己的核心并不是自动化过程，更可能是决策的过程。

举一个典型案例叫单机房故障自愈。单机房，不只仅指机房网络故障，更多指的是故障范围只要限定在一个IDC内部，无论这个故障是代码BUG，仍是外面流量接入出了问题，仍是机房整个掉电，只要故障范围是在一个IDC内均可以解决。

基础能力达标后，咱们要设计一个故障自愈系统，核心部分是外网流量调度止损决策器和内网流量调度止损决策器。外网比较简单，而内网则涉及到一些负载均衡策略、弹性伸缩策略、主备切换策略等。

盲测验收

最后讲一下盲测验收。有了故障自愈的系统后，怎么证实你的方案好用呢？在不通知业务的状况下，咱们会和IDC同事进行配合，拔网线或是制造网络拥塞，这时候才能进行完整的切换，从而能够证实基础能力是否达标。

百度如今单机房故障自愈已经覆盖了全部核心业务线，自愈时效控制在5分钟内，而且对于非数据库依赖的业务，能够作到1-2分钟完成机房级自愈。

咨询服务场景

服务咨询的场景可分为如下三种：

①经过聊天窗口（IM软件、浏览器等）实时查询业务状态，用户可视化、可追查各类问题；

②经过聊天窗口（IM软件、浏览器等）实时触发运维操做，运维工程师可远程上线、启停任务等；

③当运维操做完成，出现状态变化或异常等状况时，运维工程师可主动发送相关通知，或按照策略自动进行后续操做。

在百度内部，咱们将这种场景称为ChatOps：

•“放心”：分级发布和可用性干预、保障

•“贴心”：监控、部署一站式集成，信息主动推送和确认

•“省心”：高度自动化，减小人工介入和等待

•“开心”：助力业务发展，如迭代效率提高

•将运维人员从日渐琐碎、枯燥、疲惫、低价值、高事故率的工做中解放出来

•实现运维人员的转型和增值

AIOps的挑战

最后说一下AIOps的挑战。现有的AIOps技术，好比指标异常检测、故障自愈等，更多解决的是数据自己的特征和问题，还没抽象到服务、程序自己的特征这个层次上，也就是说，咱们并无真正地了解和解决问题自己。好比，不一样类的服务所产生的故障和表征是不同的，咱们但愿让数据更多、业务场景可扩展，而非针对几个横向的场景；在业务运营方面，咱们不只仅局限在IDC、操做系统、机器，而是注重资源和性能优化，运维还能够继续拓展。对内，能够作系统优化、成本优化；对外，帮助全部用户作云服务资源池优化，让你们更好的节约成本，提高服务能力。

以上内容来自曲显平老师的分享。

声明：本文是由msup原创，转载请联系 meixu.feng@msup.com.cn