安全且無需人為干預的自動化部署

我在 Amazon 接受工作面試時，必定會問面試官：「你們多久部署一次產品？」 當時，我正在開發一種產品，該產品每年會推出一次或兩次重大版本，但有時我需要在兩次大型版本之間發佈較小的修正版本。對於發佈的每個修正版本，我花費數小時的時間謹慎推出。然後，我瘋狂地檢查日誌和指標，以查看部署後是否損壞任何內容及需要復原。

我了解到 Amazon 實作持續部署，因此在接受面試時，我想知道作為 Amazon 開發人員，需要花費多長時間來管理和監控部署。面試官告訴我，變更透過持續部署管道，每天多次自動部署至生產中。我問他一天中花費多長時間仔細看管每項部署，以及觀察日誌和指標，以了解我的操作是否產生任何影響時，他告訴我通常不會這樣做。因為管道為他的團隊完成這項工作，因此沒有人主動監控大多數部署。「哇！」 我吃驚道。加入 Amazon 後，我確切地了解這些無需人為干預的自動化部署的工作方式，對此我興奮不已。

Amazon 並非從實作持續交付開始，開發人員過去在此常常花費數小時和數天來管理其程式碼至生產的部署。我們在整個公司範圍內採用持續交付的方式，以自動化和標準化部署軟體的方式，並減少變更進入生產所需的時間。隨著時間的推移，我們對發佈程序的改進逐步增加。我們確定了部署風險，並找到透過管道中新的安全自動化來規避這些風險的方法。我們透過確定新的風險和提高部署安全性的新方法，繼續反覆查看發佈程序。若要進一步了解有關我們的持續交付之旅以及我們如何不斷改進的資訊，請參閱 Builders’ Library 文章透過持續交付加速實作。

在本文中，我們將逐步探究程式碼變更在 Amazon 生產過程的管道中所經歷的步驟。典型的持續交付管道具有四個主要階段 - 來源、建置、測試和生產 (prod)。我們將深入了解典型的 AWS 服務在每個管道階段中發生的情況，並為您提供一個範例，說明典型的 AWS 服務團隊如何建立其中一個管道。

下圖概述了在典型的 AWS 服務團隊管道中可能找到的來源與組建步驟。

Amazon 的管道會自動驗證任何類型的來源變更，並將其安全地部署至生產中，而不僅僅是應用程式的程式碼變更。這些管道可以驗證變更並將其部署至來源，例如網站靜態資產、工具、測試、基礎架構、組態以及應用程式的基礎作業系統 (OS)。所有這些變更在個別來源程式碼儲存庫中均受版本控制。來源程式碼相依項 (例如庫、程式設計語言) 和參數 (例如 AMI ID)至少每週自動升級至最新版本。

這些來源使用與部署應用程式的程式碼相同的安全機制 (如自動復原)，部署至個別管道中。例如，可以在執行時間變更的服務組態值 (例如 API 速率限制增加和功能標誌) 將自動部署在專用組態管道中。若服務的來源變更在生產中引起任何問題 (例如解析組態檔案失敗)，則會自動復原。

典型的微型服務可能具有應用程式的程式碼管道、基礎架構管道、作業系統修補管道、組態/功能標誌管道和操作人員工具管道。對於相同的微型服務，具有多個管道可協助我們更快地將變更部署至生產中。無法通過整合測試並封鎖應用程式管道的應用程式的程式碼變更不會影響其他管道。例如，他們不會封鎖基礎架構程式碼變更進入基礎架構管道中的生產階段。相同微型服務的所有管道看起來都非常相似。例如，功能標記管道使用與應用程式的程式碼管道相同的安全部署技術，因為錯誤的功能標記組態變更可能會對生產產生影響，就像錯誤的應用程式的程式碼變更可能產生影響一樣。

對生產做出的所有變更均從程式碼審查開始，並且在合併到至主管道分支 (我們的「主要」或「主幹」版本) 之前，必須經過團隊成員的核准，這會自動啟動管道。管道強制執行以下要求：必須對主管道分支上的所有提交項進行程式碼審查，並由該管道的服務團隊成員核准。對於任何未經審查的提交項，管道會封鎖其部署。

對於全自動管道，程式碼審查是工程師在將程式碼變更部署至生產之前進行的最後一次手動審查和核准，因此這是至關重要的步驟。程式碼審查人員評估程式碼的正確性，還將評估變更是否可以安全地部署至生產中。他們評估程式碼是否接受足夠的測試 (單元測試、整合測試和 Canary 測試)，是否提供了足夠的方式進行部署監控，以及是否可以安全地復原。一些團隊使用自訂檢查清單，如以下範例所述清單，該清單會自動新增至團隊的每個程式碼審查中，以明確檢查部署安全問題。

