建立定向性業務案例 - AWS 規範指引
固定定向性業務案例的範圍焦點值驅動因素數據需求建立基礎架構總體擁有成建立營運成本最佳化擴展到全方位的業務案例估計移轉與現代化程式設定

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

建立定向性業務案例

來自整個企業的利益相關者應了解並購買商業案例，以便在過程中的每個步驟進行轉型。

在早期階段，請務必快速顯示移轉程式的足夠潛在價值，以便保護規劃和建立計畫所需的資源。定向性業務案例旨在通過可以提前收集的有限數據來實現令人信服的商業價值提供合理的信心。

該計劃建立後，商業案例進一步發展。詳細的案例可提供更高的準確性、更完整的計畫價值，並深入瞭解規劃優先順序。它定義並量化組織購買的計劃業務成果，並設定了項目治理辦公室然後可以引導計劃並衡量其成果的基準。

固定定向性業務案例的範圍

定向性業務案例通常會在 2-4 週內快速組裝。它需要產生足夠的信心，以便您可以保護資源以建立核心團隊，在需要時與合 AWS 作夥伴聯繫，並在最低限度的情況下完成優先順序的應用程式評估和產品組合分析和遷移規劃階段。

一般而言，支援產品組合移轉的定向性業務案例會建立為下列其中一項：

  • 現狀基礎架構環境與移轉後 AWS 服務架構之間的簡單總體擁有成本 (TCO) 比較。此比較顯示指定工作負載磁碟區的預期執行率差異。

  • 一個商業案例，顯示淨現值（NPV），投資回報率（ROI），投資回收期，修改後的內部收益率（MIRR）和 3-5 年現金流分析，以遷移到 AWS 包括遷移成本與保持原樣。

定向業務案例範圍通常限於下列其中一項：

  • 基礎設施技術成本的比較

  • 基礎設施技術和運營成本的比較

在一般情況下，投資組合越大，越不發達的情況下需要。這是因為可以在不顯著影響結果的情況下進行更廣泛的假設。對於較小的投資組合，任何更改都會產生更大的影響，因此需要更多的細節。

首先建立基礎架構成本比較。然後在繼續之前確定比較是否足夠引人注目。通常情況下，超過 400 台伺服器的產品組合會顯示出正面的商業案例，僅在運作後 3 年內降低基礎架構成本 AWS，或在 5 年內降低 250 部伺服器，儘管這種情況可能會有所不同。對於較小的投資組合，可能需要更多細節。

相反地，除非總移轉範圍少於大約 5 個工作負載或 50 部伺服器，否則在此階段檢查其他商業價值元件 (例如，從提升的彈性或業務敏捷性所衍生的價值) 是很少有用的。

焦點值驅動因素

基礎架構技術總體擁有成本 (TCO) 比較的基礎架構成本模型與執行工作負載所需的基本材料清單模型，並具有同等效能和可用性。 AWS 可以完成許多優化。然而，在這個階段，重點放在下列清單上，因為它們比較容易評估，而且通常可節省 30% 的總體擁有成本 (TCO)，這足以繼續前進：

  • 運算彈性 — 對應使用量不是 100% 的伺服器，例如執行 8x5 (使用率 24%)、10x5 (30%) 或 10x6 (36%) 的開發或 UAT 伺服器，以及以 2% 執行的災難復原 (DR) 伺服器，至僅在使用時收費的隨選服務。

  • 使用儲蓄計畫採購 — 規劃採購高使用率 (超過 36%) 的生產伺服器與其他伺服器，並採用合適的儲蓄計畫，將成本降低達 75%。選項包括 1 年期和 3 年的承諾，以及不同級別的預付款，以確保更高的折扣。

  • 移除僵屍 — 識別 CPU 使用率低於 2% 的伺服器，您可以確認不再需要這些伺服器，並將其從成本分析中移除。

  • 適當運算大小 — 使用 CPU 和記憶體使用率時間序列資料來評估每部伺服器所需的運算能力和記憶體。然後選取適合的亞馬遜彈性運算雲端 (Amazon EC2) 執行個體。

  • 適當調整關聯式資料庫管理系統 (RDBMS) 授權大小 — 在資料庫伺服器上正確計算後重新評估您的 RDBMS 授權需求、比較自攜授權 (BYOL) 和購買授權，以及探索 Amazon 關聯式資料庫服務 (Amazon RDS) 的潛力以增加節省成本。 AWS

  • 儲存 — 適當調整所需的總儲存磁碟區大小，並識別產品組合中每秒輸入/輸出作業 (IOPS) 的需求。決定可以使用不同 SLA 和成本移至物件儲存的量。

