古人云：“知己知彼，百戰百殆”
容量預估
對於電商大促場景一般都需要進行容量規劃及故障演練。容量規劃，就是通過對複雜業務場景的分析，應用一定的技術手段，如壓力測試、來實現對資源合理擴容、有效規劃的過程。
對於電商而言，一般的核心鏈路就是交易鏈路，簡易描述就是用戶能夠成功登陸、然後能通過瀏覽商品詳情頁進行下單訂購，或者先將意向商品先加入購物車，之後通過購物車進行訂購結算，在這期間會進行各種優惠的價格處理、庫存判斷等，最後還要能夠支付成功，這樣一個交易支付流程纔算完成。
當然，當大促的峯值時刻時，場景又有可能不同，因爲絕大部分用戶早已將意向商品加入購物車，且各種優惠券也已經申領成功，就等着那個時刻下單了。
之前進行傳統的預測方式一般是在測試環境下，針對場景進行數據模擬，需要開發、測試、運維等人員根據線上的場景，評估可能出現的情況，這種方式更依賴於人的經驗。常用的工具包括Apache Benchmark、LoadRunner（收費）、Jmeter等，這種做法非常不準確，很難模擬出接近prod環境的場景和數據。
現在中大型的互聯網公司普遍採用全鏈路壓測的方式，如京東的ForceBot、阿里巴巴的全鏈路壓測平臺（其對應的雲產品PTS，價格還是蠻貴的）。一般全鏈路壓測平臺在接入層的請求入口進行真實流量複製（如網易開源的TCPCopy），這樣開源簡化模擬數據帶來的成本，將複製的請求引入壓測環境，對壓測環境的服務進行施壓。另外若要加大壓力，開源通過調節TCPCopy的參數，將流量先蓄積（如通過MQ工具）。在DB一側通過影子庫及影子表進行隔離，影子表和生產表建立相同的表結構，通過打tag進行區分，便於隔離刪除。
一般全鏈路壓測需要注意什麼呢？
1.找到核心流程。做全鏈路壓測還是需要巨大的成本，不可能做全，遵循80/20原則，這是壓測的目標
2.選擇隔離方式。一種是進行環境的獨立隔離，但資源成本高，另一種是和prod混合，這種方式真實性更高，節省資源，但隔離性不好
3.縮小依賴服務範圍
故障演練
說起故障，運維們都想起了背鍋俠，開發及運維同學都害怕故障，有的公司雖然制定了應對策略，但是這些策略在沒有測試的情況下誰也不敢輕易啓動，害怕引起更嚴重的故障。
XX互聯網公司因爲網絡原因導致大規模故障，中斷幾個小時，是因爲沒有災備嗎？可能不太可能。雖然他們做了災備，但是因爲很長時間沒有測試過了，所以不敢切換。故障演練正式爲了解決“不敢切換”的問題。
另外不是有了故障演練就敢切換，而且還要結合應急預案及應急指揮中心。
Netflix開源了Chaos Monkey，Chaos Monkey是一個在生產環境隨機選擇並關閉服務的工具。隨後，阿里巴巴也開始進行了故障演練，阿里也有一個故障演練工具，叫：MonkeyKing，爲每年的雙11 活動做準備，不過現在都基本不維護了，MonkeyKing可以模擬硬件故障、API故障、分佈式故障、數據庫故障燈
當然故障演練不僅開源檢驗業務應用處理失敗的能力，也可以用戶處理失敗的能力，也可以用於當故障發生時，如何快速有效地發現並定位故障，通知相應運維人員進行處理，更重要的是，完善我們的應急預案，避免有類似情況發生。
最後，容量規劃及故障演練是一件非常重要的事宜，不是一個人承擔，有時需要整個開發團隊、運維團隊、DBA、測試、甚至還有運營團隊/客服/公關等一起參與討論，同時制定應急預案，成立應急指揮中心（例如阿里的全球運行指揮中心GOC）