有句話叫每一起嚴重事故的背後，必然有 29 次輕微事故和 300 起未遂先兆以及 1000 起事故隱患。
而我最近更是碰到了 3 起比較嚴重的線上事故，都是大意惹的禍。
一、數據庫鎖死
第一起事故發生在凌晨 4 點到 6 點，我們有個數據庫被鎖死了，無法更新和寫入。
當天早上 5 點客服打電話給我，把我吵醒後緊急搖人，打電話給運維，打了 5 次纔打通，他也馬上開機排查。
原因很簡單，就是有一張表，記錄極速增長，超出了數據庫的限定容量（1TB），從而導致庫被鎖，馬上擴容。
去年對這張表做過一次清理，但當時沒有引起重視，造成了今天這場事故。
幸虧這個數據庫大部分的使用場景是管理後臺，所以線上業務沒有造成太大的損失，不過小範圍內有點影響。
後續動作
將線上重要的業務與這個數據庫做剝離，也就是不再依賴這個數據庫。
對那張極速增長的表做剝離，即遷移到另一個數據庫中，對於量比較大的各類日誌數據，單獨創建一個數據庫，統一管理。
對此表做定期清理，例如只保留 3 個月的記錄，其餘全部刪除。
二、Redis 服務故障
第二起事故發生在凌晨 2 點，不過就持續了 30 秒，看來夜深人靜的時候比較容易滋生意外。
雖然只存在了 30 秒，但仍然影響了 221 個用戶。排查下來是 Redis 服務連接異常，導致服務意外重啓。
在重啓過程中，那些請求都無法被處理，從而讓業務無法響應。
在確認不是代碼邏輯造成的異常之後，開始搖運維，讓他去找服務供應商，
一開始服務商認爲是某個 Redis 命令阻塞了請求，不過在仔細覈對代碼後，發現並不是這樣。
於是再次去挑戰服務商的維護人員，故障發生的時間也再一次縮小了範圍。
最終確認在那個時間有主備切換操作（不定期），導致了報錯。
後續動作
一開始就僅僅是將切換時間改成凌晨的三點，但是隨後幾周又出現了 Redis 的連接問題。
雖然時間只有 20 多秒，不過還是影響了小部分的線上業務，對用戶體驗造成了極其糟糕的影響。
再次搖運維，讓他去溝通解決，一開始他覺得這麼短的時間應該問題不大，可以將升級時間配置到我們在辦公的時間。
好像有點道理，但是細究下來，還是有點問題的，對於用戶來說，他們只看結果，若自己碰到了異常，那麼就會認定你的系統不穩定。
他們只會在意 0 和 1，不會在意你這異常發生的概率是多少，影響的範圍是多少。
所以後面繼續和運維拉扯了一下，他了解到可以從單區升級成雙區，這樣就能在升級的同時而不影響線上業務。
不過，在升級期間，還是會有 30 秒左右的斷開時間，但各項緩存配置不用單獨做修改。
三、海外短信盜刷
短信服務已經被應用到日常業務的很多模塊中，主要用於身份的驗證，本事故與短信直接相關。
前兩個事故並沒有造成經濟損失，但海外短信盜刷造成了比較大的經濟損失。
攻擊持續了 3 天，很巧的是，正好碰到雙休日，大家都不在工位的時候。
第一天盜刷後，運維受到了費用受限的通知，告知了服務端，服務端再告知了我們組。
然後當天就讓運維把短信總量降一半，爲盜刷的國家增加每日的短信上限，我們組修改短信接口，接入風控保護。
隔了兩天是週六，發現又在被刷，原來是手機號碼和 IP 一直在變化，繞過了風控策略，並且運維並沒有對所有的國家配置短信上限。
服務端在風控保護的代碼中直接關閉了海外短信，原先設想是臨時關閉兩天，因爲我們組的業務只會影響極小部分的用戶。
結果服務端忘記發佈代碼，導致第三次被刷。
後續動作
首先將每日的海外短信上限調整到更小的數量，再縮小一半。
其次是設置海外國家白名單，如果爲所有國家配置上限數量，不僅工作量大，而且還會有遺漏的隱患。
再有，查看日誌發現，攻擊者的手機號碼都是隨機生成的，因此，我們可以做一次身份校驗。
因爲我們使用到短信的業務都會有身份信息，所以可以對手機號進行校驗，只有是數據庫中的手機才能發送短信。
這部分的短信業務已經存在許久，但是一直沒有引起我們的安全意識，非常脆弱，服務端之前也被攻擊過，後面做了防禦。
還有一種短信防禦，就是加驗證碼，在發送接口中核對驗證碼，只有是合法的，纔會提供發送服務。