輕松應對IDC機房帶寬突然暴漲問題！
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回源率問題及提升回源率經驗，以后再和大家分享）。影響就是帶寬高，后端靜態服務器及圖片及存儲壓力大（解決辦法見老男孩的7層門戶網站架構案例文章http://oldboy.blog.51cto.com/2561410/736710）
3 【解決問題】
分析了問題的可能原因，就好比較排查了。
a.真實遭受DDOS攻擊
DDOS問題的解決老男孩已經寫了原創文章（http://oldboy.blog.51cto.com/2561410/845349），提供了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、完善的監控策略及響應機制等。
盡量不打無准備之戰。兵法雲，知己知彼，百戰不殆。運維又何嘗不是這個理？
6 【實戰解決案例】
說了這么多了，都是理論，再給個案例吧【摘自老男孩Linux培訓-shell培訓教案中的例子】，這里要特別感謝白開水兄弟給予的支持。
下面的例子適合於網站流量很高，但是，還沒達到全網癱瘓的嚴重地步時的解決方案，適合我們自己的IDC機房及CDN業務（如果是CDN,那么，分析處理可以交給CDN，自己下載CDN日志分析也可）。
范例7：分析圖片服務日志，把日志（每個圖片訪問次數*圖片大小的總和）排行，取top10，也就是計算每個url的總訪問大小
說明：范例7的生產環境應用：這個功能可以用於IDC及CDN網站流量帶寬很高，然后通過分析服務器日志哪些元素占用流量過大，進而進行優化裁剪該圖片（見老男孩發布的《淘寶的雙十一超大流量應對文章點評》），壓縮js等措施。
本題需要輸出三個指標： 【訪問次數】 【訪問次數*單個文件大小】 【文件名（可以帶URL）】
解答：
測試數據
59.33.26.105 - - [08/Dec/2010:15:43:56 +0800] "GET /static/images/photos/2.jpg HTTP/1.1" 200 11299 "http://oldboy.blog.51cto.com/static/web/column/17/index.shtml?courseId=43" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
59.33.26.105 - - [08/Dec/2010:15:43:56 +0800] "GET /static/images/photos/2.jpg HTTP/1.1" 200 11299 "http://oldboy.blog.51cto.com/static/web/column/17/index.shtml?courseId=43" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
59.33.26.105 - - [08/Dec/2010:15:44:02 +0800] "GET /static/flex/vedioLoading.swf HTTP/1.1" 200 3583 "http://oldboy.blog.51cto.com/static/flex/AdobeVideoPlayer.swf?width=590&height=328&url=/`DYNAMIC`/2" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)"
124.115.4.18 - - [08/Dec/2010:15:44:15 +0800] "GET /?= HTTP/1.1" 200 46232 "-" "-"
124.115.4.18 - - [08/Dec/2010:15:44:25 +0800] "GET /static/js/web_js.js HTTP/1.1" 200 4460 "-" "-"
124.115.4.18 - - [08/Dec/2010:15:44:25 +0800] "GET /static/js/jquery.lazyload.js HTTP/1.1" 200 1627 "-" "-"
法一：通過兩個數組來計算
因為我們要的最終結果是某個文件的訪問次數和消耗的流量，所以考慮建立以文件名為索引的兩個數組，一個存儲訪問次數，一個保存消耗的流量，這樣當使用awk按行遍歷文件時，對次數數組+1，同時對流量數組進行文件大小的累加，等文件掃描完成，再遍歷輸出兩個數組既可以得到該文件的反問次數和總的流量消耗。
[root@locatest scripts]# awk '{array_num[$7]++;array_size[$7]+=$10}END{for(x in array_num){print array_size[x],array_num[x],x}}' access_2010-12-8.log |sort -rn -k1|head -10 >1.log
法二：
[root@locatest scripts]# awk '{print $7"\t" $10}' access_2010-12-8.log|awk '{S[$1]+=$2;S1[$1]+=1}END{for(i in S) print S[i],S1[i],i}'|sort -rn|head -10 >2.log
[root@locatest scripts]# diff 1.log 2.log
[root@locatest scripts]# cat 1.log
57254 1 /static/js/jquery-jquery-1.3.2.min.js
46232 1 /?=
44286 1 //back/upload/course/2010-10-25-23-48-59-048-18.jpg
33897 3 /static/images/photos/2.jpg
11809 1 /back/upload/teacher/2010-08-30-13-57-43-06210.jpg
10850 1 /back/upload/teacher/2010-08-06-11-39-59-0469.jpg
6417 1 /static/js/addToCart.js
4460 1 /static/js/web_js.js
3583 2 /static/flex/vedioLoading.swf
2686 1 /static/js/default.js
本文出處：http://blog.51cto.com/oldboy/909696
推薦：
CDN回源案例故障1：http://finderz.blog.51cto.com/1527507/504194
http://oldboy.blog.51cto.com/2561410/845349
http://oldboy.blog.51cto.com/2561410/736710