在云中执行现代化

执行是实现现代化计划的阶段。 此步骤涉及为更改准备每个人，在非生产环境中执行开发工作。 您彻底测试并以受控方式部署到生产环境。 重点是严格的测试和安全部署做法，以最大程度地减少业务中断，因为更改可能很重要。

帮助利益相关者准备现代化

在开始部署之前，必须为所有利益干系人和用户做好迎接即将到来的变化的准备。 意外可能导致混淆，甚至导致作问题。 关键准备步骤包括通信、更改冻结（前面提及）和支持计划：

1. 向所有利益干系人宣布部署计划。 提前与所有受影响的各方沟通，何时应进行现代化部署，以及预期情况。 包括关键日期，例如更改冻结开始和上线窗口，以帮助利益相关者进行适当的准备。 通过设置预期，用户可以围绕停机时间进行规划，并且内部团队可以准备就绪。

2. 对源和依赖工作负荷实施更改冻结。 正如此前在治理中计划的那样，现在是实际实施冻结的时候了。 请确保在部署之前和期间的某个时期内，工作负载及其依赖工作负载不会发生代码更改、配置调整或其他部署。 这将保持环境稳定。 确保所有团队成员和任何集成的第三方都知道这一点。 明确定义具有特定开始和结束时间的冻结窗口，以避免混淆。

3. 传达最终用户操作和部署后的调整。 用户需要事先通知部署前后所需的作，以防止工作流中断。 指示用户在切换开始之前注销或保存工作。 共享新的访问 URL、身份验证更改（例如Microsoft Entra ID登录要求），以及影响日常操作的更新工作流。 提供支持文档和快速入门指南，以减少第一天的混淆。

4. 协调用于部署的支持人员配置。 IT 运营和开发团队必须可用于监视和响应关键部署阶段的问题。 在部署后第一个工作日安排延长支持时间和人员，以应对可能的问题高发期。 通知业务部门部署后支持计划和升级过程，以确保快速解决问题。

5. 定义关键工作负荷的应急程序。 任务关键型工作负荷需要手动解决方法和应变计划才能在部署时段内维护业务运营。 记录特定程序，例如在只读工作负荷期间进行手动订单处理。 提前共享这些过程，并确认与受影响的团队的就绪情况，以确保在需要时无缝执行。

在非生产环境中进行现代化开发

现代化更改的所有开发和集成都应在生产外部（在开发、测试、过渡环境中）发生。 指导原则：首先在类似 prod 的环境中生成和测试，以便在部署到 prod 时，它已是已验证的配置。

• 在实现过程中遵循 Well-Architected 框架原则。 编码和配置新更改时，请持续应用AzureWell-Architected框架（WAF）中的最佳做法。 使用 Azure 顾问 建议和体系结构评审过程来验证设计决策。 此方法可确保现代化组件符合Azure最佳做法和操作标准。

• 创建镜像生产的非生产环境。 在与生产设置尽可能接近的Azure中启动开发/测试环境。 如果生产使用某些 Azure 服务，请在测试环境中使用相同的服务，或者选择较小规模或较低性能层级（SKU）来节省成本。 测试环境越接近生产环境，就越有信心测试结果应延续到生产行为。

• 使用源代码管理和 CI/CD 以增量方式实现更改。 像对待任何其他软件项目一样对待现代化工作。 对所有代码更改和基础结构即代码脚本使用 Git 或其他源代码管理。 它提供历史记录以及在需要时回滚代码的功能。 将工作分解为小的增量（可以是每个功能或修复），并使用功能分支。 代码审核后频繁合并更改。 设置持续集成版本，以便在每次提交时运行测试套件，以便提前捕获问题。

使用测试验证现代化更改

测试至关重要。 由于现代化不会添加新功能，因此重点在于回归测试（无任何中断）、性能测试（性能满足或超过以前的级别），以及安全测试（安全控制仍然有效或得到加强）。 在接触生产环境之前，需要验证测试环境中工作负荷的各个方面。

