我曾看到充满激情的创业团队、一个个玩法很有特色的产品，被这种互联网攻击问题扼杀在摇篮里； 也看到过一个运营很好的产品，因为遭受DDoS攻击，而一蹶不振。

这也是为什么想把自己6年做游戏行业DDoS的经验，与大家一起分享，帮助在游戏领域内全速前进的企业，了解本行业的安全态势，并给出一些可用的建议。

• 大流量压制，也就是通过海量的流量涌过去将整个机房都堵上。
• 精细化压制，使用CC攻击实现的精细化流量压制，目前往往以同时使用或者先后使用的方式配合大流量压制实现。

• 垃圾注册，玩家大量注册小号，获取新号奖励和刷金币。
• 流量作弊，渠道商利用模拟器等手段批量挂机，进行流量作弊，获取非正常利益。
• 游戏盗号，攻击者利用自动化工具，通过扫库撞库等方式进行盗号。

• 游戏破解，破解客户端游戏程序，免费获得游戏内购，改变游戏设定。
• 内挂，通过破解游戏和数据包结构，逆向出或直接调用发
• 包函数，改变正常游戏数据，实现超出正常玩家的水平和能力。
• 脱机挂，完全脱离游戏客户端程序，可以与游戏服务器自由通讯的外挂程序，对游戏的危害最大，严重破坏游戏平衡，缩短游戏运营周期。无论是手游还是端游在被破解之后都可以做外挂，还能够通过破解协议报文模拟数据并发送到服务器上去，消耗游戏的资源使得正常玩家也无法进行游戏。

2015年应该是互联网金融行业受黑客攻击最多的一年吧，各互金公司都深受其害，当时我记得*贷之家有一段时间被黑客攻击的太厉害，连续几天网站都无法打开。当然我们也未能幸免，DDoS 攻击、SQL 注入、漏洞渗透等等，几乎都经历过，有的黑客比较仁慈，应该是出于善意或者展示自己，将漏洞放到乌云上面或者漏洞盒子里面让厂商来修复。但更多的是一些黑产，完全就是威胁、敲诈、想捞一笔钱，先看看下面这位吧：

这个家伙潜伏到我们公司的客户群里面，冒充我们的客户代表将头像和资料替换成一样，然后给群里所有的客服发消息，让发送我们内部的后台地址给他，想通过这种方式来寻找突破口，当然这是里面的小菜鸟。

DDoS攻击

DDoS 攻击我们也遇到了很多次，确实没有比较好的办法，最后都是通过一些笨办法来尽量避免的，先说说我们的经历吧。有一次我正在敲代码，客服 QQ 又闪烁了起来，还没来得及打开查看，客服的经理就直接打电话过来了，我立刻一种不祥的预感，他说官网打不开了，后台也登录不了。

挂了电话，我在本机进行了测试，果然不行，立刻准备登录 VPN 查看服务器各项指标，结果登录不上去，马上上楼找运维经理，他也登录不上，刚准备给机房打电话的时候，机房来电话了，说我们的一个 IP 正经历着 1G 多的流量访问，问我们是否正在做什么活动，话没说完，就又说流量已经到 5G，不到一分钟之后流量已经到达 18G 之多。

因为我们的机房和集团公用了一个入口，结果集团上面陆续反馈他们的网站、服务也都出现了问题，机房方面害怕引起更大的冲击，直接把我们官网对外的IP封掉了，集团的其它业务才慢慢恢复了过来，我们也紧急更换了外网IP，重新切换了域名解析后才恢复。

事后我们根据 Apache 分析了日志，流量来自N多个不同的IP地址根本无法应对，也是因为这次攻击，我们领导重视了起来，将我们公司的机房网络层和公司集团彻底分离。这样不管哪一方受到大流量攻击都不会相互影响。

当然我们也想了一些笨办法，因为上次我们更换了外网 IP 之后攻击也就停止了。那么我们认为肯定是针对我们外网来的，所有我们就准备了多个外网 IP，当监控到某一个外网IP被攻击时，马上切换到另一个外网IP，这样可以起到非常有限的一点作用，因为如果黑客真的想跟我们玩，这个办法就像是小孩子捉迷藏。