數據需求

瞭解初始評估資料需求中的表格顯示建立定向性業務案例每個部分所需的資料，以及它是必要的還是選用的。

若要建立案例，您需要初始規劃資料的基礎架構子集加上成本資料。決定如何識別要包含的基礎結構取決於您的業務目標：

  • 如果計畫的目標是移轉特定應用程式並將其現代化，請考慮到共用的基礎架構，根據應用程式所需的內容來建置基礎架構產品組合。

  • 如果計劃的目標是以基礎架構為中心，例如從租用即將到期的資料中心遷移出去，則比較基礎架構的總體擁有成本不需要應用程式對應。

標示為選用的資料 (例如伺服器的 CPU 和記憶體尖峰使用率) 通常可以用標準基準值取代。您可以與 AWS 合作夥伴或 AWS 專業服務中心討論此問題。或者，您也可以從組合中部分可用的資料點 (例如 Hypervisor 所收集的資料) 來推斷值。投資組合越大，這就越準確。

建立基礎架構總體擁有成

工具對於建構基礎架構總體擁有成本比較至關重要。AWS 專業服務或AWS 合作夥伴可以為所有類型的定向性案例提供幫助，特別是如果您計劃與他們協助進行更廣泛的遷移過程。

有一些工具可以執行以下操作：

  • 收集庫存數據。

  • 收集使用率資料。

  • 提供準確的基礎架構成本基準測試資料。

  • 識別並刪除殭屍。

  • 進行正確的大小評估。

  • 建議購買選項。

  • 比較軟體授權選項。

  • 產生簡單的圖形現金流分析。

從移轉評估器 AWS 是一個選項。它提供了所有這些功能作為一個免費的託管服務。您可以透過 AWS 帳戶經理或移轉能力合作夥伴或線上提交申請來申請 AWS移轉評估員。移轉評估器是專門設計成單點解決方案，可快速比較基礎架構技術的總體擁有成本。

主要優勢：

  • 費用全免

  • 無代理程式探索或手動設定庫存資料 (工具型探索受到限制)

  • 提供專屬支援，協助部署、設定、資料收集及建置基本案例或定向業務案例

  • SaaS 操作的便利性，但可以完全在客戶網絡中運行數據收集，以支持在加載到分析引擎之前進行擦洗

  • 對 Microsoft 許可證大小調整的強大支持

  • 完整的資料匯出功能

主要限制：

  • 僅評估 x86 架構伺服器 (視窗和 Linux)

  • 設定或校準基準測試成本資料的選項有限

  • 不支持建模操作成本優化

  • 不支援移轉成本建模

  • 除了 TCO 比較之外，沒有直接支援建立商業案例

如果您決定使用商業探索工具進行產品組合探索和分析功能，例如應用程式堆疊和相互依存性探索，它通常也會提供基礎架構總體擁有成本比較。如需使用工具進行產品組合探索和評估的指引，請參閱評估探索工具的需求。

建立營運成本最佳化

IT 作業生產力的改善通常是移轉的重要價值。根據國際資料公司 (IDC) 白皮書透過 Amazon Web Services 促進業務和組織轉型，平均而言，IT 營運人員的生產力透過遷移提高 62%。 AWS然而, 有兩個挑戰，在定向情況下，大小和包括這些好處.

