任務 3：定義應用程式優先順序程序

應用程式優先順序是決定應用程式應遷移至雲端之順序的程序。您可以根據將應用程式遷移至雲端的複雜性和您定義的規則來評估優先順序。討論應用程式優先順序時，高優先順序不一定與應用程式對業務的重要性相關。事實上，業務關鍵型應用程式通常對遷移而言是低優先順序的，因為業務關鍵型應用程式的風險較高。在大型遷移中，您會優先考慮非商業關鍵的低複雜度應用程式，而且每波都會遷移越來越複雜或商業關鍵的應用程式。

在大型遷移中，您有數百個應用程式已排入遷移排行榜，我們不建議您一次排定優先順序並規劃每個應用程式。這是定義應用程式優先順序程序對大型遷移專案至關重要的原因之一。若要以敏捷的方式處理遷移，您可以挑選最高優先順序的應用程式 (3–10 個應用程式），或者您可以選取足夠的應用程式來容納 3–5 個波浪。然後，您只能完成所選應用程式的應用程式探索和波規劃。這種方法可節省大量時間，因為應用程式優先順序和波通常會在大型遷移過程中變更。

有關應用程式優先順序的常見迷思是最高優先順序的應用程式應該位於第一波中。當您執行波計畫時，由於其他應用程式尚未準備就緒，因此有很高的可能性只有少數 10 個最高優先順序的應用程式會處於第一波中。這可能是因為各種有效的原因，例如相依性、業務限制或資源可用性。應用程式優先順序是波浪規劃的關鍵因素，但不應該是您考慮的唯一因素。

在此任務中，您會定義應用程式優先順序程序和規則。此任務包含下列步驟：

• 步驟 1：定義應用程式優先順序程序

• 步驟 2：定義應用程式優先順序規則

• 步驟 3：完成應用程式優先順序程序

下一節討論複雜性評分。此手冊提供三個程序選項，說明如何排定應用程式的優先順序，而三個選項中的兩個使用複雜性評分。如需程序選項的詳細資訊，請參閱 步驟 1：定義應用程式優先順序程序。如果您打算使用應用程式提名程序，則不需要定義複雜性評分條件，而且應該直接繼續 步驟 1：定義應用程式優先順序程序。

關於複雜性評分標準

複雜性評分是用來評估遷移應用程式的難度的程序，這是排定應用程式優先順序時的關鍵因素。複雜性評分涉及根據您定義的同一組業務和技術標準評估所有應用程式。評估應用程式時，您會為每個條件指派分數。當您加總業務準則和技術準則的分數時，您會得到一個複雜性分數，以反映遷移該應用程式的整體複雜性。然後，您可以在排定應用程式優先順序和規劃波浪時，使用複雜性分數。

複雜性評分標準有兩種類別：

• 業務條件 – 此類別中的條件與遷移應用程式的業務複雜性相關，例如應用程式無法使用時的風險、安全性和合規考量，以及資源可用性。

• 技術條件 – 此類別中的條件與遷移應用程式的技術複雜性相關，例如作業系統及其版本、伺服器和使用者的數目，以及遷移策略。

您應該為您的使用案例判斷適當的評分條件。如果您手動評分應用程式複雜性，在產品組合手冊範本中，應用程式複雜性的 Score sheet 範本 (Microsoft Excel 格式） 包含一組標準條件和分數值。您可能想要從這些值開始，然後針對您的使用案例自訂這些值。如果您使用探索工具進行應用程式的優先順序，這些工具通常包含一組標準條件，您可以新增、移除或修改條件，而且您可以根據需求進行加權。當您建立條件時，請使用下兩個區段中的問題，以協助精簡您的條件。

業務條件

以下是在複雜性評分中常用的業務條件。

業務條件	描述
業務影響	如果此應用程式無法使用，請評估對業務的影響： 它是否具有財務影響？ 它是否會影響操作？ 它是否會影響客戶體驗？ 它是否會影響產品或公司事件？
員工可用性	在遷移期間，您可能需要應用程式擁有者、主題專家 (SME)、網路或基礎設施管理員、測試人員和開發人員的協助。評估這些資源的可用性，以便在遷移期間協助您： 在遷移期間，此人員是否能夠協助遷移團隊並提供指導？ 遷移後，此人員是否可用於測試和驗證應用程式？ 此人員是否能夠佈建在目標環境中執行應用程式所需的 IP 地址或連接埠？
業務複雜性	擁有許多相互依存且互連的利益相關者、資訊技術系統和組織結構，可能會提高業務複雜性。評估業務複雜性，如下所示： 企業需要多長時間才能核准基礎設施和網路變更，例如防火牆變更或佈建新執行個體？ 企業在伺服器上核准新軟體或工具安裝需要多長時間，例如探索工具？
就緒狀態	評估應用程式是否已準備好進行遷移，如下所示： 應用程式目前是否正在進行或排定進行技術重新整理？ 是否排定維護，且是否會與排定的遷移重疊？ 應用程式是否已排定停用？ 應用程式目前是否正在升級，以及是否有任何新功能正在開發或整合？
安全	評估應用程式安全需求和安全政策的複雜性，如下所示： 您需要佈建 IP 地址和連接埠以存取應用程式嗎？ 應用程式是否需要基礎設施保護？ 應用程式是否需要資料保護？ 是否需要金鑰管理？ 應用程式是否需要特殊存取管理政策？ 應用程式是否需要監控或記錄？ 應用程式是否需要事件回應程序和自動化？ 此應用程式是否需要提醒和通知？
合規	合規要求可能適用於應用程式，例如州、商業產業或公司政策提供的法律、法規和指導方針。評估應用程式的合規要求的複雜性，如下所示： 是否有任何資料隱私權和居住要求？ 應用程式中的靜態資料是否應該加密？ 是否應該加密傳輸到應用程式或從應用程式傳輸的資料？ 是否需要稽核記錄？ 應用程式是否需要符合會計和財務標準，例如系統和組織控制 (SOC)？ 應用程式是否需要符合付款安全標準，例如支付卡產業 (PCI)？ 應用程式是否需要符合病患健康資訊法規，例如健康保險流通與責任法案 (HIPAA)？ 應用程式是否需要符合公有雲端安全計劃，例如資訊系統安全管理和評估計劃 (ISMAP)？
應用程式知識	組織中的某個人，例如應用程式擁有者，是否具備維護、整合、疑難排解和修正問題的知識、技能和經驗？ 您能夠擴展應用程式以滿足業務需求嗎？
遷移技能	組織中的員工是否具備將工作負載遷移至目標環境的技能？

技術條件

以下是複雜度評分常用的技術標準。

技術條件	描述
儲存	評估應用程式目前的儲存體，如下所示： 應用程式目前存放在哪裡？ 範例包括網路連接儲存 (NAS)、儲存區域網路 (SAN) 或本機磁碟機。 目前儲存體的總大小是多少？
使用者數	此應用程式有多少使用者？ 您可以使用實際日誌或預估。
伺服器計數	應用程式堆疊中有多少伺服器？
連線能力	評估此應用程式如何連接到組織中的其他人，如下所示： 有多少其他應用程式依賴此應用程式？ 如果無法使用此應用程式，對其他應用程式有何影響？
應用程式作業系統和版本	評估作業系統 (OS) 和應用程式伺服器的版本，如下所示： 是否不再支援伺服器的作業系統版本？ 伺服器是執行 Unix 還是 Linux 作業系統？ 伺服器是否執行 Windows Server 作業系統？ 應用程式是位於大型主機還是中階伺服器上？
應用程式相依性	評估此應用程式如何依賴您環境中的其他資源： 此應用程式依賴哪些資源？ 資源可以是其他應用程式、元件、作業系統特定服務 （例如登錄檔或 Web 伺服器） 或程式庫。 如果一或多個資源無法使用，會對此應用程式造成什麼影響？
資料遷移	評估您是否需要遷移此應用程式的資料或檔案： 資料遷移有多複雜？ 檔案遷移有多複雜？
遷移策略	評估所選遷移策略的複雜性。如需遷移策略的詳細資訊，請參閱AWS 大型遷移指南。
COTS 或自訂	評估應用程式是自訂製作還是商用off-the-shelf(COTS)，如下所示： 您有最新版本的原始碼嗎？ 是否支援應用程式廠商？ 應用程式是否已外包？

步驟 1：定義應用程式優先順序程序

此手冊包含三個程序選項，可排定應用程式的優先順序。您可以選取其中一個選項，也可以決定合併兩個或多個選項，並建置自訂程序。評估您的使用案例，並判斷下列何者最適合您的環境：

• 選項 1：手動複雜性評分 – 這是手動排定優先順序的程序，可由個人完成或在研討會式工作階段中完成。在此過程中，您會使用複雜性評分標準來評估遷移每個應用程式的難度，這是排定應用程式優先順序的重要因素。此手動程序非常適合大型遷移，因為它提供一致的量化方法來排定大型應用程式產品組合的優先順序。不過，與其他兩個選項相比，根據定義的一組條件評估每個應用程式可能是一個較慢的程序。

• 選項 2：應用程式提名 – 這是手動排定優先順序的程序，通常完成研討會式工作階段。在此程序中，應用程式擁有者會指定應用程式以進行遷移。為了成功，此程序要求應用程式擁有者必須全面了解其各自的應用程式。如果時間是因素，而且您需要快速排定應用程式的優先順序，則建議執行此程序。

• 選項 3：探索工具 – 這是自動排定優先順序的程序。如果環境中的探索工具具有自動化功能，可自動進行應用程式複雜性評分或排定優先順序，使用此功能可節省時間並加速應用程式排定優先順序的程序。在此程序中，您通常會在探索工具的參數內定義條件，然後工具會分析應用程式並提供最終的複雜性分數。選擇此選項之前，請探索探索工具中可用的功能，並確認您可以自訂它以滿足使用案例的需求。

選項 1：手動複雜性評分

在此手動應用程式優先順序程序中，您可以使用工作表，根據定義的一組複雜性評分條件來評估應用程式。我們建議您在研討會式工作階段中完成工作表，或者個人可以透過與利益相關者合作來完成工作表。然後，您可以使用最終複雜度分數和應用程式優先順序規則，以判斷應用程式的優先順序。在手動程序中，這提供了最一致、量化的方法，用於判斷應用程式的複雜性，並使用該資訊來排定應用程式的優先順序。

對於此程序中的複雜度評分步驟，我們建議您使用 Score sheet 範本來處理應用程式複雜度 (Excel 格式），可在產品組合手冊範本中找到。此範本包含預先定義的業務和技術條件。您可以新增、移除或修改這些條件，也可以調整評分值。例如，您可能偏好 1–10 而非 1–5 的評分範圍。請注意下列有關所提供範本的事項：

• 您可以將滑鼠暫留在每個條件上，以取得其描述。

• 當您熟悉範本時，您應該刪除範例。這些僅供示範使用。

在整個遷移的初始化和實作階段保持更新複雜性評分表。您可以在進行產品組合評估時變更分數。應用程式深入探索是更新評分表的常見時機，因為您在團隊詳細檢查每個應用程式時，會進一步了解它。在遷移期間，如果您遇到問題，例如無法探索的相依性和限制，而無法遷移應用程式，您也可以變更應用程式優先順序。透過在整個遷移過程中維護評分表，您可以更精確地排定應用程式的優先順序。

記錄您的應用程式優先順序程序，如下所示：

1. 在產品組合手冊範本中，開啟應用程式複雜性的評分表範本。

2. 在應用程式工作表上，視需要為您的遷移新增、修改或移除條件。修改條件時，請執行下列動作：

   • 檢閱本手冊 關於複雜性評分標準一節中的指引。

   • 考量每個條件對遷移持續時間、資源和成本的影響。

   • 為了獲得可靠的複雜性分數，請包含代表組織中不同層級遷移複雜性的條件。

3. 在評分指南工作表上，更新使用案例所需的預設值和條件。

4. 儲存分數表。

5. 開啟您的應用程式優先順序 Runbook。

6. 在應用程式複雜性評分條件區段中，更新區段以反映您的評分表的位置。

7. 在應用程式優先順序程序區段中，執行下列動作：

   1. 保留選項 1：手動複雜性評分並刪除其他選項。

   2. 視需要修改您的使用案例的程序。

   3. 移除本節中包含 選項一詞的任何標題。在 Runbook 中保留這些項目可能會混淆使用者認為程序是選用的，或是有多個選項可用。

   4. 儲存您的應用程式優先順序 Runbook。

選項 2：應用程式提名

此手動應用程式優先順序程序是排定應用程式優先順序最簡單且最快的方法。在此程序中，您會要求應用程式擁有者指定可輕易遷移至雲端的應用程式。然後，您和應用程式擁有者可以快速排定應用程式的優先順序，因為您已經對指定的應用程式有深入的了解。我們建議您在研討會式工作階段中與利益相關者合作，但您也可以透過電子郵件、共用文件和其他通訊平台進行協作。

在提名程序期間，您會在 Score sheet 範本中輸入指定的應用程式，以因應產品組合手冊範本中包含的應用程式複雜性 (Excel 格式）。 samples/portfolio-playbook-templates.zip您不會使用此範本中的所有評分和條件功能，但建議您使用此工作表記錄提名和優先順序決策。

在某些情況下，應用程式提名程序會用來加速優先順序，而且可能不需要計分表。例如，如果您只排定少數應用程式的優先順序，或應用程式擁有者非常了解其應用程式，應用程式擁有者和利益相關者可以根據其知識和經驗排定應用程式的優先順序。在這種情況下，他們可以略過使用分數表，直接進行優先順序排序。

記錄您的應用程式優先順序程序，如下所示：

1. 開啟您的應用程式優先順序 Runbook。

2. 刪除應用程式複雜性評分條件區段。此程序不使用應用程式複雜性評分。

3. 在應用程式優先順序程序區段中，執行下列動作：

   1. 保留選項 2：應用程式提名並刪除其他選項。

   2. 視需要修改使用案例的程序。

   3. 移除本節中包含 選項一詞的任何標題。在 Runbook 中保留這些項目可能會混淆使用者認為程序是選用的，或是有多個選項可用。

4. 儲存您的應用程式優先順序 Runbook。

選項 3：探索工具

如果您的探索工具具有複雜性評分或應用程式優先順序的功能，則此自動化程序需要很少的資源，並且可以加速應用程式優先順序程序。您可以自訂使用案例探索工具中的條件，然後探索工具會自動分析應用程式並提供最終複雜性分數。由於工具已經有所有應用程式中繼資料，因此您不需要輸入。

例如，Flexera One Cloud Migration and Modernization （前身為 Flexera Foundation and CloudScape) 探索工具具有稱為最佳化計分卡的複雜性評分功能。此功能可讓您選取要在評分中包含的條件，並根據您的偏好權衡每個條件。資料探索完成後，探索工具會根據您提供的加權條件分析資料，並使用工具的專屬公式產生最終複雜性分數。如需詳細資訊，請參閱 Foundation and CloudScape 使用者指南 (Flexera 文件） 和最佳化計分卡 (Flexera 文件）。

此程序的缺點是，需要時間 (4–8 週） 才能在環境中設定無代理程式探索工具的掃描設備，或將代理程式安裝到所有範圍內工作負載。您必須先掃描應用程式工作負載並執行應用程式堆疊分析，讓探索工具收集中繼資料，才能在探索工具中使用評分功能。不過，您可能會發現設定探索工具所需的額外時間，可以透過減少中繼資料收集和應用程式優先順序所需的時間和資源量來復原。例如，如果探索工具的資料仍然是最新的，則產品組合工作流程可以重複使用探索工具及其來自調動階段的資料，以識別試驗應用程式。

注意

如果您使用的是探索工具程序，您仍然可以使用手動 Score sheet 範本來處理應用程式的複雜性，以便根據不同的條件來分析應用程式。此額外資訊可協助您調整應用程式的優先順序。

記錄您的應用程式優先順序程序，如下所示：

1. 如果您尚未這麼做，請在您的環境中設定探索工具。如需詳細資訊，請參閱 AWS Prescriptive Guidance 網站上的自動化產品組合探索入門。

2. 根據您工具的指示，自訂探索工具中的複雜性評分或應用程式優先順序條件。如需選取條件的詳細資訊，請參閱 關於複雜性評分標準。

3. 開啟您的應用程式優先順序 Runbook。

4. 在應用程式複雜性評分條件區段中，更新區段以反映在探索工具中定義評分條件。範例：複雜度評分標準定義於 <您的探索工具＞。

5. 在應用程式優先順序程序區段中，執行下列動作：

   1. 保留選項 3：探索工具並刪除其他選項。

   2. 視需要修改使用案例的程序。請務必包含如何產生複雜度分數報告的step-by-step說明。如果可用，您可以包含 使用者指南的連結。

   3. 移除本節中包含 選項一詞的任何標題。在 Runbook 中保留這些項目可能會混淆使用者認為程序是選用的，或是有多個選項可用。

6. 儲存您的應用程式優先順序 Runbook。

步驟 2：定義應用程式優先順序規則

在此步驟中，您會定義應用程式優先順序規則，以協助您判斷應用程式的遷移順序。雖然應用程式的複雜性分數是排定應用程式優先順序和規劃波浪的重要因素，但也必須考慮業務和技術因素。您可以建立規則來評估每個應用程式的優先順序，並協助您以適當的波浪排程應用程式。常見的商業和技術規則包括：

• 指定遷移資料中心的順序和排程

• 優先考慮業務單位

• 擷取關鍵業務應用程式的截止日期

定義您的應用程式優先順序規則，如下所示：

1. 開啟您的應用程式優先順序 Runbook。

2. 在應用程式優先順序規則區段中，為您的遷移新增自訂規則。

3. 儲存應用程式優先順序 Runbook。

4. 維護應用程式優先順序 Runbook 中的規則。隨著遷移進度、範圍變更或排程轉移，規則可能會有所變更。

以下是一組應用程式優先順序規則的範例。

優先順序	規則
1	紐約資料中心的應用程式應始終比德州資料中心的應用程式具有更高的優先順序。
2	IT 部門中的應用程式應始終比行銷部門中的應用程式具有更高的優先順序。
3	具有高複雜度分數的應用程式應具有更高的優先順序。
4	SAP 應用程式需要在年底之前遷移。

步驟 3：完成應用程式優先順序程序

現在，您可以定義產品組合工作流程如何使用規則和程序來排定應用程式的優先順序。這是產品組合工作流程在遷移實作階段參考的程序。

在應用程式優先順序 Runbook 中自訂此程序，如下所示：

1. 開啟您的應用程式優先順序 Runbook。

2. 在階段 2：排定應用程式的優先順序區段中，針對您的使用案例和環境修改適當的程序。

3. 儲存應用程式優先順序 Runbook。

任務結束條件

當您完成下列操作後，請繼續下一個任務：

• 您已從可用的選項中選取應用程式優先順序程序。

• 您已在應用程式優先順序 Runbook 中記錄下列項目：

  • 應用程式複雜性評分標準 （如適用）

  • 應用程式優先順序程序

  • 應用程式優先順序規則

• 您已更新應用程式執行手冊的第 2 階段：排定應用程式的優先順序區段。