算法实验日常巡检的检查顺序
算法训练与推理集群的巡检，先确认任务是否按预期推进，再检查资源、数据和依赖。仅看某一时刻的 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，利用率很低也可能在等待数据；结合吞吐、队列和阶段信息才能判断。把巡检顺序、证据来源和恢复动作写进运行手册，团队才能在异常出现时按同一条路径处理，而不是依靠个人记忆翻日志。
发布新模型或更改数据管线后，增加一段观察期，将新版指标与同类历史任务对比。观察期内发生的异常要与版本变更关联，但不要因为时间相近就判定为同一原因。若需要回滚，先确认检查点、数据版本与下游消费者的兼容性，避免把运行问题变成数据不一致。
巡检任务自身也应受到资源限制。采集频率过高、查询范围过大或全量日志扫描可能影响被监控服务；为任务设置超时、并发与错误告警，失败时说明哪一项没有完成。这样巡检既能提供持续信号，也不会成为集群中的另一类负载。
