事故描述
线上支付金额异常, 平台配置支付155元, 用户实际付款1.55元.
临时解决
方案1:
调整中台配置价格, 调整价格为15500元, 那么实际支付金额=155元. (最快解决实际支付金额)
影响:
用户前端页面查看金额为15,500, 会导致客户投诉(方案产品驳回)
方案2:
更改后台支付逻辑代码, 手动增加100倍.用于调起三方支付.
影响:
1.后台发版,服务波动(金额已经错了,没有更坏的结果了)
2.后续bug修复后代码还原, 并行期间可能出现配置155,实际支付15500情况.(可通过夜间使用量少时发版解决问题)
事故起因
- 初始版本中台配置按照元配置, 数据库存储为分(数据库int存储不能有小数),前端存储和展示做了*100的转换, 后续更改为所见及所得, 按照元配置,数据库按照元存储.涉及的组比较多没有通知到位, 或者通知过程中理解存在偏差.(无落实到直面的邮件/文档)
- 调起支付相关组件为第三方mpay. 存在测试环境没法调用的情况,测试环境的app没有真实上架,mpay限制支付.因为需要香港手机号注册对应账号, 正式环境覆盖不到位.
- 发版后观察不到位. 涉及金额改动,发版后除了自测,需要及时观察线上用户使用情况, 及时对账查看入款相关信息,间隔1个月才发现.
重新梳理需求
- 为什么要更改最小单位? 平台除了对接国内,还存在国外对接, 对接国外印尼支付midtrans, 印尼相关的货币体系和中国存在差异. 中国设置xx.xx元, 后台需要int类型存储最小单位xxxx分(不用double防止丢失精度). 印尼货币换算1元=2158卢比. 数据库存储=215800(中台不区分印尼的卢比还是人民币的元), 如果设置100元, 数据库存储21580000. 2千多万. 数字可读性有些差.
- 后续增加了澳门支付. 澳门的最小单位元,能否满足要求, 比如月租是否会出现14.99类似的设置.如果去掉100的换算是否可行?