AIOps在小红书的探索与实践——故障定位与诊断

1.1 AIOps是什么？ 1.2 AIOps能带来什么？
2.1 行业产品AIOps能力分析 2.2 小红书AIOps现状
3.1 能力框架 3.2 演进策略 3.3 关联团队建设
4.1 问题定义和抽象 4.2 方案设计 4.3 故障定位实现 4.4 业务落地与效果

先聊几句核心判断。小红书在AIOps方向的探索，核心聚焦微服务体系下的故障定位与诊断。说白了，AIOps就是通过机器学习算法吃透运维数据（指标、Trace、日志、变更、告警等），解决传统运维工具解决不了的问题——让运维从工具化走向智能化。在小红书已有的DevOps基础上，通过打通基础数据能力、算法能力和应用场景，再跟IaaS/PaaS层打好配合，逐步在稳定性保障、成本管理和效率提升三个方向上做出实效。

在故障定位这块，我们设计了一套智能根因定位系统：先生成调用拓扑，再采集数据、做异常检测、提取异常拓扑、最后做根因分析。这套智能诊断系统已经覆盖所有业务线近百个核心场景，平均每天触发1000多次诊断，Trace链路场景的故障定位准确率已经达到80%以上。下一步计划继续优化检测能力、加强变更关联、提升根因分析、扩大诊断范围，同时探索智能告警、变更检测、智能客服和容量评估等更多AIOps应用场景。

1.1 AIOps是什么？

AIOps（Artificial Intelligence for IT Operations），简单讲就是基于已有的可观测和运维数据（指标、Trace、变更、日志、告警等），用机器学习算法做数据分析与决策，解决那些靠人定规则搞不定的运维难题。让运维从工具化过渡到智能化。

随着互联网业务急剧膨胀、服务类型越来越复杂，基于人工指定规则的专家系统有点力不从心了。小红书在可观测和运维领域，DevOps工具刚见雏形，同样面临这种困境。

DevOps的出现部分缓解了问题——它强调从价值交付的全局视角，更侧重横向融合与打通。而AIOps是DevOps在运维侧的高阶实现，两者并不冲突。AIOps不依赖人定规则，主张数据驱动，让机器学习算法自动从海量运维数据（包括事件本身和人工处理日志）里不断学习、提炼规则，指挥监测系统采集大脑决策需要的数据，做出分析、决策。

所以说，DevOps水平是AIOps的重要基石。AIOps把AI和研发体系结合起来，需要三方面的知识：

• 行业、业务领域知识：跟业务特点相关的经验积累，熟悉生产实践中的难题
• 运维领域知识：指标监控、异常检测、故障发现、故障止损、成本优化、容量规划、性能调优等
• 算法、机器学习知识：把实际问题转化为算法问题，常用算法包括聚类、决策树、卷积神经网络等

1.2 AIOps能带来什么？

AIOps的终极目标是无人值守——让系统帮我们更好地进行业务持续、高效、高质量的迭代，解放人力。

• 稳定性保障
  ：智能异常检测，监控告警不用再配阈值，逐步自动化；还能做告警收敛，避免告警风暴；故障根因定位，找到问题根源，特定场景下还能自动止损，实现故障自愈。

• 成本管理
  ：容量评估、预测和规划，更合理地利用资源，制定预算和采购计划；更进一步可以动态调度资源，提高利用率。

• 效率提升
  ：变更检查，及时发现变更中的问题和回滚；成熟之后能做到智能变更，大大提升操作变更的质量和效率。

2.1 行业产品AIOps能力分析

（此处保留原文内容，未提供具体分析，故保持原文结构）

2.2 小红书AIOps现状

2022~2023年期间，小红书处于DevOps阶段。可观测领域有服务性能监控、链路追踪、Prometheus指标监控等工具；运维领域有流程平台、预案平台、混沌平台、告警配置、服务树等工具；研发效能领域有发布平台、代码仓库、云效等工具。自动化能力有一定基础，各领域需求都有相应工具承接，工具初步实现了数据化和流程化，但功能完备性和体验还有提升空间，智能化基本处于未开始或刚起步阶段。

