自动化流程卡住或报错时，直接重跑往往只能暂时绕过问题。更有效的做法是先按失败发生的位置分层：触发层、执行层、数据层、人工层，再以流程实例的执行记录为证据逐层核对，把假设和结论分开，最后决定重试、修正数据还是调整规则。
要点总览（TL;DR）
- 先按失败发生的位置分层：触发层、执行层、数据层、人工层，用症状对照表把现象归入其中一层，再界定是单条实例失败还是同类批量失败。
- 四类根因各有可核对的证据：触发失败看触发日志、规则版本与权限；执行超时看步骤耗时、依赖服务与重试记录；状态冲突比对对象当前状态与流程预期；人工中断查待办是否生成及归属。
- 排查从失败实例的执行记录入手，按触发、执行、数据、人工的顺序逐层排除，前一层排除后再进入下一层，假设与结论分开记录。
- 处置按风险从低到高选择：重试适用于瞬时故障，修正数据前先备份留痕，调整规则前确认影响范围，批量修改先小范围验证。
- 修复后重跑失败实例或新建同类实例验证走到预期终态，核对关联对象状态与通知，并把根因分类记入台账用于复发预防。
失败卡在哪个环节：先分清症状与范围
排查的第一步是确定失败发生在哪一层，以及影响范围有多大。流程失败的表现形式不同，对应的排查入口也不同：流程根本没有启动，问题通常在触发层；启动后停在某个步骤，可能是执行层超时或数据层校验未通过；流程长时间没有进展，需要区分是步骤仍在等待外部响应，还是待办已经生成但无人处理。
影响面的判断同样重要。单条实例失败，优先检查这条实例涉及的对象数据和审批人；同类实例批量失败，则要怀疑规则版本变更、触发条件配置错误或某个依赖服务整体不可用。如果失败集中在同一时间段，还应核对当时是否有批量任务排队、系统发布或外部接口波动。
| 症状 | 优先归入的环节 | 初步排查范围 |
|---|---|---|
| 流程未启动，无实例记录 | 触发层 | 事件是否产生、触发条件、发起人权限、流程启用状态 |
| 启动后停在某步骤，无报错 | 执行层或人工层 | 步骤耗时、依赖服务响应、待办是否生成及归属 |
| 步骤明确报错 | 执行层或数据层 | 报错信息、字段校验、对象当前状态 |
| 长时间无进展 | 执行层 | 批量任务排队、重试记录、外部服务可用性 |
| 审批长期挂起 | 人工层 | 审批人是否在岗、是否被退回或转交、待办通知是否送达 |
这张对照表的作用是缩小排查范围，不替代原因分析。把症状归入某一层后，仍需在该层内逐项核对证据，避免看到“审批挂起”就直接认定是审批人拖延，或看到“步骤报错”就认定是规则配置错误。
四类根因的假设与排除证据
每一类根因都可以先列出若干假设，再用可观察的证据逐项排除。排查时建议把假设写在前面、证据记在后面，只有证据成立才把假设升级为结论。以下四类排查顺序可以并行准备，但核对时按触发层、执行层、数据层、人工层依次推进，前一层排除后再进入下一层。
触发失败：事件、条件与权限
触发层的问题表现为流程没有生成实例。常见假设包括：业务事件没有产生，例如表单未提交或状态未变更；触发条件不满足，例如字段值不在规则设定范围内；发起人缺少权限，或流程本身处于停用状态。核对证据时，先看触发日志中是否有对应事件的记录，再比对当前规则版本与预期是否一致，最后确认发起人角色和流程启用状态。触发日志为空通常说明事件未产生，日志有记录但未生成实例则更可能是条件或权限问题。
执行超时：耗时分布与依赖服务
执行层的问题表现为步骤长时间停留或报超时错误。需要区分三种情况：单个步骤本身耗时过长，例如脚本或接口调用缓慢；外部服务无响应，例如依赖的系统返回超时或错误；批量任务集中排队，导致实例等待时间被拉长。核对证据时查看步骤耗时分布，确认慢在哪个节点；检查同一时间段其他实例是否也出现类似延迟；查看重试记录，判断是首次失败还是多次重试后仍未成功。单条实例慢和批量实例同时慢，指向的原因不同。
对象状态冲突：状态、校验与并发
数据层的问题通常表现为步骤报错提示状态不合法或字段校验不通过。常见假设包括：对象当前状态与流程预期状态不一致，例如流程等待“待审核”而对象已被改为“已关闭”；必填字段或格式校验未通过；同一对象被多个流程或多人并发修改，后写入的操作覆盖了前一步的结果。核对证据时，比对对象当前状态与流程定义中的预期状态，查看字段值和校验规则，检查操作记录中是否存在时间接近的多次修改。并发问题往往伴随修改时间集中、操作人不同的特征。
人工处理中断：待办、在岗与流转
人工层的问题表现为流程停在审批或处理节点。需要核对：待办是否已生成并送达正确的人；审批人是否因休假、转岗等原因未处理；任务是否被退回、转交或搁置，导致流程回到前序节点或停留在中间状态。证据来自待办列表、处理记录和流转历史。待办未生成属于系统侧问题，待办已生成但长期未处理则属于人工侧问题，两者的处置方式不同。
| 根因类别 | 原因假设 | 可核对证据 | 排除顺序 |
|---|---|---|---|
| 触发失败 | 事件未产生、条件不满足、权限不足、流程停用 | 触发日志、规则版本、发起人角色、流程启用状态 | 先查事件，再查条件，最后查权限与状态 |
| 执行超时 | 单步骤慢、外部服务不可用、批量排队 | 步骤耗时、依赖服务响应、重试记录、同时间段其他实例 | 先定位慢步骤，再判断是否外部依赖，最后看排队 |
| 对象状态冲突 | 状态不一致、字段校验失败、并发修改 | 对象当前状态、字段值、操作记录与修改时间 | 先比状态，再查字段，最后看并发痕迹 |
| 人工处理中断 | 待办未生成、审批人未处理、被退回或转交 | 待办列表、处理记录、流转历史 | 先确认待办是否存在，再查归属与处理动作 |
需要提醒的是，同一现象可能对应多个假设。例如流程停在审批节点，既可能是待办未生成，也可能是审批人已退回但流程未及时刷新。排查时应以执行记录中的时间点和操作主体为准，逐项排除，不凭印象下结论。
按顺序排查的操作步骤
排查从失败实例的执行记录入手，按以下顺序推进。每一步都有明确的判断依据，前一步排除后再进入下一步，避免在多个方向同时猜测。
- 打开失败实例的执行记录，确认失败步骤与时间点。记录当前实例编号、失败节点、报错信息和发生时间，作为后续核对的基准。若实例根本不存在，直接转入触发层排查。
- 核对触发日志与规则版本，排除触发层问题。确认事件是否产生、触发条件是否满足、流程是否启用、发起人是否具备权限。若触发正常，进入执行层。
- 查看步骤耗时与依赖服务状态，判断是否超时或外部不可用。对比同时间段其他实例的表现，区分单实例慢和批量排队；查看重试记录，确认失败是否可复现。
- 比对对象当前状态与流程预期，识别状态冲突。检查字段校验结果和操作记录中的并发修改痕迹。若状态和字段均正常，进入人工层。
- 检查待办归属与处理记录，确认人工中断。确认待办是否生成、当前归属何人、是否发生退回或转交，以及处理人是否长期未响应。
定位原因后，处置动作按风险从低到高选择。重试适用于瞬时故障，例如外部服务短时不可用或网络抖动，重试前应确认原步骤没有产生部分写入。修正数据适用于状态不一致或字段校验问题，修改前先备份相关对象或保留修改前快照，并记录修改人和修改原因。调整规则适用于触发条件或流程配置错误，调整前确认影响范围，避免修改后导致其他实例行为变化。涉及批量数据修改时，建议先在小范围实例上验证，确认无误后再扩大范围。
在流程记录较为完整的平台上，上述核对可以集中完成。以ONES为例，工作项的状态流转历史和流程执行记录可用于比对对象当前状态与流程预期，待办归属和处理记录可用于判断人工环节是否中断，排查时不必在多个系统之间来回切换。具体呈现方式以实际使用版本为准。
恢复验证与复发预防
修复完成后，先验证流程能否走到预期终态。常用做法是重跑失败实例，或新建一条同类实例走完整流程，确认每个节点按预期流转、审批正常生成并处理、流程最终到达结束状态。重跑前确认原实例的中间数据不会与新实例冲突，必要时先清理或归档失败实例。
流程到达终态后，还需核对关联对象的状态是否与流程结果一致，例如审批通过后对象是否已更新为对应状态；同时确认通知是否送达相关角色，避免流程已结束但相关人员未收到结果。验证通过后，把本次失败的现象、根因分类和处置动作记录到排查台账，便于后续同类问题快速对照。
复发预防可以从三个方向入手：在失败高频的环节补充前置校验，例如在触发前检查必填字段和对象状态；为耗时步骤设置超时告警，为审批节点设置待办提醒和超时升级；定期复盘失败记录，统计各类根因的占比，判断是规则配置问题集中出现，还是某个依赖服务稳定性不足。根因分类记录积累到一定数量后，可以形成团队内部的排查清单，新成员遇到类似现象时按清单逐项核对，缩短定位时间。
常见问题
流程重试后仍然失败，说明什么？
重试后仍失败，通常说明问题不属于瞬时故障。此时应回到执行记录，确认失败是否发生在同一节点、报错信息是否一致：如果每次都在同一步骤报同样的错，更可能是数据层状态冲突或规则配置问题，重试无法绕过；如果失败节点和报错随机变化，则要检查依赖服务的稳定性与批量任务排队情况。重试前还应确认原步骤没有产生部分写入，避免重复执行造成数据重复。
批量实例同时失败，排查顺序要不要调整？
需要调整。批量失败时优先核对共同因素：同一时间段是否有规则版本变更、系统发布或外部接口波动，触发条件是否被统一修改。可以先抽取两到三条失败实例对比执行记录，找出共同失败的节点和时间点，再回到单实例排查路径验证。批量失败不宜逐条重试，应先定位共同原因，避免在问题未解决时反复产生失败记录。
对象状态冲突修复后，如何避免同类问题再次发生？
可以从流程定义和操作规范两方面入手：在流程关键节点前增加状态校验，明确哪些状态下允许进入下一步；对同一对象可能被多个流程或多人修改的场景，约定修改顺序或增加互斥提示。修复完成后，把本次冲突涉及的状态、字段和操作时间记入排查台账，定期统计高频冲突节点，作为规则优化的依据。
审批长期挂起，如何区分是系统问题还是人工问题？
关键看待办是否已生成并送达正确的人。待办列表中没有对应记录，属于系统侧问题，需要检查流程流转配置和通知机制；待办已生成但长期未处理，则属于人工侧问题，需要核对审批人是否在岗、任务是否被退回或转交。两种情况处置方式不同，前者调整配置，后者通过提醒、转交或代理审批推进，不宜直接重跑流程。
没有完整的执行记录时，还能按这个顺序排查吗？
可以，但证据来源需要相应调整。缺少执行记录时，可借助对象操作历史、通知记录、审批流转记录和依赖服务的日志交叉比对，先确定失败的大致时间点和环节，再缩小范围。记录不完整会拉长定位时间，也更容易把假设当成结论，因此排查结论应标注证据来源和不确定程度，并在后续补充流程记录能力，减少同类排查的盲区。
