共用方式為


在雲端中執行現代化

執行是計劃變成現實的地方。 此步驟牽涉到準備每個人進行變更,並在非生產環境中執行開發工作。 您會以受控制的方式徹底測試並部署到生產環境。 重點是嚴格的測試和安全部署做法,以將業務中斷降到最低,因為變更可能相當重要。

準備持份者面對現代化

在按下 [部署] 按鈕之前,請務必為所有項目關係人和用戶準備即將推出的專案。 意外可能會導致混淆,甚至是操作問題。 主要準備步驟包括通訊、變更凍結(稍早所述),以及支持計劃:

  1. 向所有項目關係人宣佈部署排程。 事先,與所有受影響的各方溝通,告知現代化部署計劃的時間以及預期的情況。 包含重要日期,例如變更凍結開始和上線視窗,以協助專案關係人適當地準備。 藉由設定預期,使用者可以規劃停機時間,且內部小組可以準備就緒。

  2. 在來源和相依工作負載上實作變更凍結。 如先前在治理中規劃的,現在是實際強制執行凍結的時候了。 請確定在部署前的一段時間內以及部署期間,工作負載及其相依工作負載上不會發生任何程式碼變更、配置調整或其他部署。 這可讓環境保持穩定。 請確定所有小組成員和任何整合的第三方都知道。 清楚定義具有特定開始和結束時間的凍結視窗,以避免混淆。

  3. 傳達最終的用戶動作和部署后變更。 使用者需要事先通知部署前後的必要動作,以防止工作流程中斷。 指示使用者在切換開始之前登出或儲存工作。 共用新的存取 URL、驗證變更,例如Microsoft Entra ID 登入需求,以及影響每日作業的更新工作流程。 提供支援檔和快速入門指南,以減少第一天的混淆。

  4. 協調部署的支援人員配置。 IT 作業和開發小組必須能夠監視和回應關鍵部署階段的問題。 部署後第一個工作天,由於問題最可能浮現,因此請排程延長支援時數與安排其他員工。 通知業務單位部署後的支持計劃和升級流程,確保問題能夠快速被解決。

  5. 定義關鍵工作負載的備援程序。 任務關鍵性工作負載需要手動因應措施和應變計劃,才能在部署期間維護商務作業。 記錄特定流程,例如在工作負載只讀期間的手動訂單處理。 預先共用這些程序,並確認受影響小組的準備情況,以確保在需要時能順利執行。

在非生產環境中開發現代化

現代化變更的所有開發和整合都應該發生在生產環境之外(在開發、測試、預備環境中)。 指導原則:先在類似 Prod 的環境中建置和測試,如此一來,當您部署至 prod 時,就已經是已知的數量。

  1. 在實作期間遵循 Well-Architected 架構原則。 當您撰寫程式代碼並設定新的變更時,請持續套用 Azure Well-Architected Framework (WAF) 的最佳做法。 使用 Azure Advisor 建議和架構檢閱程式來驗證設計決策。 此方法可確保現代化元件符合 Azure 最佳做法和作業標準。

  2. 建立仿效生產環境的非生產環境。 在 Azure 中啟動盡可能接近生產設定的開發/ 測試環境。 如果生產環境使用特定 Azure 服務,請在測試中使用相同、較小規模或較低的效能層級 (SKU)來節省成本。 測試環境越接近生產環境,您就越有信心測試結果應該延續到生產行為。

  3. 使用原始檔控制和 CI/CD 逐步實施變更。 像任何其他軟體項目一樣對待現代化工作。 針對所有程式代碼變更和基礎結構使用 Git 或其他原始檔控制作為程式代碼腳本。 它提供歷程記錄,並在需要時回復程序代碼。 將工作分成更容易管理的小分塊(例如按功能或修正分配),並使用功能分支。 在程式碼審查之後,經常合併更動。 設定持續整合建置,以在每次提交時執行測試套件,以便及早發現問題。

使用測試驗證現代化變更

