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

游戏行业综述——机遇与风险并存

对于游戏而言，遭受到攻击是一件很常见的事情，据统计国内一半以上的DDoS攻击都是针对游戏行业的。目前游戏行业总体而言是机遇与风险并存的，2017年中国网游市场规模已经突破了2000亿，但是网络游戏却也是DDoS攻击的头号重灾区，其实不仅仅是中国，全球市场上针对于游戏的DDoS攻击永远是排在第一位的，而在中国这样的现象则更加严重，尤其在是从今年春节之前一直到3月份延续的这波攻击中，很多游戏厂商一直被DDoS攻击所压制。除此之外，移动端的快速增长也带来了移动安全问题，另外还出现了利用欺诈手段或游戏漏洞破坏游戏环境的现象。

DDoS攻击趋势及原因分析

对于DDoS攻击而言，其平均防御成本随着DDoS攻击流量的增长呈现出加速向上的曲线。根据计算数据分析得出：如果DDoS攻击流量达到250G，每个月的防御成本大约会需要5万美元左右；如果达到300G就会需要每月6万美元；达到350G时防御成本则需要每月8万美元；如果达到500G攻击流量，那么防御成本则需要14万美元，也就是每个月需要花费大约一百万人民币去进行DDoS攻击的防御。在2017年，300G以上的攻击已经呈现常态化了。而对于DDoS攻击每小时所造成的商业价值损失而言，据数据统计36%的应用被攻击一小时的损失在5000美元到2万美元之间，34%在2万美元到10万美元之间，还有15%被攻击时每小时损失会超过10万美元。

除此之外，根据黑客攻击的时间维度数据也能分析出一定的规律性：基本上在每天的凌晨3点到9点之间，黑客攻击将会处于睡眠期，这个时间段其实属于黑客换装弹药的时间，在这个时间段，他们会把第二天需要攻击对象的名单和需要使用脚本准备好，当早上9点的时候，黑客的脚本就会自动运行然后开展新一波的攻击，所以在早上9点到凌晨3点之间这段时间，黑客的攻击是比较频繁的。

另外，目前国内主要有两大黑产组织，这两个组织也是遍布整个东南亚地区的，他们的最顶层组织处在中国境外，而且他们所掌握的攻击流量已经超过了1个T。大家可以想象一下，这样的攻击流量其实对于任何一家游戏公司或者应用而言都将会是致命的，黑产组织中最大的拥有800G的攻击流量，小一些则拥有的大约600G的攻击流量，所以他们基本上有能力将任何一个游戏公司攻击到挂掉。而目前在阿里的威胁情报系统中已经将这两大的危险组织的肉鸡分布进行了区分。

今天，黑客发起攻击的成本其实会非常低，比如对于海外的UTB小包而言，一个G一天只要花费50元，即便是最贵的DNS反射攻击也只要1个G一天350元。但是黑客显然不是这样报价的，比如黑客盯上了某一个游戏，就会去以包天或者包月或者按照效果付费的方式进行购买攻击包，一定会将游戏服务打死，甚至会提供打不死不收钱的“包打死”服务。前一段时间大家应该都看到了小蚁网络的吴翰清在自己的公众号上发了一篇文章谈了他回到阿里的29个月。其实这篇文章中也谈到了，在2016年的时候小蚁网络打击了刚才提到的两个黑产组织中的一个，在打击之后在几个月的时间之内，整个中国的黑产组织其实就消失掉了，国内的DDoS攻击量也下降了56%，同时全球的DDoS攻击量也下降了8%，但是因为黑产组织的核心组织人员都在中国境外，半年之后这个组织就又死灰复燃了。

