流程自动化执行日志要能回答四个问题：哪条规则在什么条件下被触发、执行了哪些动作、结果成功还是失败、失败后由谁在什么时限内处理。本文给出一份字段完整、前后自洽的已填写示例，覆盖一次正常执行与一次失败重试，并逐项解释字段取值理由，帮助你把记录结构迁移到自己的规则上。示例中的编号、对象、耗时与错误信息均为演示情景，落地时按团队实际规则和系统字段替换。
要点总览（TL;DR）
- 流程自动化执行日志要能回答四件事：哪条规则在什么条件下触发、执行了哪些动作、结果如何、失败后由谁在什么时限内处理。
- 一份可用的日志包含日志头、动作清单与逐项结果、异常记录、处理与重试记录四部分，成功与失败共用同一套字段结构。
- 规则标识与版本成对记录，触发条件保留原文，动作逐项结果与整体状态分开填写，异常类型与错误信息分列。
- 失败重试要记录从断点继续还是整体重跑、重试次数、重试时间和最终状态，重试后及时回填状态避免日志停留在失败。
- 批量触发、跨系统同步、规则停用、敏感字段等情形需在示例字段外补充汇总、对账、版本快照和脱敏记录。
这份执行日志示例要解决什么问题
这份示例面向规则驱动流程的日常运维与事后复盘。规则驱动指触发条件和动作清单在配置阶段已经确定，运行时按条件判断是否执行，执行过程可以被逐条记录。读者通常是负责维护自动化规则的人、需要排查异常的业务负责人，以及要判断某次数据变化来源的协作方。
一份合格的日志，应当让人在不询问执行人的情况下回答四类问题：
- 触发依据：哪条规则、哪个版本，在什么对象的什么字段满足什么条件时被触发，触发时间是什么。
- 动作结果：规则配置了哪些动作，每个动作是否执行、执行结果如何、各耗时多少。
- 异常归属：失败发生在哪个动作、错误类型和错误信息是什么、影响了哪些对象。
- 后续处理：谁接手处理、处理时限是什么、是否重试、重试结果如何、最终状态是什么。
判断标准可以归纳为一句话：日志要能支撑“查得到、看得懂、追得回、接得住”。查得到指能按规则、对象、时间检索；看得懂指字段含义明确、取值不含糊；追得回指能还原触发时的输入和判断依据；接得住指异常有明确的责任人和处理状态。下面这份示例按这四条标准填写。
完整示例：一条跨对象同步规则的执行日志
示例场景：一条规则负责在需求状态变更为“已评审”时，把需求上的关键字段同步到关联的交付任务，并写入一条关联记录、通知任务负责人。该规则在第一次执行时因目标对象字段校验失败而中断，随后由责任人修正数据并重试成功。以下为演示情景，非真实客户案例。
日志头字段
| 字段 | 示例取值 | 说明 |
|---|---|---|
| 日志编号 | LOG-20250612-0087 | 全局唯一，便于跨系统引用 |
| 规则名称 | 需求评审后同步交付任务 | 与规则配置中的名称一致 |
| 规则版本 | v3 | 记录执行时生效的版本号 |
| 触发对象 | 需求 REQ-1042 | 对象类型加对象标识 |
| 触发条件 | 状态 = 已评审 且 交付任务关联数 ≥ 1 | 记录条件原文，不只记“条件满足” |
| 触发时间 | 2025-06-12 10:14:03 | 精确到秒，统一时区 |
| 触发方式 | 事件触发（状态变更） | 区分事件触发、定时触发、手动触发 |
| 执行总耗时 | 1.8 秒（首次）／1.2 秒（重试） | 首次与重试分别记录 |
动作清单与逐项结果
| 序号 | 动作 | 目标 | 结果 | 耗时 |
|---|---|---|---|---|
| 1 | 读取源对象字段 | REQ-1042 的负责人、优先级、计划完成日 | 成功 | 0.2 秒 |
| 2 | 更新目标对象字段 | 交付任务 TASK-3311 | 失败（首次）／成功（重试） | 0.6 秒／0.4 秒 |
| 3 | 写入关联记录 | 需求与任务的同步记录 | 成功（重试时执行） | 0.3 秒 |
| 4 | 通知责任人 | 任务负责人 | 成功（重试时执行） | 0.5 秒 |
首次执行在动作 2 中断，动作 3 和动作 4 未执行。重试时从动作 2 继续，动作 1 不重复执行，避免重复读取造成状态漂移。这一处理方式需要在规则配置中明确“失败后从断点继续”还是“整体重跑”，日志中应记录实际采用的方式。
异常记录
| 字段 | 示例取值 |
|---|---|
| 异常类型 | 数据校验失败 |
| 错误信息 | 目标字段“计划完成日”为空，不满足必填校验 |
| 失败动作 | 动作 2：更新目标对象字段 |
| 影响范围 | 交付任务 TASK-3311 未更新；关联记录与通知未发出 |
| 是否可自动重试 | 否，需人工修正数据后重试 |
处理与重试记录
| 字段 | 示例取值 |
|---|---|
| 处理人 | 规则维护人（示例中记为“维护人 A”） |
| 处理时限 | 触发后 4 小时内 |
| 处理动作 | 补全 TASK-3311 的计划完成日，发起重试 |
| 重试次数 | 1 次 |
| 重试时间 | 2025-06-12 11:02:37 |
| 最终状态 | 成功 |
| 回滚记录 | 无（动作 2 首次未写入，无需回滚） |
这份日志的完整链路是：触发条件成立 → 动作 1 成功 → 动作 2 校验失败 → 记录异常并通知维护人 → 维护人修正数据 → 重试从动作 2 继续 → 动作 2、3、4 依次成功 → 最终状态置为成功。每个环节都有对应字段，事后可以按日志编号还原全过程。
逐项解释：每个字段为什么这样填
规则标识与版本要成对记录。规则在运行中会被修改，只记名称无法区分“修改前触发”和“修改后触发”。示例中 v3 表示执行时生效的版本，若同一规则在当天升级到 v4，凭版本号就能判断某条日志属于哪一版逻辑，排查时不会把新旧行为混在一起。
触发条件要记录条件原文，而不是只写“条件满足”。条件原文是事后还原判断依据的唯一线索。当有人质疑“为什么这条需求触发了、那条没有”，对照条件原文和触发对象当时的字段值即可回答。若只记布尔结果，条件一旦被修改，历史判断就无法复核。
动作逐项结果与整体状态要分开记录。整体状态只有成功、失败、部分成功几种，但失败往往只发生在某一个动作上。示例中整体状态为失败，动作 1 却是成功，动作 3、4 是未执行。把三者混为一个状态，排查时就无法判断哪些动作需要补做、哪些需要回滚。
异常类型与错误信息要分开填写。异常类型用于分类统计和路由，例如“数据校验失败”通常转给数据责任人，“权限不足”转给管理员，“目标对象不存在”可能需要检查关联关系。错误信息保留系统返回的原文，用于定位具体字段和具体值。两者合并成一段自由文本，既不利于统计，也容易在转述中丢失细节。
处理人与处理时限要写成可核验的取值。处理人记录实际接手的人，处理时限记录团队约定的响应窗口，例如“触发后 4 小时内”。时限的起算点要写清楚，是从触发时间算还是从异常记录时间算。常见填写错误包括：只写“已通知”不写通知对象；只写“处理中”不写时限；重试后不更新最终状态，导致日志长期停留在失败。
| 字段 | 推荐填法 | 常见错误 |
|---|---|---|
| 规则版本 | 执行时生效的版本号 | 只记规则名称，升级后无法区分 |
| 触发条件 | 条件原文加关键字段取值 | 只写“条件满足” |
| 动作结果 | 逐项结果加整体状态 | 只记整体成功或失败 |
| 异常信息 | 类型与原文分列 | 合并为一段描述 |
| 处理状态 | 处理人、时限、最终状态齐全 | 重试后不更新状态 |
从这条示例可以迁移的记录规律
第一条规律是以规则为单位组织日志，而不是以动作流水为单位。一次触发对应一条主日志，动作结果作为主日志下的明细。这样检索时先定位“哪次触发”，再展开“做了哪些动作”，符合排查时的思考顺序。若按动作流水平铺，一次触发会被拆成多条互不关联的记录，反而增加还原成本。
第二条规律是保留触发输入快照。示例中记录了触发对象、触发条件和关键字段取值，这三项构成最小快照。快照不必保存对象全部字段，但应覆盖条件判断所依赖的字段和动作读取的字段。快照的价值在于：对象后续被修改后，仍能回答“当时是什么状态”。
第三条规律是成功与失败使用同一套字段结构。示例中首次执行和重试共用动作清单、结果、耗时、异常、处理等字段，只是取值不同。统一结构让查询和统计可以用同一套条件，也避免失败记录因为字段缺失而无法与成功记录对比。
第四条规律是异常记录与处理闭环成对出现。有异常记录就必须有对应的处理人、处理时限和最终状态；有重试就必须有重试次数、重试时间和重试结果。缺少闭环的日志只能说明“出过问题”，无法说明“问题是否解决”。
第五条规律是约定日志保留周期与查询入口。保留周期按团队复盘和审计需要确定，例如保留 180 天或 1 年，并明确到期后的归档方式。查询入口要支持按规则、对象、时间、最终状态组合检索。这两项属于团队约定，没有统一标准，但需要在规则上线前写进运维说明，避免出问题时才发现日志已过期或查不到。
在异常处理环节，可以把失败日志对应的处理动作落到工作项上：由维护人创建或关联一个处理工作项，记录处理人、时限和重试结果，处理完成后回填日志的最终状态。规则本身的变更说明、版本记录和运维约定可以放在团队文档中，与日志编号互相引用。ONES 支持工作项与文档的记录方式，适合承载这类“异常—处理—回填”的闭环，具体字段和入口按团队实际配置使用。
适用边界：哪些情况需要补充记录
示例覆盖的是单条触发的同步规则。以下情形需要在示例字段之外补充记录。
- 批量触发：一次触发处理多条对象时，主日志之外需要按对象记录明细，并增加“总数、成功数、失败数、跳过数”汇总字段。单条触发的字段结构可以直接复用为明细行。
- 跨系统同步失败：涉及外部系统时，需要补充对账字段，例如源系统记录标识、目标系统记录标识、对账状态和对账时间。仅靠错误信息无法判断两边数据是否一致。
- 规则停用或修改后的历史日志：规则停用后，历史日志仍需可读。需要保留规则版本的快照或变更说明，确保旧日志中的条件原文和动作清单在规则被改写后仍能解释。
- 涉及敏感字段：日志中若包含个人信息、联系方式或业务敏感值，需要按团队脱敏要求处理，例如只记录字段名和校验结果，不记录完整取值。脱敏规则应在记录前确定，事后补做容易遗漏。
- 人工介入较多的规则：处理环节涉及多人交接时，需要补充交接记录，包括转交人、接收人和转交时间，避免责任断档。
AI 智能编排的规则生成与调度、系统接口对接与集成配置细节不在本文范围。这些环节有自己的记录要求，需要在对应主题下单独设计字段。本文的示例和规律适用于触发条件和动作清单在配置阶段确定的规则驱动流程，迁移时先确认你的规则属于这一类，再按上述边界补充字段。
常见问题
规则执行成功但结果不符合预期，日志能帮上什么忙？
这种情况通常不是执行失败，而是判断依据或输入数据与预期不一致。排查时先看日志中的触发条件原文和触发对象的关键字段取值，确认当时是否真的满足条件；再看动作读取了哪些字段、写入了什么值。如果条件原文和输入快照都齐全，就能区分是规则配置问题还是源数据问题。若日志只记录了“条件满足”和“执行成功”，这一步就无法还原，只能重新触发一次来观察，成本更高。
失败后应该从断点继续还是整体重跑，日志里怎么体现？
两种方式各有适用条件。动作之间没有依赖、重跑不会产生重复写入时，整体重跑实现简单；动作有先后依赖或已执行动作会产生副作用时，从断点继续更稳妥。选择哪种方式应在规则配置阶段确定，并在日志中记录实际采用的方式和重试起点。示例中首次执行在动作 2 中断，重试从动作 2 继续，动作 1 不重复执行。日志若缺少重试起点字段，事后无法判断动作 1 是否被执行过两次。
日志保留多久合适，到期后怎么处理？
保留周期按团队复盘和审计需要确定，常见做法是保留 180 天或 1 年，没有统一标准。确定时考虑三个因素：异常复盘通常回溯多长时间、是否有外部审计要求、日志存储成本。到期后可以归档到低成本存储或按约定删除，归档时保留日志编号和最终状态等索引字段，便于需要时定位。保留周期和归档方式应在规则上线前写进运维说明，避免出问题时才发现日志已过期。
多条规则同时修改同一个对象，日志怎么排查冲突？
先按目标对象检索所有相关日志，按触发时间排序，看各条规则分别写入了哪些字段、写入前后的值是什么。排查冲突需要日志记录动作的目标字段和写入值，仅有“更新成功”无法判断是谁覆盖了谁。如果多条规则可能写同一字段，建议在规则设计阶段就明确字段归属，或在日志中增加“字段写入前值”记录。示例中的字段结构可以直接复用，只需在动作明细里补充写入前后值两列。
团队刚开始做自动化，日志字段可以先用简化版吗？
可以，但建议保留四类最小字段：规则标识与版本、触发对象与触发条件原文、动作逐项结果、处理人与最终状态。这四项对应排查时最基本的四个问题，缺任何一项都会让复盘退回到询问执行人。批量汇总、对账、脱敏等字段可以随规则复杂度增加再补充。简化版上线后，建议在第一次真实异常复盘时检查字段是否够用，按实际缺口增补，而不是等积累大量日志后再统一改造。
