AWS 雲上混沌工程實踐之可行性評估篇-知識星球

本文是亞馬遜 AWS 部落格混沌工程專欄的第二篇，該文釐清了混沌工程實驗的標的，利用實驗提前探知系統風險，採用架構和運維體系最佳化的方式來解決系統弱點，真正實現韌性架構，降低企業損失，提高故障免疫力。並透過對混沌工程實驗的成熟度等級和接納指數的深入描述，探討瞭如何透過上述可行性評估模型來衡量混沌工程實驗的可行性、有效性和安全性，以及未來的路線圖計劃。

自首篇《AWS雲上混沌工程實踐之啟動篇》發表之後，引起了大家的興趣，不少讀者發信討論。為了更好地圍繞混沌工程實踐分享我們的知識和經驗，特此成立了混沌工程專欄以饗讀者。

我們在啟動篇中談到混沌工程的發展不是一蹴而就的， Chaos Monkey 開創了混沌工程的先河，從對基礎設施的擾動（ EC2 實體隨機終止 Chaos Monkey 、模擬可用區中斷 Chaos Gorilla、模擬區域中斷 Chaos Kong 等），到利用應用閘道器控制爆炸半徑，再到精細化流量配比以區分影響，直至引入斷路器實現真正無人值守的混沌工程實驗平臺。本篇是混沌工程專欄的第二篇，筆者會探討大家比較關心的第一個問題——為了能夠成功實施混沌工程實驗有哪些可行性要求：對實現物件的架構要求？對實驗技術能力的要求？對實驗工具的要求？還是實驗可控性的要求？通常分析這樣的問題，我們必須首先弄清楚混沌工程實驗的標的。有了明確的標的，才可以深入地評估所做的混沌工程實驗是否“可行”，能否“成功實施”。

混沌工程的標的——實現韌性架構

正如 AWS CTO Werner Vogels 常說的“故障是註定的，隨著時間的流逝，一切終將歸於失敗”。我們必須接受故障發生是新常態的想法，處在部分故障的系統正常執行是完全可行的。當我們處理多達幾十個 EC2 實體的小型系統時，100％的健康執行通常是正常狀態，故障則是一種特殊情況。然而，在處理大規模系統時，即 100％的健康執行幾乎是不可能實現的。因此，運維的新常態便是接受部分故障。處在部分故障中的系統要求仍能正常執行對外提供服務，這就需要架構本身具備 Resilient 能力。這裡我並不想把 “Resilient ” 翻譯成彈性，而應該是韌性（具備恢復能力）。混沌工程就是利用實驗提前探知系統風險，透過架構最佳化和運維樣式的改進來解決系統風險，真正實現上述韌性架構，降低企業損失，提高故障免疫力。

韌性架構的重要特徵

冗餘性

架構的設計要增加冗餘性，以便提高該系統的整體可用性。如在 AWS 雲中，這意味著將其部署到多個可用區，甚至跨多個區域進行部署。

正如上圖中所看到的那樣，元件 X 的可用性是 99％（按今天的標準來說非常糟糕），但並行放置，增加冗餘性，可以將系統的可用性提高到99.99％！如果將三個元件 X 並行放置，那麼就可以達到 6 個 9 的可用性！這個結果很驚人，這就是為什麼我們總是建議客戶跨多個可用區設計架構。

擴充套件性

架構的設計必須要考慮擴充套件性，即啟用 Auto Scaling ，根據需求動態擴充套件資源 – 而不是手動執行 – 確保可以滿足各種流量樣式。如在 AWS 雲中，可使用 Application Auto Scaling 功能為 EC2，DynamoDB 和 EMR 等服務提供相同的自動擴充套件引擎，以支援 AWS 外部服務的自動擴充套件。

不可變基礎設施

不可變基礎設施指的是，每次部署都會替換相應的元件，不做更新。應用部署則使用金絲雀釋出（俗稱灰度釋出），以減少部署新版本應用時出現故障的風險。使用這種技術，可以在真實的生產環境中進行測試，併在需要時進行快速回滾。

無狀態應用

