百亿互金平台救火故事
多年前，又是周六客服打电话过来，平台官网不能訪问，app全然无法打开，客户在QQ群和微信群中各种反馈，说平台是不是跑路了？客服的多条400热线全然被打爆，电话已经接只是来…
前言
一直以来总是想以什么方式去记录下自己在互金行业的这段经历，趁着自己还记得清晰。还能找到一些资料原型。一方面能够分享出来供大家參考，可是更重要就是多年以后我能够依据这些文章回顾起来自己的那段激情岁月。
想了非常久但一直没有实施，后来认为应该从架构的角度来梳理一篇文章，就写了从零到百亿互联网金融架构发展史这篇文章。最后认为仅仅有实战出来的东西以及解决这个问题的过程，才是工作中最宝贵的经验，应该把它分享出来，在梳理的过程中认为有三起事故比較有代表性就整理出了以下这三篇文章，本篇文章从总体来回顾一下一路走过来所经历过的救火故事。
作为一个互联网金融平台，涉及到用户资金。不论什么的服务（资金）差错用户都是不可容忍的。用户不懂什么是数据库，不知道什么网络不通，就是一会看不到钱在app里面展示都会认为不安。在已经有非常多P2P公司跑路的前提下，用户个个已经被锻炼成为福尔摩斯侦探，每天打开app查看收益，监控着平台一切，甚至半夜升级断网十分钟。也会被用户察觉，直接就发到群里面，更有甚者直接在QQ群或者微信群中你们的技术行不行!
我们常说的互联网工作经验。一方面是开发经验，但事实上更重要的是处理问题的能力。
那么处理问题的能力怎么来呢。就是不断的去解决这个问题，不断的去总结经验，当中处理生产环境中问题的经验更甚,由于在处理生产环境中对个人的压力和临危应变的能力要求最高，你不但须要面临千万个用户反馈，客服不时得催促并且旁边可能就站了N个领导在看着你，一副你行不行的样子要求立马立即解决这个问题！这个时候你的操作就非常重要。稍有不慎便会引发二次生产事故。
说了这么多，仅仅是想说明，生产事故对技术综合能力要求颇高，更是锻炼处理问题能力最佳时机！
以下给大家介绍我们从零开发到如今百亿交易量所遇到的几次关键事故，有大有小挑出一些比較有代表性的事件来分享。
并发满标
公司系统刚上线的时候，事实上没有经历过什么大量用户并发的考验，结果公司做了一个大的推广，涌入了一批用户来抢标，共1000万的标的差点儿都在10秒之内搞定，大概会有上万左右的用户会同一时候去抢标，平均每秒大概有千人左右的并发，满标控制这块没有经过大的并发測试，上来之后就被打垮了，导致得结果是什么呢，1000万的标的。有可能到一千零几万满标，也有可能会九百多万就满标，也就说要不就是多了一些，要不就是少了一些，就满标了。
这就会非常尴尬。由于借款用户就借款一千万整，那么多出来的钱既不能给用户退回了。由于用户好不easy才抢上了，无端退了用户也闹；少了也是问题，用户借款一千万。少了几十万也不行，假设短得少了能够想办法找一些有钱的客户直接给买了，多了就必须又一次放出来让用户投资，非常影响士气，这个问题困扰了我们有一段时间。
购买标的流程图，不知道大家能否依据此图发现问题呢？
超募
为何会产生超募？在最早前的版本号中没有使用乐观锁来控制。假设在最后购买的用户一单出现并发，就会出现超募，比方最后剩余30000份的购买份额。由于并发量特别大。可能同一时候会有十几个用户拿到了剩余30000份剩余金额的可购买额度。有的买1000份、有的买上3000份、有的买上20000份都会驱动满标。所以最后导致了超募。
针对这个问题。主要是引入了memcached乐观锁的概念（底层主要是cas、gets两个命令）。在发标的时候存入标的总份额。当用户购买的时候首先去锁定用户购买的份额。由于乐观锁的原因，假设同一时候有两个用户拿到份额的时候保证仅仅有一个最后能够更新成功（锁定份额），（锁定份额）失败直接返回，这样就保证了在入口的时候就直接屏蔽了部分并发的请求。
少募
为何产生少募？少募是可能1000万的标的突然到980万就给满标了，这是由于在超募情况下我们完好了代码。用户一进来首先就是锁定购买份额。仅仅有锁定购买份额才干进行以下的流程，假设锁定购买份额失败直接返回，这样尽管保证了在1000万份额在购买初期必须每个用户仅仅能锁定一份。可是在高并发的情况下，由于购买流程中有十几个分支，每个分支失败就会退回锁定的份额。这样就会导致这样的现象，就是可能是并发一上来。立即就满标了。过了一会进度就回退回来了。
少募主要是由于分支失败回退导致的，一方面我们分析了easy导致回退热点，由于在用户抢标的时候会给用户实时的展示标的进度。在非常早的版本号中直接就是存入到一个标的进度表里面，并且採用了乐观锁。假设并发一高就频繁的更新失败导致回退，因此优化了标的进度这块。直接去掉了标的进度表，实时依据查询来展示标的进度（能够有延迟。有缓存）。另一方面在回退份额的时候在次推断试下memcached的份额和标的的状态，假设份额不为零并且标的状态是满标，立即自己主动更新状态保证兴许用户能够立即购买再次驱动满标。
做了以上的两种优化后，我们还遇到了其他的一些小问题。在不断的优化过程中，最终稳定下来。在后期版本号中将考虑使用MQ队列或者redis队列来处理抢标更合理对用户也更公平一些。
黑客攻击
2015年应该是互联网行业受黑客攻击最多的一年吧，各互金公司都深受其害，当中我就记得网贷之家有一段时间被黑客攻击的太厉害，连续几天站点都无法打开。当然了我们也未能幸免，什么DDOS攻击、SQL注入、寻找系统漏洞等都差点儿都经历过了，有的黑客还比較好，应该是出于善意或者展示自己，将漏洞放到乌云上面或者漏洞盒子里面让厂商来修复。
但很多其他的是一些黑产全然就是威胁、敲诈想捞一笔钱，先看看以下这位吧：
这个家伙潜伏到我们公司的客户群里面。冒充我们的客户代表将头像和资料替换成一样，然后给群里全部的客服让他们发送我们内部的后台地址，想通过这样的方式来寻找突破口，当然了这个算是里面的小菜鸟吧。
DDOS攻击
DDOS攻击我们也是遇到了非常多次，确实也没有比較好办法。最后都是通过一些笨办法来尽量的避免。先说说我们的经历吧。有一次我正在写程序。客服QQ又闪烁了起来。还没来得及打开查看信息，客服的经理电话就直接打了过来，我立马就有一种不祥的预感，说官网打不开了。后台也登录不了。
挂了电话。我在本机进行了測试果然不行，立马准备登录VPN查看server各项指标，结果登录不上去，立即上楼找运维经理。他也登录不上。刚准备给机房打电话的时候。机房来电话了，说我们的一个IP正经历着1G多的流量訪问，问我们是否正在做什么活动，刚话没有说完就说流量已经到5G，不到一分钟之后流量已经到达18G之多。由于我们的机房和集团公用了一个宽带入口。结果陆续的集团上面反馈他们的站点、服务也都出现了问题，机房方面害怕引起更大的冲击，直接把我们官网对外的IP封掉。集团的其他业务也才慢慢都恢复了过来。我们也紧急的更换了外网IP。又一次切换了域名解析才恢复。
事后我们依据apache分析了日志，流量来自N多个不同的IP地址根本无法应对，也正式由于这次攻击也才让我们领导重视了起来。将我们公司的机房网络层和公司集团彻底分离。这样的话无论那方受到大流量攻击都不会相互影响，我们也想了一些笨办法。由于上次我们更换了外网IP之后攻击也就停止了，那么我们认为肯定是针对我们外网来攻击的，全部我们就多准备了6个外网IP。当监控到对某一个外网进行攻击的时候立即切换到另一个外网地址，就这样跟他们玩，能够起到非常有限的一点作用，假设黑客真的想跟我们玩。这个办法就像是小孩子捉迷藏。
周年庆的DDOS攻击
另一次我们正在做周年庆活动，突然有人在QQ群里面给我们客服说了一句，叫你们的技术负责人来找我，然后我们的站点就挂了，我还保留了当时的一个截图例如以下：
完了之后客服就来找我，然后依照往常的策略处理完之后，我依据客服给我的QQ号码加上了那个人，开口就来吓我，我依稀记当年的对话例如以下：
黑客：你是平台的技术负责人吗？
我：算是吧
黑客：你信不信我能够让你们官网在5秒之内挂掉?
我：…（沉默，还真害怕又把官网搞挂了）
黑客：你们的官网漏洞非常大
我：假设有好的建议请您赐教
黑客：你们的server是不是什么防护软件都没有装？
我：…（继续沉默，这会在想不会是那个安全厂商来推广产品的吧，当然我们基础的防护肯定有）
黑客：我们有非常多的肉鸡。想攻击谁，几秒之内肯定搞定
我：…
黑客：我们已经给非常多互联网金融行业做了渗透測试。花点钱帮买你们平安，保证以后不会在出事情
我：…
黑客：免费的策略也有非常多，比方360、百度云的安全产品能够免费低档10G左右的流量……(中间省略)
黑客：我说了这多。你们也是不是给包烟钱。表示表示。
……
后来也和领导进行了商量，坚决不能给他们钱，不能助涨这样的嚣张气焰。实在不行就报警。
曝光一下当年使用的假QQ号。刚查了下变了个头像和描写叙述。例如以下：
后来我一直在想为什么DDOS攻击总是喜欢依据外网IP来攻击呢，慢慢好像是理解了假设针对域名来攻击的话，那不就是攻击到域名商的server了吗,一般域名商比較强大，黑客不太搞的定，也确实没有必要。当然记的前一段时间。某著名域名服务商被攻击。导致国外twitter等著名的互联网公司訪问不断到达半天以上。还是非常严重的。
可是对于我们这些小公司，倒不至于搞这么大的动作。
究竟怎样正确的防止DDOS攻击：
第一种方案，隐藏server外网地址，server前端加CDN中转。免费的有百度云加速、360站点卫士、加速乐、安全宝等，假设资金充裕的话，能够购买高防的盾机。用于隐藏server真实IP。域名解析使用CDN的IP。全部解析的子域名都使用CDN的IP地址。此外。server上部署的其他域名也不能使用真实IP解析。全部都使用CDN来解析。
另外一种方案，买一些安全产品来进行流量清洗，主要是阿里云、腾讯云这样的大厂商提供的一种服务。
第三种方案，有非常多的防火墙产品声称能够防止Ddos攻击，可是我个人使用感觉效果非常有限。
SQL注入
我们的官网使用的是PHP开发，由于框架比較老旧的原因。存在着一些SQL注入的点，我们发现了一些进行了修补。没想到还是被一些黑客找到了突破点，这块还是比較感谢这些黑客的在漏洞盒子上面提交了bug(例如以下图)，最后我们依据提示进行了紧急修复。后来我们也在WAF防火墙配置了一些拦截SQL注入的策略，起到双保险的作用。
我一直在想为什么PHP一般比較easy出现SQL注入呢，而Java较少的暴漏出来SQL漏洞的情况，我估摸着有双方面的原因：第一，PHP通常会在前端使用的较多。受攻击的机会很多其他一些。Java一般做为后端服务攻击的可能性会比較少；第二，PHP框架较多并且非常多早期的框架并没有特别考虑SQL注入的情况，Java大量普及了mybaits\hibernate这样的orm框架，框架本身对常见的SQL注入有防止的功能，但不是说mybaits/hibernate框架就没有被sql注入的可能。大部分场景下是OK的。另外參数化查询能够有效的避免SQL注入。
通过一段时间的学习，我发黑客一般先使用工具对站点做总体的扫描相似Acunetix，在依据扫描出来的漏洞做个大概的分析，可是比較深入的漏洞都须要依据站点的业务在进行调整，比方sql注入会依据页面的查询使用sqlmap等工具来进一步的渗透。当然我对这方面还是外行。描写叙述的可能不够清晰。
其他攻击
其他方面的攻击，主要是在业务方面，比方我们当初有一个非常小的失误。有一个程序猿在H5的小网页中将发送短信验证码返回了前端，最后被haker发现了，利用这个漏洞能够给随意的用户重置登录password；短信攻击。如今的站点差点儿都有发送短信或者短信验证码的功能，假设前端不做校验，haker会随便写一个for循环来发短信。一般系统的短信会进行全方位的防控。比方：1、前端加验证（字符验证码。有的是拖拽的动画）;2、后端依据用户或者IP加限制，比方用户一分钟仅仅能够发送一条短信，忘记password的短信一天仅仅能发送10条、一个IP地址限制每天仅仅能发送100条短信等。
BUG
反复派息
15年的某一天看到一个新闻说是陆金所的一个用户发现自己银行里面突然多了非常多钱，没过多久又被扣走了。然后收到陆金所那边的解释。说是给用户还本派息的时候程序出现了问题导致还本派息两次。当他们程序猿发现了此问题后紧急进行了处理，用户当然闹了呀。就上了新闻。当然陆金所通道能力确实比較强能够直接从用户卡里面扣。当大家都兴致勃勃的谈论这个话题的时候。我却有一股淡淡的忧伤，为什么呢?由于这个错误我们也犯过，详细说就是我搞的。大家可不知道当时的心里压力有多大。
事情是这样子的，我们使用的第三方支付的扣款接口不是特别的稳定。于是我们前期就对接了两种不通的扣款接口，平时前端投资的时候走一个接口，后端派息或者还本的时候走另外的一个接口，在初期的时候扣款接口不稳定，因此在给用户跑批的时候常常会有个别用户失败。须要手动给失败的用户二次派息。
做为一个有志向的程序猿当然认为这样的方式是低效的，于是将程序改造了一下。在后端派息的时候当第一种扣款失败的时候，自己主动再次调用另外一种扣款接口进行扣款。当时想着这样的方式挺好的。各个环境測试也没有问题，上线之后监控过一段时间也运行稳定。
当我感觉一切都非常美妙的时候。事故就来了，突然有一天客服反馈说有的用户说自己收到的利息感觉不正确，好像是多了（真的是太感谢这个用户了），我登录后台看了一下派息的流水复核了一遍，果然利息被反复派了。一股冷水从头而下。把当天全部的用户派息记录和到期记录都进行了检查。影响了70多个用户，导致多派息了6万多元，幸亏仅仅是派息出了问题，假设是到期的话金额会翻N倍。当中70多个人里面有几个进行了体现、几个进行了再次投资，绝大部分用户在我们发现的时候还不知情，金额也没有动。
怎么处理呢。当然不能直接就动用户的钱了，给每个反复派息的用户打电话，说明原因赠送小礼物。请求谅解后我们把反复派过的利息在次调回来。大部分用户进行了核对之后都还是比較配合的，可是肯定有一些用户不干了，当然也不能怪客户，都是我的原因，有的客户须要上门赔礼道歉，有的客户须要公司出具证明材料，我们的老板亲自给客户打了N个电话被客户骂了N遍。我心里压力可想而知，当中有一个客户特别难缠，各种威胁说既然到了我的账户里面肯定是我的，你们的失误不应该让他来承担，折腾了非常久，还是不能怪客户。可能会说有的互联网公司常常出现这样的问题后就送给客户了。哎，我们是小公司呀！这个噱头玩不起。
究竟是什么原因呢。事后进行了复盘也给领导做了汇报，平时都是首先进行派息的定时任务，过一个小时之后进行到期的定时任务。当天的派息标的比較多，跑了一个半小时，就导致了派息和到期的两个定时任务同一时候进行。转账有了并发，第三方支付的接口不稳定给我们返回的失败。事实上有的是成功的。就导致了我们进行了二次的扣款尝试引发了此问题。
这个事情给我带来了非常大的教训。对于金融扣款的这样的事情一定须要慎重。哪怕付款引发报警之后在人工处理，也不能盲目重试可能引发雪崩效应。
杂七杂八
还有就是其他一些零碎的问题了，记的有一次对用户的登录过程进行优化，导致有一块推断少了一个括号结果用户在那两个小时内，仅仅要输入账户，随意password就能够登录了。幸好及时发现这个问题，正是这个问题才导致了我们正式确立了规范的上线流程，为以后的上线制度建定了基础。
另一次我们在模拟用户投资一种标的时候，留了一个入口通过http就能够调用，測试也没有问题。有一天正好给领导演示呢。就在次用http请求的方式在浏览器运行了一下，前端就会看到自己主动投标的过程。由于生产的数据有点多。投标的过程有点长，我们为了加快进度。找了好几个人同一时候来运行这http请求，导致最后出现了问题。最后发现写測试脚本的这个同事根本就没有考虑并发的情况，才导致出现了问题。
也做了非常多的活动，记得做一个网贷之家的一个活动的时候。活动上线比較紧张，我们团队以前连续工作超过30个小时（一天一夜再一天），当天晚上我2点左右写完程序，測试从2两点測试到早上9点，最终确认没有不论什么问题，才进行投产。半夜公司没有暖气，我们实在冻的不行了。就在办公室跑步。从这头跑到那头，第二天上线之后，又害怕出现故障。监控了一天，确认没有不论什么问题。才到下午正常下班回家，那时候真是激情满满呀。
说到做活动肯定少了羊毛党，说哪一家互金公司没有遇到过羊毛党那非常少见，并且如今的羊毛党规模简直逆天了，我们用户里面就有一个羊毛党在两三天之内邀请了六七千位用户，假设说邀请一个用户送1元。那这个用户就能够搞几千块一次，并且有非常多专业的站点、QQ群、微信公共账号都是他们的聚集地，那天那个平台有活动门清，他们写的淘羊毛操作手冊有时候比我们官网的帮助文档还清晰，所以做活动的时候要考虑特别周全，各种限制，有封定、有预案、讲诚信。仅仅要是符合我们活动规则的坚决依照流程走。
另一个有趣的事情，app推送。一次我在公交车上就看到xx盒子app弹出hhhhh的推送，这个事情我们也搞过，由于在调试的时候生产和測试就差了一个參数。有时候开发者不注意就把生产參数部署到uat环境了，測试一发送就跑到生产了。这方面仅仅能严格流产管理来防止了。
事实上还非常多问题：mongodb集群和mysql的同步出现的一些状况、后台大量数据查询下的sql优化、golang使用mapreduce碰到的问题… 限于篇幅这里就不一一清晰的描写叙述了。
事实上每次的出现故障都是对团队一次非常好的锻炼机会，通过发现问题，定位问题。解决这个问题。再次回过头来反思这些问题；又一次梳理整个环节，
举一反三避免下次再次出现相似的问题。
正是由于经历这些种种的困难、考验才让团队变的更强大更稳定，也更体现了流程的重要性。更是避免再次发生相似问题。
总结
古代对将军的要求是，心有万马奔腾而过，而面平静如湖水可照镜，在互联网行业对大牛的要求也同如此，特别是技术的负责人，在面对生产事故的时候。一定首先是安抚同事。静下下心来找到问题本质在去解决，而不是不断去施加压力催促解决。重压之下非常多心里承受能力稍弱的队友，更加慌乱而不利于解决这个问题或者引发二次事故。
在看淘宝双十一视频中，有一段特别受到感触，在双十一初期，尽管技术团队做了非常多的准备，可是在零点过后流量瞬间涌入。服务被打垮。部分用户投诉刷新不出网页，紧接着隔壁同事也都反馈站点打不开，在大家都在慌乱中，xx一拍桌子大喊一声，大家都别动，三分钟之后再说。过了几分钟之后服务慢慢部分恢复了正常。
后来回顾说，当时尽管服务瘫痪。可是监控还是有部分得业务成功。说明系统并没有被压垮，而此时的不论什么操作都有可能引发更大的问题，从此之后此人一战成名。成为阿里大将。
互联网平台发展大抵都会经历三个阶段：
1、上线初期，此阶段问题最为繁多，生产事故不断。系统高速迭代优化。有人说为什么不測试到全然没有问题在投产吗？说实话在互联网行业这个非常难，第一小公司非常难做到生产环境和測试环境一致，成本太高；时间紧迫。一般都是非常短的时间内要求上线。上线之后在高速迭代。
另外互联网本就是一个高速试错的行业。错过半年时间可能风口早过。
2、发展期，此阶段主要业务模式已经得到验证，系统出现故障的频繁度较少，低级错误降低，但此时是用户量和交易量不断爆发的时候，对系统性能、高并发的要求又上来了，所以此时出现的问题大多都是性能的问题；
3、成熟期，发展期过后系统相对照较平稳，用户量和交易量都已经慢慢稳定下来，生产问题越来越少，出现故障差点儿都是细小的bug，这个阶段也是公司最忽略技术得阶段，恰好我们公司就处于这个阶段，在这个阶段就须要静下心里。组织架构升级，补齐在初期和发展起所欠的技术债务，做好公司在升下一个量级的技术准备。
全部的这些问题差点儿都集中在14年底到15年初的这个阶段，15年后半年開始到如今平台慢慢稳定了下来，到如今差点儿没有再出现过相似的问题。也由于差点儿都是两年前的事情。有非常多记的不是特别清晰了，写的比較粗糙望见谅。
作者：清纯的微笑
出处：http://www.ityouknow.com/
版权归作者全部。转载请注明出处