3.1 能力框架

为了支撑场景探索，基础数据需要提供Metric时序数据、Trace数据、Log数据、拓扑数据、事件数据以及分析后的知识数据，能快速存储和查询，为上游实时和离线计算提供数据支撑。

算法能力层主要解决三个层面的问题。第一，根据场景提供基础算法支持：异常检测、时序预测、分类、特征提取、因果分析、根因分析等。第二，在基础算法上提供样本管理、流程编排、模型训练、模型评估、参数调优等构建模型的能力。第三，有了模型构建能力之后，根据运维场景和数据，把场景数据化、数据模型化，对故障管理、变更管理、资源管理输出能力。同时与IaaS/PaaS层合作，把我们已有的AIOps能力和经验输出，结合IaaS/PaaS自身的专业领域知识，助力智能化。

算法能力不是独立构建的，而是根据运维场景和需求进行扩展和补充。故障管理中包括故障发现、故障定位、预案推荐、风险巡检、影响分析、相似故障推荐、告警收敛、故障定级、故障自愈、故障预测、告警抑制等场景，会用到异常检测、时序预测、关联分析、根因分析、相似故障分析、日志模式识别、多维指标分析等算法。变更管理中包括变更检测、智能调度、智能变更、自动修复等场景，会用到单/多时序异常检测。资源管理中包括配置推荐、成本优化、容量规划、预算规划、资源调度、性能调优等场景，会用到时序预测、服务画像等。

公司IaaS和PaaS层支撑着所有业务线，各自又包含专业领域知识和经验。要让整个AIOps体系良好运转，必须和IaaS/PaaS层合作，将我们的AIOps能力和经验输出，结合他们的领域知识，助力IaaS/PaaS层智能化，最终达成整个服务生态的智能化。

3.2 演进策略

参照业界在AIOps领域的发展，建议在三个核心方向——稳定性保障、成本管理、效率提升上制定演进策略。

• 稳定性保障：
  算法需要提供异常检测、多维指标分析、相似分析、时序预测、关联挖掘、因果分析、相似故障分析、日志模式识别、异常传播分析、异常聚类、异常节点排序等能力，主要支撑故障管理下的相关运维场景。

• 成本管理：
  算法需要提供时序预测、服务画像、性能调优能力，自动识别服务属于计算密集型、内存密集型还是IO密集型，让预算、采购、交互、计费等环节的管理更精准。

• 效率提升：
  算法需要提供异常检测能力，助力变更管控，做到智能变更、智能调度，甚至自动修复。

三个方向的演进顺序如下：

3.3 关联团队建设

在AIOps团队中，通常按职能划分为三个核心团队：SRE团队、开发工程师团队（专注稳定性保障）和算法工程师团队。这三个团队各司其职，相互配合，缺一不可。

• SRE团队：
  主要职责是从业务的技术运营中提炼需求。开发实施前需要深入考虑需求方案，产品上线后持续对产品数据进行运营分析。

• 开发工程师团队：
  负责平台相关功能和模块的开发，目标是降低用户使用门槛、提高使用效率。根据企业AIOps的成熟度和能力，在运维自动化平台和运维数据平台的开发上会有不同侧重。工程实施中需要考虑系统的健壮性、鲁棒性和扩展性，合理拆分任务以确保落地。

• 算法工程师团队：
  负责理解和梳理SRE的需求，调研业界方案、相关论文和算法，进行尝试和验证，最终输出可落地的算法方案，并持续迭代优化。

三个团队紧密协作，共同推动AIOps的实施和发展，关系如下图所示：

4.1 问题定义和抽象

