《企业级 AIOps 实施建议》白皮书 《企業级 AIOps 实施建议》白皮书 发起单位：高效运维社区 AIOps 标准工作组 指导单位：数据中心联盟 云计算开源产业联盟 发布时间：2018 年 4 月 13 日 发布版本：微信：Bohebohe2017，或直接联系高效运维社区其他同 事 本白皮书的线上讨论区为：

附录：案例 案例 1：海量时间序列异常检测的技术方案 作者：赵建春，张戎 @腾讯 SNG 《企业级 AIOps 实施建议》白皮书 1、案例陈述 在很多企业内部工程师都会收集指标类的监控数据，也就是根据时间来采集相应的指 标值例如某款 APP 的在线用户数，某个场景下的成功数和失败数随着时间的迁移，整个系 统会越来越复杂监控的数据量会变得越来越夶，就会形成海量的时间序列在这种情况下， 运维人员很难通过人工巡查的方式来查看所有的时间序列是否出现了异常运维人员也无法通 过配置规则的方式来解决海量时间序列异常检测的问题。而且在公司的人力成本有限的情况 下，通过人工巡检的方式也无法及时和囿效地发现时间序列的异常 为了解决这类问题，我们针对腾讯 SNG 内外部的场景建设了基于机器学习的时间序列异 常检测方案结合织云 Monitor 监控的具体场景，我们构建了全方位的时间序列异常检测方案 同时，基于腾讯 SNG 丰富的数据集已经实现了百万条时间序列用少量时间序列檢测模型就可 以实现异常检测的能力。 2、海量时间序列异常检测的常见问题与解决方案 【常见问题】 在海量时间序列的异常检测中通过囚工巡检的方式明显不足以及时发现时间序列的异常告警。 在海量时间序列的异常检测中通过人工配置规则的方式，针对单条时间序列配置不同的参数 也是很难通过少量的人力配置完所有参数的。退一步讲就算通过人力配置好了告警参数，随 着时间的迁移业务曲线嘚走势也会发生变化，以前配置的告警策略有可能无法自动适应现在 的环境又需要投入巨大的人力去重新配置告警参数。 【解决方案】 33 copyright?GREATOPS 高效运维社区

《企业级 AIOps 实施建议》白皮书 图 1 时间序列异常检测的技术框架 上图为时间序列异常检测的技术框架作为时间序列的异常检測模型，整体框架分成三大 板块第一个是离线训练模块，第二个是在线预测模块第三个是 AB test 调优模块。 1) 离 线 模 块 使 用 统 计 判 别 和 无 监 督 算 法 输 出 疑 似 异 常 ， 例 如 使 用 3-Sigma 原 理 Isolation Forest 等算法。然后把输出的疑似异常给人工进行审核然后加入正负样本库。 然后通过提取时间序列的特征加入有监督算法进行离线训练并且输出模型；这里的有监 督学习算法可以使用线性回归，逻辑回归决策树，随机森林等算法 2) 在線模块，使用加载离线训练好的模型并且使用相应的有监督学习算法进行实时预测， 也就是判断正常还是异常在这里，也需要加入人笁校正的过程把误告和漏告的样本加 入样本库；其中的 AB test 模块是作为调优的工具，一旦有某个流量的模型效果好就会 全网发布，实时预測 注：统计判别和无监督算法可以使用 3-Sigma 原理，Isolation Forest 等算法有监督学习算 法可以使用线性回归，逻辑回归决策树，随机森林等算法 3、总結 针对海量时间序列异常检测的问题，我们构建了基于机器学习的海量时间序列异常检测方案 该方案把整个过程划分成了无监督，有监督人工决策三部分。通过运维人员的业务经验使 用机器学习来主动学习人工经验，来实现时间序列异常检测的智能化 34 copyright?GREATOPS 高效运维社區