首先，評估全方位的生產力提升需要廣泛的資料收集，而且更適合詳細的業務案例。這項挑戰可以透過專注於使用簡單基準資料進行評估和調整大小的一些要素來解決，但這些元素仍然顯示出顯著的優勢。

其次，專注於生產力作為降低成本的來源，可能會引起主要客戶利益相關者和計劃成員的關注和負面影響。確保您提供明確的利益將如何實現，以及這對受影響的人意味著什麼。這些問題可以通過澄清，這只會增強團隊的角色來避免：

  • 遷移計劃包括開發內部操作人員並將其轉移到新角色的軌道，例如加入建立基礎架構的 DevSecOps 團隊，作為代碼自動化和測試自動化，以推動團隊成長。

  • 利益可以通過重新調整和調整運營外包合同的大小來實現，以便內部員工可以增加對更高價值的活動的關注

根據您要考慮的操作轉換構建此業務案例元素的方法：

  • 如果您有現有的內部運營團隊，請提高團隊成員的技能，並顯示預期的生產力提高。

  • 或者，您也可以從目前的營運解決方案遷移至 AWS Managed Services (AMS)，或移轉至合作 AWS 夥伴提供的替代受管理服務供應項目。

對於第一次轉型，為了獲得可以包含在這種情況下提高生產力的保守財務估計，我們建議以下幾點：

  1. 專注於伺服器管理作業生產力。它往往是操作工作的重要比例，可以更容易地評估，並且在以後更容易驗證。

  2. 根據每位全職等效 (FTE) 員工可管理的伺服器數量基準，計算所需的人員配置。在內部部署，這個數字大約是 150 個斷電器。上 AWS，它是大約 400 部伺服器。

  3. 將這些指標套用至現場部署伺服器數量與 EC2 執行個體數量的比較。

  4. 將節省的時間乘以整個營運團隊的混合成本費率。

然後，您可以透過驗證結果不會大幅超過下表所提供角色的平均生產力提升 (來自 IDC 白皮書的資料來源，促進業務和組織轉型，以利用 Amazon Web Services 產生商業價值) 來檢查結果。

Role

效率增益

IT 基礎架構管理

62%

IT 技術支援

59%

應用程式管理

43%

資料庫管理

19%

應用程式開發

25%

對於第二次轉型，您可以直接比較範圍內產品組合的目前總營運和支援成本，以及考量受管理服務的成本，藉此節省營運成本。

若要取得受管理服務的成本，請向您的客 AWS 戶經理或任何AWS Managed Services 合作夥伴提供您提議的材料清 AWS 單、您的服務等級選擇 (Plus 或 Premium)，以及您的 AMS 套件 (AMS 加速或 AMS Advanced)。這將為轉換後的解決方案中的服務元件提供受管理 AWS 服務的總成本。同樣地，您可以向合作夥伴取得定價，該 AWS 合作夥伴會根據自己的參數提供自己的受管理服務套件。

擴展到全方位的業務案例

一般而言，若要組裝全方位的商業案例，建立總體擁有成本比較 (不論是否含有 IT 生產力元素)，並估算所有移轉與現代化成本。然後創建一個涵蓋成對 migrate-and-modernize 和不 't-migrate-and-modernize 方案的現金流.

最基本的案例是準備一對案例，其中 don' t-migrate-and-modernize 案例是您目前的情況，而該 migrate-and-modernize 案例具有以下特徵：

  • 交易量、運算或網路容量不會增加或縮減

  • 儲存需求的低容量穩定成長

  • 符合現有系統uality-of-service 功能的 Q 功能 (例如可用性、耐久性、輸送量和效能)

對於所有但非常小的投資組合，這符合建立定向性案例的目標。它迅速展示了足夠的價值，以獲得向前邁進的任務。