在建置階段，將對程式碼進行編譯和單元測試。建置工具和建置邏輯可能因語言而異，甚至因團隊而異。例如，團隊可以選擇最適合他們的單元測試框架、Linter 和靜態分析工具。此外，團隊可以選擇這些工具的組態，例如其單元測試框架中可接受的最低程式碼覆蓋率。執行的測試工具和類型也因管道部署的程式碼類型而異。例如，單元測試用於應用程式的程式碼，而 Linter 則用於基礎架構即程式碼範本。所有建置都可以在沒有網路存取的情況下執行，以隔離建置並鼓勵建置可重複性。通常，單元測試模擬 (模擬) 其相依項 (例如其他 AWS 服務) 的所有 API 叫用。稍後會在整合測試的管道中測試與「即時」非模擬相依項的互動。相較於整合測試，具有模擬相依項的單元測試能夠處理從 API 叫用傳回非預期錯誤等極端情況，並確保程式碼中的非失誤性錯誤處理。建置完成後，將會對編譯的程式碼進行封裝和簽名。 

在部署至生產之前，管道將部署並驗證多個前期生產環境中的變更，例如，Alpha、Beta 和 Gamma。Alpha 和 Beta 透過執行功能性 API 測試和端對端整合測試來驗證最新程式碼是否如預期執行。Gamma 驗證程式碼是否正常工作且安全地部署至生產中。Gamma 盡可能類似於生產，包括與生產相同的部署組態、相同的監控和警示，以及相同的持續 Canary 測試。Gamma 還會部署在多個 AWS 區域，以捕捉區域差異帶來的任何潛在影響。 

整合測試可協助我們像客戶在管道中那樣自動使用服務。這些測試透過針對所有意義重大的客戶場景，在每個前期生產階段叫用於真實基礎架構上執行的真實 API，以端對端方式使用整個堆疊。整合測試的目的是，在部署至生產之前捕捉服務的任何非預期或錯誤行為。

單元測試是針對模擬的相依項執行，而整合測試則針對叫用真實相依項的前期生產系統執行，從而驗證有關這些相依項行為的模擬假設。整合測試可驗證個別 API 在不同輸入中的行為。另外，這些測試還會驗證加入多個 API 的完整工作流程，例如建立新資源，就緒前描述新資源，然後使用該資源。

整合測試會同時執行正面和負面測試使用案例，例如向 API 提供無效輸入，並檢查是否如預期傳回「無效輸入」錯誤。一些管道會執行模糊測試，以產生許多可能的 API 輸入，並驗證其不會導致服務出現任何內部故障。一些管道還會在前期生產階段執行短期負載測試，以確保最新變更不會在實際負載水準下引起任何延遲或輸送量下降。

在部署至生產之前，我們需要確保最新的程式碼向後相容，並且可以與目前程式碼一起安全地部署。例如，我們需要偵測最新程式碼是否以目前程式碼無法解析的格式寫入資料。Gamma 的 one-box 階段將最新程式碼部署至最小的部署單元，例如單一虛擬機器或單一容器，或一小部分 AWS Lambda 函數叫用。這種 one-box 部署會將剩餘的 Gamma 環境與目前程式碼一起部署一段時間，例如 30 分鐘或一小時。不必將流量專門傳至 One box。可以將其新增至與其他 Gamma 環境相同的負載平衡器或輪詢相同的佇列。例如，在負載平衡器後面有十個容器的 Gamma 環境中，One box 接收持續 Canary 測試產生的 Gamma 流量的百分之十。one-box 部署監控 Canary 測試的成功率和服務指標，以偵測部署或並排部署「混合」機群的影響。

下圖顯示了將新的程式碼部署至 one-box 階段但尚未部署至其餘 Gamma 機群之後的 Gamma 環境狀態： 

我們還需要確保最新程式碼與我們的相依項向後相容，例如，若需要以特定順序在微型服務之間做出變更。前期生產環境中的微型服務通常叫用另一個團隊擁有的任何服務的生產端點，例如 Amazon Simple Storage Service (S3) 或 Amazon DynamoDB，但其會在同一階段叫用服務團隊其他微型服務的前期生產端點。例如，團隊在 Gamma 中的微型服務 A 叫用相同團隊在 Gamma 中的微型服務 B，但其叫用 Amazon S3 的生產端點。