微服务架构松散耦合、可独立部署、高度可扩展、可维护且易于测试，已经是云原生环境下主流的应用架构。但复杂度提升也是明显的挑战：单个服务可能小而简单，但成百上千个服务组合起来，存在错综复杂的调用关系。一旦某个或某类服务出问题，引发一个或多个链路异常，面对复杂的调用链路，如何快速定位故障节点和原因，一直是业界难题。

复杂场景的调用拓扑包含的服务数甚至超过300个，关系和节点多到无法分辨。再加上每个服务的系统指标、中间件指标、接口指标、变更和告警，信息量巨大，排查非常困难。为了缩小范围、简化问题，我们把故障定位定义为：当某个业务场景出现问题时，基于其调用链路拓扑寻找根因服务节点，并列举可能的根因（包括流量陡增、网络异常、变更、存储、Exception、机器异常等影响业务可用性的问题）。范围限定在指定调用拓扑下且出现可用性问题，策略效果类故障暂不纳入诊断。业务场景的拓扑通过流量入口接口的Trace链路串联得到，目标是对该拓扑进行分析，进行根因节点推荐。

4.2 方案设计

4.2.1 方案调研

近年来学术界关于微服务根因定位的研究层出不穷，如下表所示。

• 基于随机游走：
  关键在于概率转移矩阵的设计，目标是推导真实故障传播路径。缺陷很明显——排序结果对拓扑中心（入度和出度高）的节点权重高，对叶子节点权重低。

• 基于监督学习：
  很难实际落地。一是故障类型太多，根本无法枚举；二是历史故障样本有限，通过故障注入扩充样本会导致类型集中单一，对训练模型不友好。部分故障的注入和演练对基建和业务高可用要求高，基建未成熟前无法演练。

• 基于Trace异常检测：
  需要公司基建完善，监控指标和Trace覆盖度足够高，直接对Trace实时数据进行异常分析成本较高。

可以看出，根因定位是需要强领域知识介入的问题。和学术界单纯依赖Trace、指标或日志中的某一项不同，工业界更多是将指标、日志、Trace和Event结合起来，做异常检测和关联分析，并结合公司自身业务特点和基建架构，加入一些专家规则进行根因推断，具备可解释性和灵活性，方便调整和优化。

4.2.2 定位方案设计

基于调研和对比，考虑小红书的业务特点和架构，我们设计了如下根因定位系统，辅助业务发生故障时快速定位根因。

• 触发渠道：
  核心场景拉起故障、服务诊断、告警诊断、接口诊断——不同渠道差别在于获取的拓扑不同，底层诊断逻辑共享。

• 拓扑生成：
  根据触发信息生成诊断拓扑，对公司RPC、Trace拓扑等底层能力强依赖。

• 数据采集：
  拓扑中节点和边都有指标，节点本身的监控指标（Problem, Middleware, System等）及边的调用指标（QPS、RT、失败率等），节点还能关联告警和变更事件。

• 异常检测：
  对所有节点和边进行异常检测，识别高风险变更（发布变更、配置变更等），检测高等级告警量是否有突增。

• 异常拓扑提取：
  根据异常指标、风险变更、突增告警，对拓扑节点进行状态标记，裁剪正常节点，保留异常拓扑。

• 根因分析：
  先基于RCSF挖掘出异常最集中的区域，进行第一轮TOPN根因排序，再用专家规则调整排序，同时进行网络、流量、影响范围、存储聚合等分析，输出诊断报告。

4.3 故障定位实现

4.3.1 拓扑生成

以核心场景为例，比如点开一篇笔记，会触发一个或多个接口请求。业务将这些高度相关的请求划分到一个分组，定义为核心场景。在高可用平台上，SRE和业务同学已经梳理出上百个核心场景，并监控核心场景指标。核心指标异常产生的告警会自动拉起故障，同时触发故障诊断流程，生成诊断报告并推送到故障群。

