先知道今天应该有一次什么任务
本例每天09:00处理甲、乙、丙三家门店的订单文件。系统预先生成当日计划记录,包含预期启动时间、允许延迟、应到文件及负责人。超过约定检查点仍没有对应运行记录,就提示“未启动”,不必等待程序自己报错。
计划由独立检查途径核对执行情况。如果启动任务和检查任务依赖同一个已停止的进程,就可能一起沉默;交付时应说明谁或哪个服务负责检查缺席运行。
运行结果按实际处理进度表达
| 项目 | 实际情况 | 应显示内容 |
|---|---|---|
| 甲店文件 | 12行处理成功 | 成功12行,输出位置可查 |
| 乙店文件 | 8行处理成功 | 成功8行,输出位置可查 |
| 丙店文件 | 文件打不开 | 失败,未取得行数,需补文件 |
| 整个批次 | 2份完成,1份失败 | 部分完成,共20行已处理 |
丙店未读到行数,不能写“0条订单”。生成的部分输出标明缺丙店,不能伪装成三店总表。若程序在写入后失去响应,应显示结果待确认,通过目标记录核查后再决定状态。
提醒写明影响与下一动作
一条有效提醒可以是:“B021部分完成:甲、乙店20行已处理,丙店文件无法打开。当前报告未包含丙店。请值班人员核查文件并在任务记录中处理。”提醒附任务入口,而不是把长错误堆栈直接发给所有业务人员。
同一问题持续存在时,更新同一事件并按约定间隔提醒;有人接手后记录处理人。长时间无人处理或影响扩大,再按预定规则升级。通知发送成功、送达或已读是否可判断,取决于实际渠道能力,不应混写成“已处理”。
日志够定位,通知不携带无关数据
每次运行关联计划编号、批次、程序及规则版本、输入清单、逐项结果和输出位置。技术日志可记录必要错误信息,但不直接保存密码、访问令牌等秘密;OWASP日志指南也强调此类排除与访问限制。
业务任务成功而通知失败时,状态仍是任务成功、通知待处理。不能为补发提醒而重新执行导入。相反,通知成功也不能把原本部分完成的任务改成全部成功。
恢复时只补已确认未完成的部分
丙店补交可读取文件后,建立与B021关联的补跑记录,仅处理丙店,核对其结果再生成完整报告的新版本。甲、乙店20行不重复导入。保留原部分结果、补跑输入及新旧输出关系。
验收分别模拟未启动、运行中断、文件打不开和通知失败,观察状态与提醒是否正确。最后补跑丙店,确认任务可以结束且已完成记录没有增加重复。操作员应能从这一个任务入口解释今天的输入、结果和处理经过。