共用方式為

安全部署做法的建議

  • 發行項

適用於此 Azure 架構完善的架構營運卓越檢查清單建議：

OE：11 清楚定義工作負載的安全部署做法。 強調小型、增量、品質網關發行方法的理想。 使用新式部署模式和漸進式暴露技術來控制風險。 考慮例行部署和緊急部署，或 Hotfix 部署。

本指南說明使用安全部署做法 （SDP） 的建議。 安全部署程式和程式會定義如何安全地對工作負載進行和部署變更。 實作 SDP 需要您透過管理風險的鏡頭來思考部署。 您可以將部署中人為錯誤的風險降到最低，並藉由實作SDP來限制有問題的部署對用戶的影響。

關鍵設計策略

實作安全部署做法時，有四個重要的指導方針要牢記：

  • 安全性和一致性：生產工作負載的所有變更本質上都是有風險的，而且必須專注於安全性和一致性。

  • 漸進式曝光：您可以採用漸進式曝光部署模型，將部署原因問題的潛在爆破半徑降到最低。

  • 健康情況模型：部署必須先通過健康情況檢查，才能開始進行漸進式曝光的每個階段。

  • 問題偵測：偵測到問題時，應該立即停止部署並起始復原。

下列各節提供每個點的詳細建議。

確保部署的安全性和一致性

無論您是將更新部署到應用程式程式碼、基礎結構即程式碼 (IaC)、功能旗標或組態更新，都會為工作負載帶來風險。 沒有 低風險 部署至生產環境。 每個部署都必須遵循標準模式，並應該自動化以強制執行一致性，並將人為錯誤的風險降到最低。 您的工作負載供應鏈和部署管線必須可靠、安全且已明確定義部署標準。 將每個部署視為可能的風險，並將每個部署都受限於相同的風險管理層級。 儘管有風險，您仍應繼續對工作負載進行定期變更。 無法部署一般更新會產生其他風險，例如必須透過部署解決的安全性弱點。 如需詳細資訊，請參閱 設計工作負載開發供應鏈的建議。

常見的小型部署最好是不常的大型部署。 當問題發生時，小型變更更容易解決，且頻繁的部署可協助小組建立對部署程式的信心。 當您在部署期間遇到異常時，檢閱工作負載程式，從生產環境學習也很重要。 您可能會在基礎結構或推出的設計中發現弱點。 當部署期間發生問題時，請確定 無 可指責的驗屍是 SDP 程式的一部分，以擷取事件的相關教訓。

採用漸進式曝光模型

發生部署問題時，目標是儘早發現問題，以將對終端使用者的影響降到最低。 實作漸進式推出部署模型，也稱為 漸進式曝光模型，以達成此目標。 Canary 部署是漸進式曝光的常見範例。 在此部署模型中，一小群內部或外部使用者會先接收新功能。 在第一個群組執行新版本而沒有問題之後，此功能會部署至連續較大的群組，直到整個使用者母體擴展執行新版本為止。 功能旗標通常用於為 Canary 部署中的目標用戶啟用新版本。

另一個常見的部署模型是藍色-綠色的方法。 在此模型中，會部署工作負載基礎結構的兩個相同集合或集區。 這兩個集區都能夠處理完整的生產負載。 第一個 （藍色） 集區會執行所有使用者登陸的目前部署版本。 第二個 （綠色） 集區會使用新功能進行更新，並在內部測試。 內部測試之後，生產流量的子集會從藍色集區路由傳送至綠色集區。 就像 Canary 部署一樣，隨著您在連續較大的推出波中，將更多的流量轉移到綠色集區時，推出是漸進的。 完成推出之後，更新集區會變成藍色集區，而綠色集區已準備好進行下一個部署。 這兩個集區在邏輯上彼此分開，以防止故障。 您可以在使用部署戳記設計模式的工作負載 中部署藍色-綠色模型的變化，方法是一次在一個戳記 上部署。

在這兩種模型中，推出的每個階段之間的時間應該夠長，讓您能夠監視工作負載的健康情況計量。 您應該提供充足的 製作時間、推出群組之間的時間，以協助確保不同區域的使用者或執行不同工作的使用者有時間在正常容量中使用工作負載。 烘焙時間應該以小時和天數來測量，而不是以分鐘為單位。 每個推出群組的製作時間也應該增加，讓您可以考慮一天中的不同時區和使用模式。