此外，一些管道還會在稱為 zeta 的單獨向後相容階段中再次執行整合測試，這是一個單獨的環境，其中每項微型服務僅叫用生產端點，測試將要進入生產的變更是否與多項微型服務在生產中目前部署的程式碼相容。例如，zeta 中的微型服務 A 叫用微型服務 B 的生產端點和 Amazon S3 的生產端點。

如需有關編寫和部署向後相容變更的策略說明，請參閱 Builders’ Library 文章在部署期間確保復原安全。 

每個團隊需要權衡小範圍部署的安全，以及我們向所有區域客戶交付變更的速度。透過管道一次性將變更部署至 24 個區域或 76 個可用區域，產生廣泛影響的風險則降至最低，但管道將變更交付給全球客戶可能需要花費數週的時間。我們已經發現，如之前的範例生產管道所示，將部署分為日益增大的「浪潮」有助於我們在部署風險和速度之間取得良好的平衡。管道中的每個浪潮階段都會將部署協調至一組區域，並依據浪潮推進變更。新的變更可以隨時進入管道的生產階段。在從浪潮 1 的第一步到第二步推進一組變更後，Gamma 的下一組變更被提升為浪潮 1 的第一步，因此我們不必等待大量變更部署至生產中。

管道中的前兩個浪潮對變更最有信心：第一個浪潮部署至請求數量少的區域，以限制新變更第一次生產部署可能產生的影響。該浪潮在該區域一次僅部署至一個可用區域 (或單元)，以便謹慎地在整個區域部署變更。然後，第二個浪潮在具有大量請求的區域一次部署至一個可用區域 (或單元)，客戶很可能會執行所有新的程式碼路徑，並且我們可以很好地驗證變更。

在對初始管道浪潮的部署變更安全性有了更高的信心之後，我們可以在同一浪潮中平行部署至越來越多的區域。例如，之前的範例生產管道在第 3 浪潮中部署至三個區域，再在第 4 個浪潮中部署至多達 12 個區域，然後在第 5 個浪潮中部署至其餘的區域。每個浪潮中確切的區域數量和選擇，以及服務團隊管道中的浪潮數量取決於個別服務的用量模式和規模。管道中的後續浪潮仍然有助於我們實現防止對同一區域中多個可用區域造成負面影響的目標。當一個浪潮平行行部署至多個區域時，對於初始浪潮中使用的每個區域，它都會遵循相同的謹慎展開行為。浪潮中的每個步驟僅從浪潮中的每個區域部署至單一可用區域或單元。

每個生產浪潮的部署都從 one-box 階段開始。與 Gamma 的 One box 階段一樣，每個生產 One box 階段將最新程式碼部署至浪潮每個區域或可用區域中的 One box (單一虛擬機器、單一容器或一小部分 Lambda 函數叫用)。產品 one-box 部署首先限制該浪潮中新程式碼所處理的請求數，從而將變更對浪潮的潛在影響降至最低。通常，One box 最多可處理區域或可用區域總請求數的百分之十。若變更在 One box 中造成負面影響，則管道會自動復原變更，並且不會將其推進至產品的其餘階段。

one-box 階段之後，大多數團隊使用滾動部署來部署至浪潮的主要生產機群。滾動部署可確保服務具有足夠的能力，來在整個部署過程中處理生產負載。其控制新程式碼投入使用的速度 (即當它開始處理生產流量時)，以限制變更的影響。在典型的區域滾動部署中，該區域中最多 33% 的服務方塊 (容器、Lambda 叫用或虛擬機器上執行的軟體) 會被新程式碼取代。

在部署期間，部署系統首先選擇最多 33% 的方塊作為初始批次，以取代為新的程式碼。在取代期間，至少有 66% 的總容量正常執行並處理請求。所有服務均會擴展以承受該區域失去可用區域的情況，因此我們知道該服務仍然能夠以此容量來處理生產負載。部署系統確定初始方塊批次中的一個正在通過運作狀態檢查之後，剩餘機群中的方塊可以用新程式碼取代，依此類推。同時，我們仍然始終保持至少 66% 的容量來處理請求。為了進一步限制變更的影響，某些團隊的管道一次僅部署 5% 的方塊。然而，隨後會執行快速復原，其中系統用之前以前的程式碼一次取代 33% 的方塊，以加速復原。

下圖顯示了滾動部署過程中生產環境的狀態。新程式碼已部署至 one-box 階段和主要生產機群的第一批次中。另一批次已從負載平衡器中移除，且正在關閉以進行取代。

