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

# 步驟 1. 評估您的應用程式
<a name="step1"></a>

此階段的目標是：
+ 徹底了解應用程式環境，並為現代化資料平台準備應用程式，因此您可以加速實現價值的時間，而不會影響業務，然後進行現代化、最佳化和擴展。
+ 描述您的應用程式環境，以識別與變更相關的優點、風險和成本。
+ 提供end-to-end的服務：從策略和規劃；透過部署、遷移和應用程式現代化；到持續支援。
+ 建置提供可重複使用實務和工具的政策、建議和控制，以提供持續的商業價值。

在評估階段，應用程式擁有者和架構師會使用現代化診斷程序手冊來驗證其現代化目標和優先順序。

## 使用現代化診斷程序手冊
<a name="diagnostic"></a>

現代化診斷程序手冊提供程序，用於判斷企業從目前狀態移至未來狀態的值。這包含現代化涉及的技術變更。

您可以使用診斷程序手冊來判斷應用程式或應用程式套件的優先順序，以進行雲端現代化，並識別現代化期間需要解決的元件。

### 診斷維度
<a name="dimensions"></a>

現代化診斷程序手冊可協助您了解應用程式或一組應用程式目前和目標 （遷移後） 狀態的下列維度：
+ 應用程式分組 – 是否有理由將應用程式分組 （例如，依技術或操作模型） 以進行現代化？
+ 定序 – 根據相依性，應用程式是否應該進行現代化？
+ 技術 – 技術類別有哪些 （例如，中介軟體、資料庫、簡訊）？
+ 相依性 – 應用程式是否對其他系統或中介軟體具有關鍵相依性？
+ 環境 – 使用多少個開發、測試和生產環境？
+ 儲存 – 什麼是儲存需求 （例如測試資料的複本數量）？
+ 操作模型 – 應用程式的所有元件是否可以採用持續整合和持續交付 (CI/CD) 管道？
  + 若是如此，應該將哪些基礎設施責任分配給應用程式團隊和對象？
  + 如果沒有，營運團隊應該承擔哪些基礎設施責任 （例如修補）？
+ 交付模型：
  + 根據應用程式或應用程式群組，您應該修改、重構、重寫或取代 ？
  + 現代化的哪個部分應該使用雲端原生服務？
+ 技能集 – 需要哪些專業知識？ 例如：
  + 雲端應用程式背景，使用容器和無伺服器技術從頭建置具有模組化架構的應用程式。
  + DevOps 專業知識可開發 CI/CD 程序、基礎設施即程式碼，以及使用開放原始碼和 AWS 工具和服務的自動化或應用程式可觀測性等領域的解決方案。
+ 現代化方法 – 考量應用程式目前的狀態、雲端技術選擇、目前的技術負債、CI/CD、監控、技能和操作模型，需要完成哪些技術遷移工作？
+ 現代化時機 – 商業產品組合的時機考量或其他可能影響現代化時機的計劃工作考量為何？
+ 基礎設施的單位和總成本 – 根據經濟分析 AWS，在內部部署維護工作負載的年度成本是多少？

根據這些維度評估應用程式，可協助您在將現代化推向雲端時，在商業、技術和經濟上保持穩定。

### 構成要素
<a name="blocks"></a>

當您將應用程式現代化時，您可以將觀察分為三個基本區塊：業務敏捷性、組織敏捷性和工程有效性。
+ **業務敏捷性** – 與業務內部將業務需求轉化為需求的有效性相關的實務。交付組織對業務請求的回應能力，以及業務在將功能發佈到生產環境中的控制能力。
+ **組織敏捷性** – 定義交付程序的實務。範例包括敏捷的方法和 DevOps 典禮，以及角色指派和清晰度，以及整個組織的整體協作、溝通和啟用。
+ **工程有效性** – 與品質保證、測試、CI/CD、組態管理、應用程式設計和原始程式碼管理相關的開發實務。

## 識別指標
<a name="metrics"></a>

若要了解您是否正在為客戶提供重要的服務，您必須實作可推動改善並加速交付的措施。目標、問題、指標 (GQM) 提供有效的架構，以確保您的指標符合這些條件。請依照下列步驟使用此架構來從目標中恢復：

1. 識別您正在執行的目標或結果。

1. 衍生必須回答的問題，以判斷目標是否達成。

1. 決定應測量或可測量的項目，以充分回答問題。有兩種測量類別：
   + 產品指標，可確保您為客戶提供重要的服務。
   + 操作指標，可確保您改善軟體交付生命週期。

### 產品指標
<a name="product-metrics"></a>

產品指標著重於業務成果，應在確定新工作範圍的投資報酬率 (ROI) 時建立。建立產品指標的實用技巧是詢問在實作新工作範圍時，業務會有什麼變化。將此思維正式化為測試形式，以專注於交付現代化功能時的真實情況，會很有幫助。

例如，如果您認為從舊版系統遷移交易將釋放加入用戶端的新機會，有什麼改善？ 必須建立多少容量才能加入下一個用戶端？ 如何建構測試以驗證該結果？ 在此案例中，您的產品指標可能包含下列項目：
+ 識別商業價值測試或假設 （例如，釋放 *x*% 的交易容量將加入 *y*% 的新業務）。
+ 建立基準 （例如，*x* 交易目前的容量支援 *y* 個客戶）。
+ 驗證結果 （例如，您已將容量提高 *x*%，因此您現在可以加入 *y*% 的新業務嗎？)

### 操作指標
<a name="ops-metrics"></a>

若要判斷您是否正在改善軟體交付生命週期並加速現代化，您必須知道交付軟體的前置時間和實作時間。也就是說，您可以將業務需求轉換為生產功能的速度有多快？

有用的操作指標包括：
+ 前置時間 – 從請求到生產，工作範圍需要多少時間？
+ 週期時間 – 從頭到尾實作工作範圍需要多長時間？
+ 部署頻率 – 您部署變更到生產環境的頻率為何？
+ 還原服務的時間 – 從失敗中復原所需的時間 （以平均修復時間或 MTTR 計算）？
+ 變更失敗率 – 失敗之間的平均時間 (MTBF) 是多少？