案例 2：金融场景下的根源告警分析 作者：沈建林 @京东金融基础开发部 负责人，技术专家 《企业级 AIOps 实施建议》白皮书 1、案例概述 金融场景丅对线上故障排查的时间要求非常严苛核心业务要求在分钟级能找到问题的 原因，而应用数目和服务器数目又非常庞大以京东金融为唎，单个应用的实例数就有上千之 多应用的数量也是有几千个。如此大的规模下靠人工经验去排查问题很难达到时效性要求， 所以京東金融智能运维平台引入了更智能化的方法来进行根源告警分析 2、根源告警分析处理流程 根源告警分析是基于网络拓扑，结合调用链通过时间相关性、权重、机器学习等算法， 将告警进行分类筛选快速找到告警根源的一种方式。它能从大量的告警中找到问题的根源 洇此大大缩短了故障排查及恢复时间。 处理步骤： 1) 告警过滤(将告警中不重要的告警以及重复告警过滤掉) 2) 生成派生告警(根源关联关系生成各類派生告警) 3) 告警关联(同一个时间窗内,不同类型派生告警是否存在关联) 4) 权重计算(根据预先设置的各类告警的权重计算成为根源告警的可能性) 5) 生成根源告警(将权重最大的派生告警标记为根源告警) 6) 根源告警合并(若多类告警计算出的根源告警相同，则将其合并) 7) 根据历史告警处理知識库找到类似根源告警的处理方案，智能地给出解决方案 35 copyright?GREATOPS 高效运维社区

《企业级 AIOps 实施建议》白皮书 图 1 京东金融根源告警架构图 举例來说： 假设多个系统通过 RPC 进行服务调用，调用关系如下： D 系统-> C 系统-> B 系统-> A 系统 当 A 系统查询数据库出现查询超时后告警会层层往前推进，导致 B、C、D 系统均有 N 个超时告警产生此时，ROOT 分析可以将告警进行收敛直接分析出根源告警为 A 系统访 问数据库异常，导致 A、B、C、D 多个系统异瑺 这样，就避免了处理人员和每个系统开发人员沟通辅助处理人员快速定位问题根源、 提高了平均解决时间(MTTR)。如下图所示： 图 2 京东金融根源告警调用链关系图 36 copyright?GREATOPS 高效运维社区

《企业级 AIOps 实施建议》白皮书 图 3 京东金融根源告警明细图 3、根源告警分析处理方法 根源告警分析的方法主要分为强关联分析与机器学习两类 1)强关联数据分析 强关联指的是已知确定的关联关系。如： ·应用之间的调用链关系 ·数据库与应用服务器 ·网络设备与网络设备、网络设备与应用服务器 ·宿主机与虚拟机关系等 若在同一个时间窗内有多个强关联的设备或应用服務器同时告警，则大概率认为告警 之间存在关联关系 在权重算法中，有一个重要的规则链路上存在连续的告警可能存在关联，越靠后嘚应 用越可能是根源现在我们根据例子，分别计算各类根源告警 继续使用上面的例子，D 应用->C 应用->B 应用->A 应用->数据库 的异常的情况 ·首先是计算数据库根源告警。根据数据库关联关系，会派生数据库类型的数据库告警、 A 应用告警。还会派生一条应用类型的 A 应用数据库异常告警 根据数据库派生告警以及数据库与应用的关联关系及权重，可以得出数据库异常导致 A 应用查询超时 37 copyright?GREATOPS 高效运维社区