對於較小的產品組合而言，添加成對 migrate-and-modernize和不使用的t-migrate-and-modernize 案例可能很有價值，以證明雲端遷移的價值提高的其他方面，例如：

  • 在預期成長的工作負載間，混合中等和高容量成長需求

  • 包含增強的彈性，例如高可用性、DR 和容錯

  • 透過邊緣運算、內容傳遞網路 (CDN)、多區域資料庫複寫，提升全球效能。

  • 您為該計劃作為業務優先考慮的任何其他具體改進的服務質量

針對這些案例，請確定升級目前非雲端基礎架構以符合新規格所造成的成本和現金流量影響已準確估算。取得此估算值的最直接方式可以向系統整合商索取報價，特別是如果他們也是具有移轉能力的 AWS 諮詢合作夥伴，他們可以在這兩種情況下 migrate-and-modernize 為您提供支援。t-migrate-and-modernize

對於每對情境，組裝一個包含以下內容的案例：

  • don' t-migrate-and-modernize 方案的成本。在最基本的情況下，這包括：

    • 目前基礎架構組態在商業案例期間的擁有權總成本

    • 定期增加運算、儲存空間和網路流量消耗

  • 的成本 migrate-and-modernize; 情景, 包括:

    • 設定計畫，其中包括詳細的探索、移轉規劃、詳細的商業案例開發、建立核心團隊並提升他們的技能、建立 landing zone (如果尚未到位)，以及為移轉的工作負載建立安全性管理與作業整合

    • 工作負載移轉和現代化成本

    • 移轉基礎架構的成本，包括網路連線、AWS Snowball 和等資料移轉服務 AWS DataSync，以及移轉程 AWS 序本身所需架構的公用程式成本 (例如，用於測試)

    • 隨著海浪持續上線，在遷移過程中， AWS 公用事業成本的增加，以及現有基礎設施成本的降低，因為它被 AWS 基礎服務和退役

任何滯留資產的解除運作成本和註銷

估計移轉與現代化程式設定

若要設定成功的方案，您可能需要執行一系列基礎活動來建立基準權能和詳細計劃 (如果之前尚未完成)。這些基礎活動包括以下內容：

  1. 執行詳細的產品組合探索、移轉規劃和詳細的商業案例開發 (如產品組合分析與移轉規劃一節所述)，以及記錄所使用探索工具的成本。

  2. 建立雲端業務和技術核心團隊，並透過培訓和招聘來發展內部技能。識別需要培訓的 IT 組織成員，並為每個人分配培訓預算。

  3. 建立 landing zone 並進行設定，以支援您將需要的成本、營運和安全控管功能。

AWS 諮詢合作夥伴可協助提供第 1 和第 3 項的估算值。

估算移轉與現代化成本

為了滿足定向性業務案例的目標，並展示足夠的商業潛力以進入下一個階段，請盡可能基本地進行遷移和現代化成本估算。

為此，我們建議您專注於落入下列移轉策略的應用程式，以準備定向性業務案例：

  • 淘汰

  • 保留

  • 搬遷

  • 重新主持

  • 平台重建

  • 回購

一般而言，大約 70% 的工作負載可以重新裝載、重新定位或重新平台，而另外 5% 的工作負載可以淘汰。透過移轉策略評估應用程式通常會解決降低成本案例的核心問題。

估計重構或重新架構的成本可能很複雜。在給定準備定向業務案例的時間範圍內嘗試此操作是不切實際的。如先前在判斷移轉的 R 類型中所述，請考慮針對移轉和現代化的第一階段使用重新裝載、重新定位或重新平台策略。這些 R 策略可能會在短期內加速初始投資回收，降低實施風險並改善業務案例。對於您的應用程式團隊來說，將在 AWS 環境中執行的應用程式現代化，也會比未執行的應用程式更加容易。準備詳細的商業案例時，最好加入重構 (重構) 特定應用程式的預估值。

