百度云智能运维总监曲先平本文取自百度云智能运维总监曲先平于10月20日在msup、魅族、Flyme、百度云举办的第十三届魅族技术开放日。演讲中分享的内容是有组织的。内容介绍：本文主要从百度运维技术的发展历程、如何做智能运维、故障管理场景、服务咨询场景以及面临的挑战等几个方面介绍了百度云智能运维实践。百度运维技术的三个阶段第一阶段：基础运维平台2008~20122008年，百度运维部门成立之前，没有标准统一的运维平台。比如搜索、广告、贴吧都有自己的运维平台。存在问题：技术和平台能力无法复用，业务需要交互时更加复杂。解决方案：①为帮助业务解决问题，我们整合分散在不同业务中的各种运维平台，形成标准化的运维平台；②拥有统一的运维平台，运维部门的角色分为标准运维工程师和运维平台研发工程师两种。第二阶段：2012年至2014年开放运维平台第一阶段还存在的问题：①个性化需求多，很难在一个统一的平台上全部解决②PaaS出现后，运维平台与PaaS的关系可以解决：①开放运维平台，即所有API。②通过提供标准化的监控数据采集、计算、告警能力，以及最基本的程序分发、数据分发、任务调度能力，解决自身平台的需求。③用PaaS的方式，整合部分研发技术平台和运维技术平台，解决重复造轮子的问题。第三阶段：AIOps阶段2014百度从2014年就开始了智能运维的实践，早期我们通过提升底层大数据平台的能力，提供一些数据分析和挖掘的算法和工具，解决运维问题。运维数据使用不合理，运维劳动效率低下。方法。百度对AIOps的理解2015年AI异常火热，百度也想将其先进的机器学习算法应用到运维领域，所以我们与百度的大数据实验室和深度学习实验室进行了合作。运维研究人员将需求和整理好的数据提交给实验室人员，然后他们会根据数据训练模型，最后提供一些库和方法供业务使用。2016年，Gartner提出了AIOps这个词，也就是我们所说的智能运维，这与百度的做法不谋而合。三大核心内容随着智能运维的发展，百度也以数据、工程和策略为核心内容，系统解决运维行业应用。从数据的角度来说，首先要构建完整的数据仓库，然后再构建运维知识库。知识库是在数据仓库上抽象出来的。从工程角度来说，一方面需要大数据平台和框架来分析数据和训练算法模型；另一方面，运维业务研发人员也开发了一套运维工程化研发框架，解决标准化、可扩展、可复用的问题。这个框架10月份刚刚开源，有兴趣的朋友可以看看。在百度内部，一致的运维“语言”至关重要。我们需要统一不同的工具和平台，形成一致的运维模型。因此，无论是故障感知、故障诊断决策、弹性伸缩决策，还是运维运营执行，这个问题都只能通过统一来解决。一致性不仅是数据和工程的一致性，也是策略本身的一致性。自动驾驶分类在构建整个百度智能运维体系的过程中，我们着重参考了自动驾驶中的分类理论。百度有这么两个部门，一个叫L3，一个叫L4。L3部门专注于辅助驾驶或高度辅助驾驶；L4部门专注于高度全自动驾驶。下图展示了自动驾驶的分类。运维能力分级自动运维能力分级当时，我们团队参考了这个自动驾驶分级，构建了一个自动运维能力分级标准，全方位评价我们的自动化水平。它分为六个能力等级，即手动、工具辅助、部分自动化、条件自动化、高速自动化和全自动化。重点：决策和规划是运维系统做的，不是每个人都有责任：设定优化目标（如可用性、效率、成本等）运维系统负责：根据其对需要处理的需求和解决的问题，以及运维对象的认知（经验），根据目标和状态，自主制定解决方案（规划），及时调整执行计划运维对象在控制执行过程中的反馈。智能运维能力分类在自动化能力分类中，我们还细化了智能运维能力的分类（我们始终认为智能运维是实现全自动化运维的一种手段）。实现智能化能力，重点是解决运维感知和决策过程中劳动效率低、准确性不够的问题。重点：决策和规划是运维系统做的，不是每个人都有责任：设定优化目标（如可用性、效率、成本等）运维系统负责：根据其对需要处理的需求和解决的问题，以及运维对象的认知（经验），根据目标和状态，自主制定解决方案（规划），及时调整执行计划运维对象在控制执行过程中的反馈。如何做运维我们希望每一个运维工具都能像一个小型运维机器人一样解决运维问题。运维工程师需要对每一个运维工具进行抽象，同时像一个标准的框架一样，可以在代码库中克隆，框架代码可以复制。通过感知、决策、执行三个基本核心来编写执行器，然后配置一些具体的任务调度配置或者并发执行配置；每个运维工程师都要实现感知逻辑、决策逻辑和执行逻辑。用运维核心解决可靠性问题。在测试方面，需要建立离线看代码的逻辑来验证。结合这个看代码，抽象出核心的运维故障，然后模拟一些常见的故障。具体情况可以在里面运行；写好一个运维工具或者算法后，需要直接在上面运行，检测出是否有效。故障处理场景百度内部如何解决故障处理场景故障处理场景一般分为四个主要阶段：故障发现、服务停止丢失、服务恢复和故障总结。在服务止损方面，核心是如何让用户察觉不到这个故障。对于运维来说，隔离和降级是比从代码BUG解决问题更多使用的方法。从服务恢复的角度来说，一般是在停止服务或者隔离故障之后。很大程度上需要运维和研发的配合，比如定位代码的BUG，最后决定如何解决线上问题。恢复更像是一种修复解决方案。在百度，大部分故障都可以通过隔离降级来解决，只有非常特殊的情况才会通过程序回滚来恢复。回滚是有风险的，而且效率很低。在解决故障处理场景的整个阶段，每个阶段都可以结合智能运维方式。从服务部署开始、监控添加、故障发现、止损决策、止损操作、根因诊断、恢复操作，自动生成最新报表。将AIOps应用于故障处理的核心基础是全面的覆盖监控。在百度，我们做的最全面的就是云端的监控，所以包括了这四个维度的监控：系统监控、业务监控、内网监控和外网监控。系统监控的主要监控对象是机器/容器和服务的动态内容；业务监控针对业务和用户访问日志等；内网监控针对IDC内网设备和内网链路；业务链路与百度IDC之间的状态。有了全面的监控，才能启动一个业界经常提到的智能运维技术，自动异常检测。典型异常检测场景关于异常检测场景，我举三个典型的例子。第一个是具有周期性波动的数据。上图中的蓝线、绿线和黄线分别代表今天、昨天和上周的时间线。蓝线比较明显，其次是绿线和黄线。它们是相对周期性的，而且特别强劲。这种数据很难用传统的计算方法设置阈值。针对这个场景，我们会使用不同类型的算法来具体解决这个问题。第二个与突变数据有关。变异数据也是一个典型的场景。周期性数据更多的是指日级别和周级别的数据，这个场景更多的是在一定程度上的细节，可以理解为小块数据。放大。三是关心数据是否超出一定的波动范围。这种场景我们很难用普通的监控手段覆盖。在很多情况下，均值或基线不会发生显着变化，但系统现在看起来确实处于非常不同的状态，它可能只是波动得更剧烈，对于这类场景，我们更多的是看波动情况，也就是基线以外的一些特征。今年8月，百度云开源了一款数据标注工具——Curve。我们总觉得算法虽然很重要，但远不如数据本身重要。在做机器学习的时候，数据构建是最需要解决的问题。百度的运维工程师也着力解决数据标准和数据获取的问题。报警风暴如何应对当出现大范围报警时，手机可能会直接被炸掉。异常检测重点解决故障感知问题。当检测到故障时，需要通知运维工程师。首先，进行分步通知，并对告警进行分类。然后对数据进行梳理，对每条数据进行梳理，最后抽象出数据的特征，按照每个维度或者特征进行告警合并。完成前两步后，报警会有一定程度的改善。***需通过数据分析方法或机器学习方法处理。数据的特征已经被抽象出来，所以有很多方法可以解决。第一种方法是传统的数据挖掘，如关联分析。频繁项集挖掘是应用最广泛的方法，它可以有效地组合相似的告警。.第二种方法是机器学习。因为特征抽象的比较早，做分类聚类比较直接。从我们的实践来看，***的效果和两者相差不大，大家可以试试。告警产生后，相当于感知阶段结束，进入故障处理阶段。接下来分享几个百度认为最有效的处理方法。第一种方法是多维定位。这更像是一个业务问题导向。业务有访问日志，日志由不同维度的数据组成。故障可能发生在不同的维度，运维工程师需要通过访问日志的数据进行计算分析，分析出真正影响故障的维度。在此基础上，可以进行可视化。这是一种结合业务特点的可视化方法。如上图所示，这是一个模块拓扑图，有很多圈，也有很多R&D。有各种维度，例如健康和响应时间。像模块响应时间，可能会分为很多类别，很多维度，或者很多模块。最下面的部分是每个不同的模块可能有一些对应的情况。其次，百度现在多采用基于信息熵的维度特征推荐。例如，一个故障问题的指标，一个大的流量下降，可能有不同的维度。运维工程师会对每个维度的子维度数据进行分析，分析下降的程度，以及在当前整体流量中整体下降的不同比例，然后进行排序，得到一些故障率较高的故障影响。维度，帮助工程师尽快定位问题或缩小问题范围。第二种方法是基于服务拓扑或服务关联定位。这是内部故障判断的重要依据和指导。百度运维倾向于将一个问题的分析分为六个维度：①时间维度，缩小时间范围；②网络拓扑模型，缩小空间范围，区分整体和局部故障；③服务管理模型，导出异常集群、实例或机器；④改变关联模型，在线定位程序、配置、数据、运行活动；上图是一个典型的故障诊断框架。我们对故障的分类可能有很多，比如网络故障，细分为交换机故障、链路故障、系统故障、业务问题、操作问题等等，这些都属于假设生成，可能都是交替故障问题。中间有个证据评分，相当于根据之前模型的拓扑关系对不同的故障进行评分，对拓扑关系的线进行加权，然后进行置信度计算和排序，最终给出最佳的决策判断.自愈相关问题故障自愈通过自动化、智能化的故障处理节省人力投入，通过预先设定的处理流程和智能判断策略提高故障处理的可靠性，同时减少故障时间，为业务可用性保驾护航。智能自愈①感知：通过监控系统获取业务运行指标，智能异常检测，多种网络异常事件触发方式②决策：根据不同的感知方式配置不同的决策模型③执行：基于在单机执行上，它提供了分布式处理方式，不仅仅是故障自愈过程中一个工具的执行，还包括调度、伸缩、隔离计划处理，甚至多个不同业务的联动。自愈的核心本身并不是一个自动化的过程，更多的是一个决策过程。举一个单机房故障自愈的典型案例。单机房不仅仅指机房的网络故障，更多的是指故障范围只要限定在一个IDC即可。都可以在一个IDC内解决。基础能力达标后，需要设计故障自愈系统。核心部分是外网流量调度止损决策器和内网流量调度止损决策器。外网比较简单，而内网涉及到一些负载均衡策略、弹性伸缩策略、主备切换策略等。盲测验收***说一下盲测验收。有了故障自愈系统，你怎么证明你的解决方案好用呢？在不通知业务的情况下，配合IDC同事拔网线或造成网络拥堵。只有这样才能执行完整的切换。这可以证明基本能力是否达标。百度单机房故障自愈已覆盖所有核心业务线，自愈时间控制在5分钟以内，对于非数据库依赖型业务，可在10分钟内完成机房级自愈1-2分钟。咨询服务场景服务咨询场景可分为以下三种：①通过聊天窗口（IM软件、浏览器等）实时查询业务状态，用户可以对各种问题进行可视化和追溯；②聊天窗口（IM软件、浏览器等）等实时触发运维操作，运维工程师可以远程上线、启停任务等；③运维操作完成后，当出现状态变化或异常情况时，运维工程师可以主动发送相关通知，或者根据策略自动执行Followup。在百度内部，我们称这种场景为ChatOps：“放松”：分层发布和可用性干预，保证人工干预和等待“快乐”：帮助业务发展，比如提高迭代效率，让运维人员从越来越琐碎、枯燥、体力活、低价值、高事故率的工作实现运维人员的转型和AIOps增值的挑战***说说AIOps的挑战。现有的AIOps技术，如索引异常检测、故障自愈等，更多的是解决数据本身的特性和问题，并没有抽象到服务和程序本身的特性层面。也就是说，我们并没有真正理解和解决问题本身。例如，不同类型的服务产生的故障和表现是不同的。我们希望让更多的数据和扩展业务场景，而不是针对几个横向的场景；在业务运营方面，我们不局限于IDC、操作系统和机器，而是专注于资源和性能优化，运维可以不断扩展。对内，我们可以做系统优化，成本优化；对外，我们可以帮助所有用户优化云服务资源池，让大家更好的节约成本，提升服务能力。以上内容来自曲先平老师的分享。