核心场景的拓扑强依赖公司Trace（分布式链路追踪）能力。可观测平台提供了Trace能力，并在核心场景大范围覆盖，尤其是社区、电商等业务，服务Trace覆盖率基本90%以上。通过获取多个接口的Trace链路，合并生成服务调用拓扑链路，思路如下图所示：

对于Trace覆盖不全或链路中断的场景，通过高可用平台设置核心服务，自动生成服务的RPC调用拓扑。RPC调用拓扑节点和边规模庞大，部分场景上千节点，其中有些调用和节点并非强依赖，会产生干扰。服务间强弱依赖是业务高保障中不可缺少的元数据，SRE会针对核心场景进行强弱依赖标注、验证和保鲜。针对庞大的RPC拓扑，采用如下过滤裁剪方式确保拓扑节点数<300个：

• 保留所有核心服务
• 保留所有强依赖服务
• 从叶子结点出发，递归剪除未知依赖的节点（节点数<300时停止）
• 从叶子结点出发，递归剪除弱依赖的节点（节点数<300时停止）

4.3.2 数据采集

针对节点和边，需要获取如下数据。指标获取故障拉起时刻近1小时数据，告警和变更获取最近30分钟数据，均采集自可观测平台。

数据采集之前，标准的基础设施体系很重要：监控体系需要完善（metric/trace/log等），服务需要能关联指标数据、变更数据、告警数据，所有数据尽可能关联到公司CMDB中的服务唯一标识。不能关联到服务的变更，尽可能关联到场景或业务线。否则所有非标数据都需要特殊处理，或者无法关联，自动化就无从谈起——自动化的前提一定是标准化。

4.3.3 异常检测

一个场景通常有几百个服务，按指标类型、可用区groupby之后，检测指标数往往是几万条。故障定位过程中的异常检测，目前主要还是短时序异常检测，部分指标会获取同环比数据来降噪。用大量历史数据的监督模型不合适，数据获取和检测耗时都会大增。在采集模块，我们把拓扑节点及边相关的指标划分为几个大类，并设计了各自的检测算法以提升效果。

对于类QPS指标，通常具备趋势，直接用孤立森林算法检测时，在上升期很难识别出异常下跌波动。我们使用MSRA提出的SR-CNN方法，对原始时间序列做频域变换，获得Spectral Residual（SR，谱残差）序列，放大这种波动，再基于孤立森林识别出变点。

4.3.4 异常拓扑生成

对拓扑图中的节点，经过异常检测模块后，划分为三种状态类型，状态定义如下：

对核心链路拓扑的每个节点进行状态判别，之后从叶子结点出发，递归剪枝（剪掉正常节点），直到拓扑节点数量不再变化。剪枝过程示意图如下：

4.3.5 根因分析

根因分析环节，输入是异常拓扑，输出是TOPN根因。先经过RCSF进行初步排序，再通过多场景通用的专家规则进行排序调整，输出最终TOPN根因节点。

RCSF从告警出发，认为挖掘调用链路图上异常最集中的部分可以找到根因。如图所示，从B1和B2节点出发，生成B1或B2到异常节点的调用路径，比如(B1, F1, F4, F6)是一条路径。从路径序列中挖掘频繁项集，通过支持度大小对根因节点排序。

通过RCSF可以很容易找到异常最集中的区域。我们基于上述生成的异常拓扑并结合RCSF的思路实现了一个异常拓扑排序方法，和RCSF有所不同：在生成调用路径序列时，我们使用的是风险/异常节点到任意其他风险/异常节点的路径。

基于RCSF的排序并不总是奏效。根因分析是一个需要强领域知识介入的问题。比如流量上涨导致的容量问题，通常在入口层就能识别；再如单机异常导致的问题，往往需要对指标做下钻分析。因此，我们在RCSF排序的基础上使用一些先验规则进行重排序，以下是常用的通用规则：