周年庆的DDOS攻击

还有一次我们正在做周年庆活动，突然有人在 QQ 群里面给我们客服说：叫你们的技术负责人来找我。然后我们的网站就挂了，我还保留了当时的一个截图如下：

后来也和领导进行了商议，坚决不能给他们钱，不能助长这种嚣张气焰，实在不行就报警！曝光一下当年使用的假 QQ 号，刚查了下变了个头像和描述，如下：

后来我一直在想：为什么 DDOS 攻击总是喜欢根据外网 IP 来攻击呢？后来慢慢有些理解了，如果针对域名来攻击的话，那不就是攻击到域名商的服务器了吗？而一般域名商比较强大，黑客不太搞的定，也确实没有必要。当然记的前一段时间，某著名域名服务商被攻击，导致国外 Twitter 等著名的互联网公司访问中断达半天以上，还是很严重的。但是对于我们这样的小公司，倒不至于搞这么大的动作。

那到底如何正确的防止 DDOS 攻击？根据我的个人经验总结了几条：

3、SQL注入

我们的官网使用的是 PHP 开发，因为框架比较老旧的原因，存在着一些 SQL 注入的点，我们发现后进行了修补，没想到还是被一些黑客找到了突破点。这里要感谢这些黑客在漏洞盒子上提交的 Bug (如下图)，最后我们根据提示进行了紧急修复，后来我们也在 WAF 防火墙配置了一些拦截 SQL 注入的策略，起到双保险的作用。我一直在想为什么 PHP 一般比较容易出现 SQL 注入，而 Java 较少呢？我估摸着有两方面的原因：

通过一段时间的学习，我发现，黑客一般先使用工具对网站做整体的扫描，类似 Acunetix，再根据扫描出来的漏洞做个大概的分析，但是比较深入的漏洞都需要根据网站的业务再进行调整，比如 SQL 注入会根据页面的查询使用 sqlmap 等工具来进一步的渗透。当然我对这方面还是外行，描述的不够清晰。

案例五：
一次dns缓存引发的惨案

时间2015年的某个周六凌晨5点，公司官方的QQ群有用户反馈官网打不开了，但有的用户反馈可以打开，客服爬起来自己用电脑试了一下没有问题，就给客户反馈说，可能是自己网络的问题，请过会在试试。早点8点，越来越多的用户反馈官网无法打开，并且有部分用户开发反馈app也打不开了，客服打电话叫起了还在梦乡中的我。

分析定位

被客服叫起来之后，一脸懵逼，不知道什么情况，给客服回复，知道了，立刻排查，待会有消息及时沟通。用凉水洗了一把脸清醒了一下，立刻根据经验回忆这两天生产投产的情况：上线了XX模块，不影响、修复了XXbug，应该也不影响、刚给服务器配置了https，看起来好像有点关系，但是app暂时没有投产https，怎么也出现问题，排除之。打开电脑核查了最近的投产记录应该都不至于发生这么严重的问题，随怀疑是不是网络方面有问题，立刻打电话叫起来运维经理以及相关人等一起排查。

一边让网络和运维排除问题，一边再次核查了web服务器、数据库服务器、业务日志、数据库日志，以及其它的一些监控数据，各项皆正常。试着在本机ping了一下域名确实不通，更加怀疑是网络问题，尝试这直接使用外网访问官，可以打开没有问题，可以基本确认服务没有问题，但运维部反馈网络设备什么都正常，肯定是你们投产代码出问题了，各方硬着头皮继续在排查。

9点，群里开始有大规模的用户反馈官网和app都打不开了，更有部分用户煽动，XXX公司跑出了（15年很多p2p公司跑路，导致用户都成了惊弓之鸟，稍微有问题便害怕公司跑路，个个都锻炼成了监控高手，天天看，实时刷，凌晨起来尿尿也都顺便看一下app上的今日收益），客服400热线基本被打爆了。一边继续排查问题，一边上报此问题给总监、公司各高管，给客服建议，给用户解释，IDC机房网络抖动，技术正在紧急解决，资金和数据都没有任何影响，稍安勿躁。

