起因：
發現源站流量階段性異常，基本上每2小時高發到50m左右，並持續30分鐘左右
排除過程：
在流量正常的時候，排查了各種可能性，均未果，觀察監控，在流量再次增大時，發現該伺服器上某一網域名稱的訪問日誌異常增大（如下圖），檢視ip為cdn的節點ip，所以聯絡cdn廠商，給出的解答是上層的回源探測鏈結，是在探測源站的可用性，但我們可以確認源站沒有問題，問到cdn為什麼該源站其他的**都沒有這種情況時，解釋到由於他們剛剛進行了系統公升級，會針對該問題加緊排除。
解決方法：
由於cdn服務商說解決該問題需要修改底層邏輯，所以時間會比較長，所以我們在源站增加了臨時限制方法，根據日誌可以看出訪問的客戶端為dorado，所以進行了客戶端訪問限制返回403的方法，在server段中增加下面**即可。
筆記 記一次mysql IN 大量ID優化方案
背景 基於某些業務開發過程中，會遇到這樣的查詢語句 select from table where id in 1,2,3 但是當in裡面的資料量非常大的時候，有些資料庫會對in 的資料量有大小限制，比如oracel大小限制是1000，因此如果能有一種替代in 大量資料，並且效能還不錯的方案就好了。...
記一次statspack錯誤處理
客戶資料庫警告日誌顯示，經檢查是由statspack自動排程指令碼引起的。quote thu jul 22 12 30 14 2010 errors in file oracle admin fysb bdump fysb j000 1805.trc ora 12012 error on auto ...
記一次git amend事故處理方案
問題是git commit amend 引起的。一條commit已經push到遠端develop了，但是後來又在這條commit上進行了amend操作，導致這條commit的雜湊碼發生了變化。並且後續又在這條commit之後進行了n條commit操作。大概的情況畫了個簡圖，如圖所示。下面的綠色就是最...