对于实际的攻击手法而言，由于攻击源是在逐年增加的，以前只有针对PC的攻击，后来出现了针对服务器端的攻击，曾经有数据统计大约50%以上IDC的服务器都被黑客成功入侵并成为了肉鸡，而现在还有针对于手机的攻击，很多人的手机其实都处于黑产组织的控制之中，而且现在很多的IoT设备纷纷加入了DDoS攻击的浪潮之中，也将DDoS攻击的流量逐年推高。在2014年的时候DDoS攻击还是以50GBPS为主，攻击手法以IDC伪造源IP攻击为主。而在2015年时，攻击100Gbps 的攻击已经常态化了，攻击手法也在升级，从伪造IP转向反射型Flood攻击。2016年时，200Gbps 的攻击常态化，IoT和移动终端的兴起导致基于真实设备的攻击层出不穷。而在2017年的最近两三个月，大家所看到的趋势是300Gbps 的攻击常态化，并且基于私有协议和真实源的攻击事件呈指数级上升趋，导致攻击更加难以防范。

那么黑客为什么会攻击游戏行业呢？首先可能是发泄自己的不满，有些同学对于游戏产生了不满情绪，那就可能为了发泄自己的不满将游戏打挂掉。还有黑产接单打单，比如两家竞争同一市场的游戏公司，其中一家公司就有可能找黑产对于对方的业务进行打击。还有敲诈勒索，小蚁网络也遇到很多客户说自己曾收到了黑客在微信或者QQ上面的勒索流言，要求给对方钱财否则将对游戏业务进行攻击。还有业务扶持，黑产也会与一些行业中的公司进行合作，扶持某家公司成为行业的龙头老大，其他的竞争对手就会全部被打死。最后就是机房合作，黑客会要求一些游戏厂商必须搬到某个机房中，如果不然就进行攻击。所以就是出于以上的种种原因，地下黑产才形成了今天这样对于游戏客户的攻击形式。

而且黑客的具体攻击手法也非常多样，可以拿“打尖峰”举例说明，比如大家都知道小蚁网络上5个G黑洞，此时黑客就不会持续地使用很高的流量进行攻击，因为他们知道黑洞的原理所以就会使用5.01G的流量进行攻击，这样游戏公司的IP就进入黑洞了，黑客就会主动摸索游戏公司的的业务防御上限在哪里，然后通过打尖峰的手法对游戏进行攻击直到服务挂掉。另外一种打法就是压制一个时间段，比方某一种游戏会在每天早上9点到9点半之间有大量的玩家涌入进来玩，如果在这半个小时内将游戏的登陆服务压制掉就能够导致游戏无法提供服务，这样就会导致玩家转到其他游戏。而最可怕的一种攻击手法就是最近出现的持续压制，也就是游戏从早到晚都会处于300G的流量攻击之下。以上主要是按照攻击的时间段进行划分的，而如果按照更细粒度攻击手法进行划就可以分为以下两种攻击：

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

趋势一：大流量已经常态化

目前，对于DDoS攻击而言出现了两个极为明显的趋势。

第一个趋势就是大流量攻击已经呈现常态化。黑客已经可以在极短的时间内聚集大量的攻击流量，这种大流量压制型攻击在之前可能只是个传说，而从今年的情况看来，大流量攻击已经成为了现实。随着带宽成本逐年降低，肉鸡资源的逐年丰富，大流量压制型攻击已经不再是业界的“都市传说”，高入口带宽也已经不再是攻防的保险箱，已经无法实现与攻击流量进行“军备竞赛”，因此现在也是时候需要考虑对于应对大流量攻击采取一些变革了。

趋势二：CC攻击向精细化转变

第二个趋势就是CC攻击向精细化转变，攻击的载体从IDC肉鸡到IDC和家庭肉鸡，再到IDC、PC移动端设备最后到IDC、PC、IoT和移动端设备不断转变，攻击手法也从半开链接攻击到TCP资源攻击再到服务器资源供给最后到模拟私有协议发起攻击不断变化，攻击的手法越来越细化，防御难度也越来越高。其实很难做到安全防御既能够防御大流量的攻击也能够防御精细化的攻击，这也是进行安全防御时可能出现今天能够防护住但是明天却又防不住情况的原因，因为黑产也在不断试探并打击游戏的弱点。

