企业 Workflow 上线后怎么监控？从故障时间线到受控修复

“接口返回 200，为什么客户还没开通？”企业 Workflow 投产后的第一类事故往往如此。入口请求正常，只说明入口程序处理了一次 HTTP 调用；它不能证明人工待办被领取、回执被关联、超时任务被调度、ERP 已创建服务，也不能证明错误分支有人处理。业务流程跨越数小时甚至数天，常见的请求级监控只能照见其中几秒钟。要运行这样的系统，必须同时建立实例视图、工作项视图、外部操作视图和可追责的修复入口。

本篇沿用 AcmeFlow：租户xinghe-demo、业务键CUSTOMER-001、第 03 篇定义的申请与实例 UUID。上一阶段已审核、签署并到账，主状态为READY。AcmeFlow 调用 ERP 建档时连接中断，系统不知道远端是否执行，标记为UNKNOWN，创建稳定操作键对应的对账任务。半小时后任务到期却没有 worker 拾取。此时直接把状态写成ACTIVE是伪造业务结果；反复重新创建也可能让远端生成重复记录。运维要做的是把缺失的对账工作恢复到队列，并留下谁、为何、基于哪个实例版本作了操作的证据。

图 1：实例、待办、外部操作和审计共同组成排障视图；教学示意，不是产品界面截图。SVG。

为什么仅看日志不够

日志记录了某段代码当时输出的文字，不自动提供业务上“现在在等什么”的答案。一个申请经历十几次 HTTP 调用、四个后台 worker 和两天人工等待时，单纯按时间搜索日志很容易漏掉晚到的回执或定时任务。更严重的是，日志通常按服务拆分，ERP 适配器显示“请求超时”，业务服务显示“等待回执”，值班人员不一定知道它们指向同一申请。排障页面应以tenant_id + application_id + instance_id为稳定索引，连接状态迁移、任务、事实、外部操作和事件投递，再显示每个对象自己的状态和时间。

实例视图首先要回答：主状态是什么，何时进入，当前 revision 与规则版本是什么，是否被明确终止。工作项视图要回答：哪个任务应当执行，截止时间、领取者、尝试次数、下次调度时间和最后错误是什么。事实视图要回答：签署、到账分别来自谁，绑定哪一版资料，是否仍有效。外部操作视图要回答：ERP 的稳定操作键是什么，最近一次请求和查询结果是什么，结果是明确失败、已创建还是仍未知。审计视图要回答：谁曾手动触发重试、重派或对账，原因与审批记录是否完整。把这些字段放在一起，才能看出“READY + ERP UNKNOWN + 对账任务超期”是一个需要处理的故障。

追踪 ID 仍然有用，但它不能替代实例 ID。一次长流程可能跨几十个 trace，单个 trace 也可能包含多个后台调用。建议每条日志、消息和任务至少带tenant_id、instance_id、application_id、event_id或operation_key中适用的字段；时间统一为带时区的时间戳。不要把合同全文、银行卡号、完整客户身份信息写入 tracing 属性，只保留排查所需的可控标识。追踪帮助查“这次请求经过了哪里”，实例时间线帮助查“这份申请过去两天发生了什么”；两者用途不同，可以互相跳转。

指标要覆盖入口之外的等待

AcmeFlow 至少需要四组指标。入口层关注请求率、错误率和延迟，判断用户能否提交、查询、审批。后台层关注队列长度、最老待办年龄、调度滞后和 worker 失败数，判断无人值守的工作是否持续推进。流程层关注各状态实例数、状态停留分位数、人工审核超期数、从提交到激活的端到端时长，判断客户是否被困。对账层关注UNKNOWN外部操作数、最老未知时长、对账成功率和人工升级数，判断“我们不知道远端结果”的债务是否在扩大。

图 2：HTTP、后台任务、流程实例和对账分别对应不同故障面；这是一组设计指标，不是实测仪表盘。SVG。

每个指标要定义分母和时间语义。例如“审批超时率”可以定义为某段时间内截止日期已过且仍未完成的审核任务数，除以同段时间内截止日期已到的审核任务总数；不能拿“当前未完成任务数/历史所有任务数”充当同一个率。流程时长应区分自然时间与工作时间，节假日、客户补资料、审批人休假会影响解释。对账积压还要看最老年龄：积压数长期为三条可能很平稳，但若其中一条已经等了两周，单看总数就会漏报。可设置分级阈值，如超过十五分钟提醒值班，超过两小时升级负责人；这里的阈值只是演示，应由合同 SLA 和业务风险校准。

