下班前的一场暴风雨，让园子一片狼藉。顶着暴风雨，加了服务器，但无济于事。情急之中，断蛛求生立转机。
今天下班前的 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 所使用。
