下班前的一場暴風雨，讓園子一片狼藉。頂著暴風雨，加了伺服器，但無濟於事。情急之中，斷蛛求生立轉機。
今天下班前的 17:00~17:30 左右，身份未明的爬蟲暴風雨般地襲擊園子，造成資料庫連線過萬，全站當機，由此給您帶來很大的麻煩，請您諒解。
最終我們透過給百度蜘蛛斷網才恢復正常，造成暴風雨的爬蟲不一定是百度蜘蛛，由於缺乏足夠的資料，這次襲擊園子的爬蟲身份無法確認。
給百度蜘蛛斷網，是為了減少伺服器的總負載，在上次故障時我們只遮蔽了一個網段（255個IP）的百度蜘蛛，還有大量百度蜘蛛每天在園子裡爬來爬去，雖然這些蜘蛛被關在籠子裡（限制了頻寬），但依然會給伺服器帶來不小的壓力，讓園子在暴風雨來襲時格外弱不禁風。
百度蜘蛛專用負載均衡 QPS 監控圖：
非常抱歉！園子這段時間故障有點多。
曾經的一系列故障公告，是我們魯莽走進雲端計算時代初期的痛苦代價。
現在還未成系列的故障公告，也許是 AI 時代即將到來的被代價。
不管怎麼樣，不管是代價還是被代價，AI 時代真的要來了。
【更新】
3-30 11:40 左右：又出現資料庫連線數飆升問題，又是透過給百度蜘蛛斷網恢復正常。
3-30 12:10 左右：試著解除百度蜘蛛的斷網，放出後 pod CPU 與資料庫連線數立馬飛快上升，只能繼續拉閘。
3-30 12:30 左右：將百度蜘蛛專用負載均衡的頻寬限制由130M大幅下調至50M，再次放出百度蜘蛛進行觀察。資料庫連線數由1700左右上升至3000左右，這個連線數在可以承受的範圍。12:40 左右可以開始，資料庫連線數穩定在2000左右。
3-30 14:20 左右：資料庫連線數拉伸至4000多，將百度蜘蛛專用負載均衡的頻寬限制進一步下調至30M，並增加1臺伺服器，讓資料庫連線數的拉昇變成了雲霄飛車。
3-30 14:50 左右：資料庫連線數飆升至7000多，部分 pod CPU 過載，給百度蜘蛛斷網，並遮蔽了來自微軟 azure 的一個網段 40.*.*.0/24 ，才控制住。
3-30 15:05 左右：資料庫連線數又飆升至6000多，追加來自微軟 azure 的一個網段 157.*.0.0/16，才再次控制住。
3-30 15:17 更新：從目前情況看，對於今天下午出現的問題，遮蔽微軟 azure 網段效果最明顯。
3-30 16:05 更新：透過 dns 反向解析確認被遮蔽的 azure 網段是微軟 bing 爬蟲之一 msnbot 所使用。