一分鐘精華速覽

越來越多企業正在通過故障注入和演練的方式提升系統可靠性，這其中金融行業的應用較為特殊，一方面其可靠性要求比非涉賬類系統更高；另一方面金融行業有更加嚴格的監管要求，如客戶、賬目等資訊都有嚴格約束，加之金融系統較其他行業系統更加龐大、繁雜，所以金融行業落地混沌工程和故障演練等作業需尤為謹慎、嚴謹，

本文介紹了中國人壽故障演練的專案背景、目標思路、技術方案等，分享其在預知故障和降低不確定性風險方面的實踐成效，

作者介紹

中國人壽研發中心高級工程師——劉玢

TakinTalks社區專家團成員，擁有多年開發和運維經驗，專注高可用領域，目前負責中國人壽混沌工程等多項高可用舉措的規劃和落地實施，對于構建高可用系統具有深入的理解和實踐經驗，

溫馨提醒：本文約4600字，預計花費9分鐘閱讀，
后臺回復 “交流” 進入讀者交流群；回復“0426”獲取課件資料；

背景

在最近六七年時間里，中國人壽對原來煙囪式的架構做了持續改造，對諸如長險、短險、萬能險等等獨立系統中的類似功能，做了橫向的專業化拆分、微服務拆分，新架構在帶來效率提升的同時，也帶來了更多不確定性風險，如微服務數量的指數級增長、架構越來越復雜、問題定位難度加大等等，

從2022年安全事件及生產風險原因分析看，中國人壽安全事件及生產風險主要包括非版本類變更引發、第三方或硬體故障、版本或歷史缺陷、生產長事務或者海量資料引發等，其中非版本類變更引發、第三方或硬體故障兩項總和超過50%，

一方面，微服務增多導致版本翻倍增長，帶來了更多的變更風險；另一方面，“1min-10min-30min”的故障處理要求也是不小的挑戰，總體上，因為缺乏抓手導致我們對性能、安全、兼容性、可維護性等多方面都缺乏質量信心，

基于此，中國人壽高可用工程規劃了一系列穩保能力，并于2022年開始落地基于混沌工程的故障演練，囿于金融行業生產環境的特殊性，目前中國人壽已率先完成了在故障演練在測驗環境和準生產環境的落地，

今天我將主要圍繞中國人壽故障演練的專案背景、目標思路、技術方案等，分享其在預知故障和降低不確定性風險方面的實踐成效，

一、故障演練想要達成哪些目標？

1.1 故障演練目標

故障演練的目標主要分為兩塊，業務目標和技術目標，
通過基于混沌工程平臺的故障演練能力建設和演練實施，從開發、測驗、運維、災備各個領域幫助各系統發現和解決潛在問題，提高系統穩定性和可用性，增強團隊協作能力和故障排除能力，

1.1.1 業務目標

事前（從架構設計角度）：增強業務可用性，預防事故發生；

事中（從系統運維角度）：提高故障發現能力和告警能力；

事后（從故障處置角度）：提升應急處置時效，降低故障影響范圍和時長，

1.1.2 技術目標

開發領域：去除架構設計單點，驗證系統容錯能力；

測驗領域：生產故障回歸測驗，極限場景測驗；

運維領域：驗證監控發現能力和告警有效性，驗證應急預案有效性，縮短故障處置時間；

災備領域：驗證災備切換預案的適用性和有效性，

1.2 落地思路

第一個是安全優先，先從測驗環境演練入手，再慢慢過渡到生產環境，穩定安全優先，

第二個是分步實施，先做一些簡單的場景，然后再做復雜的場景，穩步推進，同時，先引入開源工具，再加強自主掌控，不斷提升故障演練系統支撐能力，

第三個是加強協同，故障演練和做容量規劃、灰度、在線壓測等都有很大的不同，大多數時候業務團隊會認為故障演練將破壞其系統程式而抵觸不配合，因此，協同溝通以及混沌理念宣傳非常重要，

