事發

某日下午，部門使用的測試環境出現問題，所有整合測試case都執行失敗。查詢測試用伺服器發現是磁碟已滿，造成請求失敗。

應急處理

發現磁碟空間問題後，首先想到的是程式日誌過大，因為這臺機器上部署了部門的幾十個應用,以前也出現過日誌造成磁碟空間不足的問題。所以，迅速執行日誌刪除，發現整合測試case都可以正確執行了。

但是過了不一會，發現某些應用報服務已宕機。再去伺服器看，磁碟空間又滿了，而且刪除之後，幾分鐘磁碟就會再次填滿，速度十分之快。應急之下首先增加了一個2分鐘清理一次的定時指令碼，但是磁碟空間告急。

尋找問題原因

這時候，只能看增長最快的日誌檔案，然後去看具體是什麼東西列印了這麼多的日誌。查詢發現是閘道器的請求量達到了4k的qps，因為是內網所以懷疑是有人在進行壓測，分析請求之後發現基本都是同事負責的一個介面的流量。詢問發現，下午執行了壓力測試，但是壓測平臺出了問題，不能正常停止壓測。估計問題就找到了。

封鎖請求進入

但是，和壓測平臺負責的同事溝通，他們說已經殺死了壓測程式，而且壓測機沒有root許可權，不能進行tcpdump。很無奈，壓測平臺的同事也是信誓旦旦，覺得不是自己平臺的問題。

無奈之下，我們進行了對流量的分析和封鎖，進行請求引數、來源ip的封鎖。但是封鎖之後發現來源ip是公司的一個出口ip，導致其他業務的測試環境調我們調不通了。這種情況下，暫時讓其他業務方使用ip地址直連我們的測試環境。

定位請求的內網ip

最終的最終，我們找到了一種可以定位到來源內網ip的方法，用鐵一般的證據證明就是壓測平臺的幾臺機器在向我們發請求，才推動壓測平臺的同事重啟伺服器，從而徹底關閉了傳送請求的程序。

我們採用的方案是：在請求接入層針對來源流量執行一個301跳轉，跳轉到一個內網ip地址，這樣就可以抓取到來源的內網ip了。