安全部署做法的建議

  • 發行項

適用于此 Azure Well-Architected Framework Operational Excellence 檢查清單建議：

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

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

主要設計策略

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

  • 安全性和一致性：生產工作負載的所有變更原本就具有風險，而且必須著重于安全性和一致性。

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

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

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

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

安全性和一致性

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

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

漸進式暴露部署

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

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

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

健康情況模型

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

問題偵測

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

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

  • 在推出時解決問題，以向前復原部署。 您可以套用 Hotfix 來解決推出中的問題，或將問題降至最低。

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

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

一般 SDP 建議

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

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

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

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

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

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

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

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

緊急 SDP 通訊協定

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

  • 升階和核准階段加速。

  • 噴氣測試和整合測試加速。

  • 縮小製作時間。

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

考量事項

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

Azure 設施

範例

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

營運卓越檢查清單

請參閱一組完整的建議。

營運卓越檢查清單