1. 对所有修改的组件执行单元和集成测试。 开发人员应为重构的任何代码创建或更新单元测试。 即使是遗留代码，为关键函数编写单元测试也能帮助捕捉在重构时无意间改变行为的情况。 在 CI 管道中持续运行单元测试。 此外，运行集成测试以确保组件能够正确相互通信。 在修复任何 bug 后，重新运行相关测试，以确保该 bug 已被解决，并且不会破坏其他功能（避免发生回归问题）。

2. 进行端到端功能测试。 在过渡或测试环境中，执行完整的工作流测试，就像你是最终用户一样。 此测试可以通过 QA 或自动化 UI 测试进行手动测试。 登录到应用程序，执行主要任务。 确保未变功能保持不变。 基本上，模拟实际使用情况以捕获任何单元测试可能错过的内容。

3. 与相关方进行用户验收测试（UAT）。 在推出之前，让一些实际的最终用户或业务利益干系人测试现代化工作负载。 他们可能会发现开发人员所忽视的细微差别。 捕获有关可用性、性能和功能差距的反馈。 在部署之前解决关键用户验收测试（UAT）问题，并获得利益干系人正式批准，以确认业务就绪情况。

4. 在现实条件下使用负载测试验证性能。 理想情况下，现代化应提高或保持性能。 使用负载测试工具（如Azure 负载测试）来模拟实际的使用模式。 将结果与源环境中的性能基线进行比较，以确定任何降级。 在预期负载的150%下进行压力测试，以确定工作负荷限制并验证在压力下的弹性能力。

5. 执行安全验证和符合性检查。 在新代码和容器映像上运行漏洞扫描，以检测安全风险。 使用行业特定的工具对受监管工作负载执行符合性验证。 使用Microsoft Defender for Cloud扫描基础结构配置错误并验证安全控制是否符合要求。

6. 在生产部署之前解决所有关键问题。 修复测试阶段确定的功能、性能和安全问题。 确认所有测试通过和性能满足服务级别协议（SLA）。 记录所有剩余的低优先级问题，并为部署后解决创建修正计划。

创建可重用基础结构

现代化解决方案在非生产环境中通过所有测试后，您应该将基础结构设置和配置以代码形式捕获，以便在生产环境以及未来的环境中轻松复制这一过程。 可重用基础结构意味着使用基础结构即代码（IaC）模板和自动化实现一致性和速度。

1. 为经过验证的配置创建 IaC 模板。 将你的测试环境最终架构（即目标生产环境）进行代码化。 使用 Bicep、Terraform 或 Azure 资源管理器 模板定义基础结构。 参数化这些模板，以便可以在不同阶段（如开发、测试、生产）中重复使用，只需进行一些小的调整（如名称或大小）。 此设置可确保你创建的生产环境与测试的内容匹配。 它避免了手动单击Azure门户创建资源时出现人为错误。 这也意味着，如果需要重新创建环境，例如灾难恢复或部署到新区域，则可以准备好基础结构部署。 有关详细信息，请参阅 CAF 管理 - 管理基于代码的部署。

2. 在版本控制中存储模板。 将基础设施代码检入 Git 仓库（与应用程序代码一起或在一个单独的仓库中）。 使用 GitHub 或 Azure DevOps 使用正确的版本控制来管理 IaC 资产。 版本控制支持代码评审、支持团队协作，并鼓励跨项目重复使用模板。 此方法为基础结构更改提供完整的可跟踪性，并支持发生问题时回滚功能。

3. 自动执行依赖项安装和配置。 创建脚本或管道任务来部署这些模板，并处理任何所需的配置或种子设定任务。 使用 Azure Pipelines、GitHub Actions 运行采用 IaC 模板并部署到目标订阅/资源组的部署作业。 自动安装应用依赖项、配置设置和 机密管理。 目标是实现一键（或一条命令）环境搭建：从零到完整运行的测试环境。

4. 端到端测试 IaC 与自动化流程。 使用单独的Azure订阅或资源组作为沙盒，并练习使用模板和脚本从头开始部署整个环境。 测试您的 IaC 模板、管道和脚本是否可以从无到有地创建完整的基础设施堆栈。 测试不同的部署方案，包括初始部署、配置更新和回滚过程，以确认自动化正常工作。

有关详细信息，请参阅在 WAF 中 将工作负荷开发供应链 和 基础结构设计为代码 。