• 余弦相似度分析：
  用于检测Exception错误分布是否均匀。如果一个异常不是单机/单机房引发的，其分布应该是均匀的，错误数应该和机房机器数成比例。反之，如果错误数和机器分布不成比例，则提示机房/机器问题。通过计算错误数向量和机器分布向量的余弦相似度可以识别出单机/单机房问题。例如某个Exception有5个可用区的错误数err_cnt=[e1,e2,e3,e4,e5]，各可用区机器数host_cnt=[h1,h2,h3,h4,h5]，计算err_cnt和host_cnt的相似度sim，如果sim小于预设阈值就认为存在单机/单机房问题。特别地，如果是单机问题，host_cnt向量直接定义为[1,1,...,1]，长度是机器数量，err_cnt是各机器的错误数。

• 时间序列离群分析：
  针对系统指标异常。有些单机异常不会在Exception上反映出来，比如单机CPU跑满但没有相关Exception。使用DBSCAN聚类对系统指标进行离群分析，提取单机异常序列。聚类过程中时间序列的距离度量使用DTW（Dynamic Time Warping），通过自适应调整每个类别最小样本数min_samples和可达距离eps，使DBSCAN聚类结果为一类，label为-1的表示离群序列。通过这个算法可以很容易识别出指标S1为离群序列。

生产环境变更是很频繁的，当前接入公司变更事件的平台100+，同一时刻变更多则上百个。根据故障拉起时刻，获取和拓扑节点关联的最近30分钟变更以及全局变更（如实验变更），变更数量通常非常庞大。在众多变更中找到最可能引起故障的变更极具挑战性。由于故障拉起时刻通常有延迟，直接按变更距拉起时刻的远近排序并不合理。在异常检测模块，我们对所有相关指标进行异常检测，检测范围是最近15分钟，然后将异常检测结果数量按时间汇总，寻找异常点数量突增的时刻作为故障时刻，然后对所有关联变更排序，依据就是距离该故障时刻的远近，越靠近的变更越靠前。

4.4 业务落地与效果

4.4.1 产品化和业务落地

经过持续迭代优化，故障定位能力已覆盖公司所有业务线共近百个核心场景。除了核心场景故障诊断，还支持了告警诊断、服务诊断能力，平均每天触发1000多次诊断。

故障定位后生成诊断报告，报告已集成到公司故障响应平台。故障触发后1分钟内，故障群可收到诊断结果消息通知，也可到平台查看详细报告，包含拓扑展示、根因推荐、服务详情三部分。下面通过几个案例的拓扑部分介绍实际落地情况。

• 单POD问题：
  典型单实例异常引发的故障。根因分析结论：存在异常陡增，且集中分布在单个实例。根因节点：08:07 ja va.util.concurrent.RejectedExecutionException异常上涨【分布不均】10.xx.xx.xx(100.0%)

• 单Node问题：
  物理机Node故障，导致该Node上所有Pod异常，影响到多个业务服务。根因分析精准给出异常Node的IP。这种故障影响不一定大，但分散在不同服务，研发通常需要较长时间排查。综合分析：Node异常, IP:【10.xx.xx.xx】受影响服务:xxxxx-service(10.xx.xx.xx),xxxxx-service(10.xx.xx.xx)

• DB异常问题：
  DB异常引发的故障。根因分析结论：服务调用该存储存在异常陡增，多个查询方法均存在异常，多个DB节点异常时进行聚合分析。存储分析：【MySql】异常, 存储节点: process_xxx, process_xxx_xxx, xxx_data_xxx_mysql, xxx_xxx_xxx存在调用异常。

• 网络专线问题：
  网络专线问题导致大量业务服务出现报错和告警。通过对网络质量数据检测分析，根因分析给出结论：当时网络专线存在异常。网络分析：10:04 【xxxx机房】网络异常, xxx机房 | xxx机房 等机房调用【xxx机房】专线均存在丢包率异常。