标签也要控制基数。state、task_kind、result_class等有限枚举适合做指标维度；每个application_id或event_id都变成时序标签，会造成存储和查询成本暴涨。精确定位 ID 应放在结构化日志和数据库索引中，通过告警附带样本实例链接进入详情。看板可以按租户做受控聚合，但前提是租户可见性得到身份校验，不能因为指标便于聚合就向任意操作者暴露其他客户数据。

从报警到业务时间线

本次故障的合理报警不应只是“某个 Python 进程退出”。值班先看到“ERP UNKNOWN 最老时长超过阈值”和“到期对账任务尚未领取”。点击实例可见：实例READY，资料版本仍有效，审批和签署、到账证据齐全；ERP 调用使用稳定操作键，但回应丢失；对账任务在计划时间到期，仍处于WAITING。这组事实足以确定下一步是查询 ERP，而不是再次审批或给客户发送“开通成功”。

图 3：假设故障时间线，用于演练诊断；时间并非真实生产记录。SVG。

调查时还应回答“为什么任务没跑”。可能是 worker 停止、队列连接失败、任务被错误标记完成、租约未过期、调度器时钟偏移、参数校验永久失败，或告警阈值太迟。不同原因的恢复动作不同。若 worker 停止，恢复 worker 并验证到期任务被拾取；若任务状态异常，应通过受控命令重新入队；若 ERP 查询接口本身不可用，应暂停自动重试并升级对账，而不是让更多 worker 并发请求。运维手册应把“观测证据—故障分类—允许动作—验证结果”逐项对应。只写“重启服务试试”不能成为正式手册。

一份可以值班使用的修复手册

第一步，确认身份与范围：值班者在有权限的租户里按申请 UUID 找到实例，核对业务键和客户，不从聊天截图复制一个短名称就直接操作。第二步，拍下修复前快照：状态、revision、资料版本、最近一条 ERP 操作、operation_key、任务状态和最后错误。第三步，判断风险级别：如果 ERP 明确返回“已创建”，可以走确认路径；如果明确拒绝，走业务异常；如果仍未知，就保持READY，优先按稳定键查询。第四步，选择最小修复动作：本例只把已经存在的对账任务重新入队，不触碰业务状态，也不生成新的 ERP 操作键。

第五步，填写原因与证据：例如“ERP 请求在 02:01 响应丢失，按操作键查询的任务在 02:30 到期未拾取，值班单 INC-102；申请仍 READY”。原因不能只写“修复一下”。第六步，提交带expected_revision的命令；若实例已被另一位值班人员改变，返回冲突，必须重新查看，不自动重放旧命令。第七步，确认审计与后续结果：对账任务入队、审计日志可查、worker 拾取任务、ERP 查询给出证据后才允许实例走原有状态迁移。若查询仍未知，形成新的人工升级而不是把按钮连续按十次。

图 4：定位、判断、授权和入队属于一次受控操作；最终激活依赖另一次真实 ERP 证据。SVG。

修复命令最好暴露为应用接口，而不是让值班人员直接登录数据库执行UPDATE workflow_instances SET state='ACTIVE'。接口才能统一做认证、角色校验、租户过滤、状态门禁、版本条件、原因必填和审计。高风险动作还可要求双人复核，但即使只有一人，最小的守卫也不能省略。读权限与修复权限应分开，避免“能查实例”自动意味着“能重放 ERP”。工单号、执行人、命令参数、前后 revision 和结果码要进不可随意覆盖的审计记录。真正需要运维绕过正常状态机时，应有单独的例外程序和业务授权，不能把它伪装成日常按钮。

离线故障演练怎样落地

附带的 drill.py 用 SQLite 建一个最小实例、对账任务和修复审计。初始化时实例READY、ERPUNKNOWN、revision 为 5，对账任务已过期。脚本先输出快照，再让viewer角色尝试修复并断言被拒；随后由workflow-operator带足够的原因与预期版本，把任务状态改为QUEUED、实例 revision 改为 6、审计追加一条。用旧 revision 再提交同一命令会冲突。最后断言实例仍是READY，ERP 仍是UNKNOWN，没有任何盲目激活。命令python code/drill.py的本机真实输出在 run-output.txt。

图 5：修复动作的三个保护面与预期结果；其中角色检查是离线模型，不等于真实认证系统。SVG。

