適當的規劃和治理對於現代化至關重要。 在這個階段中，您會決定要套用哪些現代化方法，以及如何進行。 深思熟慮的規劃可減少執行期間預算超支、範圍爬行或服務中斷的機會。
選擇現代化策略
將工作負載現代化意味著更新工作負載，以更符合目前的商務目標、技術標準和雲端功能。 三個主要策略（重新部署、重構和重新架構）存在於複雜性和價值的連續體上。 大部分的現代化工作都會使用這些方法的組合。
關鍵是將策略與每個元件的特定需求相符，並考慮您的目標、時程表和可用資源。 避免過度現代化的誘惑。 雖然新技術令人振奮，但每個決策都應該以商業價值為基礎。
| 現代化策略 | Definition | 使用時機 | Pros | Cons |
|---|---|---|---|---|
| 平台移轉 | 使用最少的程式代碼變更將應用程式移至雲端平臺（IaaS 至 PaaS）。 | 快速獲勝，需要最少的中斷。 目前的程式代碼可運作，但作業負擔很高。 | 快速實施。 減少維護工作。 透過更佳的基礎結構改善可靠性。 | 有限的能力提升。 核心應用程式保持不變。 |
| Refactor | 修改現有的程式代碼，以改善結構、效能和雲端優化，同時維護功能。 | 技術債務會導致問題或程式代碼未經過雲端優化。 | 改善可維護性、效能和安全性。 利於未來的提升。 | 需要大量的開發人員投入和測試。 目前沒有即將推出的新功能供用戶使用。 |
| Rearchitect | 使用雲端原生模式重新設計應用程式架構（微服務、無伺服器、事件驅動）。 | 目前的架構會限制成長或雲端優化。 | 解決基本的延展性問題。 啟用進階雲端服務。 為長期創新設定基礎。 | 最複雜且耗時。 高預付成本和風險。 需要進行大量測試及平行操作。 |
分階段規劃現代化
嘗試在一次執行中將整個複雜工作負載（或多個工作負載）現代化是有風險的。 將工作分成邏輯階段。 階段可讓您提供累加值、透過處理可管理的區塊來降低風險，並根據您學到的內容來調整階段之間的課程。
將現代化分成邏輯階段。 決定如何分割工作。 沒有單一的“正確方式”。選擇對您的架構和小組結構有意義的分解。 目標是，每個階段都足夠小，可以執行和測試，而不會有壓倒性的複雜性，但足以提供價值。 分解階段的常見方式：
劃分法 Description Example 依元件或圖層 根據工作負載層級或工作負載界限來分隔階段 階段 1：資料庫移轉、階段 2：應用程式重構、階段 3：UI 現代化 依優先順序和複雜度 組織從低風險到高風險變更的工作 階段 1：非關鍵服務、階段 2：核心商業規則、階段 3：面向客戶的功能 依業務功能 圍繞應用程式或功能界限的結構階段 階段 1：使用者管理工作負載、階段 2：付款處理、階段 3：報告服務 從低風險、高價值變更開始。 針對您的第一階段，挑選一些可達成且提供有形勝利的目標，確保在問題發生時不會危及業務。 例如，先將後端服務或內部工具現代化，而不是客戶面向的網站。 目標是儘快完成第一階段（一兩個月）作為證明點。 早期的成功能夠提升團隊的信心並獲得利害關係人對後續階段的支持。
依值和相依性排序剩餘階段。 在第一個階段之後，根據商業價值和技術相依性規劃後續階段的順序。 建置藍圖，其中每個階段都有已定義的範圍，並確保關鍵元件具有其已現代化或相容的支持元素。
- 解決脆弱的區域。 如果工作負載在其目前狀態下不穩定，您甚至可能需要一個初步的「階段 0」來在原地穩定它（在舊環境中套用緊急修正），以便在階段 1 中進行安全的現代化轉型。
- 請先解決必要條件： 如果工作負載 B 的現代化取決於工作負載 A 現代化（或至少穩定），請先執行工作負載 A。
- 請考慮商業價值與風險： 您可能會決定交替，在一個階段中執行高價值但風險更高的片段，然後在下一個階段中將風險較低，以平衡小組的負載，以及業務風險。
定義每個階段的成功準則。 針對每個階段，決定何時完成並成功。 有明確的結束準則可防止階段的範圍擴大。 成功準則可能包括：
成功準則類型 Examples 技術目標 • 服務 X 會在 Azure App Service 上執行，並處理 20 個% 更多負載
• 資料庫 Y 會移轉至 Azure SQL，確保數據零遺失，且性能維持在先前基準的 10% 範圍內。優質閘門 • 沒有 Sev-1 漏洞开放
• 所有自動化測試都會通過
• 安全性掃描顯示零嚴重弱點時間和預算限制 • 在三個月內完成，並在預算的 5% 內完成
• 在排程維護期間部署根據結果調整計劃。 完成階段之後，請檢視結果和汲取的經驗教訓。 您可能會發現某些假設不正確，或某些工作比預期更簡單或更困難。 根據需要調整未來階段的計劃，如新增、合併或重新設定優先順序。階段式方法應保持彈性。 重要的是不要一次嘗試一切。
規劃現代化治理
現代化通常會對重要工作負載造成重大變更，因此需要強式治理來管理風險。 現代化治理牽涉到變更管理程序、凍結和控制範圍：
建立正式變更核准工作流程。 定義所有現代化相關變更的結構化核准程式。 與現有的變更諮詢委員會（CAB）整合，或建立專門的現代化審核委員會。 根據變更類別指派核准授權單位，並記錄項目計劃中的完整工作流程。 如需詳細資訊，請參閱 管理變更。
必要時凍結變更。 在主要部署事件之前和期間，凍結這些工作負載的其他變更。 變更凍結指在準備和部署期間，暫停任何與工作負載無關的變更。 它會穩定環境，因此您不會遇到移動的目標。 將凍結視窗傳達給所有相關小組。
避免範圍蔓延。 規模擴增是現代化改造的主要挑戰。 要求對已同意的現代化範圍進行任何建議變更，才能完成評估和核准步驟。 大部分的要求都應該延遲，除非它們很重要。 將「不，現在不行」的要求轉變為需額外處理的程序。 維護可取的創意清單，這些創意可以在完成目前的現代化工作後，納入未來的創新項目。 項目關係人應該知道他們的想法不會遺失。
定義部署策略
關鍵執行決策是如何將現代化元件推出至生產環境。 有兩個主要策略。 在就地部署中，您可以升級現有的設定（如在居住時翻新房屋）。 在平行部署中，您會架設新的系統（比如建造新房子然後搬進去）。 針對每個階段或工作負載，選擇符合變更層級和風險承受能力的策略。 現代化的每個階段通常會使用不同的策略。 例如，您可能會針對第1階段（如果是次要變更）選擇原地更新，並針對第2階段選擇併行方式（如果該階段涉及重大資料庫大修）。
針對低風險、可逆的變更使用就地部署。 就地部署會直接將變更引入目前的生產環境，或許是在維護期間。 此策略可將基礎結構額外負荷降至最低，但會增加停機時間的風險。 只有在變更很小、隔離且容易可逆時，才使用就地部署。 範例包括可以使用原始檔控制或備份快速復原的次要程式代碼更新或架構變更。
針對複雜或高風險變更使用平行部署。 在此模型中，您會為現代化工作負載設定新的環境，而舊的工作負載仍會執行。 數據會保持同步（透過復寫或移轉流程），準備好後，您就可以從舊環境轉移至新環境。 用於複雜或高風險的變更，其中停機時間必須最少。 如果您要進行主要資料庫移轉或重新架構，而涉及新基礎結構，則平行通常是這樣。 此外，如果工作負載具備任務關鍵性，而且無法超過幾分鐘的停機時間，則需要平行處理（包含複寫及快速切換）。
Strategy Description 使用時機 Pros Cons 就地部署 直接將變更部署到目前的生產環境 可逆的小型變更，在可接受的維護時間內進行 沒有重複的基礎結構，更快速的部署 風險較高，需要停機、復原速度較慢 平行部署 在轉換期間與現有工作負載一起執行新環境 複雜的變更，需要最少停機時間的任務關鍵性工作負載 更安全的部署，近乎零的停機時間，立即後援 重複的基礎設施成本、數據同步的複雜性、資源退役工作
規劃降低現代化風險
即使有最好的規劃和測試，並不是每個變更都完美無缺。 現代化通常牽涉到複雜的變更，而且總是有風險，部署可能會引入問題，或者在生產環境中表現不如預期。 準備充足的團隊的一個標誌是為每次變更或每個階段制定堅實的回滾計劃。
使用漸進式部署技術。 如果平台允許，請執行金絲雀釋出或逐漸將流量轉移至應用程式現代化的部分。 例如，在監視期間，將新版本與舊版本一起部署，一開始只會將5% 的用戶傳送給它。 此方法可以在大部分使用者不受影響時，偵測問題。 如果指標看起來不錯，請增加至 50%，然後增加至 100%。 如果某個項目開始失敗，請快速路由回 0% 新的 （回復）。
為每個重大變更建立復原程式。 針對每個重大變更或階段交付專案，請撰寫逐步復原程式。 請清楚列出復原變更的每個動作、負責每個步驟的人員，以及需要多久的時間。 復原之後，請包含哪些檢查會確認情況恢復正常。
盡可能自動化回滾。 自動化復原腳本或基礎結構即程式代碼可讓復原快速且可靠。 使用基礎設施即代碼工具（Terraform、ARM 範本、Bicep）重新部署已知的最佳狀態。 藍綠部署或金絲雀部署本身就允許如有需要「切換回」到先前的版本。 在測試環境中測試這些機制。 目標是在事件發生時凌晨3點，將人工操作轉為腳本化的動作。 將復原步驟與部署步驟一起撰寫，以便輕鬆地復原。
在部署期間和之後保持支援待命。 儘可能規劃低流量期間（週末或隔夜）的部署，但請確定相關專家可供使用。 當關鍵小組成員正在休假時，請勿這麼做。 在部署後，立即安排開發人員和運營團隊待命，以延長支援（hypercare）期間，及早攔截任何問題。 對於重大上線，一些組織會在24至48小時內持續進行戰情室風格的監控。
獲得利害關係人核准
至此，我們專注於技術規劃。 同樣重要的是獲得業務和技術領導階層的支持。 現代化通常需要大量投資，因此您需要提出令人信服的案例，並讓項目關係人在整個過程中保持參與。
為每位觀眾量身打造價值主張。 不同的利害關係者關心不同的結果。 自訂您的傳訊：
- 技術小組優先提升運營效率：減少維護、改善正常運行時間，以及減少升級問題。
- 業務領導者 著重於成果：更快的上市時間、改善的客戶體驗，以及節省成本。
記錄具有里程碑的結構化計劃。 如果看到明確的路線圖，項目關係人會更有信心。 如稍早決定，呈現您規劃的階段，以及每個階段應該達成什麼，並採用粗略的時程表。 強調早期勝利，例如“在 6 周內，我們的目標是將 X 元件現代化，並在 20%提高其效能。
量化現代化價值。 準備一些前後的指標及目標改進措施。 計量和一般改進範圍的範例（以產業基準為基礎）包括：
Category 範例指標 一般值範圍 降低成本 基礎結構、維護、授權 20-40% 年儲蓄 生產力提升 部署頻率、解決時間 50-80% 改進 風險降低 避免系統停機、安全性事件 $100K-$1M+ 成本節省 Revenue 更快的上市時間、客戶保留期 10-25% 營收加速 解決項目風險。 找出潛在的挑戰，並透過特定的風險降低策略來示範備妥。 常見的風險包括數據復寫、效能降低和整合問題。 呈現解決方案，例如自動化復原程式、完整的測試通訊協定，以及專家諮詢可用性。 透明風險討論可建立項目領導和規劃完整性的項目關係人信心。
保持一般通訊頻率。 根據已定義的成功準則報告進度、醒目提示已完成的交付專案，以及傳達即將推出的里程碑。 主動要求意見反應，並解決問題，以在整個現代化過程中維護支援。