机房流量问题总结分析

1 【提出问题】

【实际案例一】

凌晨 3:00 点某公司（网站业务）的一个 IDC 机房带宽流量突然从平时高峰期 150M 猛增至 1000M ，如下图：

该故障的影响：直接导致数百台服务器无法连接，该机房全部业务中断。

实际案例二】

某年某月某日夜老男 1 孩接到学生紧急求助，公司网站（ web 游戏业务）平时几十 M 带宽，结果突然跑满 100M ，持续 100M 已经很久。事后，该学生的总结开头如下，

凌晨一点接到报警短信，网站无法访问。立马拿起笔记本上网查看，发现整个机柜的网络都无法正常访问。第一感觉是不是IDC网络出问题了，给机房打电话反馈回来的信息是机房网络正常，但是带宽流量异常(100M带宽的流量峰值已跑瞒)。

该故障的影响：直接导致数十台服务器无法连接，该机房全部业务中断，且故障持续时间长。

【实际案例三】

某月某日，接到运维的朋友紧急求助，其公司的CDN源站，源站的流量没有变动，CDN那边的流量无故超了好几个G，不知道怎么处理？ 老男孩补充，曾遇到过一张图片不到一天，跑了20多T的一张流量。
该故障的影响：由于是购买的CDN，虽然流量多了几个G，但是业务未受影响，但是，这么大的异常流量，持续下去可直接导致公司无故损失数万元。解决这个问题体现运维的价值。

事不过三，暂时先举3个例子吧。这三个案例都是运维工作中实际遇到的故障，事发突然且需要紧急处理。在实际论坛或群里看到朋友反馈的此类问题，也多达数次，其中差不多各种鸟都有，老鸟、中鸟，小鸟。
大部分朋友解决起来，脑袋里没思路（反射弧直接定位DDOS），解决起来耗时长，造成的了业务长时间中断。老鸟解决起来也是按部就班，首先会反射为DDOS问题，结果解决时间加长了，如果能提前做好预案，恢复速度可能就会好很多，下面高手就来谈下个人的一些看法。

2  【分析问题】
1)IDC 带宽被占满的原因很多，常见的有：

a.真实遭受DDOS攻击（遇到过几次，造成影响的不多见，其中还有黑客勒索的案例）。
b.内部服务器中毒，大量外发流量（这个问题老男孩接警5次以上）

c.网站元素（如图片）被盗连，在门户页面被推广导致大量流量产生（接警3次以上）

d.合作公司来抓数据，如：对合作单位提供了API数据接口（有合作的公司的朋友了解这个）

e.购买了CDN业务，CDN猛抓源站（这个次数也不少）。

f.其他原因还有一些，不普遍就不提了。

2)CDN 带宽异常，源站没异常。

这类问题基本都是缓存在CDN的数据被频繁访问引起的。解决方法见结尾案例。

3) CDN 带宽异常，源站也异常。

可能原因如公司做推广，大量数据访问，热点数据cache里不全。或CDN问题导致数据回源（有关CDN回源率问题及提升回源率经验，以后再和大家分享）。影响就是带宽高，后端静态服务器及图片及存储压力大

3  【解决问题】
分析了问题的可能原因，就好比较排查了。

a. 真实遭受 DDOS 攻击

高手提供了17条解决经验思路，供大家参考，这里就不提了，那么实际上

遭受真实DDOS攻击并产生影响的并不是最常见的。

b. 内部服务器中毒，大量外发流量。

这个问题的解决比较简单，可能有的朋友说，看看服务器流量，哪个机器带宽高处理下就好了。其实不然，实际解决比这复杂得多，带宽打满，所有监控都是看不到的。
比较好的思路，是联系机房确定机房自身无问题后（机房一般没法帮我们的），请机房断开连接外部IP服务器的网线，如负载均衡器，仅保留VPN SERVER，然后断掉内部服务器出网光关的线路，切断外发流量源头。
接下来查看监控流量服务，判断外发流量的服务器，然后进行处理。
其实，这个问题的发生及快速定位和很多公司的运维规范、制度关系很大，高手在给一些公司做运维培训分享时发现这个问题很严重（表象很好，内部运维规范、制度欠缺很多），大家都讨论的很深入，实际用的还是和聊的有差距。。