10点，开发和运维反复的检查后，开始怀疑dns解析有问题，但具体是什么问题还不清楚，CTO决定：1、大家都打车往公司走，来公司集体解决 2、在各QQ群、微信群给用户群发解释xxx问题，安抚客户。在车上的时候重新梳理了一下用户的整个访问流程，如下图：

到公司后，根据这个思路大家在一起验证了一下，通过外网IP和内网IP访问公司所有服务都正常，但是通过域名访问不行，另外监控服务器、防火墙、网络设备日志都正常，因此断定是DNS解析出现问题。

攻坚问题

既然确实是DNS解析问题，那么问题又来了？为什么DNS解析会出现问题？如何去解决这个问题？一边给万网提工单，我们也自己测试一下电信、移动、联通在不同的网络运营商下面的访问情况，发现只有在联通网络的环境下DNS解析不了。根据客服得到的反馈也验证了这个情况，电信和移动用户反馈很少，联通用户反馈最多。于是我们又开始给联通打电话，刚开始联通不受理我们的这个请求，于是又开始以用户的身份打电话给联通公司让立刻解决不能上网的问题。

于是就开始了万网和联通的扯皮大战，万网说从他们那边查看DNS解析都正常，一起指标都正常，我们又给联通打电话联通说我们已经知道了，待会由专业的人给我们回复，过了一会联通的网络工程师回复说，像这种情况一般都是域名解析的问题。早上10:30到公司开始短短的6各小时内，我们几个轮流给联通公司合计供打了近50、60通电话，给万网提了N个工单，接了N个电话。

期间领导也开始动用各种关系，联通内部的朋友、网络运维界的大拿帮忙来定位解决，我们也尝试了很多的办法，比如，使用ipconfig/flushdns命令清除本机的DNS缓存、在万网的官网把DNS解析重新更新一边、删除在重新添加等等，也不是完全没有收获。我们一直想找一个可以测试各个地方、运营商网络的办法，终于在各方推荐和搜索的情况下找了17ce 和 360奇云测两个网站，感觉非常实用，在以后的网络定位中，成了我必备使用的工具，可以非常方便的监控各个运营商、各个地区网站的访问是否通不通、访问的速度快不快等问题，截图如下：

我们也发现，公司的其它域名也都访问正常，就是官网的这个域名和相关的子域名不通。期间很多人都问了一个问题就是你们的域名有没有忘了缴费，刚开始大家也都问了运维这边说是没有这个问题，直到中午12:30的时候在我们再三的追问下才说8点多的时候登录上万网的时候显示这个域名是欠费状态，但是他已经立刻把费用补了上去了。哎呀差点把我们气死，问了不是域名到期有提示的吗？才知道因为上一个运维经理走后，他们没有及时的更新万网的电话和邮箱导致提示邮件和短信也没有收到。

通过和万网、联通公司、领导的相关朋友沟通以及我们的测试观察，初步明白了这个事情的原因：域名忘记缴费导致万网的DNS解析被停止，用户本机或者DNS服务器有缓存，所以部分用户可以访问部分用户不能访问；缴费过后万网的DNS已经进行了更新和推送，但是DNS解析有很多的层级需要一级一级的往下面发送更新，有的层级并没有更新到，导致部分没有更新到的DNS服务商下面的用户不能访问官网。

和万网进行了沟通，问最延迟的情况所有的DNS更新到最新的时间，回答是48小时内肯定都会好的，但是我们等不起呀，随着时间的推移越来越多的用户发现问题，QQ群、微信群已经沸腾，董事长也开始关注次问题，有的客户直接在群里面说，你们的技术太不给力了(像这种还是委婉的，有的直接打电话骂人)…

临时解决方案

不断的通过17ce测试发现，大部分地区的网络都已经恢复，就剩北京联通和部分地区联通网络环境下不通，也说明了这几个地区下的DNS解析记录没有被更新。那么既然我们在上面已经定位出了问题，又了解是什么原因，就想着试着换个DNS解析服务器会不会好一点呢，于是我们把本地的DNS地址换成8.8.8.8（谷歌的DNS服务解析）发现好了！于是赶紧先写解决手册发给着急的客户来使用。