依策略估算移轉的工作量

每個遷移是不同的。在提交任何預算或計劃之前，請針對負責專案之小組的移轉活動進行種子工作負載預估，無論是您的內部應用程式團隊、 AWS 專業服務或合作 AWS 夥伴組織。

為了幫助建立定向性病例，下表提供了針對不同治療方法的指示性範圍。這些範圍假設 medium-to-large產品組合正在移轉，且移轉團隊已接受訓練且經驗豐富。對於小型產品組合，最好讓負責遷移的團隊準備估算，即使是定向性情況也是如此。

遷移策略 估算過程 元素 人員小時 人員小時
保留 不做任何事情，沒有成本，沒有收益，也不減少技術債務。

–

–

–
淘汰 估計停用所使用的硬體設備 (如果有的話)。

–

–

–
搬遷 使用 VMware 工具估算在 VMware 內複製工作負載。這包括複製數據，煙霧測試以驗證以及任何硬件退役。重新配置虛擬機器的工作量通常會少於低複雜度重新裝載模式。

–

–

–
重新主持 估計在適合生產伺服器的情況下，使用影像副本、煙霧測試、高可用性 (HA) 和災難復原 (DR) 測試以及任何硬體解除委任來複製工作負載和資料。最佳做法是使用應用AWS 程式遷移服務等工具。根據資料庫或其他基礎架構軟體是否正在執行、資料庫複雜性、是否叢集、整合複雜性和資料量等因素，將工作負載劃分為低、中和高複雜度。 每個服務器每個應用程序 遷移 HA/博士測試
低 10—14 3—5
中 16—24 4—6
高 26—38 8—12
平台重建 對於包含升級至作業系統或 RDBMS 版本的重新平台移轉，請估算重新裝載，並增加在新平台上執行重建和抽煙測試的時間。如果重新平台包括變更平台技術，請預估使用轉換工具的額外時間，例如AWS Schema Conversion Tool和，以及AWS Database Migration Service更完整的應用程式測試。改變技術的一個例子是從專有的商業數據庫遷移到開源替代品。 每個服務器每個應用程序 版本升級 技術變化
低 新增 1 至 3 個 新增
中 新增 2 至 5 個 新增二十至三十
高 新增 4—8 個 新增四至六十
回購 預估資料擷取、轉換和上傳至新購買的 SaaS 服務替代品，以及任何硬體解除委任。

–

–

–

估算移轉基礎架構成本

包含您在移轉過程中將使用之基礎結構的預估值。通常情況下，這些估計包括：

  • 連線和資料交換服務的預算，適用於從目前環境移轉至 AWS

  • 在移轉、測試和切換程序期間託管移轉工作負載所需的 AWS 服務 (尤其是運算和儲存) 的預算

  • 隨著每個遷移浪潮完成， AWS 公用事業成本的增加

  • 將不再執行移轉工作負載的現有基礎結構的解除委任成本

對於數據交換，請檢查總數據量並評估使用網絡的可行性。如果您已在移轉後提前佈建AWS Direct Connect連結或AWS VPN從 AWS WAN 上的某個點進行作業使用，則可以使用該資源到其服務配額為止。

如果您的網路容量不足，使用虛擬私人網路 (VPN) 短期增加網際網路頻寬通常是高成本效益的解決方案。如果沒有，諸如 Snow AWS ball 和 S AWS now cone 之類的 AWS 媒體交換設備可在大多數 AWS 地區提供解決方案。此外，對於非常大量的資料遷移，請考慮包括預算 AWS DataSync，這樣可以提高可靠性並且可以加速傳輸，而不論使用何種媒體。

對於商業案例的現金流分析元素來說，建模 AWS 服務的提升和降低現有基礎設施非常重要。在這個階段，你不太可能有一個波計劃，以確定何時會產生成本。我們建議下列作法：

  • AWS 在遷移過程中以固定速率提高成本。

  • 降低您計劃在相同持續時間內以固定速率解除委任的現有基礎架構的成本。