管道中的自動部署通常沒有開發人員主動觀察每個生產部署，檢查指標，以及在發現問題時手動復原。這些部署完全無需人為干預。部署系統會主動監控警示，以確定是否需要自動復原部署。復原會將環境切換回容器映像、AWS Lambda 函數部署套件或之前已部署的內部部署套件。我們的內部部署套件與容器映像類似，因為套件不可變，並使用檢查總和來驗證其完整性。

每個區域中的每項微型服務通常具有高嚴重性警示，這會觸發影響服務客戶指標的閾值 (如故障率和高延遲)，以及系統運作狀態指標 (如 CPU 使用率)，如以下範例所示。若正在進行部署，則此高嚴重性警示用於尋呼值班工程師並自動復原服務。通常，在值班工程師接到尋呼並開始工作時，復原已在進行中。

部署引入的變更可能會影響上游和下游微型服務，因此，部署系統需要監控正在部署的微型服務的高嚴重性警示，並監控團隊其他微型服務的高嚴重性警示，以確定何時復原。部署的變更也會影響持續 Canary 測試的指標，因此，部署系統還需要監控失敗的 Canary 測試。為了自動復原所有這些可能的影響領域，團隊會建立高嚴重性彙總警示，供部署系統監控。高嚴重性彙總警示將團隊所有個別微型服務高嚴重性警示的狀態彙總，並將 Canary 警示的狀態彙總為單一彙總狀態，如以下範例所示。若團隊微型服務的任何高嚴重性警示進入警示狀態，則團隊在該區域所有微型服務中所有正在進行的部署都將自動復原。

one-box 階段僅佔總流量的一小部分，因此 one-box 部署產生的問題可能不會觸發該服務的高嚴重性復原警示。為了在 One box 階段捕捉並復原導致問題的變更，然後再進入其餘的生產階段，One box 階段會額外復原僅適用於 One box 的指標。例如，其會復原由 One box 專門處理的請求錯誤率，這佔請求總數的一小部分。 

除了復原服務團隊定義的警示外，我們的部署系統還可以偵測並自動復原由內部 Web 服務框架發出的常見指標中的異常。我們的大多數微型服務都以標準格式發出指標，例如請求計數、請求延遲和故障計數。使用這些標準指標，若部署期間指標中有異常，則部署系統可以自動復原。例如，請求計數突然下降至零，或者等待時間或故障數量大大高於正常水準。

有時，部署產生的負面影響並不明顯。影響緩慢滋生。換言之，不會在部署期間立即顯現，服務當時處於低負載狀態時尤其如此。部署完成後立即將變更推進至下一個管道階段，這可能最終會在第一個區域中的影響浮出水面時對多個區域產生影響。在將變更推進至下一個生產階段之前，管道中的每個生產階段都有製作時間，即管道在部署完成之後以及進入下一個階段之前，管道會繼續監控團隊的高嚴重性彙總警示是否有任何緩慢滋生的影響。

為了計算花費在部署上的時間，我們需要權衡若我們過快地推進對多個區域的變更，與我們向全球客戶交付變更的速度所帶來的廣泛影響。我們發現，權衡這些風險的一個好方法是，對管道中較早的浪潮設定較長的製作時間，同時我們對變更的安全建立信心，然後對較晚的浪潮設定較短的製作時間。我們的目標是最小化對多個區域造成影響的風險。由於團隊成員不主動監控大多數部署，因此典型管道的預設製作時間比較保守，並且會在約四五個工作日內將變更部署至所有區域。規模較大或至關重要的服務製作時間，管道在全球部署變更的時間則更加保守。

典型的管道在每個 one-box 階段之後至少要等待 1 小時，在第一次區域浪潮之後至少要等待 12 個小時，在其餘區域浪潮之後至少要等待 2 至 4 小時，而個別區域、可用區域和每個浪潮中單元的製作時間也需要額外的製作時間。製作時間包括等待團隊指標中特定資料點數量的要求 (例如，「等待至少 100 個建立 API 的請求」)，以確保發生足夠的請求，從而讓新的程式碼經過充分鍛煉。在整個製作期間，若團隊的高嚴重性彙總警示進入警示狀態，則會自動復原部署。

雖然這種情況極為罕見，但在某些情況下，可能需要比管道通常進行變更和部署所需時間更快地將緊急變更 (例如安全修復或減少對影響服務可用性的大規模事件) 交付給客戶。在這種情況下，我們可以縮短管道的製作時間以加速部署，但我們需要對變更進行嚴格的審查。針對這些情況，我們需要對組織的首席工程師進行詳細審查。團隊必須與經驗豐富的開發人員 (操作安全方面的專家) 一起審查程式碼變更，以及其緊急性和影響風險。變更仍會像往常一樣經過管道中的相同步驟，但更快會推進至下一個階段。我們透過限制這段時間管道中執行的變更來管理加速部署的風險，僅允許解決目前問題所需的最小程式碼變更，並主動監控部署。

