去年我被资金划拨的重复投诉搞得焦头烂额。一个客户连续三次报修说钱扣了没到账,最后查出来是他自己点重试点出了三笔,我们系统也没拦着。客服转过来的工单上写着四个字:“用户骂人”。今年我换了个干法,不只盯技术指标,还把用户反馈当验收标准来卡。一年跑下来,资金划拨类投诉降了将近九成,证书更新零故障。下面说几个具体的,不搞虚的。
先说资金划拨那摊事。往年我们处理超时的逻辑是:前端发请求,后端如果3秒没返回,前端弹窗“操作超时,请重试”。用户看到这个,第一反应就是再点一次。去年四季度有个案例,一个机构客户做500万的划拨,因为网络抖动,连续点了五次重试,结果系统生成了五笔重复单,后四笔因为余额不足全部失败,但第一笔其实已经成功了。用户不知道啊,看账户余额少了500万,以为丢了,电话打到交易总监那里。我当时的情绪就两个字:窝火。事后查故障单,类似情况全年19起,其中11起是用户重复点击造成的。
今年我重做了这个流程。核心改动就一条:去掉“重试”按钮,改成“查询进度”。用户提交后立即看到“处理中,当前排第3位,预计等待2秒”。后端必须支持幂等,同一个划拨单号,无论前端发多少次请求,只处理一次。为了这个改动,我跟交易后端的老王吵了三次。他说网关协议没必要动,加个防重表就行。我说你防重表只能防同一秒内的重复,用户隔两分钟再点呢?最后我拿出那19起故障单的明细,他看了半天,拍桌子说改。
改完后我们定了18条验收细则,我挑三条最关键的:第一,轮询间隔不低于2秒,低于这个值会把网关打爆;第二,队列位置更新延迟不能超过500ms,用户等得焦虑就会刷新页面;第三,划拨终态(成功或失败)必须在5秒内推送到前端,超时就算事故。上线前在仿真环境压了三天,模拟300个并发划拨请求,最长的处理等了11秒,但没有一条丢单,也没有一条重复。上线后第一个月,资金划拨类重复报修从47单降到5单。第二个月又冒出来两单,查了发现是一台缓存服务器时间不同步导致状态查询返回旧数据。我把这个问题补充进验收标准,之后四个月零投诉。
再说设备维护里的证书更新。去年四季度那次更新,我们四个人凌晨两点开工,分头登录几十台服务器。一台一台替换文件、改权限、重启服务、检查进程。结果有一台前置机的证书路径写死了,脚本没覆盖到,开市后客户无法下单。十分钟内涌进30通投诉。修复只花了三分钟,但影响已经造成了。那之后我就下定决









