服務器報警
7月24號下午5點半開始，突然服務器報警，檢查監控，發現CPU異常100%。
該服務器正常情況下CPU使用率在40%已經算高了，另外負載經過調試都保持在CPU承受范圍內。
系統負載同時飆升
數據包的量直上雲霄
TCP連接數上2W，正常情況下最多6K
最開始沒有處理，一般來說ddos不會持續太久，結果7點服務器開始響應變慢反饋，必須處理了，辛虧有隨身遠程應急預案。
此服務器代碼半年沒動過，之前都正常的，只是中午的時候更新了下漏洞補丁，原則上是不會導致這個問題才對。通過linux命令分析了一下相關的進程，應該不是補丁導致的，否則打完補丁就應該出問題，而不是等到5點。
一開始為了應付CPU過高的問題，懷疑是我之前設置的php-fpm子線程過大（500），服務器上下文頻繁切換，導致本身就已經高負載？索性就把值設為小到280試試看什么情況，但是並沒有好轉，php-fpm慢日志還建議調大，又調回之前的設置。
再來看數據包，已經要上天了，初步評估是ddos攻擊。
初步分析
經過了1個多小時的日志分析，定位到心跳寫數據庫異常，導致數據庫連接爆滿卡死，影響到了別的業務。所以禁用了該接口，服務器相對可用。
晚上11點多回到家，依舊沒有恢復的意思，並且還出現了每隔5分鍾一次攻擊（00:16之后）。決定用cache的inc記錄看一下接口調用情況。
基本上是每秒1K+的訪問，偶爾會有高並發，短時間調用了76W+次，其他接口幾乎為0，現在是接近凌晨2點鍾，理論上設備這個點鍾已經關的差不多了，而且默認設備是5分鍾調用一次心跳接口，不可能在這個時候大面積並發。
DDOS無誤，但是這個量好像有點小，並且一般也不會通過接口調用形式攻擊吧，阿里雲都沒有觸發ddos流量清洗。
進一步分析
接下來就是看哪個IP發送的了。用netstate查了下感覺好像又比較正常。
根據該方法的日志，看到這些IP在幾秒內調用接口300次左右，有些不可思議，但是這些IP確實是對應的設備IP，難道是被自己的設備DDOS了？！
再來5分鍾一次心跳，不就是監控中后來的5分鍾一次異常情況？每五分鍾會出現一次峰值。
但是他們是如何做到秒級的百次調用呢？除非APK有問題，但是之前又沒見出現？
再次深入分析，嘗試禁封某些設備IP無效，反而更加猖狂，應該是設備APK集體出現BUG了，導致實例化了N個線程同時進行接口調用……怎么辦？設備端的APK是友方開發，並且長時間沒有更新維護了，又沒辦法讓設備重啟，最后決定分析設備日志。
最終分析
第二天聯系運維人員取了一台並發量很高的設備日志。剛好這台設備記錄了事件的全過程，分析結果如下：
1、7月24號5點半之前，設備運轉良好
2、之后出現心跳時token失效的情況，然后開始以指數級新增心跳線程。
可以看到重新獲取token之后，就出現了2個心跳包發送請求
3、反編譯APK發現重新獲取token部分的代碼是有bug的
這里應該是if和else，否則在沒有重新獲取到token的情況下，又立馬執行一次runnable，導致又再次報錯一次。
4、這個異常情況只會在token過期的時候出現，正常情況理論不會過期，所以這個bug一直沒有發現。
分析出問題之后，服務端臨時去掉了token校驗，聯系友方修復bug，發布更新，問題解決。
總結
昨晚搞到4點鍾，今天繼續分析到4點，歷時10個小時心中的石頭終於落下。
1、設備端應至少有重啟指令，以防萬一。
2、一個小小的邏輯代碼，可以使服務器直接崩潰。
3、日志監控真的很重要。
4、對於一些特殊情況，普通的測試很難遇到，除非是有經驗的測試人員，否則只能等線上才能發現了。