创建部署文档

即使有了自动化，有关部署的良好文档对于审核、载入新团队成员和将来维护至关重要。 部署文档应涵盖用户可读形式的配置、过程和回滚步骤。

1. 记录配置设置与步骤。 在可访问的文档中记录所有特定于环境的设置、连接字符串、服务终结点和安全配置。 包括分步部署说明、先决条件要求和部署后验证步骤。 本文档支持一致的部署，并支持在出现问题时进行故障排除。 如果新工程师必须进行部署，他们可以阅读本文档，然后按照其中的步骤操作或理解管道的输出。

2. 更新回滚和恢复操作程序。 完成测试后，正式化步骤，以在发生部署问题时还原更改。 包括回滚触发器、数据备份和还原过程以及恢复验证步骤。 定期测试回滚和恢复过程，以确保在需要时正常工作。 此准备可减少停机时间。

3. 在中心位置收集所有这些文档。 使用SharePoint、GitHub或 Wiki 来存储此信息。 确保团队和支持人员知道在哪里找到它。 在高压力事件中，手头有明确的文档是救命稻草。

部署现代化

生产部署是现代化工作的最后阶段。 根据所选策略（就地与并行），步骤不同。 在执行之前，请验证是否已执行所有准备步骤：利益干系人已通知、冻结有效、备份、监视备用状态。

在原有环境中部署现代化内容

1. 排定维护窗口。 如果更改需要任何停机或运行锁定资源（如数据库架构迁移）的脚本，请将其在预先宣布的维护时段内执行。 确保所有用户在那个时候都停止使用工作负载。 有一个明确的窗口也让你有一个目标来完成部署，或者决定回退（如果时间不足）。

2. 使用 CI/CD 流水线进行部署。 生产部署应使用与测试环境相同的自动化流程，只需指向生产环境。 此设置可确保一致性，因此基础结构和代码以相同的方式部署。 在运行之前，请对任何关键数据（数据库）进行最终备份。 即使可以回滚，备份也是一种额外的安全措施，以防某些情况失败。 运行管道以部署新的代码和基础结构更改。 实时显示日志和监视。 如果任何步骤失败，请暂停并评估是否可以应用纠正措施或是否需要回滚。

3. 若可行，实施渐进式流量切换（金丝雀发布）。 许多 Azure 服务允许插槽交换或逐步流量转移，即使是在就地方案下也是如此。 Azure 支持通过 Azure 应用服务 部署槽位、Azure 容器应用 流量拆分 和 Azure Kubernetes 服务 与 Azure Pipelines 进行金丝雀部署。 如果负载均衡器后有多个虚拟机，请逐个实例升级（滚动升级），以便其他实例继续处理流量。

4. 在监控的同时逐渐增加到最大流量。 新版本上线后，请密切监视它。 检查应用程序日志、性能指标和错误率。 从一小部分用户开始（或者尽可能从验证模式下的工作负荷开始）。 如果几分钟后一切看起来不错，可以增加流量至例如25%。 再次检查指标（500 个错误没有峰值，响应时间正常）。 增加到50%，然后在您计划的时间框架内增加到100%。 如果你想谨慎，可能会需要一个多小时。 若在任何步骤中发现严重问题，应立即回滚，防止影响所有用户。

5. 在部署期间保持数据一致性。 就地部署可保留现有数据终结点，同时可能修改数据架构。 以向后兼容的方式应用数据库架构更改，以在 Canary 版本期间同时支持旧应用程序版本和新应用程序版本。 使用数据库迁移脚本来添加新列或表，而无需删除现有结构，直到部署成功完成。

将现代化功能部署到并行环境

1. 创建并行生产环境。 使用 IaC 模板，在Azure创建新的生产环境，以反映所测试的内容。 此环境包括所有计算、网络和存储。 它应已启动并运行，但当前没有用户访问。 确保网络安全组、防火墙、标识（托管标识或服务主体）和监视等内容都根据需要进行配置（在生产订阅中重复测试环境设置）。

