共用方式為

向右移以在生產環境中進行測試

  • 發行項

右 移是稍後在 DevOps 程式中移動一些測試以 在生產環境中進行測試的做法。 生產環境中的測試會使用實際部署來驗證及測量應用程式在生產環境中的行為和效能。

DevOps 小組可以改善速度的其中一 種方式是採用左 移測試策略。 Shift 向左推入 DevOps 管線中稍早的大部分測試，以減少新程式代碼到達生產環境並可靠地運作的時間量。

但是，雖然許多種類的測試，例如單元測試，可以輕鬆地向左移，但某些類別的測試無法執行，而不需要部署部分或所有解決方案。 部署到 QA 或預備服務可以模擬可比較的環境，但生產環境沒有完整的替代專案。 Teams 發現某些類型的測試需要在生產環境中發生。

在生產環境中進行測試提供：

  • 生產環境的完整廣度和多樣性。
  • 客戶流量的實際工作負載。
  • 隨著生產需求隨著時間的發展，配置檔和行為。

生產環境會持續變更。 即使應用程式未變更，它仍會持續依賴變更的基礎結構。 在生產環境中進行測試會驗證給定生產部署的健康情況和品質，以及不斷變更的生產環境。

在生產環境中向右轉移以測試，對於下列案例尤其重要：

微服務部署

微服務型解決方案可以有大量的微服務，這些微服務是獨立開發、部署及管理的。 移轉測試對這些項目特別重要，因為不同的版本和組態可以透過許多方式到達生產環境。 不論生產前測試涵蓋範圍為何，都需要在生產環境中測試相容性。

確保部署後的品質

發行到生產環境只是傳遞軟體的一半。 另一半是透過實際生產環境中的實際工作負載，大規模確保品質。 由於環境持續變更，因此小組永遠不會在生產環境中進行測試。

來自生產環境的測試數據實際上是來自實際客戶工作負載的測試結果。 生產環境中的測試包括監視、故障轉移測試和錯誤插入。 此測試會追蹤失敗、例外狀況、效能計量和安全性事件。 測試遙測也有助於偵測異常狀況。

部署環

為了保護生產環境，小組可以使用通道式部署和功能旗標，以漸進式且受控制的方式推出變更。 例如，當不到 1% 的客戶在該部署通道上時，最好攔截防止購物者完成購買的 Bug，而不是在一次切換所有客戶之後。 偵測到失敗的特徵值必須超過這些失敗的凈損失，以有意義的方式測量給指定的企業。

第一個通道應該是執行標準整合套件所需的最小大小。 測試可能類似於先前在管線中針對其他環境執行的測試，但測試會驗證生產環境中的行為是否相同。 此通道會先識別明顯的錯誤，例如設定錯誤，再影響任何客戶。

初始通道驗證之後，下一個通道可以擴大，以包含測試回合的實際使用者子集。 如果一切看起來都不錯，部署可以透過進一步的通道和測試進行，直到每個人都使用它為止。 完整部署並不表示測試已結束。 追蹤遙測對於在生產環境中進行測試非常重要。

錯誤插入

Teams 通常會使用 錯誤插入 和 混亂工程 來查看系統在失敗狀況下的行為。 這些做法有助於：

  • 驗證實作的復原機制實際上有效。
  • 驗證某個子系統中的失敗是否包含在該子系統內，而且不會串聯以產生重大中斷。
  • 證明先前事件的修復工作具有預期的效果，而不需要等待另一起事件發生。
  • 為即時網站工程師建立更真實的訓練演練，讓他們能夠更做好處理事件的準備。

將錯誤插入實驗自動化是一個很好的做法，因為它們是必須在不斷變化的系統上執行的昂貴測試。

混亂工程 可以是一個有效的工具，但應該僅限於 幾乎沒有或沒有客戶影響的 Canary 環境 。

故障轉移測試

錯誤插入的一種形式是 故障轉移 測試，以支援商務持續性和災害復原（BCDR）。 Teams 應該具有所有服務和子系統的故障轉移計劃。 這些方案應包括：

  • 清楚說明服務中斷的業務影響。
  • 平臺、技術和設計 BCDR 計劃的人員，所有相依性的地圖。
  • 災害復原程式的正式檔。
  • 定期執行災害復原演練的步調。

斷路器錯誤測試

斷路器機制會從較大的系統切斷指定的元件，通常可防止該元件在界限外擴散失敗。 您可以刻意觸發斷路器來測試下列案例：

  • 當斷路器開啟時，後援是否正常運作。 後援可能會與單元測試搭配運作，但唯一知道其在生產環境中是否如預期般運作的方法，就是插入錯誤來觸發它。

  • 斷路器是否需要開啟正確的敏感度閾值。 錯誤插入可能會強制延遲或中斷相依性，以觀察中斷程序回應性。 請務必確認不僅發生正確的行為，而且會執行得夠快。

範例：測試 Redis 快取斷路器

Redis 快 取可加速存取常用數據的效能，以改善產品效能。 請考慮採用 Redis 非關鍵相依性的案例。 如果 Redis 關閉，系統應該會繼續運作，因為它可以回復為使用原始數據源進行要求。 若要確認 Redis 失敗觸發斷路器，且後援在生產環境中運作，請定期針對這些行為執行測試。

下圖顯示 Redis 斷路器後援行為的測試。 目標是確保當中斷器開啟時，呼叫最終會移至 SQL。

Diagram showing tests for the Redis circuit breaker and fallback behavior.

上圖顯示三個 AT，在對 Redis 的呼叫前面有斷層器。 一個測試會強制斷路器透過組態變更開啟，然後觀察呼叫是否移至 SQL。 接著，另一項測試會關閉斷路器以確認呼叫返回 Redis，以檢查相反的組態變更。

此測試會驗證當中斷器開啟時，後援行為是否可運作，但不會驗證斷路器組態在應該時開啟斷路器。 測試該行為需要模擬實際失敗。

錯誤代理程式可以在前往 Redis 的呼叫中引入錯誤。 下圖顯示使用錯誤插入進行測試。

Diagram showing Redis circuit breaker testing with fault injection.

  1. 錯誤插入器會封鎖 Redis 要求。
  2. 斷路器隨即開啟，測試可以觀察後援是否正常運作。
  3. 已移除錯誤，斷路器會將測試要求傳送至 Redis。
  4. 如果要求成功，呼叫會還原回 Redis。

進一步的步驟可以測試中斷者的敏感度、臨界值過高或太低，以及其他系統逾時是否會干擾斷路器行為。

在這裡範例中，如果中斷器未如預期般開啟或關閉，可能會導致 即時網站事件 （LSI） 。 如果沒有錯誤插入測試，問題可能會無法偵測到，因為很難在實驗室環境中執行這種類型的測試。

下一步