測試非常重要。 由於現代化不會新增新功能,因此重點在於回歸測試(沒有中斷)和效能/安全性測試(其運作效果優於之前,而不是更糟)。 您想要在接觸生產環境之前,先確認測試環境中工作負載的各個層面。

  1. 對所有修改的元件執行單元和整合測試。 開發人員應該為任何重構的程式代碼建立或更新單元測試。 即使是遺留程式碼,為重要函式撰寫單元測試也可以幫助發現重構後行為是否不小心發生變化的情況。 在 CI 管線中持續執行單元測試。 此外,請執行整合測試,以確保元件能夠正確地彼此通訊。 在任何程式漏洞修正之後,請重新執行相關的測試,以確保該問題確實已解決,且不會導致其他問題(避免回歸)。

  2. 進行端對端功能測試。 在預備或測試環境中,執行完整的工作流程測試,就像您是使用者一樣。 此測試可以是QA的手動測試或自動化UI測試。 登入應用程式,執行主要工作。 請確定未變更的功能保持不變。 基本上,模擬實際使用情況來發現單元測試可能會遺漏的問題。

  3. 由項目關係人進行使用者驗收測試(UAT)。 在上線之前,讓一些實際的終端使用者或商務項目關係人測試現代化工作負載是明智的。 他們可能會發現開發人員忽略的細微差別。 擷取可用性、效能和功能差距的意見反應。 在部署之前解決重要的使用者驗收測試 (UAT) 問題,並取得項目關係人正式核准,以確認業務整備程度。

  4. 在實際情況下使用負載測試來驗證效能。 現代化應理想地改善或維護效能。 使用負載測試工具(例如 Azure 負載測試)來模擬實際的使用模式。 比較結果與來源環境中的效能基準,以識別任何效能降低。 在預期負載的150%進行壓力測試,以判斷工作負載限制並驗證壓力下的復原能力。

  5. 執行安全性驗證和合規性檢查。 在新的程式代碼和容器映射上執行弱點掃描,以偵測安全性風險。 使用業界特定工具,針對受管制工作負載執行合規性驗證。 使用適用於雲端的 Microsoft Defender 掃描基礎結構設定錯誤,並驗證安全性控制是否符合需求。

  6. 在生產部署之前解決所有重大問題。 修正測試階段期間所識別的功能、效能和安全性問題。 確認所有測試通過,且效能符合服務等級協定(SLA)。 記錄任何剩餘的低優先順序問題,並建立部署后解決的補救計劃。

建立可重複使用的基礎結構

一旦現代化解決方案在非生產環境中通過所有測試之後,您應該擷取基礎結構設定和設定作為程序代碼,以便在生產環境與未來環境中輕鬆復寫。 可重複使用的基礎結構表示使用基礎結構即程序代碼 (IaC) 範本和自動化,以取得一致性和速度。

  1. 建立經驗證組態的 IaC 範本。 取得測試環境的最終架構(其會反映您想要在 Prod 中的內容),並加以編纂。 使用 BicepTerraformAzure Resource Manager 範本 來定義您的基礎結構。 把這些範本參數化,讓它們能在開發、測試、生產等不同階段重複使用,並稍微調整名稱或大小。 此設定可確保您所建立的生產環境符合您測試的內容。 它可避免在手動按兩下 Azure 入口網站以建立資源時發生人為錯誤。 這也表示,如果您需要重新建立環境,例如災害復原或部署到新的區域,您就已備妥基礎結構部署。 如需詳細資訊,請參閱 CAF 管理 - 管理程式代碼型部署

  2. 將範本儲存在版本控制中。 將您的基礎結構程式代碼簽入 Git 存放庫(應用程式程式代碼或個別存放庫中)。 使用 GitHubAzure DevOps 以適當的版本控制來管理 IaC 資產。 版本控制可啟用程式代碼檢閱、支援小組共同作業,並鼓勵跨專案重複使用範本。 此方法提供基礎結構變更的完整可追蹤性,並在發生問題時支援復原功能。

  3. 自動化相依性安裝和設定。 建立腳本或管線工作來部署這些範本,並同時處理任何必要的設定或植入工作。 使用 Azure PipelinesGitHub Actions來執行部署作業,以採用 IaC 範本並部署至目標訂用帳戶/資源群組。 自動安裝應用程式依賴項、配置設定和機密管理。 目標是做到單鍵(或單一命令)環境設置:從無到有,建立與您測試完全相符的可運行環境。

  4. 測試 IaC 和自動化端對端。 使用個別的 Azure 訂用帳戶或資源群組作為沙箱,並練習使用範本和腳本從頭開始部署整個環境。 測試您的 IaC 範本、管線和腳本是否可以從零建立完整的基礎架構堆疊。 測試不同的部署案例,包括初始部署、組態更新和復原程式,以確認自動化正常運作。

如需詳細資訊,請參閱在WAF中 設計工作負載開發供應變更基礎結構即程序代碼

建立部署文件

