准备过程

首先，在对系统进行升级改造之前，架构师从各相关部门抽调资深人员对已有系统问题进行分析，制定解决方案，并系统评估方案的可行性及风险，并针对性的制定计划及风险预案。

解决方案

在问题的分析过程中，架构师与产品团队，运维团队，运营团队及部分消费者都进行了积极的沟通和讨论，发现除了已有系统采用的技术框架已经不能满足当前业务需求外，Azure China 各区域的服务上线策略、区域扩容计划、区域价格策略等都会对未来业务系统能否以合理成本稳定运维产生影响。 因此，架构师通过微软客户经理与微软的技术支持团队进行了积极的沟通，全面的了解了微软 Azure 服务的发布及推广策略，总结为以下几点结论和策略，作为后续的系统升级的指导原则：

• 区域资源饱和风险低：对于任何云服务，每个区域的数据中心资源都会随着预留资源的不断被使用而渐渐饱和。一旦进入饱和，需要对区域进行扩容以提供新的容量，但是扩容的周期一般比较长，会有阶段性资源紧缺的风险。Contoso 当前线上商城系统所部署的东部1区域已经开放了5年，阶段性资源饱和的风险比较高，而刚刚上线不久的北部2区域及东部2区域，由于刚开放不到2年，资源饱和的风险较小，是未来几年最合适的备选区域。
• 所需服务发布及时：各区域提供的服务及更新的速度是有所区别的，与该区域的可用资源及用户需求息息相关。如 AKS 服务、时序见解、自动化等功能，在东部1区域暂时都没有支持，这些服务的缺失，严重的限制了系统功能的开发速度，也提高了系统的复杂度，及系统运维成本。例如：更高级的虚拟机和云服务，Azure Kubernetes 服务，Azure SQL Database托管实例，Azure时序见解，自动化等电商平台个性化解决方案所需服务。同时更多新服务未来也会在北部2区域及东部2区域及时发布。
• 所用资源性价比高：各区域资源的市场价格策略会受到该区域资源使用率的影响，区域可用资源越多，可以预见该区域未来通过价格杠杆来促进资源销售的概率越高，即促销的可能越大。基于与微软相关团队的探讨，北部2区域是目前已开放区域中可用资源最多的，未来进行价格促销的概率最高。目前，北部2区域的 CPP 价格比东部1区域便宜约20%-30%左右。

综合以上，结构师得出初步的解决方案结论，即在升级改造过程中将系统从 东部1区域 迁移到 北部2区域 中。

团队搭建

系统升级改造（迁移）不是由技术团队独立完成的，需要从各关键部门指定接口人，成立 V-Team 以相互配合共同完成。在本示例中，Contoso 成立了两个 V-Team，团队成员包括：公司管理团队成员，产品团队、运维团队、业务运营团队、财务团队等。

1. 决策 V-Team：各团队的决策者；
   • 分析迁移后的业务影响
   • 确定迁移的最佳方案
   • 找到受影响的业务系统，指定相关接口人，共同合作完善迁移方案
   • 跟踪整个执行过程，确保执行成功。
2. 执行 V-Team：各团队的资深成员，执行者；
   • 详细分析迁移后的业务影响
   • 迁移过程中需增加或升级的功能
   • 迁移后的割接方案
   • 建议的时间节点
   • 明确实施迁移的实施和审批流程
   • 通过流程确保所有相关团队了解迁移计划、影响，并达成共识
   • 提供相关培训，确保相关团队在迁移后系统的业务运维及运营的顺利开展

可行性评估

架构师基于关于解决方案的初步结论，需要进一步从技术、财务、业务风险等多个方面进行系统的评估，以确定方案的可行性及带来的成本、业务方面的影响。

当前使用资源:

当前线上商城所使用资源都部署在 Azure China 东部1区域的数据中心中，在过去4年多的使用过程中没有进行过大的系统架构改造。该数据中心中共运营3个订阅，分别承载内部开发环境、ToB供应链系统和ToC网页商城。3个订阅所使用的资源均比较简单，目前只包含：计算、存储、网络。

• 计算：
  • 虚拟机(D2/D3/D4/D5/F4/F)： x15
  • 合计用量： 40K Hour/Month
• 存储：
  • 磁盘(P30/P10/P15/P6/S30/S15)： x11
  • GRS存储/LRS Snapshots： x40
  • 数据存储备份在 Azure China 北部1区域的数据中心中
• 网络：
  • Basic Gateway： x1
  • Standard Static Public IP： x1
  • Dynamic Public IP： x1

在此阶段结束时，您将拥有：

• 需要迁移的 Azure 资源的完整列表。

技术评估

在技术评估阶段，您需要召集执行 V-Team 从以下不同角度完成评估：