官网的用户可以通过更改DNS来解决访问的问题，APP怎么办呢？没有办法我们也不能等，直接找开发人员把客户端调用的地址由域名暂时先改为外网的IP地址打一个版本供用户临时使用。安卓还比较好办，直接让用户下载安装使用还好，但是IOS那时候的审核最少都需要一周黄花菜都凉了。其实iPhone手机可以单独设置DNS的，我们进行了设置和测试后发现也可以实现，于是马上更新到手册中发送给客服发送到群里面给用户使用。

点击下载当时写的DNS更新手册

有人说直接让用户使用外网就行了吗，使用外网首页打开到是没有问题，但是各系统之间调用，相关配置文件里面写的也都是域名的地址，如果硬改的话可能会引发另外的问题。第一天搞完就10点多了，中间就4点吃了一顿饭，打了N个电话大家都非常累，于是当天就先这样了，第二天大家一早到公司继续跟进。

第二天到公司经过17ce测试发现所有的节点都已经通了就剩北京联通的两个接点没响应，但是北京是我们的大本营，绝大部分的用户都是北京的，继续和万网、联通沟通看怎么能彻底的解决这个问题，另一方面做好最坏的打算，如果一直不通怎么办。在生产环境中梳理所有使用域名的配置文件，做好随时可以直接更新为外网地址而不能影响服务，app完整的重新做一个版本，做好随时可以投产让用户强制升级到外网直连的版本。

到第二天晚上10点的时候，北京联通的这两个节点还是不通，和领导进行了商议如果到周一早上8点来的时候这两个网络还是不能通的话，就上线改造好的系统和APP强制升级（因为当时周末还没有标的，周内才有发标计划）。第三天早上起来的第一件事情就是拿起手机，查看自己的联通网络是不是可以登录上官网，结果通了！皆大欢喜。

俗话说真理是愈辩愈明，经过了这次事故，也彻底的让我了解了DNS解析的整个过程。

DNS 解析流程

DNS( Domain Name System)是“域名系统”的英文缩写，是一种组织成域层次结构的计算机和网络服务命名系统，它用于TCP/IP网络，它所提供的服务是用来将主机名和域名转换为IP地址的工作。俗话说，DNS就是将网址转化为对外的IP地址。

dns从用户访问到响应的整个流程

• 第一步：浏览器将会检查缓存中有没有这个域名对应的解析过的IP地址，如果有该解析过程将会结束。浏览器缓存域名也是有限制的，包括缓存的时间、大小，可以通过TTL属性来设置。
• 第二步：如果用户的浏览器中缓存中没有，操作系统会先检查自己本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
• 第三步：如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。
• 第四步：如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/ip参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。
• 第五步：如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性。
• 第六步：如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找域名域服务器，重复上面的动作，进行查询，直至找到域名对应的主机。
• 第七步：如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。

这个事情发生后给了我们很大的教训:
第一、流程管理有漏洞，离职交接不到位；
第二、危机处理不成熟，影响公司声誉； 
第三、监控机制不完善，像外网不通的这种问题，应该提前设置监控措施。

有时候非常的严重的问题，就是你常常忽略的小不点

案例六：
一次生产事故的优化经历

在一次正常的活动促销之后，客服开始陆续反馈有用户反应在抢标的时候打不开网页或者APP，在打开的时候标的就已经被抢光了，刚开始没有特别的上心，觉得抢标不就是这样吗，抢小米手机的时候也不就这样吗？随着活动继续推进，有更多的用户强烈抗议，用户领了加息卷或者抵现卷之后抢不上标的，认为是平台作假故意不让使用以达到节省资源。

分析过程

其实以前也会有陆续的用户反馈不减少，给客户以小米抢手机为例子忽悠了过去，这次用户反馈太过强烈，才让我们重视了起来。我们前端一共三款产品，app、官网、H5，其中app使用量最大，官网其次，H5平时使用量极少但是做活动期间流量会暴增（活动一般都是H5游戏居多，H5也便于推广营销）,前端的三款产品都是分别使用lvs负载到后端的两台web服务器中（如下图），这次用户反馈基本在web和app端，所以重点观察这四台服务器。

