前言
之前上次的事件，还没完全解决，上周末，又出了一个大事情，做支付才几个月，感觉经历的东西真是比之前几年还多，估计被刷了大概有个差不多5k来单，一单好像50 60U
简单介绍下我们的系统和业务背景知识
小六六目前负载的是支付网关系统，也就是说收钱的咯， 收到钱之后，给人家发货，虚拟币之类的咯！大概就是这样的模式，然后周末出问题的渠道就是类似于淘宝商城这样的渠道，就是用户去淘宝上买虚拟币，然后淘宝那边调用我们的接口去发货这种模式，大概的交互过程，也很简单，给大家画画
image.png
其实这种充值方式在平时我们用的应该不多，游戏中应该是有的，如果是电商的话一般都是下单支付类，过程和这样又是不一样的，后面有空慢慢给大家讲讲支付，今天我们继续来看这个Case
出现问题的过程以及我们排查的思路
发现问题
image.png
一般我们都有一个订单充值的金额告警，什么意思呢？给大家科普下，就是我们认为在我们系统没有做很大活动之前，我们的系统的一个充值金额和昨天同期的一个对比，他会在一个范围内，然后我们根据渠道去区分，也就是说每个渠道每天这个时间段的充值金额应该在 0.5x 到 1.5x之间， x是昨天同期的充值金额，如果超过这个范围，我们就认为这样的可能有异常的，需要我们去观察的，如果说连续的几个小时都是这样的情况，那么就很有可能就会出问题了，这个时候就需要我们去观察系统，看是否是真的有异常，
然后周末的下午，我们发现系统的异常值是平时的10倍，这就很可疑了，你想呀，如果说你到达平时的2倍，这种情况是有可能的，但是一下次10倍，这是非常不正常的，而且告警一直在刷，每半个小时都是昨天同期的10倍，然后我们风控的大佬就说，要我们支付的同事开始排查问题
排查问题
排查问题，但是只能一步步来，首先我们看看这些告警的订单，都是哪些uid再下单，再看看这些uid过往的行为吧，看看有没有啥异常的先，然后我们发现这些用户的行为，其实都还很正常，送礼，充值，玩游戏，也没有恶退啥的，但是有些uid很奇怪，一下冲几百单的冲，这是为啥呢？然后我们就找到其中的一个订单，然后发现我们系统的单的日志，一切还算正常，也没啥问题，这就很奇怪了，然后我们就想着进一步排查吗，那怎么进一步排查呢？上面我给大家说了这个渠道的交互流程，这些发货的通知是渠道告诉我们的，那我只要保障说我的渠道账号收到钱了，那其实就能说明确实是那个用户一时兴起，比较土豪，人家要冲，你也栏不住是吧，然后我们登录到渠道后台，发现绝大部分的订单都再付款中，我擦，这就很奇怪了，为啥会大部分的单，没付款就发货了？难道是我们的系统被人破解了？我们就赶紧说联系渠道说把密钥先改了，就是处理事故的第一要素就是止损嘛！然后渠道那边回复说不能马上改，要下周上班才行，我擦，那要把这个渠道给关了？然后我们发现其实这个渠道有流水还是挺多的，并且也有很多成功的单，我们再三斟酌，还是觉得再观察下，因为我们发现这个刷单再此时是没有什么量的了。然后也通知了渠道要他们帮忙一起排查
继续推断
然后，我们发现了一个很奇怪的问题，就是说调用我们发货接口url的字段里面有一个method 是validate,是验证,难道渠道那边搞了什么事情？把校验的接口的参数调用了发货接口，聊到这里，很多读者就会说，怎么会呢？就算能调通，但是他们2个返回参数应该也对不上呀，你们难道不校验其他参数吗，然而事实上，validate 和 topup的接口的参数的字段上一摸一样的，所以导致了如果渠道调错了接口，我们也会发货的，所以估计是这个渠道被有些用户试出来了，发现只要下单，我的虚拟币就会增加，所以呢导致了 后面的单子被刷。。然后我们当时临时就把这个校验给加上了，然后相当于这个渠道的这个子渠道上被拦了的。然后就不会发货了
渠道得出结论
再我方得出结论一个小时之后，渠道方才发现这个问题，最后发现上他们再上一个子渠道的时候，把我们的url配置错误本来应该配置validate url 他们却配置了发货的url，导致了了被刷，当时我们把源头拦住了之后，就开始冻结这些被刷的金豆，启动追溯，改封的封，改冻结的冻结。然后把这些处理之后，当我们向渠道要赔偿的时候呢？渠道竟然回复了这几句
We found that there’s an incorrect URL configuration for the validation request. Upon further investigation, we discovered that Hago didn’t manage to do a validation for Coda’s request (e.g. any input with the correct signature will result in a top-up for SKU and price sent).
我擦，这。。。。但是当时接这个渠道的时候，也没有强制我们去校验这个参数，并且我们已经平稳的运行了几年了，今天你告诉我这个事情是我们的锅，这种强词夺理也就你说的出来，不过目前他只是找到这些来说说，至于最后的赔付还没沟通完成，我们拭目以待吧
一点小心得
通过这个事情，小六六觉得对于支付营收来说，我们应该要有更高的标准去对待，对于渠道的东西在开发的时候就应该多方面，多维度去考虑问题，像上面的问题，其实我们自己当时考虑加了这个校验，其实这个也能拦住，其实支付这边的细节考虑的非常多，每个异常你都要考虑的很清楚，上次过个codereview 一个渠道就过了3个小时，我觉得这种是必须的而且很重要！
结束
支付的专业知识，和支付的一些有趣的事情，小六六会慢慢的给大家写的，好了，今天就到这里了，我是小六六，三天打鱼，两天晒网。