• 变更导致问题：
  限流操作变更，兼容性问题导致错误限流。根因分析给出结论：对应服务存在失败率等异常上涨，同时存在限流变更操作。根因节点：15:17~16:40, xxx在xx系统对xxxx-xxxx-default进行配置发布。

除此之外，还支持了流量分析、影响范围分析、存储分析、堆栈分析等诊断能力。

4.4.2 衡量指标和结果

在故障定位上，最关心的指标是准确率。学术界通常使用如下公式评估：

AC@K表示给出根因节点个数为k时的准确率。当前选择K为5进行评估，即在列出的TOP5节点中包含根因节点就认为定位准确。以双月为周期复盘，通过不断迭代优化，通过Trace链路进行智能诊断的核心场景中，最近一个双月可用性故障case准确率数据已经达到80%以上。

此外，已经开始对故障定位采纳率进行数据运营——准确率是平台侧复盘标注的结果，采纳率则是研发和SRE侧复盘标注是否认为结果有用。随着TOP5准确率提升，后续会提出更高要求，由推荐TOP5转变为推荐TOP3，最终目标是推荐TOP1。

上文详细阐述了小红书将AIOps应用在故障定位场景中的落地与实践，以及最终效果。基于Trace调用链路的故障定位准确率从最初的40%多提升到近期的80%以上。一年多来，通过对每双月上百个故障的复盘分析，深知故障定位任重道远。当前诊断能力主要聚焦在后端，从端到端来看还有客户端、接入层、存储等其他环节；除了可用性问题，业务效果类、数据类问题的定位和排查也是重灾区。后续在故障定位方向的优化主要从以下几个方面展开：

• 检测能力优化：
  整个诊断过程中，指标异常检测无处不在。需要持续优化，减少噪声干扰；针对不同指标选择合适的历史数据范围和异常检测算法，甚至对数据标注，多算法回归择优。

• 变更关联加强：
  变更仍是导致故障的主要原因。上面拓扑中的节点已做变更关联，但还存在不规范、无法准确关联的情况，甚至有些变更有间接影响。变更关联需要各平台数据规范化以及上报信息规范化，需要持续治理。

• 根因分析能力增强：
  提升Trace覆盖范围和观测能力覆盖，确保出问题的核心节点都在拓扑中并能获取监控数据；抽象提炼更多根因分析场景，选择合适的AIOps算法形成更多诊断组件；利用混沌平台故障注入能力，在迭代优化的同时做故障回归验证，确保定位准确率，不断迭代专家规则。

• 扩大诊断范围：
  除了后端，客户端、接入层、存储都支持根因分析，并将诊断能力接入公司故障诊断过程；平台化并开放AIOps能力，支持客户端、接入层、存储等PaaS/IaaS层的检测和诊断。

• 业务自定义诊断：
  当前已通过定义业务环节和关联核心指标进行自定义诊断，但整体准确率还未及预期。后续会提供更多链路定义和诊断规则定义的能力，让业务研发参与到自定义诊断中，将业务定位逻辑自动化。

• 预案推荐与自愈：
  当前对于单点问题已提供快速解决方案，后续会结合影响范围分析进行业务预案推荐，部分确定场景自动执行，建设自愈能力。

在AIOps领域，除了故障定位的深入探索和落地，目前还在智能告警、变更检测、智能客服、容量评估等领域进行探索和落地。

• 大东
  ：高可用平台研发工程师，当前从事高可用平台AIOps方向的研发工作，在智能告警、根因分析、变更检测、告警中心等领域有研发和落地经验。

• 寒峰
  ：高可用平台研发工程师，当前从事高可用平台AIOps方向的研发工作，在CMDB、智能告警、故障诊断、容量评估、智能客服等领域有研发和落地经验。

• 大原
  ：高可用平台研发工程师，曾负责小红书链路体系的搭建，当前从事高可用平台故障预防和止损的平台研发工作，在预案止损、混沌工程、风险治理等领域有研发和落地经验。