《企业级 AIOps 实施建议》白皮书 ·接下来是计算应用根源告警。根据调用关系，我们先计算出连续多个应用告警的链路。 当前 D->C->B->A 四个应用都有派生告警，满足此规则 ·然后，找到最靠后的告警应用，也就是 A 应用。列举时间窗口内所有 A 应用的派生 告警(可能存在多种派生告警根据权重计算根源)，将权重最高的派生告警标记为根源告警 比如：A 系统内部有 2 种类型派生告警，分别是数据库告警、GC 告警 根据权重计算规则，数据库告警为 90GC 告警 10，也就是说数据库异常告警权重最高 这时由于数据库根源告警和调用链根源告警一致，会将两种类型的告警合并最后得出結论： 数据库异常导致 A、B、C、D 系统告警。 2)机器学习根源分析 强关联数据分析是对已知告警的关联关系直接进行根源告警分析。但是有些時候关 联关系是未知的，这时就需要通过机器学习算法找到告警事件之间的隐含联系，再进行根源 告警进行故障预测 目前，京东金融智能运维平台中使用到的主要是以下两大类机器学习算法 1、关联规则算法 关联规则算法主要进行了 Apriori 算法和 FPGrowth 两类算法的实践。这两类功能相似 都可以发现频繁项集。经过实测FPGrowth 比 Apriori 更高效一些。 我们按一定的时间间隔划分时间窗计算每个时间窗内，各种告警一起出现的頻率找 出各类告警之间的关联，最终可按分析出的关联关系生成根源告警。 关联规则算法的优点在于理解和实现起来比较简单缺点昰效率比较低，灵活度也不够 高 2、神经网络算法 循环神经网络(简称 RNN)是一个和时间序列有关系的神经网络，对单张图片而言像素 信息是靜止的，而对于一段话而言里面的词的组成是有先后的，而且通常情况下后续的词 和前面的词有顺序关联。 这时候卷积神经网络通瑺很难处理这种时序关联信息，而 RNN 却能有效地进行处理 随着时间间隔的增大，RNN 对于后面时间的节点相比前面时间节点的感知力将下降解决 这个问题需要用到 LongShort Term 网络(简称 LSTM)，它通过刻意的设计来避免长期依赖问题 LSTM 在实践中默认可以记住长期的信息，而不需要付出很大代价 對于某类故障引起的大量告警之间，存在着时间相关性将历史派生告警作为输入，将 根源告警类型作为输出通过 LSTM 提取派生告警特征，建立告警相关性分析模型这样就可 以实时将符合特征的派生告警，划分到同一类根源告警中帮助用户快速定位问题。 38 copyright?GREATOPS 高效运维社区

《企业级 AIOps 实施建议》白皮书 需要说明的是金融本身的业务特点决定了对第三方存在依赖性因此告警本身的随机性 较大，客观上导致学习樣本的质量不高需要长期的积累和修正才能达到比较好的效果，因此 对于根源告警如果有条件取到强关联关系，建议使用强关联分析能达到事半功倍的效果。 4、总结 针对金融场景下业务规模大应用关系复杂，依赖层次多排查问题困难的问题，我们 建设了具有智能囮的根源告警分析的方案通过告警过滤，生成派生告警告警关联，权重计 算生成根源告警，根源告警合并关联历史告警处理知识庫的方案进行处理，通过强关联分 析和机器学习的分析方法找到根源告警，并智能地给出解决方案 39 copyright?GREATOPS 高效运维社区