这个脚本故意没有假装连接第 03 篇的 PostgreSQL，也没有远端 ERP。它验证的是修复命令的判断顺序和局部事务，还注入“预期对账任务不存在”的情况，断言实例 revision 和审计均回滚，不能只改实例却无任务可执行。接入原基座时，实例主键、租户与revision要来自同一条workflow_instances查询；对账工作项可以沿用第 08 篇的计时器表或独立工作队列表，但必须保持稳定的operation_key；审计应新建独立表，以instance_id关联，并明确访问与保留策略。第 03 篇早期状态 CHECK 不包含后续READY，实际迁移前需按 05/06/08 篇的演进路线调整。此处的 SQLite DDL 不是给 PostgreSQL 直接执行的迁移脚本。

演练不能只跑成功路径

一次有意义的故障演练，至少从四个不同故障点注入。停止 worker，看积压和最老任务年龄是否按预期上升，并确认 worker 恢复后不会重复执行业务效果；让 ERP 已执行却丢失回执，确认主状态停在READY、按原操作键查询，不生成新服务；制造重复回执，确认事实去重、历史不新增重复迁移；让无权限操作者点击修复，确认请求被拒且有安全日志。演练前先记录预期信号和恢复条件，不要在事故结束后再选择“最容易证明成功”的指标。

图 6：教学故障注入计划。只有本地权限、版本和状态断言在本篇运行；其余生产依赖演练需在部署环境完成。SVG。

每次演练还要问是否影响真实客户。离线环境可直接操控虚构申请；测试环境应隔离租户和模拟 ERP；生产演练则需与业务方约定窗口、回滚与止损界限。尤其是“模拟支付到账”“模拟 ERP 创建”这类动作，绝不能对真实账务或生产 CRM 随手试验。异常路径的验收需要看到完整链条：告警触发、值班接收、定位实例、判断动作、执行修复、审计留存、业务状态依据真实证据收敛。只证明“重启后 worker 进程活着”，不能证明客户申请已经恢复。

FDE Thinking：如何证明系统可运营

客户可能把“有看板”当作“可运营”，但一个绿色仪表盘不能回答具体申诉。FDE 应拿一份脱敏申请做现场演练：客户问“为什么三小时还没开通”，值班者能否在五分钟内找出当前状态、等待原因、最晚责任方和下一次动作？如果不能，缺的可能不是更多图表，而是状态模型、稳定关联 ID 或可执行的修复手册。监控设计从业务问题倒推，通常比先安装一套 tracing 平台再寻找指标更有效。

受控修复也不是让系统“人工万能”。越是长流程，越要严格区分“恢复任务执行”与“篡改业务事实”。把卡住的对账任务重新入队，仍然保留 ERP 的未知状态；把实例直接改成ACTIVE，则向下游宣称服务已经创建，可能引发计费、通知和客户使用权。两个操作的风险完全不同。FDE 在交付时应让客户的运营负责人实际操作一次低风险修复，同时明确高风险异常由谁批准、哪些证据必须上传、哪些动作永远不通过普通后台开放。

把“卡住”分成四类，而不是一个红灯

同样是申请两小时未变化，可能是合理等待，也可能是故障。第一类是业务等待：运营审核员尚未到截止时间，实例停在SUBMITTED，待办OPEN，不应向值班工程师发故障页，只需要业务看板与到期提醒。第二类是容量等待：队列有任务，但 worker 处理速度跟不上，最老任务年龄持续增长；它需要扩容、流量控制或排查慢依赖。第三类是结果未知：ERP 请求发出却未收到可信回应，此时最危险的动作是盲目重试创建。第四类是永久拒绝：参数不合法、租户不匹配或审批被驳回，自动重试通常不会改变结果，需要业务修正或结束流程。监控规则若把四类都叫“FAILED”，值班者只能凭经验猜下一步。

状态停留时长也不能只看绝对数字。SUBMITTED等待人工一天可能符合合同，READY + ERP UNKNOWN等待一天则可能严重影响服务；REJECTED作为终态停留很久本来正常。应按“状态 + 等待原因 + 到期时间 + 客户等级”定义服务目标。看板将“尚未到期的正常等待”与“超过可操作截止时间的异常等待”分开，才能让报警有行动价值。对账任务的due_at不等于申请应在客户面前完成的SLA_at；前者是内部调度时间，后者是业务承诺。两者可以相互推导，但必须分别存储与展示。

报警也要防重复轰炸。一个 ERP 依赖故障可能让上千个实例进入 UNKNOWN；如果每份申请都给同一位值班者发一条短信，真正要做的“恢复 ERP 查询能力”会被噪声掩盖。可以按依赖、区域、租户和错误类别聚合成一个事故，再把受影响实例列表作为可钻取细节。同时仍须保留单个高价值客户超时的升级渠道。告警收敛不能把个案吞掉；阈值应该结合重试预算、SLA 和值班容量，用演练不断调整。最终考核不只是告警发出率，还包括“发现到定位”“定位到恢复”和“恢复后验证”各耗时。

