算法实验日常巡检的检查顺序算法训练与推理集群的巡检先确认任务是否按预期推进再检查资源、数据和依赖。仅看某一时刻的 GPU 利用率或日志条数无法说明系统健康指标需要与任务版本、输入分布、并发和时间窗口一起解释。巡检输出应当是排查线索而不是直接替代根因判断。第一层看用户或训练任务的可见结果请求成功率、队列等待、任务进度、检查点完成和结果写入。第二层看服务与资源Pod 重启、节点状态、GPU 显存、CPU 限流、磁盘空间、网络错误和依赖延迟。最后检查配置变化例如镜像、模型、数据版本、调度策略和额度是否在异常前发生过变动。基线必须有上下文固定阈值适合明确的容量边界但对有昼夜周期、训练阶段或批量作业的指标基线需要按工作负载、时段和版本区分。历史数据不足、缺失或来源冲突时系统应标记为“需要检查”而不是宣布正常。统计异常分数也只表示偏离程度不能证明多个指标有因果关系。def classify(value, baseline, observations): if observations MIN_SAMPLES: return unknown if value baseline.upper or value baseline.lower: return review return ok异常发现后先保存关联的时间序列、任务 ID、配置版本与日志摘要。低风险动作可以自动化例如创建工单、提供仪表盘链接或暂停新的试验提交重启节点、清空缓存、改动资源限制等状态变更仍应由明确流程审批。多条相关告警可以分组分组规则却不能掩盖原始严重事件。巡检规则要持续校准每次告警都记录是否有行动价值、最终原因和处理时间。频繁误报的规则需要检查数据质量、标签和阈值漏报则要确认原始指标是否存在、采样是否足够以及通知链路是否可靠。模型或统计方法若参与告警排序也要独立评估其误报、漏报和延迟保留确定性关键告警的直接路径。训练集群还要区分资源繁忙与任务失效。显存很高可能是正常大 batch利用率很低也可能在等待数据结合吞吐、队列和阶段信息才能判断。把巡检顺序、证据来源和恢复动作写进运行手册团队才能在异常出现时按同一条路径处理而不是依靠个人记忆翻日志。发布新模型或更改数据管线后增加一段观察期将新版指标与同类历史任务对比。观察期内发生的异常要与版本变更关联但不要因为时间相近就判定为同一原因。若需要回滚先确认检查点、数据版本与下游消费者的兼容性避免把运行问题变成数据不一致。巡检任务自身也应受到资源限制。采集频率过高、查询范围过大或全量日志扫描可能影响被监控服务为任务设置超时、并发与错误告警失败时说明哪一项没有完成。这样巡检既能提供持续信号也不会成为集群中的另一类负载。