欺诈与作弊

另外两种威胁就是欺诈与作弊，比如垃圾注册、撞库以及流量作弊等。

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

破解与外挂

还有两种威胁就是破解与外挂，包括了客户端破解和伪造数据包。

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

云盾游戏安全解决方案

小蚁网络的云盾所提供的其实是全方位游戏安全解决方案。针对于DDoS攻击，云盾提供了DDoS高防IP和游戏盾。DDoS高防IP的防护峰值带宽20~300Gbps，并且防护阈值可以弹性调整；而游戏盾是云盾中创新性的防御DDoS攻击的手段，当攻击流量超过300G时就可以使用游戏盾进行防御，目前游戏盾能够防御的DDoS攻击已经达到了600G左右。除此之外，云盾还提供了针对移动安全和数据风控的解决方案。

游戏安全之一- DDoS高防IP服务

DDoS高防是一项针对海量DDoS攻击的清洗服务，防护能力高达300Gbps。DDoS高防IP服务其实是多线的，有电信线路、联通线路还有BGP线路，其通过CName解析或者将VIP贴到高防中心上去的方式将流量引过去再将流量还原给用户，但是DDoS高防服务的上线却只能达到300G，300G以上就会受限于机房带宽的能力了。

游戏安全之二- 游戏盾服务

游戏盾服务采取的对抗手段再也不是进行安全攻防的“军备竞赛”这样依靠带宽去对抗带宽的手法了，而是采用流量拆分和智能调度方式去防护DDoS攻击。其原理其实非常简单，就是黑客在同一时间只能够找到几十台服务器中的一个IP地址，最多将这个IP地址的服务器打挂掉，但是无法将整个服务打挂掉，所以游戏将能够保全大部分的客户而只有很少的客户会受到损失，通过这样的方式去防护游戏。针对于CC攻击，游戏盾实现了多层的精细化的CC防护，目前看来其效果也非常好，对于今天大家看到的针对大型游戏公司的CC攻击而言，20万QPS已经非常常见了。而且游戏盾不仅仅是一个产品而是一整套的服务体系，其也在不断地对于攻防能力进行提升。

游戏安全之三-移动端安全

对于移动端安全而言，主要进行的是应用加固，通过安全组件将移动端应用的协议加密，并进行安全存储和加密防止黑客破解。

游戏安全之三-业务风控

对于业务风控而言，如果应用是一个Web客户端，黑客就可能进行垃圾注册等进行攻击，这样采用业务风控的手段就可以防止黑客刷应用的接口。

实际案例分析

接下来为大家介绍一些使用小蚁网络云盾所提供的安全解决方案的实际案例。

案例一

在2014年，小蚁网络第一次将自己的DDoS服务进行商业化，也是在这一年，小蚁网络的一个游戏客户遭遇了全球历史上最大规模的DDoS攻击，攻击流量达到了453.8G，并且持续攻击了大约28个小时。而小蚁网络当时也帮助客户成功地防御住了这长达28个小时的DDoS攻击，当时采用了BGP带宽帮助客户进行防御，但是其实BGP带宽的防御成本是所有防御带宽中最高的。

案例二