业务时间线需要哪些不可改证据

一个可追溯的时间线应以追加记录为主。状态迁移历史记录原状态、新状态、命令、执行者、资料版本与发生时间；事实记录来自哪个系统、外部事件 ID、原始摘要与校验结果；任务记录创建、领取、超期、完成与取消；外部操作记录稳定键、请求摘要、尝试次数与结果类别。系统可提供整理后的当前视图，但不应因为当前状态显示 ACTIVE 就删除中间的 UNKNOWN 和查询记录。事故复盘恰恰需要知道是否在未知结果时发生过盲目创建。

时间顺序也要谨慎。支付平台发生时间、消息到达时间、数据库提交时间和运维查看时间可能不同；跨系统时钟有偏差，不能仅按一个毫秒时间戳确定因果。应同时保存业务事件时间和本系统接收时间，并用事件 ID、operation key、revision 建立明确关联。若迟到的签署回执携带资料 v1，而实例已经是 v2，时间线要显示“收到但因版本不匹配未推动状态”，不能悄悄丢弃，也不能让它满足当前门禁。类似地，ERP 回执对应旧操作键时，必须先核对是否属于同一申请和同一次创建动作。

审计与普通应用日志的保留策略不同。日志可按成本滚动，审计则需要满足企业指定的留存期限、访问审批和不可随意更改要求。本文不预设一个通用法定期限，因为行业、地区和合同差异很大；交付时应由客户合规负责人确认。导出日志给排障人员时，应对客户数据脱敏；修复审计至少包含操作者身份、角色、原因、工单号、请求参数、预期版本、执行结果和时间。若执行结果为“冲突”，这也是值得留下的操作记录，不能只有成功时才审计。离线脚本只写成功修复一条审计，生产实现需要覆盖拒绝和失败尝试的安全日志，这是一条明确的未实现边界。

三种常见故障各有不同处置

对“worker 停止”的事故，先确认消息仍在队列或数据库中，任务状态没有被错误提交为完成。恢复服务后观察最老任务年龄是否下降、相同操作键是否出现重复执行、依赖系统是否被突发请求压垮。可以限速排空积压，不应一次把一天的任务全部同时发给 ERP。对“回执丢失”的事故，先以原操作键查询远端。如果查到已创建，保存 ERP 记录 ID 与查询证据，走正常状态迁移；若查不到，应判断查询是否具有足够一致性，远端是否允许用同键安全重试；若查询本身也失败，继续保持 UNKNOWN 并升级，不把“查不到”误读成“从未执行”。

对“错误参数”的事故，重点是找到输入来源与受影响范围，而不是延长重试。若某个资料版本的产品代码不被 ERP 接受，应停止自动调用，回到有权限的业务修正流程，保留原失败记录，修改资料后创建新版本的操作键与审核链。若只修适配器映射而业务资料不变，可以在评审后让相同业务操作按兼容规则重试，但必须和远端幂等合同一致。对“人工待办超期”，处理者是运营主管而不一定是工程值班；可重新派单或升级，却不能代替审核人自动批准。技术报警与业务待办升级要分别设计接收人。

在任何处置中，都要有“停止条件”。例如对账查询连续失败三次或总时长超过十分钟，转人工；批量补投时错误率高于阈值，暂停队列；同一实例 revision 在调查期间变化，终止本次修复并重新读取；发现租户或业务键不一致，直接升级安全事件。手册只列“怎么重试”而不列“什么时候停”，可能把一次局部故障放大成大面积重复写入。

修复接口落到 PostgreSQL 时的事务边界

离线 SQLite 脚本中的repair()先校验角色、原因和预期版本，再在事务里执行带租户、状态、ERP 状态和 revision 条件的更新。PostgreSQL 集成应保持同样的原子条件，并让审计和重新入队一起提交。可以采用UPDATE ... WHERE instance_id=:id AND tenant_id=:tenant AND state='READY' AND erp_status='UNKNOWN' AND revision=:expected RETURNING revision；返回零行就报告冲突或资格不符，不继续插入任务。随后对唯一的对账工作项做受控重排，插入修复审计并提交。若任何一步失败，整组修改回滚，不能出现“审计说已修复但任务没入队”的结果。

