本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 業務驅動因素和技術指導原則 ## 商業驅動程式 無論您的組織是否已決定移至雲端或接近該決策，定義和記錄雲端遷移的商業驅動因素都會釐清遷移的原因。記錄原因之後，您可以定義要遷移的內容及其遷移方式。此活動很重要。我們建議您儘早在程序中進行，以通知和引導後續步驟。  識別應參與討論的利益相關者，以記錄驅動因素。一般而言，組織中CxOs、資深經理和關鍵技術領導者，以及您自己的客戶。雖然您的客戶不太可能參與此次討論，但我們建議您組織中的一或多個人員被指定代表客戶的觀點和目標。 業務驅動因素應連結至指標，該指標可在遷移過程中測量，以驗證是否已實現結果。公司的策略目標和年度報告可以做為起點。  根據現有和預計的指標，將對話重點放在公司因轉移到雲端而想要達到的目標。考慮目標和業務成果。此外，考慮隨著雲端採用率的增加，成功是什麼樣子。  接著，為每個驅動程式建立重要性層級。優先順序為何？ 預期的效益是什麼？ 好處如何支援業務目標和成果？ 在應用程式產品組合評估的情況下，答案將有助於排定遷移工作負載的優先順序，並建立技術指導原則。不過，業務驅動因素將定義和影響整個遷移計畫。 ## 技術指導原則 技術指導原則會在產品組合評估的後期階段通知遷移策略選擇。在目前階段中，重點是識別它們。  指導原則可以建立為衍生自業務目標和成果的一般技術相關和方法相關決策。 例如，公司的主要目標是降低成本，所需成果是在 12 個月內於指定日期之前關閉內部部署資料中心。產生的引導原則是盡可能使用主機重新託管遷移策略，將所有應用程式提升並轉移至雲端。在這種情況下，lift-and-shift方法可加速短期遷移結果。應用程式移出內部部署資料中心後，公司可以專注於其他業務驅動因素，以最佳化或現代化遷移的工作負載。 若要建立技術指導原則，請先分析業務驅動因素。識別將實現業務目標和成果的技術和技術清單。接下來，精簡清單，並根據適用性或偏好指派相關性順序，以達到所需的結果。 記錄並傳達指導原則給參與規劃和執行遷移的人員。強調原則與實際實作之間的疑慮和潛在衝突。 下表提供商業驅動因素和技術指導原則的範例。 | | | **商業驅動程式** | **結果** | **指標** | **技術指導原則** | | --- |--- |--- |--- | | 加速創新。 | 提高競爭性、提高業務敏捷性 | 每天或每月部署次數、每季發佈的新功能、客戶滿意度分數、實驗次數 | 透過使用微服務和 DevOps 操作模型來重新考慮區分應用程式，以提高敏捷性和新功能的上市速度。 | | 降低營運和基礎設施成本。 | 符合的供需彈性成本基礎 （為您的使用量付費） | 隨時間變化的支出 | 1. 使用基礎設施適當調整大小來重新託管應用程式。 
2. 淘汰低使用率或沒有使用率的應用程式。 | | 提高操作彈性。 | 改善運作時間，縮短復原的平均時間 | SLAs、事件數量 | 1. 將應用程式轉換為最新且最佳支援的作業系統版本。 
2. 為關鍵應用程式實作高可用性架構。 | | 離開資料中心。 | 資料中心在 6–12 個月內關閉 | 伺服器遷移的速度 | 使用 來重新託管應用程式[AWS Transform MGN](https://aws.amazon.com/application-migration-service/)。 | | 留在內部部署，但增加敏捷性和彈性。 | 改善現場部署時的競爭性和運作時間 | 每天或每月部署次數、每季新功能發行次數、SLAs、事件次數 | 1. 透過將系統功能擴展到雲端來現代化系統。
2. 評估 是否重新託管或轉譯至 AWS Outposts。 | 定義架構原則來告知遷移策略也很重要。例如，您可能會引進 AWS 雲端的架構原則，所有遷移的應用程式都必須加密所有通訊。如果目前尚未在內部部署套用這類原則，則會強制遷移團隊在遷移過程中實作變更，這會影響工作量和規劃。定義所有架構原則，並與相關團隊共用。