昨天下午星球有同學問了一個問題：目前業內高可用部署主要採用方案？
看到這個問題，我的第一反應是問題太寬泛，不夠明確。我反問了她一個問題：“你需要什麼高可用？業務高可用？服務高可用？數據庫高可用？還是其他？”
針對問題我也給出了我的理解和方案，大致內容如下：
|
高可用類型 |
簡單理解 |
高可用方案 |
|
業務高可用 |
用戶的操作都可以正常被處理 |
冗餘設計+故障預案+監控告警+良好的服務發佈體系 |
|
服務高可用 |
service可持續處理請求，但不對業務的正確性負責 |
分佈式集羣+限流熔斷方案+ |
上述的內容只是一個引子，因爲高可用和線上服務的穩定性有密切的關係。而軟件測試或者說質量保障的工作範疇，不僅僅在測試環境，線上環境的服務質量保障，也是我們需要關注的重點。
這其實也是我在之前的文章《如何建立高效的質量保障體系》中提到的一點：交付(線上)質量持續運營。見下圖：
那麼如何做好線上的服務質量保障工作，達到持續運營的理想狀態呢？這是我本篇文章要聊的話題。
發現線上故障
業內程序員面試時候據說有個三高的說法，即：高併發、高性能、高可用。
分佈式架構中有CAP理論，即：Consistency(數據一致性)、Availability(服務可用性)、Partition tolerance(分區容錯性)。
這些點對軟件系統提出了很高的要求，既要能扛得住高併發流量衝擊，又要具備很好的性能來處理請求，還要達到服務和業務的高可用，並且要保證業務數據的一致性，最後還要對異常場景有一定的冗餘處理能力，簡直是難上加難。
而線上服務(或者說生產環境)，我們最擔心也最常見的就是出現線上故障。故障的種類很多，什麼服務掛了、支付失敗、無法加載商品圖片等等不一而足。
要保障線上服務質量，避免出現線上故障的前提，除了在測試階段做好測試，上線發佈前仔細驗證之外，還需要具備在故障發生時及時發現故障的能力。
目前最常見的發現故障的手段有兩種，分別是：日誌分析和監控告警。
當然，很多的監控告警系統也是通過埋點數據和日誌採集，對採集的數據進行過濾，解析成一定的結構數據，然後進行存儲以及可視化展示來做的。
比如很經典的ELK(Elasticsearch+Logstash+Kibana)，如下圖：
通過日誌分析和監控告警，我們可以快速的發現線上故障，及時的進行處理。
處理線上故障
發現線上出現故障後，第一優先級永遠是快速恢復線上業務的可用性，然後再考慮其他。
寫到這裏突然想起之前就職的某家企業交易團隊負責人的話：優先業務止血，再考慮問題定位分析和優化。
以我的工作經歷來說，一般發現線上故障後的處理流程如下：
一般來說，線上故障處理，主要會涉及到如下四種角色：
NOC：一般指專門的線上服務巡檢和監控值班人員，出現故障時作爲信息收集和信息分發中心；
運維/研發：線上故障由對應業務域/服務的研發和運維進行處理(研發對代碼最熟，運維有服務配置發佈和變更權限)；
測試/產品：故障恢復後測試進行觀察驗證，如果影響範圍較大，還需要通知產品甚至市場運營進行對應的配合處理；
高層領導：如果故障比較嚴重，需要上升到更高級別的負責人，並且某些重要操作需要高層決策和授權；
修復線上故障
一般來說，對於線上出現故障，快速恢復服務可用業務可用，降低故障帶來的損失是首要的，修復bug反而是其次。
所以在線上出現故障時，一般都會採用一些臨時方案來達到快速止血的目的。常見的臨時方案有：
- 服務重啓；
- 部署回滾；
- 限流降級；
有臨時方案就有後續的優化方案，一般在線上故障恢復後，會進行如下幾個步驟：
- 利用日誌和故障現場保留的dump文件等進行根因分析；
- 修復故障後在測試環境進行驗證，確認沒問題後再發布到生產環境；
- 記錄故障從發生到徹底修復的全過程，進行線上故障覆盤，提出後續改進方案並跟進落地；
當然，除了上述的一些手段，還可以通過如下幾種方式來降低線上出現故障的影響和損失：
- 組織線上故障演練，培養技術同學的臨時反應和處理問題能力；
- 通過灰度發佈或者發佈beta版本，讓用戶成爲幫助我們發現問題；
- 做專項的混沌工程，在不斷的攻防演練中提升線上服務的質量和穩定性；
運營線上質量
聊了這麼多，那測試同學如何針對線上故障，做好質量持續運營呢？可以從上面的幾張配圖來切入。
線上服務巡檢：NOC並不是一個崗位，而是一種職責，測試同學對於業務和自己負責的項目相對更熟悉，要做到最快速度發現和處理線上故障，就是要讓最正確的人第一時間響應和介入處理。
而測試同學可以達到監控巡檢和信息分發以及快速驗證的作用。當然，這種機制需要一定的時間建立，還需要一定的基礎技術服務設施支撐。
組織故障覆盤：流程和規範可以將好的實踐標準化流程化自動化，讓技術團隊共享經驗，而組織故障覆盤並且跟進後續的優化落地效果，就是一個測試同學可以很好勝任的事情。
故障處理手冊：有了日常線上巡檢，組織了故障覆盤，可以沉澱很多的最佳實踐，可以將這些實踐抽取共性，沉澱輸出爲一份故障處理手冊，並在團隊內做宣講和落地。
這樣既可以讓其他同學在面對故障時能更快的響應處理，也能讓新同學入職後快速的熟悉團隊的技術棧，加快融入速度。