首先怀疑网络带宽是否被涌满，找到网络工程师通过工具来监控，在抢标的时候带宽最高使用率只有70%左右，随排除之；再次怀疑web服务器是否抗不住了，使用top命令查看官网负载的两台服务器，在抢标的瞬间会飙到6-8左右，抢标后也慢慢的恢复了正常，app两台服务器高峰到10-12，随后也恢复正常。

跟踪web服务器业务日志，发现在数据库更新层报请求不到新的数据库连接或者数据库连接已经用完，认为是数据库的最大连接数太小，于是调整mysql数据库最大连接数为以往的3倍；下次抢标的时候继续观察业务日志，发现已经不报数据库链接的相关错误了，但还是很多用户反馈抢标时候打不开页面。

继续跟踪web服务器，在抢标时使用命令（ps -ef|grep httpd|wc -l）查看httpd得连接数有1千左右，随机查看apache配置文件中设置的最大连接数为1024（apache默认的最大连接数为256），原来抢标期间连接数已经到达最大连接数，很多用户在抢标的过程中已经获取不到http连接导致页面无响应或者app一直在等待中。于是调整apache配置文件中的最大连接数为1024*3。

在抢标过程中继续观察，apache的连接数在抢标的时候仍然可以飙到2600-2800之间，根据客服反馈，仍然有很多用户反馈抢标的问题，但比之前稍微好一点，但是有零星的用户反馈已经抢到标的，最后又给回退了。然后继续观察数据库服务器，使用top命令和MySQLWorkbench查看mysql主库和从库的各项负载吓一跳（如下图），mysql服务器主库的各项指标均已经达到峰值，而从库几乎没有太大压力。

跟踪代码发现，三端的业务代码全部连接主库，从库只有后台的查询业务在使用，于是立刻启动改造；将除过抢标过程中的查询外，其它页面或者业务的所有查询改造为查询从库，改造之后观察，发现主库的压力明显减少，从库的压力开始上来了。如下图：

根据客服的反馈，改造之后抢到标回退的问题几乎没有了，抢标过程中页面打不开或者打开慢的问题有一定的缓解但仍有部分用户反馈此问题，根据上面各项目分析结果得出：

• 1 负载的两台服务器均已经达到处理的极限，需要配置更多的服务器来负载。
• 2 mysql主库的压力明显减少，但是从库的压力却上去了，需要将现在的一主一从已从改为一主多从的模式。
• 3 彻底解决这些问题，需要综合考虑平台的整体优化，如：业务优化（去掉业务中热点）、增加缓存、部分页面静态化（可以使用雅虎和谷歌的前端优化规则，网上也有很多的测试网站可以评测）等等。

当时根据这些情况写了一份优化的报告,见下文：

优化报告

1 背景

随着公司业务不断发展，业务量和用户量的激增，官网pv也从最初的xxx-xxx到现在的xxx-xxxx，APP活跃用户更是大幅增加；因此也对平台目前的技术架构有了更大的挑战。特别是近期平台标源紧张的情况下，满标的时间更是越来越短。服务器的压力也越来越大；因此需要升级目前的系统架构，以支持更大的用户量和业务量。

2 用户访问示意图

目前平台有三款产品面对用户，平台官网、平台APP、平台小网页；其中平台官网和平台APP的压力比较大。

3 存在的问题

用户抢标的时候问题集中在以下几个方面
1、网页或者APP打不开
2、网站或者APP打开慢
3、抢标过程中转账成功后，因为服务器负责压力大更新失败，再次退款
4、数据库连接数用完，导致满标后添加投资记录失败，回退标的进度

4 分析

通过对近期的服务器参数，并发量，以及系统日志等进行深入的分析，得出：
1、平台官网、平台APP抢标过程中服务器压力巨大，其中平台APP问题更加突出，抢标高峰期间单台APP服务器apache最大连接数已经接近2600，接近apache最大的处理能力

