百度云智能运维负责人 曲显平

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

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

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

存在的问题：

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

解决方法：

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

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

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

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

①个性化需求很多，统一平台很难全部解决

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

解决方法：

①开放运维平台，即全部API化。

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

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

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

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

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

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

在百度内部，一致的运维“语言”非常关键。我们要统一不同的工具和平台，形成一致的运维模式。所以不管是故障感知、故障诊断决策、弹性伸缩决策还是运维操作和执行，只有统一起来才能解决这个问题。一致不仅是数据一致、工程一致，还需要策略本身的一致性。

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

自动化运维能力分级

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

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

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

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

智能化运维能力分级

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

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

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

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

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

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

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

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

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

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

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

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

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

典型的异常检测场景

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

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

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

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

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

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

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

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

完成前两步之后，报警会有一定改善。最后要用数据分析方法或者机器学习的方法处理。数据的特征已经被抽象化，所以有很多方法可以解决，第一种方法是传统数据挖掘，比如关联分析，频繁项集挖掘是最被广泛使用到的方法，它可以有效将同类报警进行合并。第二种方法是机器学习，因为前面抽象出了特征，那做分类聚类都是比较直接的事情。从我们的实践情况看，最后的效果两者相差不大，大家都可以尝试。

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

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

在这个基础上，可以做可视化。这是一类结合业务特征的可视化方法，如上图，这是一个模块拓扑图，很多圈圈，很多研发，这里有健康度、响应时间等等各种维度的展示。像模块响应时间，又可能会分很多类、很多维度或者很多模块，底下是每一个不同的模块，都可能产生对应的一些情况。

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

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

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

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

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

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

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

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