一笔销售订单刚保存成功,库存也已预留,夜间作业却再次把它当成待处理订单。第二天,作业又处理了一遍。界面上看不到一场轰轰烈烈的故障,业务数据却一天比一天偏离正确状态。用《仙剑奇侠传 1》的物品作比喻,这种问题很像断肠草。
《仙剑奇侠传 1》的物品资料将断肠草列为毒蛊,描述其效果为中毒后每回合持续损血。ABAP 没有名叫断肠草的语言元素,也没有内建的中毒状态。真正相似的,是一种跨越多次处理、持续造成损失的业务状态或程序缺陷。它可能藏在数据库记录里,也可能藏在周期作业、重试队列、接口映射或者结算规则中。只要触发条件仍在,每运行一次,就再伤一次。
这个类比有个关键尺度。程序运行得慢、一次保存失败,虽然令人头疼,却只是单次事件。断肠草式故障需要持续性。某个错误条件被保留下来,后续处理又不断读取它,损失才会随时间积累。游戏按回合结算伤害,企业系统则按作业轮次、接口重试次数、结算周期,或者用户重复提交的次数结算伤害。
我们可以把这种结构写成一个简单关系。设第n nn次处理后的错误金额为