二、技術方案如何選擇？

2.1 平臺功能規劃

技術選型是整個專案落地最重要的一塊，我們將功能規劃分成了五部分，實驗配置、實驗管理、安全管控、監控整合、故障注入，前面兩部分各家都大同小異，這里將重點分享后面三個功能規劃背景，

1）安全管控
這部分規劃我們花費了最多的精力和時間，在做混沌工程時，大家首先都會關注如何建立系統穩態，如何控制爆炸半徑等，而金融行業系統的安全管控尤為重要，所以我們花了大量時間，與諸如阿里等一線公司做交流和調研，借鑒成功的經驗，具體實作程序我將在后面展開，

2）監控整合
我們要把原有的監控能力做整合，來適應混沌平臺的需求，中國人壽做過很多監控能力的建設，如機房監控、主機監控、網路監控、資料庫監控、服務鏈路監控等等，原來的監控平臺對這些監控能力都做了接入，但為了告警方便和防止誤報，很多監控資料都做了抽樣，比如按分鐘做一個統計資料再整合起來，如果直接給混沌平臺來使用，會導致時效性不足或者故障被掩蓋，因此，我們需要重新做監控能力的整合，

3）故障注入

故障注入能力可能是大多數人關注的重點，我們規劃的故障注入能力包括基礎故障（如CPU資源、網路資源、磁盤、行程、記憶體）、JVM類故障、網路請求類故障、訊息中間件故障、K8S引擎故障、Cattle引擎故障等等，這部分我們花了較長時間做收集整理，

此外，我們還做了一些定制開發的故障，因為僅基于開源工具，很多場景故障無法模擬，舉個例子，中國人壽現在使用了大量的中間件，一個Java工程使用很多外部jar包，有些外部包又依賴其他包，整個生態非常龐大，而外部的故障工具只能對其中某些地方做故障注入，不能完全滿足實際的故障模擬需求，所以需要很多定制化的故障開發來補齊這部分能力，

2.2 技術選型程序

完成功能規劃后，我們從業界主流的混沌工程平臺中挑選了一些產品進行深入研究和試驗測評，從故障注入能力、安全管控能力、實驗配置與編排、界面易用性、部署難度、服務支持、擴展性兼容性等7個方面，做了深入的分析和對比，

基于技術自主可控的思考，最終我們選擇了“自研+開源”的方式，基于開源的ChaosBlade，進一步做了定制化開發，包括自定義故障的開發、監控能力整合等，形成了現有的混沌工程平臺，

三、如何分階段落地故障演練？

整個故障演練作業可以分成三個階段，目前已經完成測驗環境和準生產環境的故障演練，我將重點分享這兩個階段的落地實操，

3.1 故障演練-測驗環境

3.3.1 整體作業成效

從2022年7月開始至今，總計完成13個系統測驗環境的故障演練，累計進行30輪演練，發現143個風險點并采取預防措施，整改問題超過50個，

3.3.2 演練程序

1）第一輪：線上分散式演練

第一輪演練是線上分散式的，持續時間一周以上，主要參與人員有混沌教練、產品架構師、測驗人員，其中，產品團隊需要提供架構檔案（如物理架構、邏輯架構、技術堆疊情況等）、歷史故障清單（如上下游關系比較近的系統故障）、演練的重要關注點等，

在此程序中，我們會根據系統技術堆疊和系統架構，先在故障演練庫中選出適合的基礎故障，再根據實際溝通情況補充應用適合的故障，接下來，基于開發環境對挑選出來的故障做預演練，其目的就是通過合適的方式生成故障——有些故障比較簡單，通過故障工具可以直接生成，但需要找到合適的位置并做深度剖析；還有一些故障需要定制開發，并做演練迭代，

整個程序根據系統的復雜度，短則持續1周，長則2-3周，演練完成后，就能形成適合該系統的比較完整的故障清單，

2）第二輪：集中研討整改措施