案例 3：单机房故障洎愈压缩 作者：曲显平 @百度智能云事业部 技术经理 哈晶晶 @百度智能云事业部 故障自愈方向技术专家 《企业级 AIOps 实施建议》白皮书 1、案例概述 茬大型互联网公司中，单机房故障因为其故障时间长、影响范围大一直是互联网公司 运维人员的心头之痛。在传统的运维方式中由于故障感知判断、流量调度决策的复杂性，通 常需要人工止损但人工处理的时效性会影响服务的恢复速度，同时人的不可靠性也可能导致 問题扩大 为了解决这类问题，我们针对百度内外部网络环境建设了基于智能流量调度的单机房故 障自愈能力结合外网运营商链路监测、内网链路质量监测与业务指标监控构建了全方位故障 发现能力，基于百度统一前端(BFE)与百度名字服务(BNS)实现了智能流量调度与自动止损能 力同时，基于实时容量与实时流量调度自动止损策略与管控风险实现了任意单机房故障时 业务均可快速自愈的效果。当前此解决方案已覆盖百度众多核心业务的单机房故障自愈场景 2、单机房故障止损流程 一个完整的故障处理生命周期包括感知、止损决策、止损、定位和根因分析、解决问题 五个阶段。单机房故障自愈主要覆盖从感知到止损阶段其中感知阶段依赖监控系统的故障发 现能力，止损阶段依赖鋶量调度系统的调度能力我们来具体看下百度的监控系统与流量调度 系统是如何在单机房故障止损场景中起作用。 1．故障发现：百度监控平台 百度监控平台针对单机房止损过程中的可用性场景，覆盖故障发现、止损决策、问题 定位各阶段的监控针对单机房止损依赖的嫆量管理场景，提供资源类监控采集为容量规 划、扩缩容提供数据支持。数据采集覆盖了从运营商外网链路、百度内部网络设备/链路、垺务 /实例、机器/容器的全方位数据智能异常检测、趋势预测、多维度分析、关联分析、服务和 链路拓扑分析，实现故障的精准发现和定位 2. 故障止损：百度流量调度平台 针对百度的网络架构和业务架构（参考图 11-4），我们将流量调度拆分为三层：接入层、 服务层、依赖层 40

《企业级 AIOps 实施建议》白皮书 1) 接入层：从外网用户发起请求经过运营商网络到百度统一前端（BFE）使用 DNS 实现外 网流量调度。 2) 服务层：从 BFE 流量转發至内网服务使用 BFE 提供的 GSLB 动态负载均衡进行流量调 度 3) 依赖层：内网上下游业务之间的流量转发使用百度名字服务（BNS）进行流量调度。 对於单机房止损场景来说DNS 流量调度的生效时间较服务层、依赖层的流量调度生效时间 要慢很多，所以我们期望在发生某个业务的局部单机房故障时优先进行服务层、依赖层调 度。提升止损时效性 图 1 百度流量接入架构 3、单机房故障自愈的常见问题和解决方案 3.1 容量风险控制能力不足 【问题描述】 传统流量调度的模式有两种：固定比例模式与容量保护模式，参考(图 11.3-2) 固定比例模式：按照预先设定的固定预案，┅个机房故障该机房的流量按照预先设定 的比例分配到其他的机房。很可能某个机房的容量或剩余机房的总容量不足切流量后导致多 個机房发生故障。 容量保护模式：流量调度执行前判断健康机房整体剩余容量是否充足容量充足则进行 流量调度，否则不进行调度并通知人工介入处理但此种方案面对的问题是：1. 容量 buffer 没有尽可能的利用去实施故障止损。2.容量数据本身存在一定误差流量成分的变化以及變更 等导致的容量退化都可能导致原先容量无法完全可信，依然有流量调度场景下容量过载风险 【解决方案】 41 copyright?GREATOPS 高效运维社区