即使使用自動化,在部署上擁有良好的文件對於稽核、讓新小組成員上線,以及未來維護而言也至關重要。 部署檔應涵蓋人類可讀取格式的設定、程序和復原步驟。

  1. 文件的組態設定和操作步驟。 記錄可存取檔中的所有環境特定設定、連接字串、服務端點和安全性設定。 包含逐步部署指示、必要條件需求和部署后驗證步驟。 本文件可促成一致的部署,並支援在發生問題時進行疑難解答。 如果新進工程師必須進行部署,他們可以閱讀這份文件,跟隨步驟或瞭解管道的輸出。

  2. 更新回滾和復原程序。 完成測試之後,請正式化步驟,以在發生部署問題時還原變更。 包含復原觸發程式、數據備份和還原程式,以及復原驗證步驟。 定期測試回復和復原程式,以確保其在需要時正常運作。 此準備可減少停機時間。

  3. 請將所有文件收集到一個集中地點。 使用 SharePoint、GitHub 或 Wiki 來儲存此資訊。 請確定小組和支持人員知道哪裡可以找到它。 在高壓力事件中,手邊有明確的文件可幫助解圍。

部署現代化

生產部署是現代化工作的高潮。 根據您選擇的策略(就地或平行),步驟會有所不同。 在執行之前,請仔細檢查是否已完成所有準備步驟:項目關係人通知、凍結生效、備份、待命監視。

就地部署現代化

  1. 計劃維護時段。 如果變更需要任何停機或執行中的腳本來鎖定資源,例如資料庫架構移轉,請在預先宣告的維護視窗中執行。 請確定所有用戶當時都已關閉工作負載。 擁有清楚的視窗也會提供您完成部署的目標,或在您用完時間時決定復原。

  2. 使用 CI/CD 管線進行部署。 生產部署應該使用與測試時相同的自動化管線,但需指向生產環境。 此設定可確保一致性,因此基礎結構和程式代碼會以相同的方式部署。 在執行之前,請先對任何重要數據進行最終備份(資料庫)。 即使您可以復原,備份仍是一道額外的安全防護措施,以防萬一發生意外。 執行管線以部署新的程式碼和基礎結構變更。 實時顯示記錄和監視。 如果有任何步驟失敗,請暫停並評估您是否可以繼續修正,或需要回復。

  3. 盡可能實作漸進式流量路由(Canary)。 許多 Azure 服務允許槽位交換或漸進式流量轉移,即使在原地部署情境中也是如此。 Azure 支援透過 Azure App Service 部署插槽Azure Container Apps 流量分割,以及 使用 Azure Pipelines 的 Azure Kubernetes Service 進行金絲雀部署。 如果您在負載平衡器後方有多個虛擬機,請一次更新一個實例(滾動升級),讓其他實例承載流量,然後輪換。

  4. 在監視時逐漸增加至完整流量。 新版本上線後,請密切監視它。 檢查應用程式記錄、效能計量、錯誤率。 從一小部分的用戶開始(或盡可能從驗證模式中的工作負載開始)。 如果經過幾分鐘後一切看起來都正常,則提高至25%的流量。 再次檢查指標(500 錯誤沒有峰值,回應時間正常)。 將增加至50%,然後再在您計劃的任何時間範圍內增加至100%。 如果您想要謹慎,可能需要超過一個小時甚至更久。 如果在任何步驟中觀察到嚴重問題,請在影響所有使用者之前啟動復原。

  5. 在部署期間維護數據一致性。 就地部署會保留現有的數據端點,同時可能修改數據架構。 以回溯相容的方式套用資料庫架構變更,以在 Canary 版本期間同時支援舊版和新應用程式版本。 使用資料庫移轉腳本來新增數據行或數據表,而不需要移除現有的結構,直到部署順利完成為止。