無狀態應用是自動擴充套件和不可變基礎設施的先決條件，要求應用必須獨立於先前的請求或會話，處理所有客戶端請求，並且不會儲存在本地磁碟或記憶體中。

避免級聯故障

級聯故障指的是因依賴關係引發的區域性故障導致整個系統崩潰（俗稱蝴蝶效應）。架構設計必須考慮級聯故障的處理方式：

轉移切換：當一個叢集宕機時，所有的流量都轉移到另一個叢集，如跨可用區切換，或者跨區域切換。
重試退避：指數退避演演算法逐漸對客戶端重試請求減速，避免網路擁塞，同時新增抖動保證效能，詳細討論參看這裡。
超時機制：過載請求會將連線耗盡，導致系統宕機。超時機制的引入，服務的質量會下降但不至於系統全面崩潰。
冪等操作：由於暫時的錯誤，客戶端可能多次傳送相同的請求，可能導致系統處理錯誤。冪等操作，一種可以反覆重覆的操作，沒有副作用或應用程式的失敗，可以消除上述隱患。
服務降級：當伺服器壓力劇增的情況下，有策略地減少或退化部分服務，以此釋放伺服器資源以保證核心任務的正常執行，如只讀樣式、停用耗時耗資源的功能等等。
拒絕服務：請求過載時，按優先順序開始丟棄相應的請求。
服務熔斷：若某個標的服務呼叫過慢或者有大量超時，直接熔斷該服務的呼叫，對於後續呼叫請求，不在繼續呼叫標的服務，直接傳迴響應，快速釋放資源，待標的服務情況好轉則恢復呼叫。

基礎設施即程式碼

基礎設施即程式碼可減輕繁瑣的手工配置和部署任務，由於可用完全相同的方式反覆執行，因此解決了隨時間推移引發的配置漂移問題，當有故障發生，基礎設施的恢復快速且有效。同時可對基礎架構以程式碼的形式進行版本控制，管理其更新、審核、驗證和回溯分析。

弄清楚了混沌工程的標的，現在可以來深入討論如何來評估混沌工程實驗的可行性條件。

混沌工程的可行性評估模型

在執行混沌工程實驗時，我們需有一個通用的標準來，判斷這個實驗可不可行，做得好不好。混沌工程的可行性評估模型，結合了亞馬遜和Netflix的混沌工程成熟度模型，從成熟度等級和接納指數兩個維度來衡量混沌工程實驗成功實施的可行性：

混沌工程實驗的成熟度等級

成熟度可以反映出混沌工程實驗的可行性、有效性和安全性。成熟度的級別也會因為混沌工程實驗的投入程度而有差異。這裡將成熟度等級分為1、2、3、4、5級進行描述，等級越高成熟度越好，混沌工程實驗的可行性、有效性和安全性會更有保障。

混沌工程實驗的接納指數

接納指數透過對混沌工程實驗改寫的廣度和深度來描述對系統的信心。暴露的脆弱點就越多，對系統的信心也就越足。類似成熟度等級，對接納指數也定義了 1、2、3、4 級進行描述。

混沌工程實驗的可行性路線圖

把當前專案進行成熟度等級和接納指數的評估，將兩者的結果合併放在一張圖上，就可構建出類似於魔力象限的坐標軸。這不僅可以瞭解當前專案進行混沌工程實驗的可行性，同時還可以與其他專案進行差異對比。此外，根據之前所討論的混沌工程實驗標的，設定想要達到的成熟度等級和接納程度，便獲得可行性路線圖，瞭解自身努力的方向。

綜上，本文是混沌工程專欄的第二篇，在此我們弄清楚了混沌工程實驗的標的，並透過對混沌工程的成熟度等級和接納指數的深入描述，探討瞭如何透過上述可行性評估模型來衡量混沌工程實驗的可行性、有效性和安全性。

本文轉載自亞馬遜AWS官方部落格，原文連結：https://aws.amazon.com/cn/blogs/china/aws-chaos-engineering-feasibility-assessment/

AWS 雲上混沌工程實踐之可行性評估篇

朋友會在“發現-看一看”看到你“在看”的內容

朋友將在看一看看到

釋出到看一看

相關推薦

熱門標籤

熱門文章

分享創造快樂