2、数据库服务器压力巨大。数据库压力主要在两个时期比较突出
1）当平台做活动的时候，官网、小网页、APP访问量巨增，导致数据查询量跟着巨增，当到达数据库处理极限时，就会表现出网站打开慢等问题；
2）当用户抢标的时候，用户抢标的压力又分为两个阶段：抢标前和抢标中。抢标前，因为满标速度很快，用户提前打开抢标页面不断刷新，这样数据库的查询压力会不断增大，如果抢标的用户量非常大，会导致在抢标之前将数据库连接数用完；抢标中，单次购买大概会涉及15张左右表进行更改查询，每个标的份额1000万大概每次会有100-200人左右购买完成满标，以中间值150人计算，在几秒的时间内需要对数据更新2000-3000次(仅仅是更新，不包括查询 )，产生大量并发，可能会导致更新失败或者连接超时，从而影响到用户投标和系统正常满标。

5 解决方案

1、web服务器解决方案
单个用户访问web服务的示意图

目前网站和平台APP均是采用了两台服务来做均衡负责，每台服务器中安装了apache来做服务端接受处理，每台apache最大可以处理大约2000条连接。因此理论上目前网站或者APP可以处理大于4000个用户请求。如果要支持同时1万的请求，则需要5台apache服务器来支持,因此目前缺少6台web服务器。
升级服务器后的访问示意图

2、数据库解决方案
当前数据库的部署方案

1)主从分离解决主库80%的查询压力。目前平台官网、APP均连接mysql主库导致主库压力倍增，把服务中的查询全部迁移到从数据库可以大量减轻主库的压力。

2)增加缓存服务器。当从库查询到达峰值的时候，也会影响主从的同步，从而影响交易，因此对用户经常使用的查询进行缓存以达到减少数据库的请求压力。需要新增三台缓存服务器搭建redis集群。

3、其它优化
1）官网首页静态化，从cnzz统计来分析，首页占比网站的整体访问量的15%左右，对于首页不经常变动的数据通过静态化来处理，提升官网打开的流畅度。

2）apache服务器的优化，开启gzip压缩，配置合理的链接数等

3) 去掉投资过程中的更新热点：标的进度表。每次投标成功或者失败都需要对标的进度表进行更新，多线程更新的时候就会出现乐观锁等问题。去掉过程中的更新，只在满标后将标的进度信息保存在标的进度表，优化投资过程中对数据库的压力。

6 服务器升级方案

1、平台最大的压力来自于数据库，需要将现在的一主一从，改为一主四从。官网/app/小网页产生的大量查询，由虚IP分发到三台从库，后台管理查询走另外的一个从库。数据库需要新增三台服务器
数据库升级后的示意图

2、增加缓存减少数据的压力，需要新增两台大内存的缓存服务器

3、需要新增三台web服务器分解用户访问请求

app需要新增两台服务器
在抢标过程中app服务器压力最大，需要新增两台服务器，配置完成后的示意图

官网需要新增一台服务器
官网在抢标过程也有一定的压力，需要新增一条服务器，完成后示意图如下：

总合计之后需要购置8台服务器，其中有两台要求有大内存（64G以上）

其它攻击：

其它方面的攻击，主要是在业务方面，比如我们当初有一个很小的失误，有一个程序员在 H5 的网页中将发送短信验证码返回了前端，最后被黑客发现了，利用这个漏洞可以给任意的用户重置登录密码；短信攻击，现在的网站几乎都有发送短信或者短信验证码的功能，如果前端不做校验，黑客会随便写一个 for 循环来发短信，一般系统的短信会进行全方位的防控，比如：前端加验证（字符验证码，有的是拖拽的动画）;后端根据用户或者 IP 加限制，比如用户一分钟只可以发送一条短信，忘记密码的短信一天只能发送10条、一个 IP 地址限制每天只能发送100条短信等。

4、BUG

重复派息

