現(xiàn)代系統(tǒng)必須能夠處理混亂以避免停機

盡管我們盡最大努力避免它們，但IT事件是這項工作不可避免的一部分 - 并且試圖保持領先于業(yè)務影響的停機時間只會變得更加棘手。今天的系統(tǒng)緊密耦合，越來越復雜，更多的移動部件帶來更多出錯的機會。

這就是為什么越來越多的組織轉向微服務以提高服務可用性和更好地恢復故障的原因之一。雖然這些是破壞單片應用程序的重要前提，但它們也可能增加失敗的風險 - 除非明確考慮到彈性設計。

準備失敗

鑒于分布式系統(tǒng)固有的混亂特性，應該開發(fā)服務，不僅要預測故障，還要在發(fā)生故障時自動恢復。這意味著定期發(fā)生故障，以確保您的系統(tǒng)能夠處理混亂而不會中斷對最終客戶的服務。為了實現(xiàn)這一目標，您需要能夠在測試環(huán)境中模擬類似生產的流量。

當然，在更改生產之前測試彈性是個好主意。如果您不這樣做，您將無法驗證您的服務是否支持平均和峰值負載。事實上，最安全的選擇是確保您的產品能夠處理峰值量的兩倍而無需擴大規(guī)模。

在彈性測試方面，正確的工具不應過于關注請求的處理方式，只要他們最終能夠產生正確的影響。請記住，在某些情況下，輸入服務可能無法將請求移交給系統(tǒng)的其余部分，但不會報告失敗。通過確保實際上正在進行端到端驗證，不要冒險在監(jiān)控雷達下飛行的問題。

下一步

在了解服務如何在負載下運行之后，是時候開始介紹故障事件了。與所有軟件測試一樣，最好使用自動化工具，以便您輕松快速地重現(xiàn)場景，以便您可以協(xié)調影響不同基礎架構技術的復雜事件。除了驗證修復和服務更改的能力之外，這還允許您在任何環(huán)境和計劃中運行隨機故障方案。

有意義的失敗事件在很大程度上取決于您的服務布局，您可以通過詢問與您相關的特定問題來制定它們。例如，當數(shù)據(jù)庫在一段時間內無法訪問時，使用前端的人員會受到什么影響?這些用戶是否仍可以在Web UI中導航?他們是否仍然可以對其信息進行更新，并且當數(shù)據(jù)庫再次可以訪問時，是否可以正確處理這些更新?

如果您運行多個微服務，則可以詢問是否存在全局中斷，如果任何單個服務崩潰?；蛘撸绻幸粋€緩沖服務之間通信的排隊機制，當消費者服務(或服務)停止工作時會發(fā)生什么?用戶是否仍然可以使用您的應用程序?并且考慮到平均負載，在隊列溢出并開始丟失消息之前你有多長時間?

一旦定義了有關基礎架構的幾個關鍵問題，就可以開始列出模擬這些失敗的不同方法。停止特定服務或數(shù)據(jù)庫服務器可能就足夠了。您可能希望阻止服務的主線程來模擬死鎖，而其容器仍然響應并運行。您可能決定在網絡中引入規(guī)則以阻止特定服務之間的流量。在Linux環(huán)境中，您可以使用“tc”等工具來模擬網絡情況，如高延遲，丟失，損壞或重復的數(shù)據(jù)包。

通過演練學習和提高

創(chuàng)建故障場景最有價值的方面之一是它們可以暴露系統(tǒng)可能失敗的所有潛在方式，從而為自我修復邏輯奠定了基礎。您的團隊將完成手動恢復服務的步驟 - 順便說一下，確保他們能夠在SLA中執(zhí)行此操作?？梢允褂么嘶謴瓦^程的自動化，但與此同時，您可以輕松了解您的團隊已經完成了使服務重回正軌的過程。通過使故障情景隨機且有規(guī)律并且不公開運行的完整細節(jié)，您還可以包括對演習的發(fā)現(xiàn)和診斷 - 畢竟這是SLA的關鍵部分。

混沌工程的核心是將系統(tǒng)的復雜性作為給定，通過模擬新的和古怪的條件來測試它，并觀察系統(tǒng)如何響應。這是數(shù)據(jù)工程團隊需要重新設計和重新配置系統(tǒng)以實現(xiàn)更高的彈性。學習新的有用的東西有很多機會。例如，您可能會發(fā)現(xiàn)下游服務發(fā)生更改時服務未獲得更新的實例，或者完全缺少監(jiān)視的區(qū)域。有一些令人興奮的方法可以讓您的產品更具彈性和穩(wěn)健性!