前言
多年前入職了現在的公司，當時還沒有完整的異常測試的體系，后來根據自己的經驗結合現狀，幫助公司建立了一套異常測試的流程和文檔，和另外的同學一起設計了異常故障注入平台，也完成了一些演練的落地，在這里做一些總結。
kv故障演練
kv即key-value數據庫，業界普遍使用的有redis、zookeeper等，和關系型數據庫如mysql相比一般只提供對key的CRUD等的簡單操作，讀寫速度卻快很多。
kv在我們現在的系統中有幾種使用用途：
- 用於緩存數據，將數據庫的數據緩存到kv里，減輕大量查詢對數據庫訪問的壓力
- 用於臨時數據的存儲，比如鎖、登陸態、記數器等
由於之前線上出現過因為kv異常導致整體業務不可用的問題，所以需要對所有使用kv的場景進行排查，確認是否是強依賴、是否能夠降級，最終做到kv故障也不會影響核心業務的運行。
場景分析
在場景分析階段，需要拉各業務線統一進行分析和梳理，確認各業務和應用在哪些場景和哪些接口邏輯里面有調用到kv，是否有降級，進行梳理和記錄。
可以簡單按這個方式登記下：
| 業務線 | 依賴kv的場景 | 是否有降級或者處理異常 |
| x x x |x x x | x x x |
在記錄之后，需要審視和評估，這些使用到kv的地方是否合理，是否能做降級，比如：
- 查詢kv失敗，如果數據存儲在db是否可以降級為查db；
- 核心流程里面加鎖解鎖訪問kv失敗，到底應該忽略錯誤讓業務進行下去還是拋異常中斷流程或是做其他異常處理，需要進行權衡、謹慎判斷
在這過程中發現的問題可以提前進行優化，避免到了實際演練的時候出現太多的阻塞問題
確認用例&制定計划
根據之前的分析，整理出了各業務涉及kv的場景和用例，但僅僅有這些是不夠的。做kv故障演練的根本目的還是保證核心主流程在kv異常時還能夠正常運行，所以演練的用例還是要以核心主流程為基礎。另一方面，隨着系統復雜度的提高，業務方互相調用錯綜復雜，以業務方為緯度的梳理往往不夠全面，比如業務方A沒有調用kv的場景，但A的主流程會調用業務方B的接口，而該業務方B的接口的是個不太重要的功能但依賴了kv，可能就會被遺漏。
這樣的問題適合在演練的時候發現，這實際上也是種集成的概念：各業務單元先保證自己對kv的依賴和處理是合理的，然后集成在一起，通過演練確保整體業務是健壯的。
於是我們可以根據核心主流程和依賴kv的場景輸出演練時候的用例。有了場景和用例，可以制定相關的演練計划。考慮到業務之間存在依賴，比如只有賬號功能正常了，才能登陸后做后續的操作；只有支付功能正常，才能下單走交易流程。所以在執行上需要安排基礎業務方先行進行操作和驗證，沒有問題后再安排后續業務方進行驗證。
最后，一個完整的演練計划包括這么幾個步驟：
- 起始時間和各階段的時間。因為故障演練一般在測試環境進行，會影響其他人的使用，所以時間選擇需要避開高峰時間段同時控制時長，並提前通知。
- 執行故障。需要提前和運維或者kv維護人員溝通，安排人進行故障注入操作。
- 執行降級。有些降級需要手動執行，需要加入計划中，注明操作項和操作人，只有確保降級成功后再開始后續驗證。
- 業務回歸。先讓基礎業務方進行回歸，再安排上層業務方參與。
- 問題排查和記錄，對於發現的問題統一進行記錄。
- 故障恢復。恢復故障后，各業務方確認業務是否都恢復正常。
- 分析匯總結果。對於執行失敗的case和發現的問題，進行記錄和補充原因，需要進行后續排查、優化的給出后續計划和時間點。
執行演練
按照之前的計划執行演練，最好將參與演練的開發和測試都安排在大會議室方便交流和問題排查。
先找人對kv注入故障，比如停掉服務，然后通知需要手動降級的業務方開始操作降級。降級完成后，讓基礎業務方先行進行驗證，沒有問題則通知上層業務方開始介入進行功能回歸。
期間可能需要協調不同業務方去排查互相調用時出現的問題。
最后，等各業務方都確認用例執行完成，則可以恢復環境。
記錄和分析結果
對於執行過程中的失敗，需要詳細記錄失敗場景、報錯日志等信息，幫助開發排查問題，也方便自己下次進行回歸驗證。
演練結束后，對失敗的原因進行分析，並給出后續的action。
作為演練的負責人，需要不定期的跟進action的完成情況，督促業務方盡快進行優化改進，等上一次演練發現的問題解決的差不多了，就可以開啟新一輪的演練。
一般情況下，如果這次是第一次做故障演練，對於整體功能的可用性就不能抱有太大期望，可能在基礎業務方這層就會存在問題，導致上層業務無法正常運行。
但是不必氣餒，演練就是個需要不斷迭代改進和鞏固的過程，之前演練了2-3次之后，整體的流程基本上就能跑下來了。看到系統不斷的變健壯，還是很有成就感的。
降級演練
雙11期間，系統往往會遭遇大流量的洗禮，作為質量保障的一環，需要對系統自動降級和過載保護的有效性進行驗證。所以組織了針對性的一次驗證和演練。
用例設計
降級
執行方式：接口接入自動降級組件，構造請求，觸發配置的規則
關注點：
1.規則是否生效(超時/失敗等)
2.降級行為是否符合預期,如返回默認數據或錯誤,
3.降級期間業務功能是否正常
4.解除異常,降級行為是否能夠自動恢復
5.可能的話關注下降級切換花費的時間以及切換過程中的失敗率
限流
執行方式：接口接入過載保護組件，構造流量進行加壓
關注點：
1.流量超過限制,是否觸發限流
2.限流行為是否符合預期
3.流量降低,業務是否恢復正常
熱點緩存
執行方式：接口接入過載保護組件，構造流量進行加壓
關注點：
1.出現熱點商品是否觸發過載保護，將熱點商品加載到localcache
2.流量降低,業務是否恢復正常模式
測試策略與執行
接口級別驗證->功能級別驗證
先針對單接口，驗證接入組件是否生效。此時可以在降級和過載保護組件里配置強制開啟降級，通過簡單的接口調用直接觸發降級和過載保護，驗證處理結果是否符合預期。在這個層次上主要發現降級是否生效，處理邏輯是否正常的問題。
然后根據功能場景，構造流量進行降級和過載的驗證。通過不斷加壓，讓流量達到配置的閾值，觀察系統是否自動開啟了降級和過載保護，持續一段時間，然后觀察接口返貨、系統響應是否正常，系統狀態和日志輸出是否正常，然后慢慢降低流量，觀察系統是否能夠恢復正常。這這個層次上主要發現降級和過載配置合理性的問題以及性能上的問題。
分析總結
對於發現的問題進行分析和總結，推動開發進行優化和改進。
執行單獨的降級和過載保護的驗證解決的是有無保護的問題，一些配置參數配置是否合理往往需要結合全鏈路壓測的時候來一起進行分析判斷。
后記
之前參與主導和編寫了公司的測試白皮書，今年出了電子版。有興趣的朋友可以交流學習下:
https://shop13579785.youzan.com/wscvis/course/detail/2ocqwv300c8oh
