FDE岗位实务指南 · 第18篇上一篇的四道检查管的是动作发出之前。这一篇处理动作发出之后的硬情况请求发出去了响应没回来。页面转圈然后提示超时。此刻用户的直觉动作只有一个再点一次。产品团队的直觉通常也一样在重试按钮旁边加个倒计时或者在客户端代码里写个失败自动重试三次。这个直觉在读操作的年代是无害的——再查一次库存查两遍也没事。但在写操作的年代再点一次可能是双倍扣款、两张采购单、两条重复的核验记录。第 16 篇那张没展开的故障卡三就停在这个路口客户端显示超时服务端到底执行了没有不知道。而且这就是唯一诚实的起点。超时不是失败超时是未知——客户端与服务端之间的应答断了动作本身却可能已经走完。把未知当成失败处理直接重试是这个场景里代价最高的思维错误。一、超时以后发生了什么先不要猜先把超时那一刻的可能性摊开。请求发出后响应丢失可能发生在三个位置请求没到达服务端网络中断在去的路上服务端收到并执行了但响应丢在回来的路上服务端执行了一半卡住。三种情形的业务后果完全不同第一种重试是安全的第二种重试就是重复执行第三种连该不该重试都没法直接回答。用户看到的现象只有一个——页面显示等待。现象一模一样背后的世界有三种而处理动作取决于你在哪个世界。这就是为什么先不要猜猜错了代价是业务数据猜对了没有奖励因为没人知道你猜过。这里面的关键是一种代价的不对称。查一下再决定成本是几分钟的等待和一次查询调用猜错了直接重试成本是一笔重复的业务记录以及随之而来的对账、冲正、解释和信任损耗。两笔账摆在一起先查再说几乎是唯一理性的选择——可它违反直觉因为等待是被动的重试让人感觉在解决问题。好的机制设计就是要让理性的选择成为默认路径让直觉的选择走不通。正确的第一反应是承认我不知道结果然后把这个未知当成一种需要专门处理的状态而不是一个需要立刻消灭的异常。还有一种常见误判值得点名把超时当性能问题。系统太慢了优化一下——优化或许有必要但它回答的是另一个问题。哪怕响应快如闪电只要网络上存在断点响应丢失就永远可能发生。性能优化降低超时的频率机制设计消除超时的歧义两件事都做但别指望前者替代后者。澄川制造第 16 篇留下的那张卡教学合成核验员甲对 A-017 v2 提交确认客户端超时页面仍显示等待中。甲没有重试——因为系统在这个位置的设计不是允许重试而是进入待查询。这个设计选择就是这一篇要讲的东西。二、把业务动作和请求标识对应起来处理未知状态的前提是事后能查。而能查的前提是每一个业务动作从发出那一刻起就携带着一个稳定的、唯一的请求标识。这个标识要解决的核心问题叫重复控制。同一个业务意图——甲确认 A-017 v2——无论被提交一次还是五次系统都应该只执行一次。实现的方式是幂等请求携带业务级标识澄川的约定请求 K-17 关联A-017 v2 确认动作 甲服务端执行前先查这个标识——没见过执行并记录见过直接返回第一次的结果不再执行。第一次成功、第二次返回既有结果对用户来说两次体验一致对业务数据来说只发生了一次动作。幂等这个词听起来唬人意思很朴素同一个操作执行一次和执行多次效果一样。电梯的关门按钮就是幂等的——按一下和按十下门都是关一次。而提交订单天然不是幂等的按十次就是十张订单除非系统专门做了设计用标识识别出这十次是同一个意图只执行第一次后面九次原样返回第一次的结果。重复控制的所有工程就是把非幂等的业务动作包上一层幂等的外壳。标识本身怎么设计直接决定这层外壳靠不靠谱。太粗——比如只用用户 动作类型——用户正常提交两笔不同业务也会被误判成重复太细——比如带上时间戳——重试时时间戳变了标识就识别不出是同一个意图幂等失效。正确粒度是业务上算作同一笔的那些要素的组合谁、对哪个对象的哪个版本、做什么动作、关键参数是什么。这里有三条纪律每条都对应一种真实出过的错。其一标识必须是业务内容决定的不能是会话随机数。同一个业务意图重试时标识相同不同业务意图标识不同——甲确认 A-017 v2和甲确认 A-017 v3必须是两个标识因为 v2 和 v3 是两笔不同的业务。同一请求标识被复用于不同业务内容就会把后一笔业务错当成前一笔的重复直接返回旧结果——这种错误比重复执行更隐蔽因为表面上一切成功。其二标识要绑定版本。第 17 篇讲的版本一致性在这里延伸一步K-17 绑定的是 A-017 的 v2如果查询期间提案变成了 v3那么基于 v2 的确认这个意图本身已经失效正确处置不是重试是回到第 17 篇的版本拒绝路径。其三标识要有去处请求记录、执行记录、目标对象三者能互相找到。查 K-17 能查到它有没有执行记录查执行记录能查到它改了哪个对象查 A-017 能反查出关联它的所有请求。三张牌少一张查询这个动作就断链。这三张牌其实就是第 17 篇证据五要素在恢复场景的倒影执行端写证据时想到的以后要查在这一篇兑现了。设计执行证据时不考虑恢复查询恢复时就会发现查无此据设计恢复机制时不核对证据字段查询时就会发现缺关键一环。两头是同一张图纸的正反面分两次画就会对不上。三、查询结果并处理重复请求有了标识超时后的标准动作是查询不是重试。澄川这张恢复卡教学合成是这样填的请求 K-17关联 A-017 v2 确认动作客户端超时查询执行记录——核验记录已保存确认动作实际已成功处置是向客户端返回原记录、把页面从等待中更新为已确认明文约束不得再次创建同一结果。注意这个处置里没有重试。查询发现已执行剩下的事只是把结果如实呈现给用户——这叫恢复不叫重试。恢复卡上还写了一栏容易漏的内容如果查询这条路也断了执行记录服务恰好也不可用接手人是谁、查证材料是什么——系统负责人接手查证材料是服务端日志与数据库中的核验记录表在查询恢复前该申请单的确认入口对所有人临时锁定防止任何人在未知状态下再制造一笔。恢复卡里还有一个细节值得停下来看返回原记录并更新页面这十个字意味着结果要可追溯回原物。不是重新生成一份看起来一样的结果给用户而是把服务端已保存的那份核验记录本身取出来、展示出来。重新生成会引入第二次不一致的机会——生成的和保存的万一有出入用户看到的就是假象。恢复原物看到的就是事实本身。查询的结果不止已成功一种决策表要覆盖全部分支已知已成功——返回既有结果不得重复执行已知明确失败服务端有失败记录——业务条件重新校验状态、版本还在不在后允许重试已知明确拒绝——走第 17 篇的拒绝路径不重试仍然未知——转人工核查限制一切可能产生重复副作用的操作直到查清楚。四种分支四种动作唯独没有默认再试一次。这张表要贴在每个相关角色的手边——客服接到我点了没反应的求助时照表第一步就是查询标识而不是指导用户您再点一次试试。把这些分支整理成一张超时处置决策表字段是已知状态已成功/已失败/已拒绝/未知、查询方式按请求标识查执行记录、可重试条件明确未执行且业务条件重新校验通过、接手人未知状态转系统负责人、恢复依据执行记录与服务端日志。这张表和第 16 篇的排障卡、第 17 篇的授权矩阵是同一类东西把到时候再说的临场判断提前变成照表执行的既定动作。事故现场最不缺的资源是慌乱最缺的资源是判断力——决策表就是把判断力从事故现场提前存进文档里。还要补一个视角这套机制不只防用户手抖也防系统自己的重试。消息队列的重投、定时任务的补跑、Agent 在结果不明时的再试一次——自动化的重试比人工重试勤快得多破坏力也大得多。所有写入路径上的执行者无论人还是系统都走同一个幂等闸门这是这套设计里最不能讨价还价的部分。特别要点名 Agent 场景模型在结果不明时的默认倾向是再调用一次工具因为这最像继续完成任务。第 17 篇给 Agent 立的规矩是建议而非直接执行这一篇要再加一条Agent 的重试意图必须经过幂等闸门且它的请求标识必须继承自最初那次业务意图而不是每次调用重新生成——否则 Agent 的五次重试在系统眼里就是五笔新业务。四、区分重试、恢复、补偿与人工处置查清楚了接下来的动作才谈得上选择。四个选项对应四种局面混用是另一类事故。四个选项的判别顺序是固定的1、先问执行了没有——没执行考虑重试2、执行了再问结果送达了没有——没送达走恢复3、送达了或已可见再问这个结果对不对——不对走补偿4、最后问这个动作可不可逆——不可逆直接转人工处置。顺序不能乱在执行了没有还没答案时谈补偿和没确诊就开刀一样荒唐。重试适用于明确未执行且业务条件仍允许。两个条件缺一不可没执行过有证据而且现在执行仍然合法状态、版本重新校验过因为超时之后世界可能变了。所以重试三次从来不是通用解法——它假设了所有失败都是未执行而这个假设在写操作场景里恰恰是错的。退一步说即使确认了未执行重试前还有一道第 17 篇留下的手续业务条件重新校验。超时发生在五分钟前这五分钟里申请单可能已被他人确认、预算可能已被占用、提案可能已从 v2 变成 v3——五分钟前合法的意图此刻未必合法。重试不是把旧请求原样再发一遍是带着旧意图重新过一次当下的校验。恢复适用于已执行但结果没送达。动作不重复只是把既有结果找到、返回、把各处的状态刷成一致。K-17 走的就是这条路。补偿适用于执行了但事后发现不该执行或执行错了。关键认知补偿是一个新的业务动作不是把原动作删掉。采购申请已经下发撤销不是删除那条记录而是发起作废采购申请的新动作由对方系统确认后再更新状态原记录、作废记录、两者之间的因果全部留在审计里。把补偿做成删除等于篡改历史——审计要的是发生过什么、怎么纠正的不是看起来什么都没发生过。人工处置适用于高风险或不可逆动作。客户消息发出去了收不回误触达就是事实能做的是记录事件、生成安抚任务、触发合规报告。这类动作的正确设计是在建模时就和主动作一起把补偿路径想清楚而不是等事故发生后临时发明。补偿记录里要包含什么原动作标识、补偿动作标识、两者的因果关联、补偿的发起人和理由、外部系统的确认结果。少任何一项后来的审计者看到的都是两笔孤立的记录看不出这一笔是为了纠正那一笔。补偿是叙事的另一半原动作讲了发生了什么补偿讲我们怎么纠正的两半合在一起才是完整的业务事实。还有一条边界要明说外部系统的动作未必能原样回滚。写进 ERP 的采购单、发给供应商的确认对方系统认不认你的作废、按什么规则认取决于对方的接口能力——具体接口的幂等保证和回退能力只能查那一家的官方说明不能凭感觉假设。设计恢复方案时把每个外部动作按可直接撤销 / 可补偿 / 不可逆分好类这个分类表就是事故时的作战地图。五、做一次响应丢失的受控演练机制设计得再好没在真实断点上验证过都是纸上防线。澄川的做法教学设定是在隔离环境里做受控演练用教学故障开关模拟请求已保存核验记录、响应丢失页面停在等待中然后观察两件事——用户侧有没有路径绕过待查询直接再次提交有就是漏洞系统侧查询、恢复、页面更新的全流程是否按恢复卡走通走完之后核验记录、请求记录、对象状态三者是否一致。演练本身也要留记录哪天做的、模拟的是哪类丢失、四个分支各走了哪条路、发现的问题和修复。这份记录和排障卡、实验记录进同一个档案——它是下次审计这套机制还活着吗的证据也是新人理解系统行为边界的教材。演练同时要跑三个对照组明确拒绝的请求不应进入待查询直接走拒绝路径、明确成功的请求正常闭环、无法查询的请求触发人工接手与入口锁定。四个分支各过一次这套机制才算从设计过变成验证过。演练不是一次性的写入路径每次调整、外部系统每次升级、执行者每次新增比如新接入一个 Agent四个分支都要重跑。恢复机制和权限边界一样是每次改动后需要重新确认的东西——第 17 篇那句边界不是一次建成的在这里原样适用。迁移练习留给你回到禾木家居主管确认一条质检发现后客户端超时如果是你设计创建辅导任务这个动作的请求标识怎么定、重复创建的任务对组长的工作清单有什么影响、已下发给组长的任务算不算已产生外部影响把已成功、已失败、未知三种状态分开各写出可采取的下一步——写不出来的那一种就是你要补的设计。下一篇进入运行期上线之后怎样持续知道它还在好好工作——输入分布会不会漂移人工推翻率会不会爬升业务规则变了系统知不知道。