在現有基礎架構下降之前， AWS 成本將增加 1-2 個月。這提供了 1 個月的 AWS 公用程式使用量，以便為每個波執行遷移。它包括測試時間，以及額外的時間來完成停止替換基礎設施的成本所需的解除委任工作。

估算解除委任成本

無法重新部署的解除委任設備，並以合法且環保的方式處置，可能會產生一些小費用。但是，對於定向性業務案例，通常唯一可能的重要總和是註銷替換資產的任何剩餘帳面價值的成本。

對於定向性業務案例，我們建議您執行以下操作：

  • 檢閱您的資產清單。

  • 確定那些將被退役。

  • 為了減少註銷，請檢查切換裝置的機會，以便清單上較新的裝置可用於取代較舊、更完全折舊的資產。

  • 對將在此時退役的資產的 future 帳面價值進行評估。

  • 將其納入為解除委任的移轉成本。

組裝和調整全方向性業務案例

在您為每對案例準備完整的成本集之後，請為每個案例建構貼現現金流量對帳單並繪製圖表。我們建議您在與硬體更新週期相同的期間建立定向性業務案例。伺服器、儲存裝置和網路裝置通常需要 5 年。當您使用與硬體重新整理週期相同的週期時，只有一次重新整理的成本會包含在每個案例的原樣成本中。

然後計算您需要獲得批准才能進入計劃下一階段的關鍵財務指標。我們通常包括以下內容：

  • 淨現值（NPV）來衡量評估的成本降低和生產力增益的絕對值

  • 以月為單位的投資回收期，以驗證回報是否足夠快

  • 最終的運行率比較，以驗證過程是否在整個期限內佔用了足夠的成本

  • 投資報酬率（ROI）和修改後的投資回報率（MIRR），用於評估該計劃的相對財務績效，而不是貴組織可能優先考慮的其他資本需求

使用案例的第一個反覆項目來判斷預期的財務績效是否表示應該進行細分，如下列範例所示：

  • 如果投資回收過慢，請考慮加速和降低移轉成本的選項，如下所示：

    • 使用 AWS 合作夥伴或 AWS 專業服務來擴充可用資源，並以更基本的模式進一步平行移轉工作負載。

    • 對於在 VMware 中執行的工作負載，請至少在初始階段將重新定位策略與重新裝載或重新平台策略進行比較。使用重新定位策略可降低移轉成本並提高移轉速度。

    • 在技術上可行的情況下，將需要更複雜的重新平台或重構 (重新架構) 策略的工作負載推送到 future 階段，超出初始商業案例的範圍。

  • 如果投資回報率和 MIRR 太低，請考慮以下幾點：

    • 您正在考慮的情況是否太保守？ 您是否有反映最有可能的容量增長和彈性需求的場景？ 您是否有比較目標內包含服務品質增加的成本的案例？

    • 您是否可以調整要在第一階段移轉的應用程式產品組合的範圍，以便專注於將產生更高回報的工作負載，例如目前使用率較低或災難復原 (DR) 需求昂貴的工作負載？

    • 是否可以優化應用程式產品組合的範圍，以最初排除在商業上達到較低商業性的特定工作 例如，您是否可以延遲第三方軟體授權因為在公有雲基礎架構中部署條款不同而變得更昂貴的工作負載？

  • 如果最終執行率比較不符合預期目標，請探索下列事項：

    • 首先，請確認其他指標符合預期。定向性業務案例主要是表明有足夠的財務機會可以證明開始移轉準備的下一階段。

    • 找出在移轉初始階段 AWS 之後繼續改善成本效能的機會清單。

準備詳細的業務案例時，包括機會清單的評估。此外，在案例的持續維護中加入機會評估，以及移轉完 month-to-month 成後的成本最佳化程序。