发布、定时与日志

调试通过只是“我本地能跑”。要让团队放心用，还要做三件事：发布稳定版本、按需定时运行、用日志持续维护。

---

发布：从草稿到稳定版本

发布前的“通行证”

发布前自检：

[ ] 输入参数明确（必填项写清楚类型和示例）
[ ] 输出字段稳定（命名清晰、不会偶尔丢字段）
[ ] 关键节点配了等待和失败处理
[ ] 凭据通过「连接」管理，不是写死在节点里
[ ] 至少完整跑通过 1～2 次
[ ] 失败情况下能看懂日志

不全打勾就先别发布。

发布操作

1. 在编辑器右上角点 发布。
2. 填写：
   • 版本号：建议遵循 “主版本号.次版本号.修订号”，例如 0.1.0。
   • 发布说明：写清楚这次改了什么、和上一版的差异。
   • 工作流简介：必填，写给使用方看，能让没参与过的人读完知道用法。
3. 确认后生成新版本。

发布后注意：

• 草稿和已发布版本是分开的。继续编辑草稿不影响已发布版本。
• 旧版本可以保留以备回滚。
• 重大行为变化建议升次版本号 / 主版本号。

灰度与回滚

• 重要工作流先发布到测试空间或 少量调用方 验证一段时间再切生产。
• 出问题时先回滚到上一个稳定版本，再排障，不要一边线上爆一边改。

---

定时：让它按计划自动跑

上线前置条件（再次提醒）

只把 已发布且手动运行成功 的工作流交给定时任务。否则定时任务变成“稳定地周期性失败”。

配置一个定时任务

1. 进入 定时任务，点击 新建。
2. 选择要调度的工作流和具体的发布版本。
3. 配置触发时间：
   • 简单方式：每天 / 每周 / 每月几点。
   • 高级方式：直接填 Cron 表达式（编辑器会预览“下次执行时间”）。
4. 配置输入参数（通常是默认值或基于时间生成的参数，例如“昨天日期”）。
5. 配置失败处理：
   • 重试次数（推荐 1～3 次）。
   • 重试间隔（建议指数退避，例如 30s / 2m / 10m）。
   • 失败告警通道（飞书 / 邮件 / Webhook）。

上线前先单跑一次

不要直接启用周期。先点 立即运行一次：

• 看运行日志：每个节点是否成功。
• 看输出：是否和手动跑结果一致。
• 故意配错一次（比如临时关掉一个连接），确认能收到失败告警。

成功标准：单次执行 100% 符合预期，再启用周期开关。

详细操作可参考 定时任务。

---

日志：看完就能定位问题

怎么看一次执行

每次执行都会留下：

• 整体状态：成功 / 失败 / 警告 / 取消。
• 节点列表：每个节点的开始时间、耗时、是否成功。
• 节点输入 / 输出：能看到上下游变量。
• 错误信息：失败节点的报错原文。

看日志的固定路径

1. 找 第一个失败节点（不是最后一个）。
2. 看 它的输入 是不是预期的值。
3. 看 错误信息 是不是已知模式（超时 / 401 / 元素未找到 / 文件不存在）。
4. 对照 上一次成功 的日志，找差异。

如果日志没报错但结果不对，多半是数据问题，去看 常见问题与排障 中“数据 / 输出不对”一节。

---

上线后的日常维护

每周看一次

• 执行成功率是不是降了。
• 是否出现重复失败的节点。
• 凭据是否快过期。

关键时刻要做

• 业务对接系统改版前后：手动跑一次回归。
• 节假日 / 跨年 / 月底：检查时间相关参数。
• 客户端或工作流升级版本后：定时任务里要显式切到新版本。

长期不用就关停

不再使用的定时任务及时关闭或删除，避免“僵尸任务”继续触发。

---

一份发布上线的总检查清单

[ ] 工作流已发布稳定版本
[ ] 输入 / 输出字段、命名、单位、格式都明确
[ ] 凭据放进了连接，不是节点里硬编码
[ ] 关键节点有等待 + 失败处理
[ ] 测试环境完整跑通 1～2 次
[ ] 失败告警通道已验证（故意失败一次，能收到通知）
[ ] 定时任务先“立即运行”一次，再启用周期
[ ] 出现问题时知道找谁、有回滚版本

---

卡住了？

你遇到的情况	处理方式
发布后行为和测试不一致	检查定时任务绑定的版本号是固定还是“跟随最新”
定时任务到点没触发	看任务是否启用、客户端是否在线、上次执行结果
一直收不到失败告警	检查告警通道（飞书 / 邮件 / Webhook）是否仍然有效
改了草稿但线上没变	草稿和发布是两个东西，需要发布新版本
紧急要回滚	切到上一个稳定版本，再排障

---

下一步

• 想看节点参数：指令参考。
• 想完整理解定时任务：定时任务。
• 想系统化排障：常见问题与排障。
• 想集中管理凭据：连接外部系统。