2. 建立数据库复制机制。 配置数据库平台的本机复制功能，以在源工作负荷和Azure目标工作负荷之间建立连续数据复制。 验证初始数据同步是否成功完成，并且复制是否正常。 可以从备份或快照中执行数据库的初始批量复制，然后为新的事务启用复制。 使用数据库平台的监视工具监视复制中的滞后时间。 更高的延迟会增加系统切换的风险和时间长度。 在复制滞后时间为零之前，不要继续执行下一步。

3. 复制非结构化数据和文件。 在最终切换前，将非结构化数据和文件复制至 Azure。 使用 Tools 进行对象和文件迁移功能，将文件传输到相应的Azure存储服务。 此准备减少了在最终切换期间需要复制的数据量。

4. 完成最终数据同步。 在切换时刻，希望数据零丢失或最小丢失。 对于数据库，确认源工作负载无待处理事务，且数据库复制已完成。 在某些情况下，可能需要短暂暂停对源数据库的写入以清除最终变更（尤其是为了事务一致性）。 可采用事务日志传送或短暂停机进行最后一次增量备份还原。 使用AzCopy或类似工具复制任何修改的非结构化数据。

5. 逐步将用户流量切换至新环境。 更新 DNS 记录和负载均衡器配置，以将用户流量定向到Azure环境。 监视工作负荷运行状况和性能。 从 1% 的实时流量开始，通过 Azure 负载均衡器，并使用加权路由，将流量分配到经过现代化的工作负载中。 监视实时指标，包括响应时间、错误率和数据库连接运行状况。 以快速增量（5%、15%、50%）提升流量，单位为分钟而非小时，同时设置自动回滚触发条件。

6. 执行最终切换至 100%。 自信后，将所有用户路由到新环境。 该切换可能是 DNS 切换（若 TTL 较低，仅需几秒到几分钟），或是负载均衡配置切换。 此时，用户已正式使用现代化工作负载。

7. 请立即验证并监控切换之后的状态。 执行切换后的验证检查。 使用自动化测试套件对所有关键业务流程执行端到端功能测试。 使用校验和验证和哈希函数比较源与目标工作负载间的数据准确性。 让工作负荷所有者确认所有主要功能都正常运行。 在切换后的前 24-48 小时内监视工作负荷性能、错误率和用户访问模式，以识别性能下降或功能问题。

8. 让旧环境以热备用状态继续运行一段时间。 先不要拆掉任何东西。 将旧工作负荷保留为至少 24-72 小时的热备用状态，并尽可能进行数据同步（或准备快速同步）。 若生产环境中出现意外的严重问题，仍可通过重新引流回退。 你应该尽量减少数据丢失，因为可以通过日志或其他方式恢复。

验证现代化成功

现在，新的工作负载已推出，需要在生产中验证一切是否按预期工作并满足验收标准。

1. 确认用户访问成功和工作负载性能良好。 用户访问验证可确保现代化是透明的，并且性能符合预期。 此确认会验证用户是否可以在不中断的情况下访问工作负荷。 在迁移后的初始期间监视用户访问模式、工作负荷性能指标和错误率。

2. 仅在彻底验证后才宣布迁移成功。 完整验证可确保所有利益干系人确认工作负荷稳定且功能正常。 此确认可防止过早地声明成功，这可能会导致以后出现问题。 获取工作负荷所有者、测试人员和业务利益干系人确认工作负荷满足所有要求并正常运行。

在稳定期间支持工作负荷

即使在成功启动后，仍计划稳定期，以便密切监视工作负荷。 新式化工作负载可能有未知问题，这些问题仅在一段时间后才会出现在实际使用模式下。

• 在稳定期间建立增强的支持覆盖率。 在上线后的头几天或几周（具体取决于复杂性），应启动更严格的支持流程。 分配经验丰富的 IT 人员或迁移合作伙伴以密切监视工作负荷，并提供比正常作更短的 SLA。

• 更新您的操作文档和工具。 确保所有运行手册、支持文档和监控配置均已更新，反映当前状态。 针对任何新过程（例如新的备份过程、微服务的新重启过程）训练运营团队。 将现代化工作负载连同充分的知识传递一起移交给运营/支持团队。 确保资产清单/CMDB 记录新服务器、IP、服务以及删除或标记旧服务器。

后续步骤