若存在較大的負面影響風險，管道會阻止自動部署至生產中。管道使用一組評估部署風險的「封鎖程式」。例如，若環境中目前存在問題，自動將新變更部署至產品可能會使影響變得更糟或延長時間。在開始將新的部署推進至生產階段之前，管道會檢查團隊的高嚴重性彙總警示，以確定是否存在任何作用中的問題。若警示目前處於警示狀態，則管道會阻止變更繼續進行。管道還可以檢查組織範圍內的警示，例如大型事件警示，其指示另一個團隊的系統是否存在廣泛影響，並阻止可能會增加整體影響的新部署。若需要將變更部署至生產以便從高嚴重性問題復原，開發人員可以覆寫這些部署封鎖程式。

此外，管道還會設定一組窗期，定義何時允許開始部署。在設定窗期時，我們需要權衡兩個部署風險原因。一方面，非常小的窗期可能會導致在關閉窗期時管道中堆積變更，從而增加在開啟窗期時下一次部署中的任何變更都產生影響的可能性。另一方面，超出正常工作時間的非常大的窗期會增加延長失敗部署影響的風險。在下班時間，相較於值班工程師和其他團隊成員工作的白天，值班工程師的工作時間更長。在正常工作時間，部署失敗後，團隊可以更快地投入工作，以免需要任何手動復原步驟。

團隊成員並未主動監控大多數部署，因此，在自動復原後需要手動操作的情況下，我們將部署時間最佳化，以最大程度地縮短與值班工程師的聯絡時間。值班工程師通常在夜間、假期和週末花費更長的時間，因此這些時間不在窗期範圍內。根據服務的用量模式，某些問題可能在部署後的幾小時內不會出現，因此，許多團隊還從其窗期中排除了週五和下午的部署，以降低部署後在夜間或週末需要值班工程師工作的風險。我們發現，即使在需要手動操作的情況下，這組窗期也可以實現快速復原，確保在正常工作時間之外減少與值班工程師的聯絡，並確保在關閉窗期時將少量變更繫結在一起。

典型的 AWS 服務團隊擁有許多管道來部署團隊的多種微型服務和來源類型 (應用程式的程式碼、基礎架構程式碼、作業系統修補程式等)。每個管道具有多個部署階段，以用於日益增多的區域和可用區域。這意味著團隊需要進行大量組態設定，以便在管道系統、部署系統和警示系統中進行管理，並且需要大量工作來保持最新的最佳實務以及滿足新的區域和可用區域。在過去的幾年中，我們採用了「管道即程式碼」實務，透過在程式碼中對該組態進行建模，更輕鬆且一致地設定安全、最新的管道。我們的內部管道即程式碼工具從區域和可用區域的集中清單提取，可輕鬆地將新的區域和可用區域新增至整個 AWS 的管道中。此外，該工具還允許團隊使用繼承對管道進行建模，定義在父類團隊管道中通用的組態 (例如每個浪潮中的區域以及每個浪潮的製作時間長短)，以及將所有微型服務管道組態定義為繼承所有通用組態的子類。

隨著時間的推移，我們依據可協助我們權衡部署安全與部署速度的方法，在 Amazon 上建立了自動化部署實務。同時，我們希望盡可能減少開發人員因擔心部署所花費的時間。透過使用廣泛的前期生產測試、自動復原和交錯式生產部署，將自動部署安全融入發佈程序，這使我們能夠最小化部署對生產產生的潛在影響。這意味著開發人員無需主動監控生產部署。

藉助完全自動化的管道，開發人員可以使用程式碼審查來檢查其程式碼，並核准變更已準備好進入生產。將變更合併至來源程式碼儲存庫之後，開發人員可以繼續執行下一個任務，而無需進行部署，確信管道將以安全、謹慎的方式將其變更運用於生產。自動化管道負責在一天中多次持續部署至生產，同時權衡安全與速度。透過用程式碼對我們的持續交付實務進行建模，AWS 服務團隊比以往任何時候都更容易設定其管道，以自動、安全的方式部署其程式碼變更。

如須有關 Amazon 改善服務安全性與可用性，同時提高客戶滿意度和開發人員生產力的詳細資訊，請參閱以持續交付加快腳步

如需有關編寫和部署向後相容變更的策略說明，請參閱 Builders’ Library 文章在部署期間確保復原安全