七個關鍵問題的應對策略-續2
6.拆分過程的測試和部署如何處理
通過前面的分析，我們瞭解到測試、部署和運維，在微服務環境下會變得複雜。試想，原來只需要測試一個系統，現在要測試一堆系統，原來要發佈一個應用，現在要發佈一堆應用。原來線上排查問題，只需要從一個日誌文件看日誌信息，一個數據庫找數據，現在都不知道去哪兒找數據，因爲第一時間不知道業務處理在哪個環節出錯了，需要先搞清楚一個跨多個系統的調用處理過程，在哪個環節出了錯，如果是顯式的錯誤，有日誌還好點，要是沒有報錯，而是數據錯了，那簡直就是排查問題的噩夢。
特別是如果兩個不同的服務系統，分別是兩個小組維護，一有問題就可能會產生相互推諉扯皮，A 讓 B 先去排查是不是 B 的問題，B 讓 A 去排查是不是 A 的問題，出現兩個和尚沒水吃的尷尬境地。一個解決問題的辦法就是，自動化，降低人爲因素的影響，也消滅服務拆分帶來的這種重複勞動的複雜性，提升測試、部署、運維效率。
1） 自動化測試
建立全功能覆蓋的測試 case，並實現自動化，變更時全量自動迴歸。集成 Sonar 等工具，檢查代碼風格、單測覆蓋率和成功率等，控制代碼質量。我們一般要求核心業務代碼，覆蓋率 100%；重要業務代碼，覆蓋率 90%；一般的後端業務代碼，覆蓋率 80%；其他代碼覆蓋率 60%。遺留代碼，維護時把本次修改設計到的代碼，覆蓋率提升到 60%。代碼風格可以參考阿里巴巴或是 Google 的 Code Style 編碼規範定製適合自己團隊的標準。
2）自動化部署
藉助與 Jenkins、Nexus、Ansible，Docker、K8S 等工具，實現多個應用的自動打包，編排，以及自動化部署，構建微服務項目的部署流水線。特別是基於 K8S，我們可以實現微服務的服務自愈和自動彈性伸縮，在服務失敗後重新拉起，在負載高或者低時動態控制容器數量。
3）自動化運維
通過標準規範，配置管理工具，資源交付工具等手段的配合，逐步實現基礎架構、應用、IT 服務和業務運營的自動化，實現日常運維處理和運維流程的自動化，降低風險、提高效率，促進組織能力和成熟度提升。
7.拆分後的運維和監控如何處理
監控與運維是生產環境運行系統的日常工作，就像是人體的免疫細胞一樣，保障着整個系統的健康運行，業務的正常運轉，下面我們從 5 個方面說明一些微服務下的健監控和運維工作要點。
1） 系統監控
系統監控是最基礎的監控指標，是我們瞭解系統內部運行情況的直接手段。我們要對所有重要的狀態進行度量和監控，全面實時的掌握系統健康狀態。
2） 業務監控
業務監控意味着我們要從用戶的角度看來待系統的監控指標，而不僅僅是技術角度，這樣我們就能發現和分析業務指標的突然變化是什麼原因造成的，跟系統本身有沒有關係，有沒有需要我們改進提升的地方，可以更好的支撐業務增長，影響和穩定業務指標。時常可能會出現，業務方說客戶都在抱怨系統不穩定，卡了，延遲高了，但是我們從系統監控上看，系統的指標沒有大的變化，那麼一定是我們設定的監控指標不夠，沒有覆蓋到業務的全流程。反過來，也說我們和業務方、和客戶思考問題的角度有差異，爲了更好的服務客戶，我們需要調整自己的視角，從用戶角度出發思考問題。
3） 容量規劃
只瞭解系統的過去和現狀是不夠的，因爲隨時可能會有突發的流量襲來，導致系統被衝擊，可能會超出系統處理能力導致延遲飆升，直至系統宕機崩潰。所以我們需要在平時做好容量規劃，通過持續的壓測，瞭解到系統的極限處理能力，針對瓶頸資源持續做優化，提升處理能力，做好容量預案，隨時有激增流量的擴容方案，超出處理能力的限流和熔斷、系統過載保護方案，保障系統的穩定運行。
4） 報警預警
做好了業務和系統指標監控，也做了容量規劃，那麼我們還需要通過這些指標和容量策略，在合適的時機對系統進行干預，把系統風險提前消滅掉。所以，我們需要根據經驗定義預警報警的閾值，根據容量水位進行擴容縮容的後續處理動作。
特別報警預警的實時性，是我們應對線上突發異常的一個重要指標，例如對於 web 和 app 用戶，如果我們在系統突發異常的 10 秒內收到預警，然後又花了 20 秒把系統重啓，恢復了服務能力，那麼用戶可能會覺得剛纔 30 秒是不是網絡卡了一下，不會產生大規模的客訴。相反地，假如我們 2 分鐘收到報警，又花了 10 分鐘才處理完，這時候基本上大批客戶都會感知到了這次故障，稱爲一個有大量客訴的事故了。
5） 故障處理
從我們的實際經驗來看，導致系統出現非預期的不可用性故障，主要有三類原因：
-
人爲的操作失誤導致的宕機類不可用，沒有標準的操作流程或者操作者沒遵守流程；
-
遺漏的功能或性能相關的 bug 問題引起的不可用，我們的測試覆蓋不足，或者對系統間的影響關係判斷不準確，導致 Corner-Case 有遺漏；
-
不可預知的突發條件或狀況引起故障的不可用，比如我們使用了 AWS，突然某個時間段 AWS 日本某個可用區的網絡突然發生了大規模超時，某個 RDS 的底層硬盤突然損壞等；
這三類問題的應對策略是分別如下：
-
操作失誤的應對策略：制定標準操作流程，並根據實際情況不斷更新和調整，貫徹培訓，嚴格執行，用流程來防止人爲的不規範；
-
功能問題的應對策略：建立全功能覆蓋的測試 case，並不斷擴充 Corner-Case，逐步實現自動化，跟 CI/CD 集成，每次修改後都能及時的迴歸所有已知的 case，不留死角。完成系統和服務依賴關係分析，梳理和合理改造影響範圍。建立可跟蹤的性能測試基線標準和環境，每次重構或者設計調整，都通過基線環境進行性能驗證，不把性能問題帶到線上。
-
突發故障的應對策略：突發問題是我們真正面臨的問題，一般來說不可控，超出預期，難以通過我們的努力直接解決。
故障處理的第一原則是，先解決問題，然後再去考慮分析原因，覆盤過程，總結經驗教訓，最後纔是考慮要不要追責。特別強調的是，如果一個線上的發佈或者變更操作，有可能造成客戶的感知事件，最好就先跟客戶進行一個可以預期造成業務影響的溝通，給客戶同步一下操作的時間，目的，持續時間，可能造成的影響，讓客戶可以從容的安排和調整自己的業務，保證不受影響或者降低損失（如果停機會給客戶造成損失的話）。如果技術團隊對這個操作沒有十足的把握，最好考慮在一個可接受的時間窗口內停機處理。對於發佈造成的故障，我們一直有個說法：
如果發佈可能導致宕機這件事是提前告知了客戶，那麼真的發生了宕機就是一個故事。相反，如果可能導致宕機這事兒沒有提前告知客戶，那麼操作過程導致宕機，就是一個事故。