開發健全的工作負載健康情況模型

開發健全的健康情況模型，作為可觀察性平臺和可靠性策略的一部分。 您的健康情況模型應該提供工作負載元件和整體健康情況的深入可見度。 在推出期間，如果您收到與使用者相關的健康情況變更警示，則應立即停止推出，並對警示原因進行調查，以協助判斷下一步行動方案。 如果用戶沒有回報的問題，而且所有健康指標在烘焙時間保持綠色，則推出應該繼續。 請務必在健康情況模型中包含使用計量，以協助確保缺少用戶回報的問題和負面健康情況訊號不會隱藏問題。 如需詳細資訊，請參閱 建置健康情況模型。

實作失敗偵測機制

當您的部署在其中一個推出群組中造成問題時，首度發行必須立即停止。 在收到警示時，必須立即執行問題原因和效果嚴重性的調查。 從問題復原可能包括：

  • 復原 部署中所做的變更，並還原回最後一個已知的工作組態，以復原部署。

  • 在推出期間解決問題，以推動 部署。 您可以套用 Hotfix，或將問題降至最低，以解決推出中的問題。

  • 使用最後一個已知的工作組態來部署新的基礎結構 。

回復變更，特別是資料庫、架構或其他具狀態元件變更，可能很複雜。 您的 SDP 指導方針應該提供清楚的指示，說明如何根據工作負載的數據資產設計來處理數據變更。 同樣地，必須謹慎處理向前復原，以確保 SDP 不會被忽視，並安全地執行 Hotfix 或其他最小化的工作。

建立緊急部署的通訊協定

  • 在組建成品之間實作版本控制，以協助確保您可以在必要時回復和向前復原。

  • 使用發行流程或主幹型分支結構，以強制執行跨開發小組緊密同步的共同作業，而不是 Gitflow 或以環境為基礎的分支結構。

  • 盡可能自動化您的 SDP。 如需自動化 IaC 和應用程式持續整合和持續傳遞 （CI/CD） 程式的詳細指引，請參閱 實作自動化的建議。

  • 使用 CI 做法，定期將程式代碼變更整合到存放庫中。 CI 做法可協助您識別整合衝突，並降低大型風險合併的可能性。 如需詳細資訊，請參閱 持續整合指南。

  • 使用功能旗標選擇性地啟用或停用生產中的新功能或變更。 功能旗標可協助您控制新程序代碼的曝光，並在發生問題時快速回復部署。

  • 將變更部署到鏡像生產環境的預備環境。 練習環境可讓您先測試受控制設定中的變更，再部署到實時環境。

  • 建立預先部署檢查，包括程式代碼檢閱、安全性掃描和合規性檢查，以協助確保變更安全部署。

  • 實作斷路器，以自動停止發生問題之服務的流量。 這樣做有助於防止系統進一步降低。

緊急 SDP 通訊協定

建立規範通訊協定，以定義如何針對 Hotfix 調整 SDP，或針對安全性缺口或弱點暴露等緊急問題進行調整。 例如，您的緊急 SDP 通訊協定可能包括：

  • 促銷和核准階段加速。

  • 煙霧測試和整合測試加速。

  • 縮短製作時間。

在某些情況下，緊急狀況可能會限制品質和測試閘道，但閘道仍應盡可能儘快執行頻外練習。 請確定您在緊急狀態中定義誰可以核准 SDP 加速，以及必須符合才能核准加速的準則。 將您的緊急 SDP 通訊協定與您的緊急回應計畫一致，以協助確保所有緊急情況都根據相同的通訊協議進行處理。

考量

建置和維護安全部署做法相當複雜。 您完全實作健全標準的成功取決於您在軟體開發的許多領域做法的成熟度。 使用自動化、僅限 IaC 進行基礎結構變更、分支策略中的一致性、使用功能旗標和其他許多做法有助於確保安全部署。 使用本指南將工作負載優化，並在做法發展時通知您的改進計劃。

Azure 便利化

範例

如需如何使用此部署模型的範例，請參閱 Azure Kubernetes Service （AKS） 叢集架構指南的藍綠部署。

卓越營運檢查清單

請參閱一組完整的建議。

卓越營運檢查清單