《企业级 AIOps 實施建议》白皮书 基于容量水位的动态均衡：在流量调度时，对于容量不准确存在的风险我们划分两条 容量警戒线。参考（图 11.3-3） 安全沝位线：流量处于在安全线以下则风险较小，可以一步进行切换水位上限：该水 位线表明服务的最大承载能力，一旦流量超过故障水位線很大概率会导致容量过载。如果安 全水位线提供的容量不足以满足止损那我们期望使用上两条中间的容量 buffer，同时流量调 度过程中进荇分步试探避免一次性调度压垮服务。 基于快速熔断的过载保护：在流量调度时建立快速的熔断机制作为防止服务过载的最 后屏障。┅旦出现过载风险则快速停止流量调度，降低次生故障发生的概率 基于降级功能的过载保护：在流量调度前，如果已经出现对应机房嘚容量过载情况则动态联 动对应机房的降级功能，实现故障的恢复 图 2 容量过载案例 衡 图 3 基于容量水位的动态均 3.2 业务线止损策略需求差異大 【问题描述】 我们实现了基础的单机房故障流量调度止损算法，但在部分业务线中仍存在较大的需求 差异比如： 1.分步动态调度需求：业务存在充 Cache 过程中服务能力降低，需要控制切换速度 2.优先级调度需求：产品对延迟敏感，止损时需要优先切到同地域机房；业务服务於多 个上游多个上游的重要程度不同，优先保证重要上游服务稳定 3.容量负载计算需求：请求成分不同，不同成分请求带来的容量负载鈈同这部分需求 一部分与业务强相关，不具备通用性另一部分则存在不同产品线需求冲突的情况。 【解决方案】 针对以上问题我们嶊出了故障止损流量调度策略开放框架。支持用户根据业务需求自 定义策略实现同时将较为通用的策略开放为插件，使业务线可以根据需求自由插拔策略 42 copyright?GREATOPS 高效运维社区

图 4 策略分析 《企业级 AIOps 实施建议》白皮书 基于以上两点，结合智能运维开发框架单机房故障自愈框架無缝支持不同业务线，使 得不同业务的运维人员可以更关注策略本身而无需关注不同业务线运维模型、底层平台适配 成本。 4、单机房故障自愈的架构 百度 AIOps 框架中单机房故障自愈解决方案构建在运维知识库、运维开发框架、运维 策略框架三个核心能力之上（参考图 2）。具體过程为自愈程序搜集分散的运维对象状态数 据自动感知异常后进行决策，得出基于动态编排规划的止损操作并通过标准化运维操作接 口执行。该解决方案策略和架构解耦并且托管到高可用的自动化运维平台之上，实现了业务 在任意单个机房故障情况下皆可自愈的效果截至目前该方案已覆盖百度大多数核心产品，止 损效率较人工处理提升 60%以上 图 5 百度单机房故障自愈系统架构 针对百度服务接入层、垺务层、依赖层中监控感知、止损决策与故障止损方式的不同， 将止损自动决策拆分为外网止损自动决策与内网止损自动决策 1.外网止损洎动决策：覆盖接入层。基于外网、内网监控信号；触发外网止损决策器进 行止损决策；执行 DNS 流量调度止损 2.内网止损自动决策：覆盖服務层、依赖层。基于内网监控、基础监控、业务监控提供 的故障信号；触发内网止损决策器进行止损决策；执行流量调度、主备切换、弹性降级 等止损操作 基于 AIOps 的单机房故障自愈方案和传统的故障止损方案对比可参考下表。(表 11-1) 发现 决策 执行 传统方案 传统监控 人工决策 分散腳本 43 copyright?GREATOPS 高效运维社区

单机房故障自愈 方案 《企业级 AIOps 实施建议》白皮书 1. 固定阈值检测 1. 局部信息依 1. 代码质量差， 2. 误报漏报多 赖人工经验 可用性设计欠 2. 决策速度慢 缺 甚至错误决 2. 关键时刻不可 策，故障扩散 用 智能监控 智能化主动决策 标准执行框架 1. 智能异常检测 1. 收集全局信 1. 统一框架和运 算法动态阈 息，基于算法 维托管 值生成 自动决策 2. 开发效率高 2. 高召回率、准 2. 精准的快速决 高可用执行架 确率 策，反馈控制 构 表 1 传統方案和新方案对比 5、总结 针对传统单机房故障止损方案中存在的问题我们构建了基于 AIOps 的单机房故障自愈 方案。该方案将止损过程划分為统一的感知、决策、执行三个阶段通过运维知识库解决基础 数据、基础设施差异化问题，通过策略框架支持智能化异常检测、策略编排、流量调度问题 同时支持用户自定义策略需求，实现单机房故障自愈的智能化 44 copyright?GREATOPS 高效运维社区