Proctor框架：生产HPC系统半监督性能异常诊断与根因定位实战
半夜两点，值班手机响了，调度器上的消息说某个队列里有作业运行时间已经超过了预设上限的1.8倍。登录集群一看，CPU利用率看起来是满的，内存也没爆，文件系统负载也没有明显的“墙”；但作业就是快不起来。如果你管过大型HPC集群，一定对这种“看起来正常但性能不对”的故障不陌生。这就是生产高性能计算（HPC）系统里最折磨人的一类问题：性能异常，而不是可用性故障——机器没宕、作业没退出，只是效率塌了。
这类问题恰恰是“Proctor: A Semi-Supervised Performance Anomaly Diagnosis Framework for Production HPC Systems”这个项目要解决的。它是一套面向生产HPC系统的半监督性能异常诊断框架，核心目标是：在海量、缺少标注的运行数据中，自动识别出性能异常，并且进一步定位到导致异常的资源维度和时间窗口。换句话说，它不只是喊一句“你的系统慢了”，而是要告诉你“某个作业在哪些节点上、哪个阶段、因为哪类资源争抢而慢了”。
这篇文章我会从设计思路、关键技术、实操细节、部署时踩过的坑几个层面，把这个框架拆开聊透。面向的读者是HPC平台运维、性能工程团队、以及做系统监控算法研发的朋友。你有过集群性能问题排查经历的话，会更容易共鸣；就算你是刚接触性能诊断的新人，跟着这篇文章走一遍，也能理解为什么半监督是生产环境下的务实选择。
1. 项目概述与核心思路拆解
1.1 生产HPC性能异常诊断，到底难在哪里
先说说背景。生产HPC系统和实验室里的测试集群完全不同，开个玩笑说，它像是个24小时不停工的流水线，上面跑着各种五花八门的工作负载：有的是计算密集型的分子动力学模拟，有的是IO密集型的科学数据读写，还有的是通信密集型的MPI并行计算。同一个节点上可能有多个用户作业共存的调度策略，还有各种历史遗留的批处理脚本。
在这种环境里做性能异常诊断，第一个难点是异常的定义。一个作业运行时间比中位数长30%，算不算异常？对于一个跑了两小时的大作业来说可能算，对于一个只跑了两分钟的短作业来说，可能只是正常的调度扰动。性能异常的形态千变万化，没有固定的“标准答案”。
第二个难点是可解释性。在运维侧，你不仅仅要回答“有没有异常”，你还要回答“为什么异常”。如果不清楚根因是CPU频率降频、网络链路拥塞、还是文件系统锁竞争，就算报警了，也没法让用户满意。生产环境里，用户提交一个作业，跑得慢了，他不太会关心一个0.83的异常分数，他关心的是“是不是别的作业偷了我的核”、“是不是磁盘又卡了”。
第三个难点是标注数据极其稀缺。要训练一个排序模型或分类模型，往往需要大量的“正常/异常”标注。但对一个运行中的生产集群来说，除非是已知的事故复盘，否则谁能准确地说某段时间里的所有作业都属于哪一类？我们不可能雇一堆工程师每天盯着监控面板打标签。这就是为什么全监督方案在生产HPC场景里很难落地。
1.2 为什么半监督是这个场景下的务实选择
既然全监督不行，那无监督呢？纯无监督类方法，例如孤立森林或基于自编码器的重建误差，能识别出偏离历史模式的数据点，但它们有个通病：生产负载本身是高度动态的，正常波动范围很大。一个节点上同时跑着两个大数据作业，和空载时的指标分布完全是两回事。纯无监督模型很容易把“合法但少见”的负载状态当成异常，误报率会高到让你怀疑人生。
半监督的思路则聪明得多。它假设你手里可能只有极少量的标注样本，比如某次磁盘故障期间采集到的几个故障样本，某次网络拥塞时的历史数据，甚至是通过故障注入构造出来的样本；还有大量的未标注样本。模型可以利用少量标注来校准“什么是异常”，同时利用大量未标注数据来学习“什么是生产环境的常态”。
这就像带一个新人排查问题：你可能只见过两三次故障现场，但你在正常环境里工作了大半年，你已经知道正常系统长什么样，所以当你碰到一个新情况时，你能迅速判断它不对劲。Proctor的核心哲学就是这个：大量常态数据负责建立“正常感”，少量标注负责定义“异常味”。
1.3 Proctor框架的整体设计目标
在我参与过的同类框架设计里，目标一般可以归纳成三个词：在线、可解释、低开销。Proctor也不例外。
在线，指的是诊断不能只在离线跑完一次性报告就结束，要能够持续从指标流里计算异常分数，并尽量早地发现问题。可解释，指的是最终输出要包含异常时间、异常指标权重、关联的应用作业ID和节点列表，而不是一个孤零零的分数。低开销，指的是采集和推理过程本身不能显著干扰生产作业，采样频率不能太高，模型复杂度不能太离谱。
所以整体架构大致是四层：最底层是监控数据采集层，负责从集群里收集作业信息、节点指标和调度器事件；往上是特征工程层，把原始时序数据切分成作业运行阶段，提取统计特征；中间是异常诊断层，包含半监督模型、滑动窗口打分器和根因定位模块；最顶层是报告服务层，将异常聚合为可阅读的诊断报告，通过运维面板或告警通道推送出去。下面我逐一拆解这些层里的关键选型和实现细节。
2. 核心细节解析与关键技术选型
2.1 特征工程：先搞清楚应该看哪些指标
很多团队做性能异常检测时，巴不得把所有能采到的指标全部塞进模型，这个做法在HPC场景下格外容易踩坑。一是指标维度太高，计算代价大；二是很多指标之间高度相关，冗余信息会稀释有效特征；三是某些指标对作业性能的影响并不是单调的。
理想的起始特征集应该覆盖四类资源维度：计算、内存、网络、存储。具体来说，可以包括节点CPU利用率、平均负载、每时钟周期指令数（IPC）、内存带宽利用率、空闲内存比例、网络流量收发速率、TCP重传率、文件系统读写IOPS、元数据操作速率等。
特别要提一下IPC这个指标。它很容易被忽略，但非常关键。一个CPU利用率接近100%的节点，IPC可能只有0.2，这通常意味着指令流水线在等待缓存命中或内存响应——也就是说，计算单元在“空转”。在HPC环境里，很多并行作业的性能下降恰恰体现在IPC上，而不是CPU利用率上。如果你只看CPU利用率，会得到“忙死了”的错觉。
特征规约方面，不建议直接用秒级原始数据。生产HPC作业运行时间长，直接喂原始时间序列会引入大量噪声；建议以作业为单位，或者以一个作业的某个运行阶段为单位，提取统计特征。比如某个MPI并行作业的每次迭代可以切成一个窗口，统计该窗口内各指标的分位数、均值、标准差、变化趋势。窗口大小需要根据作业类型调整，我习惯用1分钟到5分钟，既能抑制瞬态抖动，又能保留异常发展的时间分辨率。
另外，所有特征在进模型前必须做跨节点的标准化。不同硬件型号的基线性能差异巨大，老节点和新节点的IPC本身就差一个量级。如果直接合并训练，模型会误把新旧节点的配置差异当成异常。处理方式通常是按节点型号分组做z-score归一化，或者至少把节点型号作为分类特征拼进去。
2.2 半监督诊断模型的网络设计思路
Proctor这类半监督框架，比较有代表性的实现方式是“重建模型 + 分类头”的组合。先使用大量未标注样本训练一个自编码器，让模型学会压缩和重建正常样本。因为正常样本占绝大多数，自编码器会倾向于只记住正常模式。到了诊断阶段，如果输入一个异常样本，它的重建误差会显著偏大，这个偏差就是异常分数的一个关键信号。
但仅有重建误差还不够，因为有些罕见的正常负载模式也会导致重建误差偏大。这时，少数标注样本就派上用场：在自编码器编码得到的隐变量之上，再接一个分类头，用少量“已知异常”和“已知正常”的样本去训练，让模型学会校正重建误差产生的偏置。这个策略很实用：自编码器在预训练时对海量无标注数据负责特征对齐，分类头只用几百个甚至几十个标注样本就能生效。
具体操作时，损失函数可以设计成两项之和。第一项是重建损失，用均方误差；第二项是分类损失，用交叉熵。为了控制两者的相对重要性，可以在训练初期把重建损失的权重调高，后面再逐步提高分类损失的权重。一个常见的启发性经验值是重建损失权重0.7、分类损失权重0.3，实际需要根据标注样本的质量调整。如果标注质量差、噪声多，分类损失权重应调得更小，比如0.1，避免过拟合到错误标签。
模型的输入特征维度一般控制在几十到一百多，输出则有两路：一路是重建后的特征序列，一路是“异常/正常”的类别概率。推理阶段，最终得分可以设计为重建误差和分类概率的加权和。比如：
最终异常分数 = α × 重建误差 + β × 异常类别概率
系数α和β在验证集上通过网格搜索确定。我试过的取值区间大概是α在0.4到0.6之间，β在0.4到0.6之间，两者可以不需要和为1，因为最后要统一缩放到[0,1]区间。
2.3 从检测到诊断：根因定位与线索回溯
检测出异常只完成了一半工作，定位根因才考验功力。生产HPC系统的性能异常往往不是从单个节点“均匀”发生的。一个MPI作业可能跑在128个节点上，真正出问题的可能就只在那两三个节点，它们是通信中的慢节点，导致整个作业被拖垮。如果不能精确定位到节点，运维只能盲目地猜测，效率极低。
Proctor的做法是给每个节点、每个作业阶段、每个指标维度单独计算贡献分。你可以把它想象成一个“指标故障树”：从作业整体异常分数出发，逐层分解到作业列表、节点列表、指标列表。当某个作业的最终分数很高时，诊断模块会过滤出该作业对应的所有节点和时序窗口，然后计算每个节点的重建误差和分类概率，再把这些得分反推到各个原始特征维度上。
这里需要引入一个关键概念：维度归因。我的常用做法是在已知异常时间窗口里，把每个特征的重建误差单独挑出来，找误差最大的Top K个特征。举个例子，假设某个作业的异常窗口出现在14:00到14:15，节点的整体重建误差从0.2飙升到0.8，逐特征查看后发现“存储写IOPS”和“元数据操作延迟”两项贡献了70%的误差增量。那我就可以大胆怀疑是文件系统或存储端出现了问题，而不是计算节点本身。
这一层如果做得细致，能给你的运维决策带来巨大价值。你可以直接对一个用户说：“你的作业在节点N1和N2上，于14:00-14:15期间，存储写入时延比正常值高3倍，疑似存储端锁竞争，建议调整写入策略。”这个结论拿出来，用户立刻就知道该怎么配合你排查了。
3. 实操过程与核心环节实现
3.1 训练阶段：如何用少量标注和大量未标注数据构建模型
下面按照一个实际的落地流程来走一遍，假设我们有一个为期一个月的生产监控数据集。数据源是调度器日志和节点性能计数器，存储格式是时间序列数据库。我们计划以作业为单位构造样本。
第一步，数据准备。把一个月内的作业记录拉出来，筛选出运行时间超过10分钟、至少占用了1个完整节点的作业。以每个作业的每个节点组合作为一个基础样本。对于每个样本，提取运行过程的中段（去掉开头和结尾的初始化/清理阶段）若干分钟的指标窗口，计算每个指标的均值、P90分位数和斜率。这样每个样本会得到一个固定长度的特征向量。我用的特征维度是64，这已经能覆盖大部分计算和IO指标。
第二步，正常数据预训练。把样本按时间顺序分成训练集和验证集，注意不要把同一作业的多个节点切到两边，避免数据泄露。选一个输入维度等于特征维度64、中间瓶颈维度16的窄口自编码器，用Adam优化器，初始学习率1e-3，batch size 256，训练50个epoch。训练集上不包含我们准备用作标注的已知异常样本，保证自编码器学到的正常模式不掺毒。
第三步，少量标注数据微调。找过去一个季度内已经复盘过的故障记录，比如某次存储控制器升级引发的IO时延飙升、某次交换机链路拥塞影响通信。把这些故障对应的作业节点样本归为“异常”，再随机选一些运行稳定的作业样本归为“正常”。标注数量不需要多，我实操下来，30到100条异常样本、200到300条正常样本就能让分类头有不错的泛化能力。
注意一点，生产环境的故障记录非常脏，同一个作业可能某一阶段异常、另一阶段正常。你在标注时要精细化到“阶段”，而不是整段标一个标签。如果不好精细化，可以把该样本直接丢弃，宁可少标注，不要胡标注。
第四步，训练分类头。保持自编码器的编码器权重基本冻结，或者只允许非常小的学习率微调，训练一个两层的全连接分类头，输入是16维隐变量，输出是1维的异常概率。训练5到10个epoch，避免分类头过拟合到少量标注样本上。
模型训练完成后，我需要验证阈值。在验证集上计算所有正常样本的异常分数，取P95分位数作为检测阈值。这个阈值不是死的，后面每两周会重新校准一次。
3.2 在线诊断流程：滑动窗口打分与报警
在线推理流程需要设计成流式模式。建议使用滑动窗口，窗口长度和模型训练时的窗口保持一致。这里有个经验值：窗口长度选5分钟，滑动步长选1分钟。也就是说，每个节点每分钟都会用过去5分钟的数据算一次异常分数。这样做的坏处是计算量稍大，但好处是可以更快发现趋势变化，不会因为窗口重叠太多而拖沓。
离线推理倒是无所谓，但在线推理必须要做特征缓存。因为特征工程依赖分位数和窗口聚合，如果每次随机读取历史数据，IO开销会拖死监控服务。建议用内存环形缓冲区，每个节点一个队列，保留最近10分钟原始采样点，到了打分时刻直接从内存取，不查数据库。
在线打分分为两个分支。如果当前异常分数低于阈值，则维持静默状态；如果高于阈值，就会进入细诊断流程：重新计算各节点和特征维度的归因贡献，生成一条包含作业ID、节点列表、指标维度、异常分数、时间窗口的报告。为了避免同一异常反复报警，还要设计一个防抖机制：连续两个窗口的异常分数都超过阈值，才正式发出诊断报告；一旦分数回落到阈值以下，并且持续10分钟，就算作恢复。
3.3 生产部署中的资源开销控制
在HPC生产系统上部署任何额外组件，都必须非常小心性能干扰。采集代理如果每秒钟采样一次全部指标，而且自己还在做复杂的聚合计算，那就会和业务作业抢CPU和内存。我的原则是：采集频率不超过30秒一次，特征聚合放到中心侧完成，节点代理只做轻量级转发。
在推理服务端，不建议直接对每一个节点、每一个作业都执行完整的神经网络推理，因为很多节点其实很健康。我采用的策略是两级检测：先做便宜的三西格玛规则过滤，比如某个节点CPU利用率突然跌破某个下限，同时IPC也下跌，才进入神经网络打分阶段。这样做的原因是，神经网络推理虽然单个样本只需要几毫秒，但乘以数千个节点数后，持续运行的CPU开销也不容小觑。规则过滤可以把90%的正常节点直接过滤掉。
模型服务建议以容器方式部署在管理节点上，设置CPU limit为2核，内存limit为4GB，用Prometheus或类似系统暴露指标。实测下来，对中等规模集群（300到500节点）完全够用。如果集群规模上千节点，则需要使用批处理推理，而不是逐样本推理。
4. 常见问题与排查技巧实录
4.1 误报率居高不下，怎么压下去
半监督模型在生产环境里最容易遇到的问题就是误报率。我遇到过一个典型场景：一批短作业频繁启动，每个作业只有几十秒，它们引发的一过性资源竞争被模型判断为异常。这类误报的来源主要是特征窗口太短或者阈值不够鲁棒。
我的解决方案有两步。第一步，在特征工程里增加作业运行时长和作业类别的特征，让模型学会区分短作业的初始化波动和真正的性能故障。第二步，优化报警判定：由单窗口超阈值，改为连续两个窗口超阈值，同时要求异常分数比正常基线高出至少20%才报警。这个简单的防抖操作能滤掉大量毛刺。
另外，阈值不能设一个固定值就不管。生产负载有日周期和项目周期，建议每周用最近的正常数据重新计算一次P95阈值。你可以写一个定时任务，每周跑一遍验证集上的分数分布，自动调整阈值参数。这比手动改成拍脑袋的值靠谱多了。
4.2 标注样本太少或标签噪声太大，模型学偏了怎么办
如果只有十来个标注样本，直接训练分类头很容易过拟合。一个行之有效的技巧是异常注入。你可以在正常作业的指标上，人为地注入某种故障模式，比如把存储时延特征加上一个偏移，或者在通信指标上模拟丢包抖动，生成合成的“伪异常”样本。这些伪异常虽然不完全代表真实故障，但能让分类头学到“偏离常态就要警惕”的边界，从而提高模型的泛化能力。
我刚才说过，标签噪声比标签不足更危险。你要建立严格的标注流程。我们当时要求每个标注必须附上事件链接和故障根因描述，没有链接的标注不采用。宁可让异常标注少一些，也不能因为错误标注把决策面带偏。
如果发现模型在某个类别的故障上完全失效，比如丢包类异常一个都检不出，先别急着改网络结构。检查一下故障发生时段的原始指标，看看是不是特征提取时把短暂脉冲平均掉了。如果是的话，把特征里增加脉冲峰值特征，比如TCP重传率的P99，往往就能解决。
4.3 训练集与生产环境存在数据漂移，模型越用越不准
生产HPC系统会升级硬件、调整调度策略、引入新类型作业。三个月前训练好的模型，很可能在新的负载形态下产生大量漏报和误报。这就是数据漂移问题。
最简单的应对方案是定期重训。把所有未被标为异常的新数据都当作准正常数据，连同历史标注样本一起重新训练自编码器和分类头。时长建议每个月重训一次，如果集群发生过大规模变更，比如新节点上线或作业调度策略变化，那就要立刻重训。
更高阶的方案是引入域自适应层。比如在新集群或新硬件型号上，只用少量无标注数据来调整BatchNorm层的统计值，冻结其他参数。这个技巧在图像领域已经验证过多次，在系统指标时序特征上同样有效。具体做法是：加载旧模型，用新数据跑几个batch的前向，更新BatchNorm的running mean和running variance，然后继续推理。这个操作简单、见效快，特别适合异构集群场景。
4.4 诊断报告给了，但用户不认，怎么办
最后聊一个容易被纯技术团队忽略的问题：报告的语言。你输出一堆“权重因子”、“重建误差贡献度”，用户看不懂。用户是计算物理学家、流体力学研究者，不是机器学习专家。他们只关心“我的作业为什么变慢了”。
所以报告层面一定要做一次翻译。不要写“文件系统写时延P90由10ms升至35ms，异常贡献度0.42”，而是写“作业的写入阶段比正常情况下慢了3.5倍，推测与该时间段的存储IO拥塞有关，建议将输出目录临时切换到另一存储池”。技术细节保留在附注里，给平台工程师看；主报告要用业务语言。
我在实际使用中还发现，如果能在报警的同时附上一张时间-作业-节点三者的热力图，用户接受度会高得多。一张直观的图胜过一段抽象的描述。
5. 实操心得与后续扩展建议
5.1 落地半监督框架时，我学到的三件事
第一次把这类框架部署到生产环境时，我以为难点在模型调参和算法选型，后来才发现真正的难点在于数据质量。特征工程和数据清洗花的精力，远远超过模型训练。如果你没有可靠的时间序列数据库和作业数据，再好的半监督算法也跑不出效果。所以建议第一步先做数据基座，再谈诊断模型。
第二件让我印象很深的事是：异常分数稳定，但运维同事依然不信任。原因是模型很少给出错误的肯定判断，反而经常沉默，错过真正的故障。后来我们下调了阈值，提高了报警频率，并且加长了防抖窗口，让模型更敏感、更稳定，用户体验才真正好转。宁可多一些可忽略的假报警，也不要漏掉一个让.整个队列停滞的严重问题。
还有一个容易忽视的点：负责开发这个框架的工程师，最好自己也懂一点MPI通信、文件系统协议和调度器原理。如果做算法的人连“Intel ICC编译的二进制在AMD处理器上性能差是正常的”都不知道，模型训练的时候就会把平台差异当故障，让你白费很多精力。跨学科理解和沟通，在这个项目里和模型精度同样重要。
5.2 这个框架可以往哪些方向继续扩展
我们把半监督诊断跑通之后，自然想到了两个拓展方向。
其一是引入更细粒度的时序建模能力。目前我们用的是统计特征，但很多性能异常有时间依赖模式。把特征输入改成一个轻量级的时间序列编码器，比如Transformer或TCN，能让模型学到沿时间轴的变化趋势。同时，无标注数据可以用来做时序预测任务预训练，这和自编码器重建的思路殊途同归。
其二是把异常诊断和作业调度协同起来。既然模型能定位到异常节点，为什么不把它作为调度器的反馈信号呢？当某节点集合的异常分数高到一定程度时，调度器可以把后续作业分配到其他健康节点上，降低作业被干扰的概率。这个方向涉及控制系统和调度策略的改造，短期内难做完美，但值得先在小集群上做实验验证。
玩过HPC运维的朋友应该都知道，性能异常诊断这个领域从来不缺数据，缺的是把数据变成可执行洞察的最后一公里。Proctor这套半监督框架，至少帮我们在那个方向上踩出了一条脚印。
最后再分享一个小技巧：无论模型输出多完整，一定要给它接一个“人工确认”的闭环按钮。当运维工程师确认某条报警确实是故障时，这次确认要立刻转化为新的标注数据，进入下一轮训练。这个看似朴素的机制，能让模型在半年内越用越准。我见过太多团队把模型部署上线以后就只读不写，最后模型退化到被弃用，非常可惜。