2015年的某一天看到一个新闻说是陆金所的一个用户发现自己银行里面突然多了很多钱，没过多久又被扣走了，然后收到陆金所那边的解释，说是给用户还本派息的时候程序出现了问题导致还本派息两次。当他们程序员发现了此问题后紧急进行了处理，用户当然闹了，也上了新闻，当然陆金所通道能力确实比较强可以直接从用户卡里面扣，当大家都兴致勃勃的谈论这个话题的时候，我却有一股淡淡的忧伤，为什么呢？因为这个错误我们也犯过，具体说就是我搞的，大家不知道我当时的心里压力有多大！

事情是这样子的：我们使用的第三方支付的扣款接口不是特别的稳定，于是我们前期就对接了两种不同的扣款接口，平时前端投资的时候走一个接口，后端派息或者还本的时候走另外的一个接口，在初期的时候扣款接口不稳定，因此在给用户派息的时候经常会有个别用户失败，需要手动给失败的用户二次派息。

做为一个有志向的程序员当然觉得这种方式是低效的，于是将程序改造了一下，在后端派息的时候当第一种扣款失败的时候，自动再次调用第二种扣款接口进行扣款，当时想着这种方式挺好的，各个环境测试也没有问题，上线之后监控过一段时间也运行稳定。当感觉一切都很美妙的时候，事故就来了，突然有一天，客服反馈说，有的用户说自己收到的利息感觉不对，好像是多了（真的是太感谢这个用户了），我登录后台看了一下派息的流水，复核了一遍，果然利息被重复派了，感觉一盆冷水从头而下。

我把当天所有的用户派息记录和到期记录都进行了检查，发现影响了70多个用户，导致多派息了6万多元，幸亏只是派息出了问题，如果是到期的话，金额会翻N倍，其中70多个人里面有几个进行了提现、几个进行了再次投资，绝大部分用户在我们发现的时候还不知情，金额也没有动。怎么处理呢，当然不能直接就动用户的钱了，只能给每个重复派息的用户打电话，说明原因并赠送小礼物，请求谅解后，我们把重复派过的利息再次调回来。

大部分用户进行了核对之后都还是比较配合的，当然肯定有一些用户不干了，但你也不能怪客户，因为都是我的原因。有的客户需要上门赔礼道歉，有的客户需要公司出具证明材料，我们的老板还亲自给客户打了N个电话，被客户骂了N遍，我心里压力可想而知。其中有一个客户特别难缠，各种威胁，说既然到了我的账户里面，肯定是我的，你们的失误不应该让我来承担，折腾了很久，还是不能怪客户。你可能会说有的互联网公司经常出现这种问题后就送给客户了，哎，可是我们是小公司呀！这个噱头玩不起。

到底是什么原因呢，事后进行了复盘也给领导做了汇报：平时都是首先进行派息的定时任务，过一个小时之后进行到期的定时任务，当天的派息标的比较多，跑了一个半小时，就导致了派息和到期的两个定时任务同时进行，转账有了并发，第三方支付的接口不稳定，给我们返回失败，其实有的是成功的，就导致了我们进行了二次的扣款尝试，引发了此问题。这个事情给我带来了非常大的教训，对于金融扣款的这种事情一定需要谨慎，哪怕付款引发报警之后再人工处理，也不能盲目重试，极有可能引发雪崩效应。

杂七杂八

还有就是其它一些零碎的问题了，记的有一次对用户的登录过程进行优化，导致有一块判断少了一个括号，结果用户在那两个小时内，只要输入账户，任意密码就可以登录了，幸好及时发现这个问题，正是这个问题才导致了我们正式确立了规范的上线流程，为以后的上线制度奠定了基础。

还有一次我们在模拟用户投资一种标的时候，留了一个入口通过 http 就可以调用，测试也没有问题，有一天正好给领导演示呢，就再次用 http 请求的方式在浏览器执行了一下，前端就会看到自动投标的过程。因为生产的数据有点多，投标的过程有点长，我们为了加快进度，找了好几个人同时来执行这个 http 请求，导致最后出现了问题，最后发现写测试脚本的这个同事根本就没有考虑并发的情况，才导致出现了问题。

