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

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

DDoS攻击趋势及缘故原由剖析

php棋牌游戏前端棋牌游戏平安解决计划 Vue.js

对付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配置文件中的最大连接数为10243。

在抢标过程中连续不雅观察,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年后半年开始到现在,平台逐步稳定了下来,到现在险些没有再涌现过类似的问题,也由于险些都是两年前的事情,有很多记的不是特殊清楚了,写的比较粗糙看见谅。