• 迁移策略：
  根据技术及业务现状，讨论迁移策略。在本示例中，Contoso 希望在迁移过程中实现以下目标：

  • 利用此次迁移机会重新设计技术架构，并利用更多 PaaS 层级的云服务
    • 使用 AKS 和 SQL 托管实例功能来优化数据存储性能；
    • 使用 AKS 服务/时序见解/自动化等功能分析站点流量和浏览到购买的转化率，以根据客户行为确定特别优惠和新产品，并创造具有目标内容和优惠的个性化购物体验，增加满意度；
    • 使用 Security Center 和 Azure Policy 来提高开发部署的安全性。
  • 目前使用的某些 D 系列虚拟机型号较老，各方面指标不够强大，无法满足未来的工作负载。技术团队预计要将 D 系列虚拟机全部更换成 DSv2 系列，可为企业提供更快的 CPU、更好的本地磁盘性能和更高内存。

  具体到迁移策略，可以有两个不同选择：迁移、然后改造 和 迁移 + 改造。

  • 迁移、然后改造：将位于东部1区域的资源直接迁移到北部2区域，然后对系统进行升级改造。这种做法可以分阶段进行，通过小步走的渐进、局部改造方式完成系统升级。
  • 迁移 + 改造：在北部2区域中部署升级改造过的系统模块，然后将没有变化的模块从东部1区域直接迁移到北部2区域，最后进行数据迁移及转换完成整个过程。这种做法迁移周期短，节省成本。

• 资源评估：
  在每个订阅运行一系列脚生成资源组、每个资源组中的资源以及环境中的资源组部署设置的列表。将生成的列表与开发团队进行确认，确保生成的资源列表与已有系统的部署方案中涉及资源保持一致。

• 环境评估：
  了解源区域的环境和目的区域的环境之间服务与配置的一致性，估算在目的环境中的资源成本和运维成本。

• 依赖关系评估：
  梳理部署在 Azure 中各应用程序之间以及与外部系统的依赖关系，接口及接口版本信息。

• 复杂性评估：
  评估系统在 Azure 中的部署架构，部署的各类资源之间的依赖关系，了解系统迁移的复杂度。

• 性能分析：
  梳理系统各模块的性能指标，并在目标环境中进行相应性能测试，以确保目标环境中的各类资源能满足性能要求。

• 初步测试：
  根据系统内部及外部依赖关系，制订迁移评估方案。通过执行有限范围的测试来验证迁移方案。

在此阶段结束时，您将拥有：

• 系统内部资源之间的依赖关系，及外部系统依赖关系列表。
• 包含迁移方案，迁移周期等信息的迁移复杂度评估信息。
• 完成供决策 V-Team 进行审批的综合技术评估报告。

财务评估

估算整个迁移过程中涉及的成本支出，确保具有相应的审批和预算来完成迁移。

• 日常运维成本： 估算在目标环境中的日常运维成本及使用成本。
  • 根据目标环境中预计使用的资源列表，估算使用成本。大部分存储和计算资源的使用成本在北部2区域将会降低约10%~30%。
  • 根据已有系统的运维方案估算目标环境中的运维成本。使用高级的托管资源将预计节省10%人力成本。
• 迁移成本： 估算整个迁移过程中必需的人员/工具/额外资源及合作伙伴等的成本。
  • 估算为迁移项目支付的人力成本。
  • 估算为迁移项目支付的第三方工具成本（包含：迁移工具、新环境带来的第三方系统使用成本等）。
  • 估算为迁移项目支付的额外 Azure 资源使用成本。
  • 估算为迁移项目支付的合作伙伴成本。

在此阶段结束时，您将拥有：

• 完成供决策 V-Team 进行审批的综合财务评估报告。

风险评估

系统的迁移有可能会造成业务中断风险，需要进行相应的风险评估，并根据风险评估结果制订迁移计划。

• 业务风险
  • 业务运营影响: 整个迁移过程可能会持续几个月，其间有可能会对系统的稳定运行及性能带来影响。需要评估迁移项目的合理开展时间，如何规避旺季及关键商业活动的时间窗口。
  • 业务中断风险：评估业务割接导致的业务中断对公司业务带来的影响，评估合适的业务割接窗口，以减少业务中断带来的业务影响。
• 降低风险方案
  • 根据割接窗口评估业务影响范围，评估可行的应急预案（包含：响应机制、回滚方案等）。
  • 评估应急预案需要的预算和人员。
  • 建议与您的微软AE联系，基于您的需求，共同讨论分析潜在风险，及可行的建议，降低迁移的风险迁移。

在此阶段结束时，您将拥有：

• 完成供决策 V-Team 进行审批的综合风险评估报告。

（可选）方案审批

决策 V-Team 与公司决策层基于评估进行审批，执行 V-Team 基于审批结果开展迁移工作。