以線下集中的形式開展，時間是半天左右，將混沌教練、產品經理以及產品組架構師等等骨干全部召集，對第一輪確定的故障清單做集中演示，同時，現場討論并確定整改舉措，有些故障會涉及多個角色，也有可能產品組不認可問題整改意見，此時則需要多輪討論，最終商定具體的整改方案，

3）第三輪：應急預案有效性驗證

此階段加入運維部署負責人，還是以線下的形式進行，主要對應急預案的有效性進行驗證，時間也是半天左右，

此輪我們會挑選一部分和運維緊密相關的故障，對第二輪整改后的系統進行可觸發應急處置的故障演練，運維人員介入并根據應急預案實施一遍，看看是否能覆寫并及時處理故障，同時，也會在現場討論應急預案的舉措是否合理、是否需要增加、是否需要完善等等，并可能在現場做多次迭代實驗，

3.3.3 演練結果

對于金融系統來說，真正敢上生產環境做演練的幾乎沒有，所以我們在測驗環境的演練識訓會相對少很多，前面講到我們總計完成了13個系統測驗環境的故障演練，其演練結果和問題大致可做如下分類，

從資料中可以看出，大部分問題集中在監控缺失和告警規則，盡管監控平臺已經建立了好幾年，但是從演練結果來看，監控告警能力并不如大家想象的樂觀——存在監控盲區或者需要達到一定閾值才會在監控中呈現、告警規則不合理等等，這里也是我們測驗環境演練最有價值的識訓之一，

（中國人壽某系統演練問題清單）

3.2 故障演練 - 準生產環境

3.3.1 演練背景

客戶活動管理系統是中國人壽的客戶節活動平臺，在活動高峰時，瞬時TPS可達到8000以上，為應對即將到來的客戶節活動，我們在此系統上做了準生產環境的故障演練，之所以稱之為準生產環境，是因為雖然它本身是生產環境，但在客戶節來臨前，它沒有生產流量，所以我們可以直接在生產環境做尺度更大的故障注入，

3.3.2 演練程序

演練需同時依賴在線壓測平臺和監控平臺進行，由于是在生產環境演練，所以必須用在線壓測的方法才能把生產流量打上去，另外更重要的一點是，雖然客戶活動平臺剛上線沒有生產流量，但是其上下游系統也會有生產風險，所以需要依靠在線壓測平臺做流量區分，將測驗流量打入影子庫中，同時，一些不能呼叫的介面也需依托在線壓測平臺做Mock，所以，先有在線壓測平臺后，再來建設混沌平臺，作業推進會更加合理，

3.3.3 演練成效

1）依托在線壓測平臺全面驗證各個模塊容量；一般情況下，容量驗證依靠性能測驗，但性能測驗有個比較大的難點，即A模塊產生性能瓶頸但下游的B模塊還未到達瓶頸，此時需要性能測驗不停做生產變更和配置調整才能達到最優，而通過混沌工程平臺，簡單對CPU或記憶體做一定比例的占用、對網路延時做少量調整即可檢測出鏈路上各個模塊的性能極限，

2）對資料庫高可用、PAAS平臺多活、應用限流熔斷、監控和告警等進行了全面驗證；

3）首次生產應急演預案有效性驗證，應用彈性擴容、資料庫擴容和重啟等，

四、故障演練解決了哪些實際問題？

4.1 開發領域

1）強弱依賴梳理

重保期間人力成本降低，開門紅是每家保險公司都非常重視的活動，由于業務量巨大，在這種活動重保期間，我們以前的做法是所有關聯系統的運維人員、產品經理都需要24小時值班做支撐，這樣的成本投入是非常高的，而依托故障演練的強弱依賴梳理，可以精確知道哪些系統更重要需要24小時保障，而其他不關鍵的系統則可以適當降低回應要求，了解組件之間精確的依賴關系，能夠更合理安排運維支持，更大程度上減少人力成本，

2）高可用舉措有效性驗證

