口水記
今天和朋友聊天，他說，今天出了一個事故，由於以前的一個設計問題，今天在線上操作了某個需要消耗服務器和數據庫大量資源的動作（稱爲a操作吧），暴露出了設計和性能的問題，導致接口的後續響應超時，從而出現了線上問題。
聽了朋友的全程描述，我精簡一下導致出現問題的原因：
- 當初數據庫未考慮到後續功能的一個迭代，導致業務實現複雜，每一次操作a都需要大量的資源
- 在幾個月前，有想過優化，但是由於業務等原因，擱置了
- 當初和操作人約定過不在白天高峯期操作，但是隨着人員的流動，口頭約定並沒有交接
事故已經發生，無法避免，那麼我先讓我朋友先將事故產生的髒數據進行處理
然後再總結一下事故
事故總結至少應該包含以下幾點
- 事故導致的現象
- 責任人
- 產生的原因
- 優化方案
- 後續如何避免
關於前面所說的三個原因，在這裏，我分別講一下方案，當然，我也是給我朋友的建議，不一定是最好的，所以歡迎大家來提出更好的建議
關於設計的一個缺陷，導致a操作需要大量的資源，那麼這種情況首先應該考慮的是去重構，改進設計，而不是其他邊邊角角的優化，很簡單，這個設計缺陷不改動，一旦隨着後續業務迭代，人員流動，出現致命的宕機纔想改動時，這個代價，實在是太大了。
其次，在當時如果真的是業務很忙，來不及，那麼很簡單，給a操作限流，加大配置（這裏有一個比較有意思的地方，我那朋友的數據庫最大活躍連接數當時配置的是20，明顯是不夠的，具體需要多大，按照公司業務峯值來計算，參考磁盤的I/O讀寫來評估）。通過限流（只限制a操作），其實可以很大程度解決一個其他請求過來超時的情況。
那麼第三點，口頭約定，這個就比較迷了，在工作上的事情，口頭約定不靠譜，不靠譜，不靠譜。
如果在需求上沒有做，那麼就要做一個硬性的控制，例如在接口上控制a操作的一個次數，時間等，加上硬性限制。也花不了多少時間。
最後，大家在設計之初，就要考慮全面一點，否則不是給自己留坑，就是給他人埋雷。