看运维如何拯救一个百亿互金平台
|
短信攻击,现在的网站几乎都有发送短信或者短信验证码的功能,如果前端不做校验,黑客会随便写一个 for 循环来发短信,一般系统的短信会进行全方位的防控,比如：
4、BUG4.1 重复派息2015年的某一天看到一个新闻说是陆金所的一个用户发现自己银行里面突然多了很多钱,没过多久又被扣走了,然后收到陆金所那边的解释,说是给用户还本派息的时候程序出现了问题导致还本派息两次. 当他们程序员发现了此问题后紧急进行了处理,用户当然闹了,也上了新闻,当然陆金所通道能力确实比较强可以直接从用户卡里面扣,当大家都兴致勃勃的谈论这个话题的时候,我却有一股淡淡的忧伤,为什么呢? 因为这个错误我们也犯过,具体说就是我搞的,大家不知道我当时的心里压力有多大! 事情是这样子的：我们使用的第三方支付的扣款接口不是特别的稳定,于是我们前期就对接了两种不同的扣款接口,平时前端投资的时候走一个接口,后端派息或者还本的时候走另外的一个接口,在初期的时候扣款接口不稳定,因此在给用户派息的时候经常会有个别用户失败,需要手动给失败的用户二次派息. 做为一个有志向的程序员当然觉得这种方式是低效的,于是将程序改造了一下,在后端派息的时候当第一种扣款失败的时候,自动再次调用第二种扣款接口进行扣款,当时想着这种方式挺好的,各个环境测试也没有问题,上线之后监控过一段时间也运行稳定. 当感觉一切都很美妙的时候,事故就来了,突然有一天,客服反馈说,有的用户说自己收到的利息感觉不对,好像是多了(真的是太感谢这个用户了),我登录后台看了一下派息的流水,复核了一遍,果然利息被重复派了,感觉一盆冷水从头而下. 我把当天所有的用户派息记录和到期记录都进行了检查,发现影响了70多个用户,导致多派息了6万多元,幸亏只是派息出了问题,如果是到期的话,金额会翻N倍,其中70多个人里面有几个进行了提现、几个进行了再次投资,绝大部分用户在我们发现的时候还不知情,金额也没有动. 怎么处理呢,当然不能直接就动用户的钱了,只能给每个重复派息的用户打电话,说明原因并赠送小礼物,请求谅解后,我们把重复派过的利息再次调回来. 大部分用户进行了核对之后都还是比较配合的,当然肯定有一些用户不干了,但你也不能怪客户,因为都是我的原因.有的客户需要上门赔礼道歉,有的客户需要公司出具证明材料,我们的老板还亲自给客户打了N个电话,被客户骂了N遍,我心里压力可想而知. 其中有一个客户特别难缠,各种威胁,说既然到了我的账户里面,肯定是我的,你们的失误不应该让我来承担,折腾了很久,还是不能怪客户. 你可能会说有的互联网公司经常出现这种问题后就送给客户了,哎,可是我们是小公司呀!这个噱头玩不起. 到底是什么原因呢,事后进行了复盘也给领导做了汇报：平时都是首先进行派息的定时任务,过一个小时之后进行到期的定时任务,当天的派息标的比较多,跑了一个半小时,就导致了派息和到期的两个定时任务同时进行,转账有了并发,第三方支付的接口不稳定,给我们返回失败,其实有的是成功的,就导致了我们进行了二次的扣款尝试,引发了此问题. 这个事情给我带来了非常大的教训,对于金融扣款的这种事情一定需要谨慎,哪怕付款引发报警之后再人工处理,也不能盲目重试,极有可能引发雪崩效应. 4.2 杂七杂八还有就是其它一些零碎的问题了,记的有一次对用户的登录过程进行优化,导致有一块判断少了一个括号,结果用户在那两个小时内,只要输入账户,任意密码就可以登录了,幸好及时发现这个问题,正是这个问题才导致了我们正式确立了规范的上线流程,为以后的上线制度奠定了基础. 还有一次我们在模拟用户投资一种标的时候,留了一个入口通过 http 就可以调用,测试也没有问题,有一天正好给领导演示呢,就再次用 http 请求的方式在浏览器执行了一下,前端就会看到自动投标的过程. 因为生产的数据有点多,投标的过程有点长,我们为了加快进度,找了好几个人同时来执行这个 http 请求,导致最后出现了问题,最后发现写测试脚本的这个同事根本就没有考虑并发的情况,才导致出现了问题. 也做了很多的活动,记得做一个网贷之家的一个活动的时候,活动上线比较紧张,我们团队曾经连续工作超过30个小时(一天一夜再一天),当天晚上我2点左右写完程序,测试从2两点测试到早上9点,最终确认没有任何问题,才进行投产. 半夜公司没有暖气,我们实在冻的不行了,就在办公室跑步,从这头跑到那头,第二天上线之后,又害怕出现问题,监控了一天,确认没有任何问题,才到下午正常下班回家,那时候真是激情满满呀. 说到做活动肯定少不了羊毛党,哪一家互金公司没有遇到过羊毛党?而且现在的羊毛党规模简直逆天了,我们用户里面就有一个羊毛党在两三天之内邀请了六七千位用户,如果邀请一个用户送1元,那这个用户就可以搞几千块一次. 而且有很多专业的网站、QQ群、微信公共账号都是他们的聚集地,那天那个平台有活动门清,他们写的淘羊毛操作手册有时候比我们官网的帮助文档还清晰,所以做活动的时候要考虑特别周全,各种限制,有封定、有预案、讲诚信,只要是符合我们活动规则的坚决按照流程走. 还有一个有趣的事情,是App 推送,一次我在公交车上就看到某盒子 App 弹出 XXX 的推送,这个事情我们也搞过,因为在调试的时候生产和测试就差了一个参数,有时候开发人员不注意就把生产参数部署到 uat 环境了,测试一发送就跑到生产了,这方面只能严格流程管理来防止了. 其实还很多问题：mongodb 集群和 mysql 的同步出现的状况、后台大量数据查询下的 sql 优化、golang 使用 mapreduce 碰到的问题… 限于篇幅这里就不一一描述了. 其实每次出现问题都是对团队一次非常好的锻炼机会,通过发现问题,定位问题,解决问题,再次回过头来反思这些问题,重新梳理整个环节,举一反三避免下次再次出现类似的问题. 正是因为经历这种种的困难、考验才让团队变的更强大、更稳定,也更体现了流程的重要性,更避免了再次发生类似问题. 总结（编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