比如有的公司开发直接FTP连接随时发布代码，或者由开发人员负责定时多次上线。而运维人员又不知晓，结果导致问题发生定位时间长，这点建议各公司的老大多思考下。
高手的运维思路是，如果把网站机房比喻为一座房子，那首先要堵住后门（内部），其次是监控好前门（做好安全，留个小窗户给外面人看，即80端口服务，同时安排站岗值班的）。
网站的无休止的随时随意发布代码，对网站的稳定影响是至关重要的。对运维人员对故障的定位快慢也很关键。根据老男孩不完全调查，约50%以上的重要运维故障都是程序代码导致的，这也是老男孩给企业做培训分享时，灌输建议CTO的，多把网站稳定的责任分给开发，而不是运维。如果这个思想不扭转，网站不稳定状况就难以改变。
c. 网站元素（如图片）被盗连
这个属于网站的基本优化了，apache,lighttpd,nginx都有防盗链的方案，必须要搞。说到这也提个案例，高手的一个学生，到了企业工作，发现人家网站没有防盗链，结果上来没有周知老大，直接做防盗链了,然后美滋滋的当时还给我留言，说给公司搞防盗链了，很有成就，结果导致公司对外合作的业务，都是小叉子了，幸亏发现的及时没出大问题。
d-e. 合作公司来抓数据，如：对合作单位提供了 API 数据接口或购买了 CDN 业务。

最常见的就是购买CDN服务，如：CDN新建一个节点（可能数十机器），直接来我们IDC原战来抓数据（有的做好点的夜里来抓）。把原站抓的流量暴涨，严重的导致服务宕机。几家CDN公司，都有过这样的问题。这点希望CDN公司看到了，能改善，毕竟用户上帝嘛。

当然和电信，联通，GOOGLE,BAIDU，词霸等公司的合作，也会有流量暴高的情况，这里面包括了为合作的站搜索引擎爬虫爬数据的问题。有时虽然带宽流量不高，但是服务器或数据库撑不住了，搜索引擎专门喜欢爬我们的站内搜索，DISCUZ，CMS等早期的开源程序的搜索都是全站like %%方式去数据库搜索的，几个爬虫过来，直接就挂掉了，当然这不是本文要讨论的，解决方案以后再聊。

f. 其他原因还有一些，不普遍就不提了。

上面的几点比较常见，其他原因就不多见了，因此，作罢，打这么多字真不轻松啊。

4  【苦练内功】

首先，高手强调下，大家要经常培养下自己的心里素质，遇到问题不能发慌。遇到不少朋友，处理紧急故障时，大脑都空白缺血了，手抖的无法敲击键盘了，这样的状态如何解决故障呢？如果老大在后面看着就更是雪上加霜了，甚至有个别学生直接跟高手哭鼻子了，宕机几分钟损失上万，负不起责任。

其实上面的大家的表现都是正常的，没什么不对的，曾经高手也是这样过来的，也是不断的挑战自己才练出来的。
希望朋友们能多提前做功课，不要问题来了在思考解决办法，临时的应对一定会是手忙脚乱的，即使是老鸟。如果提前有预案和防范演练，问题发生后就坦然得多，这可以扩展到运维的方方面面，DB,WEB,备份，恢复，流量等。
5  【亡羊补牢】

发生问题后，要充分总结，争取下次发生了，能提升速度，当然最好不发生。其实，运维人员挺悲催的，开发的下班就没事了，我们还得7*24开手机，来个短信提心吊胆的，甚至看到有个门户DBA发微薄，说making love时都可能被报警短信打断。1、提前优化运维制度、规范。2、提前优化网站结构、单点故障。3、留足备用带宽及服务器资源，把控好风险。4、完善的监控策略及响应机制等。

尽量不打无准备之战。兵法云，知己知彼，百战不殆。运维又何尝不是这个理？