企业 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外部操作数、最老未知时长、对账成功率和人工升级数判断“我们不知道远端结果”的债务是否在扩大。图 2HTTP、后台任务、流程实例和对账分别对应不同故障面这是一组设计指标不是实测仪表盘。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 stateACTIVE。接口才能统一做认证、角色校验、租户过滤、状态门禁、版本条件、原因必填和审计。高风险动作还可要求双人复核但即使只有一人最小的守卫也不能省略。读权限与修复权限应分开避免“能查实例”自动意味着“能重放 ERP”。工单号、执行人、命令参数、前后 revision 和结果码要进不可随意覆盖的审计记录。真正需要运维绕过正常状态机时应有单独的例外程序和业务授权不能把它伪装成日常按钮。离线故障演练怎样落地附带的 drill.py 用 SQLite 建一个最小实例、对账任务和修复审计。初始化时实例READY、ERPUNKNOWN、revision 为 5对账任务已过期。脚本先输出快照再让viewer角色尝试修复并断言被拒随后由workflow-operator带足够的原因与预期版本把任务状态改为QUEUED、实例 revision 改为 6、审计追加一条。用旧 revision 再提交同一命令会冲突。最后断言实例仍是READYERP 仍是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 stateREADY AND erp_statusUNKNOWN AND revision:expected RETURNING revision返回零行就报告冲突或资格不符不继续插入任务。随后对唯一的对账工作项做受控重排插入修复审计并提交。若任何一步失败整组修改回滚不能出现“审计说已修复但任务没入队”的结果。由于第 03 篇基座的原始实例只有审核状态本段是集成落点不是已在其 PostgreSQL schema 上运行的 SQL。需要先扩展erp_status、对账任务表或工作项种类、审计表迁移旧实例并补权限接口。若业务允许多个并行对账任务还要定义唯一约束的作用域本篇单一任务 ID 的 SQLite 演示不能直接推导到多工单会签或批量外部操作。认证信息应来自可信会话或服务身份不能让请求体自填roleworkflow-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 结果一致才可以关闭业务故障。把每个中间里程碑写进工单可以避免团队在技术系统恢复后过早宣布业务恢复。