架構設計的落地情況驗證，以前有很多架構設計，經過評審上線后落地好壞是很難評估的，比如在架構設計檔案里承諾實作的點，實際上線后可能由于各種原因并未達到設計要求，混沌工程故障演練能有一定檢驗效果，

單點故障容錯驗證，主要驗證集群中一個單點產生故障后，業務是否還能繼續，在實操中，業務壓力較大時，其中一個節點故障，整個集群的可用性并不一定如設計的那樣有效，比如，在一次對某系統生產故障復現的故障演練中，當我們對Redis做故障注入，發現當主節點瞬時記憶體大量占用出現故障時，從節點并未切換為主節點，所以單點故障的容錯驗證是有必要的，

限流、熔斷閾值驗證，如前面提到，有些設計看起來是沒問題的，但是不經過驗證，它真的不一定是可靠的，

PaaS、網格等多活驗證，中國人壽有自己的PaaS平臺，做了一套多云多活的高可用設計，包括一套信創云做補充，通過混沌平臺我們驗證了PaaS平臺和網格的多活策略的有效性，

中間件高可用驗證，對Redis、訊息佇列等依賴比較重的系統特別需要這一塊的實驗，

4.2 測驗領域

1）生產故障回歸測驗
月度生產故障根因分析支持，在生產環境出故障或者難以還原現場時，我們會用混沌工程模擬現場，盡管分析出來的根因可能會不一樣，但這對周邊系統的高可用提升具有借鑒意義，即當生產發生此故障時，周邊系統的高可用手段應該如何發揮作用，
重大生產問題復盤支持，

2） 極限場景模擬測驗
性能測驗無法模擬的場景支持，有很多場景是無法通過性能測驗模擬出來的，比如發壓的壓力達不到、或者流量配比不科學、或者中間一些環節的容量不夠，無法把足夠的壓力傳導到指定模塊上，此時可以通過混沌工具占用一部分的CPU或者記憶體，再去做極限場景的性能測驗，

4.3 運維領域

1）監控發現能力和告警有效性驗證

監控發現能力補全和告警有效性驗證，前面講到進行了30輪演練后，我們發現監控缺失和告警規則不合理占大部分，我相信這種情況應該在各家公司是普遍存在的，

2）應急預案有效性驗證

促進應急預案的完善；
鍛煉運維隊伍，提升故障處置時效，

五、未來展望

未來我們希望打造更便捷，更安全，更智能的故障演練服務，

更便捷：當前在做故障演練時，我們的投入是很大的，基本是把混沌小組最厲害的工程師、混沌教練，還有各個產品團隊的架構技術骨干都集中到一起才能把整個作業開展起來，難度高、專業性強導致了便捷性的不足，未來在更便捷方面，我們想像使用自來水一樣做故障演練，

更安全：當前我們還沒有真正上生產，一是因為大家信心不足，二是監控指標的有效性、完整性以及依托監控指標快速恢復現場的能力也還有待進步，

更智能：我們也在思考人工智能和混沌工程的結合，比如說不需要人工再做復雜的架構和技術堆疊分析、歷史故障分析，甚至實作自動的故障注入和實施等，（全文完）

Q&A

1、混沌教練需要具備什么樣的素質?

2、混沌工程構建故障是用的哪些測驗工具？測驗環境和準生產環境使用的工具有哪些不同?

3、故障演練、在線壓測如何分工與協作?

4、怎么做到月度生產故障和重大生產問題故障的混沌場景，鏡像生產資料?

更多詳細內容，歡迎點擊“閱讀全文”，觀看完整版解答！

宣告：本文由公眾號「TakinTalks穩定性社區」聯合社區專家共同原創撰寫，如需轉載，請后臺回復“轉載”獲得授權，

本文由博客一文多發平臺 OpenWrite 發布！

標籤：其他

上一篇：記一次排查：介面回傳值寫入excel后，從單元格copy出來的資料會帶有多重引號的問題

下一篇：返回列表