將現代化部署至平行環境

  1. 建立平行生產環境。 使用 IaC 範本,在 Azure 中建立新的生產環境,以反映您所測試的內容。 此環境包含所有計算、網路、記憶體。 它應該已啟動並運作,但目前沒有使用者流量。 確保網路安全群組、防火牆、身分識別(受控識別或服務主體)和監控等項目都按照需要進行配置(基本上就是在生產訂閱中重複測試環境的設置)。

  2. 建立資料庫複寫。 設定資料庫平臺的原生復寫功能,以建立來源與 Azure 目標工作負載之間的連續數據復寫。 確認初始數據同步處理順利完成,且復寫狀況良好。 您可以從備份或快照集進行資料庫的初始大量複製,然後為新交易啟用複寫。 使用資料庫平臺的監視工具監視複寫延遲。 較高的延遲會增加系統切換風險和持續時間。 在復寫延遲為零之前,請勿繼續進行下一個步驟。

  3. 複製非結構化數據和檔案。 在最終的完全移轉之前,將非結構化數據和檔案複製到 Azure。 使用 用於物件和檔案移轉的工具,其功能可將檔案傳輸到適當的 Azure 儲存服務。 此準備可減少在最後切換過程中需要複製的數據量。

  4. 完成最終的數據同步處理。 在移轉時刻,您希望沒有或只有極少的資料流失。 針對資料庫,確認來源的工作負載上沒有擱置的交易,而且資料庫的複寫已完成。 在某些情況下,您可能需要短暫暫停源資料庫的寫入,以排清最終的變更(尤其是交易一致性等專案)。 您可以使用技術,如交易日誌傳送或短暫停機時間,來執行最後一次增量備份還原。 使用 AzCopy 或類似工具複製任何修改過的非結構化數據。

  5. 逐漸將使用者流量移轉至新環境。 更新 DNS 記錄和負載平衡器設定,以將使用者流量導向至 Azure 環境。 監視工作負載的性能和健康情況。 從 1% 的即時流量開始,透過 Azure 負載平衡器使用加權路由將流量導向新的工作負載。 監視即時計量,包括回應時間、錯誤率和資料庫連線健康情況。 在數分鐘內而非數小時中快速增加流量(5%、15%、50%),如果超過閾值,會啟動自動回滚觸發器。

  6. 完成最終切換至 100%。 一旦您有信心,請將所有使用者重新導向至新的系統環境。 此切換可能是 DNS 切換,如果生存時間 (TTL) 值很低,或是變更負載平衡器的設定,可能需要幾秒鐘到幾分鐘的時間。 此時,使用者已經開始使用現代化的工作負載。

  7. 立即驗證並監視系統切換後。 執行切換後的驗證檢查。 使用自動化測試套件,對所有重要商務程序執行端對端功能測試。 使用來源和目標工作負載之間的總和檢查碼驗證和哈希函式比較來驗證數據精確度。 讓工作負載擁有者確認所有主要功能都正常運作。 在系統切換後的前 24-48 小時內,監控工作負載性能、錯誤率和使用者存取模式,以辨識任何性能衰退或功能問題。

  8. 讓舊環境持續執行 (熱待命) 一段時間。 別撕掉任何東西了。 最好將舊工作負載保留為至少 24-72 小時的備援狀態,並盡可能持續資料同步(或準備好能快速同步)。 如果生產環境中出現非預期的嚴重問題,您仍然可以選擇透過將流量重新導回來進行回復。 您應該不會遺失太多數據,因為您可以從日誌或其他方式恢復。

驗證現代化成功

現在,新的工作負載已上線,您必須在生產環境中驗證一切如預期般運作,並符合驗收準則。

  1. 確認使用者存取成功和工作負載效能。 使用者存取驗證可確保現代化是透明的,且效能符合預期。 此確認會驗證使用者可以存取工作負載,而不會中斷。 在移轉後的初始期間監視使用者存取模式、工作負載效能計量和錯誤率。

  2. 只有在徹底驗證之後才會宣佈移轉成功。 完成驗證可確保所有項目關係人確認工作負載穩定且正常運作。 此確認可防止過早宣告成功,而可能導致稍後發生問題。 從工作負載擁有者、測試人員和業務項目關係人取得確認,工作負載符合所有需求並正確運作。

在穩定期間支援工作負載

即使在成功推出之後,也要安排一段穩定期,對工作負載進行額外關注。 新現代化工作負載可能有未知的問題,這些問題只會在一段時間後才會出現在真實世界的使用模式之下。

  1. 在穩定期間建立加強的支持涵蓋範圍。 在上線後的頭幾天或幾週(視複雜度而定),應加強支援計劃。 指派經驗豐富的IT人員或移轉合作夥伴,以密切監視工作負載,並提供比正常作業較短的SLA。

  2. 更新您的作業檔和工具。 請確保所有的作業手冊、支援文件和監控配置都已更新,以反映新的現實。 針對任何新的程式訓練作業小組,例如新的備份程式、微服務的新重新啟動程式。 將現代化工作負載交給具有完整知識轉移的作業/支援小組。 請確定您的資產清查/CMDB 會記錄新的伺服器、IP、服務,以及移除或標記舊版伺服器。

後續步驟