由于第 03 篇基座的原始实例只有审核状态，本段是集成落点，不是已在其 PostgreSQL schema 上运行的 SQL。需要先扩展erp_status、对账任务表或工作项种类、审计表，迁移旧实例并补权限接口。若业务允许多个并行对账任务，还要定义唯一约束的作用域；本篇单一任务 ID 的 SQLite 演示不能直接推导到多工单会签或批量外部操作。认证信息应来自可信会话或服务身份，不能让请求体自填role=workflow-operator就通过。测试要包含跨租户、错误状态、旧 revision、重复命令、数据库中途失败与审计写入失败。

故障演练的报告怎么写

报告首页应写清注入点、隔离环境、业务影响预期、观察到的信号、实际修复动作和最终证据。不能只给“通过”两个字。例如“在测试租户停掉对账 worker 五分钟；最老任务年龄从零升至五分钟，入口 API 错误率仍低；恢复后两分钟任务被拾取，ERP 模拟服务对同一操作键只生成一条记录，实例由 UNKNOWN 经查询确认后进入 ACTIVE；审计保留恢复命令”。这比“worker 恢复正常”说明更多，也容易与业务方讨论目标是否满足。

要把未观察到的情况写出来。若测试没有真实 ERP，就不能声称生产 ERP 的查询具有读后写一致性；若模拟服务在内存里去重，就不能声称重启后仍去重；若在单机脚本中没有网络分区，就不能声称处理了连接半断。明确边界不是削弱交付，而是帮助客户决定下一轮 PoC 的优先级。一次演练能证明一条具体故障路径；系统长期可靠性仍依赖持续的监控、发布控制和定期复验。

给值班人员一条真实的操作路径

假设周一早上客户成功经理报障：“昨晚提交的客户申请显示等待开通，客户已经签约付款。”值班人员首先按租户和申请 UUID 查询实例，而不是按客户名称模糊搜索后直接点击重试。实例页显示READY、revision 5、ERP UNKNOWN；事实页显示当前版本签署和到账各一条；工作项页显示对账任务已经超期。值班人员查看最近一次 ERP 操作键，确认没有第二个创建请求，然后检查查询任务为何没有被拾取。若 worker 已恢复、只是任务状态卡住，值班者填写工单号和原因，带 revision 5 提交“重新入队对账”，得到 revision 6 与审计 ID。此刻应向业务方解释“前置条件已满足，正在核对 ERP 创建结果”，而不是宣称已经开通。

如果修复按钮返回冲突，通常说明另一位操作者或后台任务已经改变实例；立即刷新，重新判断。若 ERP 查询确认 CREATED，则由正常流程保存 ERP 记录 ID 并进入 ACTIVE；若查询返回明确不存在，还要核对远端查询一致性和操作键合同，才可能使用原键重试创建；若远端继续不可达，就升级给 ERP 负责人并保留 UNKNOWN。整个过程可由工单、实例时间线、外部操作记录和审计记录复现。值班完成后要记录客户可见状态是否正确、告警是否及时、根因是否为 worker 调度、下一次如何预防。这样的“关单”比只恢复一个进程更接近业务闭环。

另一个容易忽视的场景是错误报警。客户资料正在修改，业务规则暂不允许 ERP 创建，实例停在 SUBMITTED 很合理。如果监控只看“超过一小时未 ACTIVE”，就会把正常等待误报为故障。排障入口必须解释等待原因，告警规则必须以任务截止时间和状态门禁为准。这样值班人员才能把时间花在真正异常的 UNKNOWN 和超期队列上，而不会在大量正常申请里寻找一条事故。

交接给客户运维团队时，还要检查手册是否能由未参与开发的人执行。让新值班者在测试环境完成一次“找到超期实例—解释等待原因—提交受控修复—确认审计”的演练，记录他们在哪一步需要向开发者询问隐藏知识。如果某个关键字段只有开发者知道如何查询，就把它加入实例页面或手册；如果操作需要直接改数据库，则评估是否应该补一个受权限控制的命令。交付不是把 README 发出去就结束，而是确保组织在开发团队离开后仍能用证据安全地恢复业务。

值班交接还要约定“修复完成”的证据：对账任务只从 WAITING 进入 QUEUED，不算客户服务恢复；任务被 worker 拾取，也不算 ERP 已创建；只有按稳定操作键查到可信的 ERP 服务记录、状态迁移写入历史、客户侧查询与 ERP 结果一致，才可以关闭业务故障。把每个中间里程碑写进工单，可以避免团队在技术系统恢复后过早宣布业务恢复。