3. 异常分类与恢复需求建模

在自动化实验中，异常并不是一个笼统的“出错”概念。若把所有异常都当作同一种故障处理，恢复策略往往要么过度保守、频繁中断实验，要么过于激进、掩盖真实问题。因此，本节的核心任务是把实验中出现的异常拆解为可辨识、可判定的类别，再把每一类异常转化为明确的恢复需求，使恢复动作有依据、有边界、有验收标准。

一、为什么需要分类体系

自动化实验通常由实验编排器、被测设备、仪器、通信链路、数据采集与存储、计算资源等多个环节组成。不同环节的异常，其表现、影响范围和可恢复性差异很大。例如，设备掉电与一次网络抖动都可能表现为“数据缺失”，但前者需要重新初始化设备并重跑当前用例，后者可能只需重连并补采一个采样窗口。如果不加区分，恢复逻辑就无法选择正确的动作。

分类体系的价值在于三点：第一，把模糊的“异常”变成可观测的特征组合，例如错误码、超时、心跳丢失、数据校验失败、资源占用率等；第二，为每类异常指定恢复目标，是恢复到异常前状态、跳过当前步骤，还是终止实验并保留现场；第三，为恢复动作定义成功判据，避免“执行了恢复动作”被误认为“恢复成功”。

二、五类典型异常及其判定特征

结合自动化实验的常见场景，可将异常划分为设备故障、通信中断、数据污染、资源死锁和逻辑错误五类。它们并非互斥，实际排障中常出现组合，但分类时仍应以“主导原因”为准，避免恢复动作互相冲突。

• 设备故障：仪器或被测设备无法响应、返回错误状态、自检失败、输出超限。典型特征包括设备状态字异常、命令超时、读数恒定不变或明显越界。恢复需求通常是设备复位、重新初始化、重新建立安全输出，并决定是否重跑当前用例。
• 通信中断：链路断开、丢包、握手失败、协议解析错误。典型特征是心跳丢失、重传次数超限、连接句柄失效。恢复需求是重连、重建会话、校验链路质量，并判断断连期间的数据是否需要补采。
• 数据污染：采集数据出现错位、重复、缺失、时间戳乱序或数值超出物理合理范围。典型特征是校验和不匹配、采样间隔异常、同一时刻多条记录。恢复需求是隔离污染数据、标记数据质量、必要时重采或从备份恢复。
• 资源死锁：多个任务互相等待对方持有的资源，导致实验停滞。典型特征是任务长时间处于等待状态、资源占用率居高不下、无新日志产生。恢复需求是识别死锁环、释放或抢占资源、设置超时与重试上限。
• 逻辑错误：实验流程、参数计算或状态机判断出现错误，导致结果不符合预期但系统并未崩溃。典型特征是流程跳转异常、参数组合非法、结果与预期偏差大。恢复需求是回滚到最近检查点、修正参数或流程分支，并记录逻辑错误上下文。

三、从分类到恢复需求的转化方法

分类本身不是目的，关键是把每一类异常转化为可执行的恢复需求。转化过程可以按“识别—定级—定目标—定动作—定判据”五步展开，但不必机械套用，实际建模时可根据实验特点调整粒度。

第一步是识别。为每类异常定义可观测的触发条件，例如设备故障可定义为“连续3次命令超时且状态字bit5置位”；通信中断可定义为“心跳间隔超过2秒且重传次数大于5”；数据污染可定义为“校验和不匹配或采样间隔偏离标称值超过20%”。这些条件应尽量量化，避免“感觉不对”这类主观判断。

第二步是定级。根据异常对实验目标的影响程度，划分为轻微、中等、严重三级。轻微异常可自动恢复并继续；中等异常需暂停当前用例、恢复后重跑；严重异常应终止实验、保留现场并告警。定级直接影响恢复动作的激进程度。

第三步是定目标。恢复目标要明确是“回到异常前状态”“跳过当前步骤”还是“安全终止”。例如资源死锁通常以“释放资源并继续”为目标，而设备严重故障可能以“安全停机并保留现场”为目标。

第四步是定动作。动作应具体到可执行的命令或操作序列，例如“发送*RST复位指令→等待5秒→查询*IDN?确认设备在线→重新加载配置”。避免使用“进行恢复”这类模糊表述。

第五步是定判据。每个恢复动作后都要有明确的成功判据，例如“设备自检返回0”“心跳连续3次正常”“数据校验通过且时间戳单调递增”。只有判据满足，才认为恢复完成，否则进入升级处理。

四、恢复需求建模示例

下面以“通信中断”为例，给出一个可参考的恢复需求建模片段。假设实验平台通过TCP与数据采集器通信，采样周期为100ms，心跳周期为1s，允许的最大断连窗口为500ms。

异常类别：通信中断
触发条件：心跳丢失 ≥ 2次 或 重传次数 ≥ 5
影响等级：中等
恢复目标：重建链路并补采断连窗口数据
恢复动作：
  1. 关闭旧socket，释放端口
  2. 以指数退避重连，首次等待200ms，最大等待2s
  3. 重连成功后发送握手帧，校验协议版本
  4. 查询采集器缓存，获取断连期间的时间戳区间
  5. 若缓存完整，补采并合并；若缓存缺失，标记该区间为无效
成功判据：
  - 心跳连续3次正常
  - 补采数据时间戳连续，无重复
  - 丢包率 ≤ 1%
升级条件：重连3次失败 → 转设备故障处理

这个示例体现了分类到需求的完整转化：触发条件可观测，恢复动作可执行，成功判据可验证，升级路径明确。实际建模时，可把五类异常都按类似结构整理成恢复需求表，作为实验编排器异常处理模块的输入。

五、常见误区与检查要点

在实际建模中，容易出现几类问题。一是分类过粗，把设备故障和通信中断混为一谈，导致恢复动作互相干扰；二是恢复目标不明确，只写“恢复通信”，没有说明恢复到什么程度；三是缺少成功判据，恢复动作执行后无法判断是否真正恢复；四是忽略升级路径，重试多次失败后没有后续处理，导致实验卡死。

检查恢复需求是否合格，可以问四个问题：触发条件是否可观测、可量化？恢复动作是否具体到命令或操作序列？成功判据是否可验证？失败后是否有升级或终止路径？四个问题都能明确回答，恢复需求才具备可执行性。

此外，还需注意异常之间的耦合。例如通信中断可能导致数据污染，资源死锁可能引发设备超时。建模时应定义主导异常的判定优先级，避免多个恢复动作同时触发。一般建议按“设备故障 > 通信中断 > 资源死锁 > 数据污染 > 逻辑错误”的顺序判定，先处理底层可用性问题，再处理数据与逻辑问题。

完成分类与需求建模后，下一步就是把这些需求落到实验编排器的异常处理状态机中，使每一类异常都能被自动识别、自动恢复或自动升级。本节建立的分类体系和恢复需求，正是后续恢复策略设计与验证的基础。