第二个案例则是大家比较熟悉的，就是闲来互娱的实际案例。闲来互娱是2016年4月份成立的游戏公司，其主要游戏业务是地方棋牌游戏，它刚开始时发展非常迅速，但是却在5月和6月份时被DDoS攻击打击得非常惨烈，使得其业务基本上无法开展并且接近倒闭边缘。这时小蚁网络向闲来互娱提供了安全防护解决方案，并且小蚁网络和闲来互娱合作将安全解决方案应用到了其整个游戏攻防体系中去。而在4月份到11月份被昆仑万维以20亿的价格收购之间的4、5个月的时间内其经历了2次大型的攻击对抗。第一次对抗发生在安全解决方案部署完成之后，黑客很快发现仅靠大流量攻击完全打不下来，于是黑客开始破解游戏客户端，将游戏客户端破解之后就发现了游戏客户端中对于流量调度的原理，这样就能够把所有的IP防护节点全部找出来，之后对于找出的节点进行逐个打死。所以小蚁网络帮助闲来互娱在第一轮对抗中做的就是将应用进行加密，并将逻辑进行混淆，这样就使得黑客难以在同一时间发现更多的节点的IP地址，而最多一次只能获取一个节点的IP。在第二轮攻防中，黑客发现使用大流量攻击无法打下来，但是使用CC攻击却非常有效，于是他们使用CC攻击的手法去攻击登录服务，而大家都知道登陆服务相当于应用的入口，当登陆服务受到攻击时就发现防御能力急剧下降，即便其他的游戏节点都正常也是无济于事，不能起到任何作用了，所以小蚁网络此时推出了NGCC防护能力，使用NGCC防护之后即便是50万QPS也能够轻松防御，基本上就保护住了闲来互娱的第二轮攻击，一直到其被收购之前都保证游戏运行非常平稳。

案例三

还有一个案例是2016年2月的另外一个游戏公司在一个月的时间内连续被攻击了多次，并且攻击流量超过了400G，而这个流量在2016年初时是非常高的，这个公司同样也快被打挂了，此时小蚁网络帮助其启用了高防 游戏盾的安全解决方案，同时帮助该公司实现了态势感知和溯源，也帮其找到了在背后进行攻击的黑客并通过游戏公司报警，小蚁网络提供证据最后将犯罪嫌疑人捉拿归案，这也是反击能力的体现。大家知道很多游戏公司被攻击之后往往是打不还手的，其实并不是因为游戏公司脾气好，而是往往通常情况下游戏公司并不知道到底谁在发起攻击，所以如果客户拥有了溯源的能力就可以找到在背后对自己发起攻击的那个人并将其绳之以法，同时也将会为自己的业务赢得一定时间的安全发展时机。

案例四

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 攻击？根据我的个人经验总结了几条：

• 第一种方案：隐藏服务器外网地址，服务器前端加 CDN 中转，免费的有百度云加速、360网站卫士、加速乐、安全宝等，如果资金充裕的话，可以购买高防盾机，用于隐藏服务器真实 IP，域名解析使用 CDN 的 IP，所有解析的子域名都使用 CDN 的 IP 地址。此外，服务器上部署的其他域名也不能使用真实IP解析，全部都使用CDN来解析；
• 第二种方案，买一些安全产品来进行流量清洗，主要是阿里云、腾讯云这种大厂商提供的服务。
• 第三种方案，有很多的防火墙产品声称可以防止 DDOS 攻击，但是我个人使用感觉效果非常有限。

3、SQL注入

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

• 第一，PHP 一般在前端使用的较多，受攻击的机会更多一些，Java一般做为后端服务，攻击的可能性会比较少；
• 第二，PHP 框架较多，而且很多早期的框架并没有特别考虑 SQL 注入的情况。Java 大量普及了 Mybaits、Hibernate 等 ORM 框架，框架本身对常见的 SQL 注入有防御的功能，但不是说他们就没有被 SQL 注入的可能，大部分场景下是 OK 的，另外参数化查询可以有效的避免 SQL 注入。

通过一段时间的学习，我发现，黑客一般先使用工具对网站做整体的扫描，类似 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) 去掉投资过程中的更新热点：标的进度表。每次投标成功或者失败都需要对标的进度表进行更新，多线程更新的时候就会出现乐观锁等问题。去掉过程中的更新，只在满标后将标的进度信息保存在标的进度表，优化投资过程中对数据库的压力。

其它攻击：

其它方面的攻击，主要是在业务方面，比如我们当初有一个很小的失误，有一个程序员在 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年后半年开始到现在，平台慢慢稳定了下来，到现在几乎没有再出现过类似的问题，也因为几乎都是两年前的事情，有很多记的不是特别清楚了，写的比较粗糙望见谅。