也做了很多的活动，记得做一个网贷之家的一个活动的时候，活动上线比较紧张，我们团队曾经连续工作超过30个小时（一天一夜再一天），当天晚上我2点左右写完程序，测试从2两点测试到早上9点，最终确认没有任何问题，才进行投产。半夜公司没有暖气，我们实在冻的不行了，就在办公室跑步，从这头跑到那头，第二天上线之后，又害怕出现问题，监控了一天，确认没有任何问题，才到下午正常下班回家，那时候真是激情满满呀。

说到做活动肯定少不了羊毛党，哪一家互金公司没有遇到过羊毛党？而且现在的羊毛党规模简直逆天了，我们用户里面就有一个羊毛党在两三天之内邀请了六七千位用户，如果邀请一个用户送1元，那这个用户就可以搞几千块一次。而且有很多专业的网站、QQ群、微信公共账号都是他们的聚集地，那天那个平台有活动门清，他们写的淘羊毛操作手册有时候比我们官网的帮助文档还清晰，所以做活动的时候要考虑特别周全，各种限制，有封定、有预案、讲诚信，只要是符合我们活动规则的坚决按照流程走。

还有一个有趣的事情，是App 推送，一次我在公交车上就看到某盒子 App 弹出 XXX 的推送，这个事情我们也搞过，因为在调试的时候生产和测试就差了一个参数，有时候开发人员不注意就把生产参数部署到 uat 环境了，测试一发送就跑到生产了，这方面只能严格流程管理来防止了。

其实还很多问题：mongodb 集群和 mysql 的同步出现的状况、后台大量数据查询下的 sql 优化、golang 使用 mapreduce 碰到的问题… 限于篇幅这里就不一一描述了。其实每次出现问题都是对团队一次非常好的锻炼机会，通过发现问题，定位问题，解决问题，再次回过头来反思这些问题，重新梳理整个环节， 举一反三避免下次再次出现类似的问题。

正是因为经历这种种的困难、考验才让团队变的更强大、更稳定，也更体现了流程的重要性，更避免了再次发生类似问题。

总结

古代对将军的要求是，心有万马奔腾，面如湖水平静，在互联网行业，对领导的要求也如此，特别是技术负责人，在面对生产事故的时候，一定是先安抚同事，静下心来找到问题本质，再去解决，而不应该不断去施加压力催促，重压之下很多心里承受能力稍弱的队友，会更加慌乱，不但不利于解决问题，还可能引发二次事故。

在看淘宝双十一视频中，有一段感受特别深，在双十一初期，虽然技术团队做了很多的准备，但是在零点过后流量瞬间涌入，服务被打垮，部分用户投诉刷新不出网页，紧接着隔壁同事也都反馈网站打不开，在大家都在慌乱中，XX一拍桌子大喊一声，大家都别动，三分钟之后再说，过了几分钟之后服务慢慢恢复了正常。后来回忆说，当时虽然服务瘫痪，但是监控到有部分业务成功，说明系统并没有被压垮，而此时的任何操作都有可能引发更大的问题，从此之后此人一战成名，成为阿里大将。

互联网平台发展大抵都会经历三个阶段：

1.上线初期，此阶段问题最为繁多，生产事故不断，系统快速迭代优化。有人说为什么不测试到完全没有问题再投产？说实话在互联网行业这个很难：

2.发展期，此阶段主要业务模式已经得到验证，系统出现问题的频度较少，低级错误减少，但此时是用户量和交易量不断爆发的时候，对系统性能、高并发的要求又上来了，所以此时出现的问题大多都是性能的问题；

3.成熟期，发展期过后系统相对比较平稳，用户量和交易量都已经慢慢稳定下来，生产问题越来越少，出现问题几乎都是细小的 bug。这个阶段也是公司最忽略技术的阶段，现在我们公司发展到了这个阶段，在这个阶段需要静下心来，做组织架构升级，补齐在初期和发展期所欠下的技术债务，做好公司进入下一个量级的技术储备。

所有的这些问题几乎都集中在14年底到15年初的这个阶段，15年后半年开始到现在，平台慢慢稳定了下来，到现在几乎没有再出现过类似的问题，也因为几乎都是两年前的事情，有很多记的不是特别清楚了，写的比较粗糙望见谅。