本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 步骤 1：评估您的应用程序
<a name="step1"></a>

本阶段的目标是：
+ 彻底了解您的应用程序格局，为现代数据平台做好应用程序准备，这样您就可以在不影响业务的情况下加快价值实现时间，然后进行现代化、优化和扩展。
+ 概述您的应用程序格局，以确定与变更相关的效益、风险和成本。
+ 提供 end-to-end一系列服务：从战略和规划；到部署、迁移和应用程序现代化；再到持续支持。
+ 制定政策、建议和控制措施，提供可重复使用的实践和工具，以实现持续的业务价值。

在评估阶段，应用程序所有者和架构师使用现代化诊断手册来验证其现代化目标和优先事项。

## 使用现代化诊断手册
<a name="diagnostic"></a>

现代化诊断手册提供了一个确定企业从当前状态转变为未来状态的价值的过程。这包括现代化所涉及的技术变革。

您可以使用诊断手册来确定云现代化的应用程序或应用程序套件的优先级，并确定现代化过程中需要解决的组件。

### 诊断维度
<a name="dimensions"></a>

现代化诊断手册可帮助您了解应用程序或一组应用程序的当前状态和目标（迁移后）状态的以下方面：
+ 应用程序分组 — 是否有理由对应用程序进行分组（例如，按技术或运营模式）进行现代化？
+ 排序 — 根据依赖关系，应用程序进行现代化是否有先后顺序？
+ 技术 — 技术类别有哪些（例如，中间件、数据库、消息收发）？
+ 依赖关系 — 应用程序是否与其他系统或中间件有关键依赖关系？
+ 环境 — 使用了多少开发、测试和生产环境？
+ 存储 — 存储要求是什么（例如，测试数据的副本数量）？
+ 运营模式 — 应用程序的所有组件能否采用持续集成和持续交付 (CI/CD) 管道？
  + 如果是，应将哪些基础设施职责分配给应用团队以及分配给谁？
  + 如果不是，运营团队还应承担哪些基础设施责任（例如修补）？
+ 交付模式：
  + 根据应用程序或应用程序组，您应该更换平台、重构、重写还是替换？
  + 现代化的哪一部分应该使用云原生服务？
+ 技能组合 — 需要什么专业知识？ 例如：
  + 云应用程序背景，用于从头开始使用容器和无服务器技术构建具有模块化架构的应用程序。
  + DevOps 通过使用开源以及 AWS 工具和服务，在 CI/CD 流程、基础设施即代码以及自动化或应用程序可观察性领域开发解决方案的专业知识。
+ 现代化方法 — 考虑到应用程序的当前状态、云技术选择、当前的技术债务、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）是多少？