共计 5498 个字符，预计需要花费 14 分钟才能阅读完成。
本文是根据百度云智能运维负责人曲显平 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
