华为云用户手册

业务账号规划 按照业务架构在华为云上创建不同层级的组织单元OU，每个业务OU下面可以挂载多个业务账号，每个业务账号上可以承载一至多个业务系统。 原则上，业务账号的规划需要跟组织定义的业务单元（业务单元之间要求强隔离）保持一致，业务单元可以是子公司、事业部、产品线、部门、项目组或业务系统等。业务单元的粒度越细，组织对精益治理的诉求越强。根据华为云为大量企业和政府客户设计和实施Landing Zone方案的经验，总结了如下三种规划业务账号的模式。 图2 规划业务账号的模式

IT管理账号规划 针对企业的中心IT部门，在华为云上创建对应的组织单元，并在其下面创建安全和基础设施两个下级组织单元，分别容纳安全管理的子账号群和基础设施管理的子账号群。这些IT管理账号可以对企业范围内所有子账号进行统一的IT管理。 原则上，IT管理能账号的规划需要跟组织当前的IT组织规模和职责划分保持一致，避免打破当前利益平衡。根据华为云为大量企业和政府客户设计和实施Landing Zone方案的经验，总结了如下三种规划IT管理账号的模式。 图3 规划IT管理账号的模式 模式1是全量规划，针对大型IT组织，这些IT组织通常有数十上百个IT管理人员，内部已经按照安全运营、日志审计、网络运营、运维监控、公共服务、数据平台、DevOps等职责划分了独立的IT职能小组。为了保障IT部门内部的职责隔离，将这些IT职能小组分别映射到独立的账号，这些账号行使独立的IT职责，所以称为IT管理账号或IT职能账号，如下表所示。 表1 IT管理账号 账号名称 账号履行的IT职能 责任团队 建议开通的云服务 主账号或管理账号 针对整个企业进行统一组织和账号管理、统一财务管理、统一控制策略管理和统一身份权限管理 CIO或IT主管 组织Organizations、资源治理中心RGC、成本中心、 IAM 身份中心 网络运营账号 集中部署和管理企业的网络资源，包括网络边界安全防护资源，实现多账号环境下的统一网络资源管理和多账号下VPC网络的互通，尤其需要集中管理面向互联网的出入口和面向线下IDC机房的网络出入口 网络管理团队 ER、DNS、NATG、EIP、VPC、DC、CC、VPN、CFW、WAF、AAD等 公共服务账号 集中部署和管理企业的公共资源、服务和应用系统，并共享给其他所有成员账号使用 公共服务管理团队 镜像服务 IMS、 容器镜像服务 SWR、弹性文件服务SFS、 对象存储服务 OBS、自建NTP服务器、自建AD服务器等公共资源 安全运营账号 作为企业安全运营中心，统一管控整个企业内所有账号的安全策略、安全规则和安全资源，为成员账号设置安全配置基线，对整个企业的信息安全负责 安全管理团队 统一部署具备跨账号安全管控的服务，如 安全云脑 SecMaster、 企业主机安全 HSS、 数据安全中心 DSC、 数据加密 服务DEW、云证书服务CCM、漏洞管理服务CodeArts Inspector 运维监控账号 统一监控和运维各个成员账号下的资源和应用，统一进行告警管理、事件处理和变更管理，并提供运维安全保障措施 运维团队 应用运维管理 AOM、COC、 云日志服务LTS 、 应用性能管理 APM、 云堡垒机CBH 等 日志账号 集中存储和查看所有账号的审计日志和安全相关的日志（如VPC流日志和OBS访问日志等） 合规审计团队 云审计 服务 CTS 、 云日志 服务LTS、、配置审计服务Config、对象存储服务OBS等 数据平台账号 集中部署企业的大数据平台，将其他账号的业务数据统一采集到数据平台进行存储、处理和分析 数据处理团队 数据湖 、大数据分析平台、 数据接入服务 、 数据治理 平台 沙箱账号 用于进行各种云服务的功能测试、控制策略的测试等 测试团队 按需部署各种需要测试验证的资源和服务 除了上述子账号之外，中心IT部门可以根据自己的职责和权限隔离需求创建更多的子账号。比如独立的应用集成账号等。

调研技术组件的详细信息 调研单个应用的部署架构所涉及的各个技术组件（包括主机、数据库和中间件等）的详细信息，包括资源规格、版本、容量、配置等，如下表格所示。 表2 主机信息调研表示例 主机名 主机类型 (E CS /物理机) 规格 CPU （core） 内存（GB） 操作系统版本 系统盘类型 系统盘大小（G） 数据盘类型 数据盘大小（G） 私网IP 公网IP 此处仅给出表头信息作为参考。 表格具体内容请按业务实际情况进行补充。 表3 数据库信息调研表 应用名称 区域 实例名称 架构类型 IP地址：端口 版本 实例规格 CPU 内存 存储类型 磁盘容量 此处仅给出表头信息作为参考。 表格具体内容请按业务实际情况进行补充。 表4 中间件信息调研表 应用名称 区域 名称 版本 连接地址 规格 Topic数量 Partition数量 此处仅给出表头信息作为参考。 表格具体内容请按业务实际情况进行补充。 调研方式如下所示。 图2 调研方式图 首选CMDB法； 如果CMDB无法获取，次选CMP云管平台法，从现网云管平台或虚拟化管理软件获取； 如果CMDB和CMP都行不通，可以安装信息收集工具（比如华为云RDA）进行采集； 如果以上方法都不可行，则采用人工访谈的方式调研信息。

调研应用的四层部署架构 收集接入层、应用层、中间件层和数据层的详细信息，收集三种关联关系（共享数据、共享服务器、应用间通信依赖），可以参考下表收集应用的详细部署架构： 表1 应用调研表 应用类型 接入层 应用层 中间件层 数据层 接入 域名 备注 应用名称 NAT NGINX 主机数量 IP地址 Redis Kafka MQ MySQL Mongo 内部/外部域名 WAF 备注 也可参考下图绘制应用的部署架构图： 调研方式如下图所示： 图1 调研方式

概述 云上架构设计包括基础环境设计、应用部署架构设计、大数据架构设计三部分，如下图所示： 图1 云上架构设计总图 基础环境设计：企业上云首先要准备好基础环境，基础环境构建好以后，上云工作才能正式开始。基础环境在业界也叫做LandingZone（着陆区），基础环境设计包括6个方面，即账号和权限设计、整体网络设计、整体安全设计、资源治理设计、运维监控设计、财务管理设计。 应用部署架构设计：应用部署架构是应用在云上的技术架构，应用部署架构要从接入层、应用层、中间件层和数据层来设计，包括每一层的云服务技术选型，同时还要考虑架构设计的6要素（即：可用性、性能、可扩展性、安全、成本、可运维性），其中重点考虑可用性、可扩展性和性能，安全、成本和可运维性遵循基础环境的设计进行适配即可。 大数据架构设计：大数据的部署架构设计包括大数据集群部署架构设计、大数据任务调度平台部署架构设计和大数据应用部署架构设计，其中大数据应用的部署架构可以参考应用部署架构的设计方法。大数据架构设计同样要考虑架构设计的6要素。 在做云上架构设计时，企业可以参考TOGAF的架构设计方法论，可以关注其架构开发方法（ADM）、四个架构设计领域、最佳实践和工具，有助于设计出更加高效、灵活和可扩展的上云架构。 父主题： 方案设计

双AZ高可用设计 公有云最常用的就是双AZ高可用方案，应用的四层架构（接入层、应用层、中间件、数据层）建议实现端到端的双AZ部署，如下图所示。 图1 双AZ高可用设计 设计要点： 业务模块：集群部署的业务，资源分别部署到 2 个AZ内，并通过 ELB 实现双AZ的负载均衡；单点业务ECS可通过 SDRS 作AZ级容灾。 云服务高可用：主备节点分别双AZ部署。 数据库同步：云上使用RDS数据库服务，进行跨AZ主备部署，跨AZ间数据同步。 灾难恢复切换：当AZ发生故障时，RDS 数据库等自动切换至备库，应用层自动或者通过 SDRS 的一键容灾切换功能切换至其他AZ。 容灾演练：通过应用切换或 SDRS 提供的容灾演练功能进行一键演练。 进行双AZ高可用设计时，如果业务对时延特别敏感（比如电信业务的NFV网元上云），则需要进行充分的验证和评估，并采取适当的优化措施，以确保业务能够在公有云双AZ环境中获得满意的性能和用户体验， 选择合适的AZ 云服务提供商通常会提供各个AZ的大致物理位置和网络延迟信息，不同AZ间可能在物理位置上相隔较远，导致网络延迟增加，实施跨AZ高可用方案要优先选择距离较近的AZ，可以降低网络延迟并提高应用的响应速度。 延迟验证 在正式实施双AZ高可用方案前，需要充分的测试和验证来评估应用程序在不同AZ之间的延迟情况。通过模拟真实负载的压力测试，来记录不同AZ之间的应用调用延迟，用于评估是否满足业务的需求，并做出相应的决策。 父主题： 可用性设计

调研评估的反模式 在进行上云调研评估时，可能会遇到一些反模式，这些模式如果不加以识别和避免，可能会影响调研评估的效率，也可能会导致调研评估结果不准确，无法支撑有效决策和后续的上云方案设计。以下是一些在上云调研评估中常见的反模式。 没有选择正确的调研方法 调研开始阶段，直接发各种复杂的调研表格给企业，进行信息收集，容易造成信息提供方抵触，从而影响调研的效率和结果的完整性及准确性。 优化建议：应采用科学的调研方法，遵循先易后难、先粗后细、持续迭代的调研思路，比如，先从CMDB收集信息，并结合现有的文档资料，梳理出需要调研的Gap信息，然后再精简调研表格，去做高效的调研和补充。 业务调研不足 仅关注技术层面的调研评估，而忽略了业务需求和用户场景。 优化建议：深入业务调研，分析用户场景，确保上云能够满足业务需求，提升用户体验。 评估不全面 仅关注某个单一指标（如成本、性能等），而忽略了其他同样重要的因素。 优化建议：建立全面的评估指标体系，综合考虑成本、性能、安全性、可扩展性、可运维性等多个方面。 低估迁移复杂性 认为上云只是一个简单的技术迁移，而忽视了应用程序架构、数据依赖关系及其对业务流程的影响，导致迁移后出现各种问题。 优化建议：要充分进行内、外部各种关联关系分析，识别强弱关联，并评估风险和影响，作为后续批次规划和切换方案的输入，将问题和影响降到最低。 通过识别并避免这些反模式，可以更加高效准确地进行上云调研评估，为企业的上云决策和方案设计提供有力支持。 父主题： 调研评估

可用性定义 可用性(Availability)是产品/服务在规定的条件下和规定的时刻或时间区间内处于可执行规定功能状态的能力，是产品可靠性和可维护性的综合反映。服务可用性一般会用SLA（Service-Level Agreement）来衡量，各类云服务都有承诺的SLA标准。不同SLA级别对应的停机时间如下表所示： 表1 SLA级别表 SLA 每周故障时间 每月故障时间 每年故障时间 99% 1.68 小时 7.2 小时 3.65 天 99.90% 10.1 分钟 43.2 分钟 8.76 小时 99.95% 5 分钟 21.6 分钟 4.38 小时 99.99% 1.01 分钟 4.32 分钟 52.56 分钟 父主题： 可用性设计

数据调研 数据调研主要包括如下方面： 表1 数据调研方法表 调研内容 调研目的 举例 数据类型 根据数据类型选择合适的迁移工具 HDFS、HBase、MySQL等 数据量 历史数据量，用于评估历史数据迁移周期； 日增量数据，用于评估每日增量数据同步周期。 历史数据X PB 日增量Y TB 数据分层 调研数据分层主要用于迁移优先级和数据校验标准。 数据接入层、中间层、结果层 数据权限 根据源端数据权限控制组件的不同，选择不同的权限数据迁移方式 Sentry、Ranger等 数据重要性 调研数据重要性的目的是区分核心数据和非核心数据，用于迁移优先级和数据校验标准。 交易类是核心数据，日志类是非核心数据 数据更新频率 针对不同的刷新周期，制定数据的迁移计划和校验计划。 日刷新/周刷新/月刷新/实时更新 任务执行区间 让数据迁移、数据校验和业务高峰期错开。 离线任务上班前和下班后执行 调研的方法主要是通过当前大数据平台获取，并辅助一些调研访谈进行补充和确认。 父主题： 大数据调研

应用团队 企业内部通常有多个业务部门，每个业务部门负责自身所需业务系统的投资、建设和运维，因此通常在业务部门会组建自己的应用团队。将这些业务系统云化需要应用团队的配合和协同，应用团队需要协同云实施团队进行业务系统的现状调研、迁移实施、应用现代化改造和测试验证，协同云架构团队基于云技术和云服务设计业务系统的云上应用架构，协同云运维团队确保业务系统在云上的长期安全稳定运行。应用团队的成员通常都来自于业务部门，因为不同的业务部门拥有独立的应用团队，所以应用团队可能是多个，这些应用团队虚线汇报给CCoE团队，应用团队通常包含应用架构师、应用开发工程师、应用测试工程师和应用运维管理员，其职责和技能要求如下表所示。 表1 应用团队的角色和职责 角色 职责 技能要求 来源 应用架构师 明确业务系统云化的业务收益，如业务连续性、业务敏捷性等。 负责制定业务系统的迁移策略（Rehost、Replatform、Refactor等）和迁移顺序。 支撑云实施团队提供业务系统的现状进行调研，为其提供资源现状、应用架构、部署架构、依赖关系等信息。 负责设计和管理业务系统在云上的应用架构，包括应用的架构模式、技术选型、部署方式等，确保应用的性能、可扩展性、安全性和可靠性。 与数据架构师和云架构师紧密合作，确保应用架构与数据架构和云架构的兼容性。 指导开发团队进行应用开发和部署。 深入理解各种应用架构模式和设计模式，例如微服务架构、事件驱动架构等。 熟悉各种开发语言和框架。 熟悉DevOps实践和工具。 具备良好的代码设计和开发能力。 了解应用安全最佳实践。 具备良好的沟通和团队协作能力。 业务部门 应用开发工程师 将现有应用迁移到云平台，包括代码迁移、数据迁移、数据库迁移等。 负责应用现代化改造，如将单体应用拆分为微服务，或采用Serverless和事件驱动架构。 对现有代码进行重构，使其更具可维护性、可扩展性和可测试性，并针对云环境进行优化，例如利用云原生服务和API。 精通至少一门主流编程语言，例如 Java、Python、Go等 熟悉DevOps实践和工具。 具备良好的代码设计和开发能力。 熟悉主流的云平台及云服务。 能够与周边团队有效沟通和协作。 业务部门 应用测试工程师 针对云上业务系统设计测试用例并制定测试计划。测试用例包括功能测试、性能测试、安全测试和可靠性测试等用例 按照测试计划和测试用例，选择合适的测试工具对云上业务系统进行全方面的功能、性能、安全性和可靠性等测试。 编写和维护自动化测试脚本。 编写测试报告和文档。 有扎实的测试理论基础，熟悉软件测试理论、方法和流程等。 具备丰富的测试经验，熟悉各种测试类型，如功能测试、性能测试、安全测试和可靠性测试等。 熟悉主流的云平台及云服务。 熟练使用自动化测试工具，能够编写自动化测试脚本。 能够与周边团队有效沟通和协作。 业务部门 应用运维管理员 负责云上业务系统的部署、监控和维护，确保业务系统的安全稳定运行。 处理应用运行中的故障，优化应用性能。 配合开发团队进行应用的版本更新和发布。 监控应用日志，分析并解决潜在问题。 熟悉云平台的 APM 服务，具备应用性能监控和 日志分析 能力。 掌握CI/CD工具和容器编排工具。熟悉常见的应用部署方式（如容器化、微服务架构）。 熟悉常见中间件（如Nginx、Redis、Kafka）的运维管理。 业务部门 父主题： 云卓越中心

分析云化收益 基于前面制定的云化目标，您接下来还需要对其进行收益分析，将其转换为财务收益，以便进行项目ROI评估，为管理层的战略决策提供依据。下面根据前面推荐的7个云化目标分别进行财务收益的评估，汇总后就能得到整个云化转型项目的总收益。 提升业务系统的可用性SLO 通过提高业务系统的可用性SLO，减少系统的停机时间，进而减少因停机导致的收入损失，因此可以基于业务系统的每小时停机损失来计算该指标的财务收益。假设某业务系统每小时停机损失为10万元。云化转型前的SLO为99%，每年停机损失为 10万元/小时 * 87.6小时 = 876万元；云化转型后的SLO为99.95%，每年的停机损失为10万元/小时 * 4.38小时 = 43.8万元。那么的每年财务收益为832.2万元。 缩短新产品或新版本的TTM 云化转型后，企业借助云平台提供的DevOps工具链、应用现代化和弹性计算资源可以大幅加速新产品的TTM和已有产品的迭代周期。如果新产品的TTM从6个月缩短至3个月，假设新产品每个月带来200万元的收入，那么提前3个月上市将带来600万元的额外收入。对于已有产品，如果将其版本迭代周期从3个月缩短至1个月，假设新版本每个月能带来100万元收入，那么新版本提前2个月上市将带来200万元额外收入。 减少不合规及安全事件造成的经济损失 云化转型后，企业利用云服务商提供的全面安全防护措施、合规审计工具和自动化合规报告可以大幅提升安全性和合规性。如果安全事件和不合规事件的数量从原来的每年20起减少到5起，假设每起安全事件平均造成20万元的处理和损失费用，那么总共每年可以减少300万元的经济损失。 降低IT基础设施的TCO 传统模式（自建数据中心）下企业按照预测的业务峰值需求准备硬件和软件等IT资源，但实际业务负载长期处于平均水平，导致资源长期处于低利用率状态，造成巨大的成本浪费。而云模式下企业按照实际业务负载弹性提供所需云资源，企业只需为实际使用的资源付费，将大幅降低IT基础设施的成本。计算传统模式和云模式下的TCO涉及很多成本项目，两种模式下的成本项目不同，例如传统模式下需要考虑机房建设和维护成本，但云模式下没有这些成本项目，这些成本已经隐含在云服务的价格中。下表是传统模式的成本构成，包括资本支出和运营支出。 表1 传统模式的成本构成 成本类别 成本项目 成本项目的具体含义 资本支出（Capex） 硬件成本 服务器、存储设备、网络设备（路由器、交换机、防火墙等）的采购成本。 软件成本 操作系统、虚拟化、数据库、中间件等软件的许可证费用。 机房成本 如果是自建机房，包括机房的建设和装修成本、安保系统（包含视频监控和门禁设备等）的建设成本、电力供应系统和冷却系统的建设成本。如果是租赁IDC机房，主要是机架租赁成本，这个属于运营支出。 实施成本 一次性的系统集成、测试、部署等费用。 运营支出（Opex） 人力成本 机房运维、IT运维和安保所需的人力成本，包括人员的薪资、福利和培训等费用。 硬件维护成本 硬件设备的维护、维修、更新换代费用。 软件维护成本 软件更新、补丁、技术支持等费用。 机房维护成本 除硬件和软件维护之外，针对安保系统、电力供应系统和冷却系统等为维持机房正常运转所必须的维护费用。 能源成本 运行整个数据中心的能源和电力费用。 机架租赁成本 租用IDC机架的费用。 带宽成本 互联网接入带宽费用。 企业云化转型之后，主要包含运营支出，成本构成如下表所示： 表2 云模式的成本构成 成本类型 成本项目 成本项目的具体含义 运营支出（Opex） 计算资源成本 虚拟机、容器、无服务器计算等服务的费用，通常按使用时间、CPU、内存等计费。 存储资源成本 对象存储、块存储、文件存储等服务的费用，通常按存储空间、请求次数、数据传输量等计费。 网络资源成本 互联网带宽、公网IP地址、NAT网关、负载均衡器、VPN等网络服务的费用。 数据库成本 关系型数据库、NoSQL数据库等服务的费用，通常按实例规格、存储空间、请求次数等计费。 安全运营成本 为保护云上数据和应用系统的安全而使用网络防火墙、应用防火墙、数据安全保护等安全服务的费用。 其他服务成本 中间件、大数据、人工智能、物联网等其他云服务的费用。 云管理成本 监控、日志、运维、审计、治理等云管理服务的费用。 云迁移成本 一次性的迁移上云、资源部署和集成测试的费用。 技术支持成本 根据选择的支持计划，需要支付的技术支持费用。 人力成本 IT运维人员（主要是应用运维）的薪资、福利、培训等费用。 另外，传统模式下还需要考虑IT设备的折旧，通常3-5年就需要针对IT设备进行升级换代。所以对比两者的TCO时不应该按照一年期进行对比，而是应该按照企业的IT设备折旧周期，也就是对比3-5年的TCO。 计算上述传统模式和云模式的成本是一项复杂的工作。其一，IT设备和云服务的价格是动态变化的，比如云服务商经常调整云服务的价格，您计算云服务的成本时可以参考华为云提供的价格计算器和商务优惠。其二，同样的IT设备和云服务在每个国家和地区的价格也不一样，电力价格和人力薪资在不同的国家和地区差距比较大。其三，您还需要获取当前IT资源的数量和配置规格，然后将其逐一映射到不同规格的云资源，这样才能相对准确地估算两者的TCO。华为云提供了一个计算TCO的Excel模版，可以帮助您快速分析和对比传统模式和云模式的TCO，可以联系您的销售人员获取这个模版。另外，您计算人力成本时，需要考虑提升IT运维效率所节省的IT运维成本，计算方式可以参考下面的第7点：提升IT运维效率。 按照分析报告和众多企业的上云实践，云化转型通常可以减少10%~30%的IT基础设施TCO，假设企业在传统模式下3年期的IT基础设施TCO为8000万，云化转型之后预计将减少800万元~2400万元。 业务创新和市场扩张带来的新增收入 云化转型后，企业借助云平台的先进技术进行产品、服务和商业模式创新，基于云服务商的全球布局快速进军海外市场。如果通过业务创新和进军新市场可以为企业带来50万活跃用户，假设每个用户每年平均贡献收入60元，总共每年为企业带来3000万元的新增收入。 减少碳排放量 由于大型云数据中心的规模效应和更高效的能源利用，以及云服务商大量使用了可再生能源，企业在云化转型后可以大幅降低能耗和碳排放量。计算碳排放量是一个复杂的过程，涉及很多因素，可以利用云服务商提供的碳排放计算器。如果云化转型后碳排放量减少50%，每年的碳排放量从10000吨减少到5000吨，假设碳交易价格为100元/吨，那么每年因减少碳排放量的收益为50万元。 提升IT运维效率 云化转型后，企业无需管理IT基础设施，再借助云服务商提供的智能监控系统和自动化运维工具可以大幅提升IT运维效率。如果每个运维工程师可管理的服务器数量提升 2 倍，从100台提升至200台，假设企业总共有2000台服务器，每个运维工程师的年薪是20万元，那么每年总共可以节省200万元运维成本。需要注意的是该项收益包含在降低IT基础设施的TCO所带来的收益中，可以将本项收益汇总到那里。 以上收益均为估算，实际收益需根据企业具体情况进行调整。这些收益包括成本节约、损失减少和收入增加等直接收益，但不包含因提升业务系统可用性、提升安全性和合规性、减少碳排放量所带来的公司品牌价值提升等间接收益。将上述收益汇总后就得到了整个云化专项项目的总收益，结合云化转型的总投资可以计算出ROI，为管理层的战略决策提供有力支撑。 父主题： 制定战略

云架构团队 云架构团队在云化转型中发挥着关键作用，参照TOGAF框架和卓越架构技术框架架（Well-Architected Framework），全面负责设计云上的技术架构和数据架构，协同应用架构师基于云技术和云服务设计业务系统的云上应用架构，帮助企业在云上构建高安全、高可用、高性能且成本优化的云基础设施和应用系统。云架构团队通常包含云架构师和数据架构师，其职责和技能要求如下表所示。 表1 云架构团队的角色和职责 角色 职责 技能要求 来源 云架构师 负责云平台和云基础设施的整体规划和架构设计，包括Landing Zone、平台工程、网络、存储、安全、灾备等方面，确保云基础设施的安全性、可靠性、性能和成本效益。 选择合适的云服务商和云服务类型。 制定和推广云上架构设计原则，赋能应用架构师和数据架构师在云上设计良好的技术架构。 领导和指导云实施团队，确保技术方案的落地。 深入理解云计算技术和架构，熟悉主流云平台。 具备丰富的Landing Zone、平台工程、网络、安全、存储、灾备等方面的知识和经验。 熟悉TOGAF和WAF等架构框架。 具备良好的沟通能力、团队合作精神和领导力。 企业架构师团队或者外聘 数据架构师 负责设计和管理企业在云上的数据架构，包括数据存储、数据处理、数据集成和数据治理。 选择合适的数据存储方案，例如关系型数据库、NoSQL数据库、 数据仓库 等。 确保数据的质量、安全性和合规性。 与应用架构师和云架构师紧密合作，确保数据架构与整体架构的兼容性。 深入理解数据建模、数据仓库、数据湖、数据治理等概念和技术。 熟悉各种数据库技术，包括关系型数据库和NoSQL数据库。 熟悉大数据技术，例如Hadoop、Spark、Flink等。 具备数据分析和数据挖掘能力。 熟悉数据安全和数据隐私相关的法规和标准。 具备良好的沟通和团队协作能力。 大数据部门或外聘 父主题： 云卓越中心

制定云化目标 云化目标一定要与组织的业务战略和业务目标对齐，而且云化目标要符合SMART原则，即目标应是具体的（Specific）、可衡量的（Measurable）、可实现的（Achievable）、相关的（Relevant）和有时限的（Time-bound）。例如，如果组织经常因为业务系统中断导致收入减少和品牌受损，可以制定一个具体的业务目标：“在未来一年，将业务系统的可用性从99%提升到99.9%”。在设定云化目标时，您还需要充分考虑组织的资源和能力现状，确保目标是可实现的。通过上述云化成熟度评估，您正好能够掌握组织当前的能力现状和差距，可以有针对性地制定云化目标，避免设置过高或过低的目标。 为了制定可衡量的云化目标，需要针对云化驱动力设计合理的量化指标，方便组织的管理层进行跟踪和评估云化转型的实际效果。我们针对上述各种驱动力设计了以下量化指标。 表1 云化驱动力的量化指标 类别 驱动力 量化指标 业务驱动力 提升业务敏捷性 新产品（新业务系统）的TTM，包含从设计、开发、测试到上市的端到端时间。 已有产品（已有业务系统）的新版本或新特性的迭代周期，包含从设计、开发、测试到上市的端到端时间。 加速业务创新 新产品、新服务和新商业模式等带来的新用户数。 新产品、新服务和新商业模式等带来的新增收入。 保障业务连续性 业务系统的可用性SLO。 业务中断导致的经济损失。 市场扩张 进入新市场带来的新用户数。 进入新市场带来的新增收入。 合规遵从 不合规造成的经济损失，包括赔偿和罚款。 提升可持续性 碳排放减少量。 技术驱动力 提升资源弹性 资源利用率。 资源扩容速度、资源部署时间。 提升系统韧性 RPO、RTO。 P1、P2、P3、P4事件数量。 提升扩展性 系统扩容速度。 提升安全性 安全事件数量。 安全事件导致的经济损失，包括赔偿和罚款。 提升运维效率 单位资源所需要的运维工时。 每个运维工程师可运维的资源数量（如VM数和存储容量）。 MTTR（平均故障修复时间）。 提升性能效率 TPS、QPS等吞吐量指标。 系统响应时间。 并发用户数。 资源利用率。 财务驱动力 按需付费 IT基础设施资本支出。 降低成本 业务单元成本，如每个订单的成本，每个用户的成本等。 IT基础设施的TCO。 新增收入 业务创新和市场扩张带来的新增收入。 上述量化指标比较多，跟踪、评估和管理这些指标的工作量比较大，所以不建议您的组织全部拿来评价云化转型的效果。考虑到有些指标之间存在包含关系，比如业务系统的可用性SLO隐含了RPO、RTO、MTTR等指标。另外，云化转型最终是为了取得业务收益，而不仅仅是技术收益。所以，我们建议您根据组织的业务目标和业务优先级将这些指标进行收敛，主要聚焦业务驱动力和财务驱动力所对应的指标，其次才是技术驱动力的相关量化指标。我们推荐以下指标来制定组织的云化目标。 表2 云化目标示例 量化指标 云化目标示例 业务系统的可用性SLO 业务系统全年可用性SLO从99%提升到99.95%。 新产品或新版本的TTM 将新产品的TTM从6个月缩短至3个月，已有产品的迭代周期从3个月缩短至1个月。 不合规及安全事件造成的经济损失 将不合规及安全事件数量减少75%，经济损失减少75%。 IT基础设施的TCO 将 IT 基础设施的 TCO 降低 15%。 业务创新和市场扩张带来的新增收入 基于云进行业务创新和全球市场扩展，在未来三年带来X万活跃用户，实现新增收入 Y 亿元。 碳排放减少量 上云后减少碳排放量 50%。 每个运维工程师可运维的资源数量 将每个运维工程师可管理的服务器数量提升 2 倍，从100台提升至200台。 父主题： 制定战略

财务驱动力 云化转型带来了大量的财务收益，包括按需付费，降低成本和新增收入等，对CFO和财务主管极具吸引力。 降低成本 传统模式（自建数据中心）下企业按照预测的业务峰值需求提前采购硬件和软件等IT资源，为了避免在高峰期出现性能瓶颈或服务中断，通常会过度采购资源。但实际业务负载具有波动性，大部分时间运行在平均水平或低于平均水平，结果是IT资源长期处于闲置或低利用率状态，造成成本的巨大浪费。 云模式下企业按照实际业务负载弹性提供所需的云资源，企业只需为实际使用的资源按需付费，无需预先购买大量硬件和软件。在业务高峰期，云平台能够迅速扩展云资源满足需求，而在在业务低谷期，能够释放多余云资源，这将大幅减少资源浪费、降低成本。传统模式和云模式的成本模型对比如下图所示。 图1 传统模式和云模式的IT基础设施成本模型对比 总体上讲，云模式节省IT基础设施成本的主要原因有以下几点： 按需付费：云模式可以根据业务高峰期和低谷期自动调整云资源数量，企业只需为实际使用的云资源付费，而传统模式需要提前购买和维护大量的硬件和软件资源。这种按需付费的模式避免了资源闲置和浪费。 规模效应: 云计算本质上是规模经济，云服务商建设和运营超大规模的数据中心，具备超大的计算能力和存储容量。由于规模庞大，云服务商可以通过批量采购硬件和软件、优化资源利用率、提升能源利用效率和自动化管理等方式大幅降低运营成本，以更低的成本对外提供IT资源。 降低运维成本: 云服务商负责IT 基础设施的维护和管理，企业无需投入大量人力和资金进行IT基础设施的日常运维。而且云平台提供了智能监控系统和自动化运维系统可以大幅提升应用系统的运维效率，企业可以减少在应用系统运维领域的人力投入，进一步降低了运维人力成本。自动化运维也降低了人为错误的风险，从而减少纠错成本。 值得注意的是，云模式下也可能会产生成本浪费，上图中橙色曲线和蓝色曲线之间的部分就是云模式下的成本浪费，这种浪费是由很多原因造成的，比如在业务高峰期间申请的云资源没有及时释放掉，在后面的运维治理章节，我们将详细描述如何进行成本优化和持续成本运营。 新增收入 云计算不仅可以降低成本，还可以帮助企业创造新的收入来源： 缩短产品上市时间: 云平台可以快速部署和扩展应用，帮助企业更快地推出新产品和服务，抢占市场先机，从而获得更多的市场份额和收入。 拓展新市场: 云平台的全球覆盖能力，使得企业更容易进入新的市场，拓展业务范围，接触到更广泛的客户群体，从而增加收入。 提升客户体验: 云平台可以提供更稳定、可靠和高性能的服务，提升客户满意度和忠诚度，从而增加收入和客户留存率。 业务创新: 云平台的灵活性和集成的新技术，可以支持企业进行产品和服务创新、探索新的运营模式和商业模式，挖掘新的市场机会，创造新的收入来源。 资本支出转变为运营支出 传统模式（自建数据中心）下 IT 基础设施建设需要巨额资本支出（Capex），购买服务器、存储设备、网络设备等硬件，并承担维护和更新成本，这需要企业一次性投入大量资金。云服务则采用按需付费模式，将资本支出转化为运营支出（Opex）。企业只需根据实际使用的计算资源、存储空间和网络带宽付费，如同水电费一样。这种模式可以显著降低企业的初始投资门槛，提高资金利用效率，并根据业务需求灵活调整资源使用，避免资源闲置和浪费。这对于预算规划和现金流管理至关重要，也使得企业能够更灵活地应对市场变化。 总而言之，云化转型带来的财务优势是 CFO 和财务主管拥抱云计算的核心原因。通过降低成本、新增收入，并将资本支出转变为运营支出，云计算可以帮助企业提高财务绩效。 父主题： 识别云化驱动力

安全设计原则 华为云根据自身安全实践和成功交付大量项目的经验，提炼了如下十大安全设计原则，你可以在此基础上设计企业在云上的整体安全方案。 零信任原则（Zero Trust Principle） 遵循“永不信任，始终验证”的安全理念，假设任何人或程序都不可信，无论是内部用户、外部用户还是网络设备。系统内的组件进行任何通信之前都将通过显式的验证，减少系统信任带来的攻击面。零信任把现有的基于实体鉴别和默认授权的静态信任模型（非黑即白），变成基于持续风险评估和逐次授权的动态信任模型。零信任不根据网络空间位置决定可信度，其重心在于保护资源，而不是网段。与传统安全理念对比，它将网络防御的重心从静态的、基于网络的边界转移到了用户、设备和资源上。所有的资源（如人/物/终端/应用/网络/数据/供应链）都需要进行持续身份验证和信任评估，从全局视角执行动态安全策略。零信任通过动态、持续性的实体风险评估，缩小受攻击面，保证系统安全。 最小授权原则（Principle of Least Privilege） 基于华为云的细粒度授权机制，只授予用户或应用程序完成任务所需的最小权限，限制访问权限可以减少攻击面，即使用户密码或应用程序被攻破，攻击者也难以获得更广泛的访问权限。如果用户或应用程序的任务产生变化，也应该及时调整权限确保任务能够顺利完成。 纵深防御（Defense in Depth） 不要依赖单一的安全机制，而是采用多层安全措施，即使一层防御失效，其他层也能提供保护。这就像城堡的护城河、城墙、城门等多重防御体系。需要企业建立覆盖涵盖全技术堆栈的纵深防御机制，将多种类型的安全控制应用于所有技术堆栈，包括网络边缘、VPC、 云存储 、ECS实例、操作系统、应用程序配置和代码等。 安全和成本平衡（Balance between Security and Cost） 尽管安全领域强调纵深防护，但越全面的安全防护方案的成本也更高。企业应基于业务系统的合规要求（如信息安全等级保护）和敏感数据的分类分级设计成本可接受的安全防护方案，不应盲目针对所有的业务系统和数据都采用全方位和高级别的安全防护方案。 云原生安全防护（Cloud Native Security） 云服务商提供了丰富的云原生安全服务（比如WAF、Anti-DDoS、 云防火墙 、秘钥管理等）。这些云原生安全云服务与云平台深度集成，在性能、弹性、便利性上有较好的优势，同时，云服务商的安全运营经验也会持续推动云原生安全服务的能力提升，因此建议企业优先选择云原生安全服务。华为云提供的云原生安全服务清单，请参考章节云原生安全服务-。 攻击者视角（Attacker Perspective） 企业应当从攻击者视角评估业务系统的安全性，识别安全风险，据此加固安全方案，以降低系统被攻击的可能性、提升攻击成功的难度，让攻击者发起攻击的成本超过其获得的利益。 持续安全运营（Continuous security operation） 安全防护三分在于技术，七分在于运营。只有不断优化安全管理流程、持续安全运营、持续监控和评估云环境的合规性，才能保障业务系统的长期安全稳定运行。 木桶原则（Barrel Principle） 安全是一项系统工程，适用木桶原则，任何一项安全短板都会降低整体安全性，因此要避免安全短板的出现。 人和数据分离（Separation of people and data） 利用工具和管理机制减少人员直接访问和处理数据的必要性，减少处理敏感数据时出现人为错误和人为删改的风险。 DevSecOps 将安全性纳入到整个软件开发生命周期中，从需求分析、设计、开发、测试、部署、运维、运营的每个阶段都考虑安全性，以确保系统的安全性和稳定性。通过将安全检测手段与DevOps的自动化流程相结合，DevSecOps可更快地检测和修复安全漏洞，并提高软件开发的效率和质量。 父主题： 安全架构设计

目标读者 如整体框架所述，CAF的内容涵盖云化全旅程和云化全视角，涉及到了组织内不同部门的不同角色，以下角色能从CAF中找到跟自身职责相关的指导，这些角色可以将这些指导作为决策和行动的起点。 CXO（包含CEO、CIO、CTO、COO、CFO等） 业务主管 IT主管、技术主管 财务专家 人力资源主管 云架构师、应用架构师、数据架构师、网络架构师 IT治理专家 运维主管、IT运维专家 CISO、安全专家、合规审计专家 应用开发专家、应用测试专家 应用运维专家 迁移实施工程师 项目经理 父主题： 云采用框架简介

应用部署架构概述 应用部署架构设计的方法论来源于华为云架构师在各个领域的实战经验，基于这些实战案例，我们总结了一套方法论来指导企业进行云上应用部署架构的设计，帮助企业上好云、用好云。 应用部署架构按照各个组件的功能，一般可以抽象出四个层级：接入层、应用层、中间件层、数据层。 图1 应用的四层部署架构设计 接入层：为外部访问提供了访问入口，云上业务部署在VPC私有网络中，与外部网络是隔离的，当外部需要访问VPC业务时，通常可以通过如下两种方式： 专线：云专线是搭建用户本地数据中心/其他云厂商与云上虚拟私有云（Virtual Private Cloud，VPC）之间高速、低时延、稳定安全的专属连接通道。可以让用户通过内网地址访问云上弹性云服务器、负载均衡等资源，也可以使云上云下进行业务互通、数据传输等。 EIP：即弹性公网IP（Elastic IP），包括公网IP地址与公网出口带宽服务。可以与弹性云服务器、裸金属服务器、虚拟IP、弹性负载均衡、NAT网关等资源灵活地绑定及解绑，提供访问公网和被公网访问能力。 VPN： 虚拟专用网络 （Virtual Private Network）用于搭建用户本地数据中心与华为云VPC之间便捷、灵活，即开即用的IPsec加密连接通道，实现灵活一体，可伸缩的混合云计算环境。 应用层：负责工作流控制，实现业务逻辑。上承接入层，处理接入层的请求，返回请求结果；下接中间件层或数据层，实现对数据的增删查改。在云上，应用承载的资源主要有： 虚拟机：在云上，虚拟机又叫做弹性云服务器（Elastic Cloud Server，ECS），是由CPU、内存、操作系统、云硬盘组成的基础的计算组件。弹性云服务器创建成功后，可以像使用自己的本地PC或物理服务器一样，在云上使用弹性云服务器。 容器：容器虚拟化技术已经成为广泛认可的容器技术服务器资源共享方式，容器技术可以在按需构建容器技术操作系统实例的过程当中为系统管理员提供极大的灵活性。 中间件层：负责应用软件在不同的技术之间共享资源，管理计算资源和网络通信，主要解决分布式环境下的数据传输，数据访问，应用调度，流程管理等。在云上，常用的业务中间件有： 缓存：华为云提供的缓存中间件主要为分布式缓存服务（Distributed Cache Service，简称DCS），包含Redis、Memcached等。 消息中间件：华为云提供的分布式消息中间件主要包含：Kafka、RabbitMQ、RocketMQ等。 数据层：负责系统业务数据的持久化，为上层业务逻辑的实现提供数据支持，一般是各类数据库、文件系统等。 应用部署架构设计的目的是保证企业应用的性能体验、可用性和安全性，同时还要兼顾可扩展性、成本和可运维性，因此设计应用部署架构需要考虑6个要素，包括可用性、可扩展性、性能、安全、成本和可运维性，原因如下： 可用性：可用性设计的目的是确保应用系统在云上的可用性和可靠性，保证系统在面临各种异常情况下仍能保持稳定运行，保障业务连续性。 可扩展性：可扩展性设计的目的是确保应用程序能够在不同的负载下保持可用性和性能，能够基于负载进行扩展以满足这些需求，而不会导致系统崩溃或者性能下降，保障用户体验。 性能：性能设计的目的是为了确保应用在云上的部署架构能够满足用户的性能需求，包括响应时间、吞吐量、并发数等。 安全性：安全性设计的目的是确保应用程序和数据在云环境中得到充分的保护，防止恶意攻击和数据泄露等安全问题发生。 成本：成本设计的目的是为了在保证应用性能、可用性、安全性的前提下，尽可能地降低部署和运维的成本。 可运维性：可运维性设计的目的是提高系统的可维护性（包括自动化部署、监控告警、日志分析、容量规划、故障排查等），保障系统在运行时的状态可视化，故障时的快速恢复。 其中安全性、成本和可运维性这三个设计要素是全局的，在基础环境中进行统一设计，应用部署架构设计时可以直接适配使用。因此，应用部署架构设计需要重点关注的是可用性、可扩展性和性能这三个要素，下面重点介绍这三个要素的设计： 父主题： 应用架构设计

Landing Zone设计原则 华为云基于自身实践和大量Landing Zone项目的成功交付经验提炼了如下原则，您可以将其作为起点制定符合您企业所需的设计原则。 康威定律：按照康威定律，系统的技术架构反映了所属组织的架构。Landing Zone的组织单元和账号架构应该与企业的组织架构和业务架构保持一致，推荐按照企业的业务架构、地理架构和IT职能规划Landing Zone的组织单元和账号体系。 相关性原则：不需要把企业内部的完整组织架构映射到华为云上，只把那些负责管理IT系统的组织单元（如部门、分公司）和使用IT资源的用户映射到华为云上。如行政部门不管理、不查看、不操作任何云上IT资源，就不需要在华为云上创建一个对应行政部门的组织单元；如财务小张不负责IT系统的成本核算、分析和预算管理，就无需为小张在华为云上创建一个拥有财务管理权限的用户。 组织单元设计原则：需要相同控制策略（包括服务控制策略和标签策略）的账号归属到同一个组织单元下，可以在该组织单元集中施加控制策略，该策略将继承到其下的每一个子账号和下层组织单元。 运行环境隔离原则：生产环境要保持稳定、可靠和安全，而开发和测试环境更强调灵活性，所以生产环境与开发测试环境需要严格隔离。同时针对生产环境配置更严格的控制策略，针对开发测试环境配置更松的控制策略。 业务账号设计原则：针对业务部门，建议按照企业当前所定义的业务单元（如子公司、事业部、产品线、部门或项目组等）创建对应的子账号。 IT管理账号设计原则：针对IT部门，可以按照企业当前的IT职责划分不同的IT管理类子账号，如安全运营、运维监控、网络运营、数据平台等子账号。 父主题： Landing Zone设计

选择了不适合的云运营模式 在企业云化转型过程中，选择了不合适的云运营模式是一种常见的反模式。云运营模式直接影响企业在云环境中的资源管理、运营效率、安全合规和成本控制等方面。如果企业在未充分了解自身业务需求、组织结构、技术能力和战略目标的情况下，选择了不适合的云运营模式，可能会导致运营效率低下、安全合规风险加大、成本失控、管理复杂度增加等一系列问题，最终阻碍企业获取云化的业务价值。这种反模式的具体例子如下： 集中化运营模式用于快速变化的业务：如果企业业务需要快速响应市场变化，但采用了集中化运营模式，所有资源申请和变更都需要CCoE团队审批，就会导致流程缓慢，错失商机。 去中心化运营模式用于需要高度合规性的业务： 如果企业的业务系统相对成熟稳定，对安全性和合规性要求很高（例如金融行业），但该企业采用了去中心化运营模式，各个部门各自为政，就难以保证整体的安全策略一致性，增加合规风险。 赋能和协同运营模式用于资源和预算有限的小型企业： 赋能和协同运营模式需要投入较多的资源来构建和维护复杂的IT基础设施和IT治理策略，对于资源和预算有限的小型企业来说，可能过于复杂和昂贵。

CCoE团队成员不够完善 CCoE是企业内部为云化转型专门成立的中心化团队，全程负责整个云化旅程，其目标是通过提供最佳实践、指导和资源，帮助企业最大化云计算的价值，确保云化转型项目的成功实施。CCoE就像云化转型的引擎，如果CCoE团队成员不够完善，就像引擎缺少关键零件，无法高效运转，甚至可能导致转型失败。这种反模式的具体例子如下： 缺乏云架构师: 缺失专业的云架构师会导致云化转型如同无舵之舟。架构设计缺乏整体规划，系统扩展性差，难以维护，容易形成“拼凑式”的云环境，资源利用率低。技术选型不当则可能导致性能问题、成本超支和安全风险。此外，现有系统与云平台的整合也将面临挑战，难以充分利用云原生特性。最终，企业将难以发挥云平台的优势，甚至面临安全和性能瓶颈。 应用团队参与不足: 应用团队是云平台的最终用户，如果他们没有充分参与到CCoE的工作中，将会导致云平台与实际业务需求脱节。由于缺乏来自业务一线的实际输入，云化技术方案的设计可能无法满足业务场景，迁移过程也会因缺乏应用团队的配合而变得困难重重。更重要的是，应用团队的缺席会阻碍DevOps和自动化的推进，限制创新，最终导致云化转型无法带来预期的业务价值。 缺乏云治理专家：云治理专家如同云环境的“管家”，他们的缺失会导致云资源的使用缺乏管控，成本失控，安全风险增加。由于缺乏专业的治理策略和措施，企业难以满足合规性要求，面临法律风险。此外，缺乏有效的监控和管理机制，无法及时发现和解决问题，影响业务稳定性。 关于如何建立一个功能完整的CCoE团队，请参考章节 云卓越中心 。

没有搭建Landing Zone就开始启动迁移 Landing Zone是指在云平台上搭建的一套架构卓越、安全合规、易扩展的多账号运行环境，它包含了云骨干网络、IAM、合规审计、资源组织和治理策略等。未建立Landing Zone就开始进行业务系统的迁移，意味着企业在没有统一的云基础架构和治理框架的情况下，将应用和数据直接迁移到云上，好比没有打好地基就盖房子，是一种常见的反模式。它会导致一系列问题，最终延误项目进度，增加成本，甚至危及安全性。请在迁移任何业务系统之前就应该完成Landing Zone的规划和部署，关于如何规划Landing Zone，请参考章节Landing Zone设计 。

如何选择试点应用 试点应用的选择应该站在整体角度综合考虑是否满足优先试点的条件，选择试点应用时可以考虑如下因素： 上云意愿：企业推行全面上云时，不同业务部门的上云意愿是不一样的，可以优先考虑意愿度高、有充足的人力和时间、投入积极的业务。 业务重要性：根据企业现有的应用和业务，选择重要性较高，但又不影响正常运营的应用作为试点。 上云价值：选择上云的价值可量化、容易量化的应用，如降低成本、提升可用性、实现业务快速部署等，通过试点应用证明上云的价值。 实施难度：根据企业的IT部门的实施能力，选择一些实施难度较低的应用作为试点。 业务影响：考虑上云后对其它业务流程及数据流向的影响，尽量避免影响其它业务的正常运行。 安全性：考虑上云后对数据安全性及相关法律法规要求，尽量避免存在安全风险或者违反相关法律法规情况。 可测试性：企业上云要通过试点迁移尽量验证方案并识别可能存在的问题，并不断测试和优化方法来保证上云成功，因此，要选择可测试性强的应用，能够充分验证方案，为后续规模上云铺路。 父主题： 上云试点

组建方案设计团队 在企业推进上云方案设计的过程中，构建一个高效且专业的方案设计团队是确保项目成功的关键。该团队将负责设计全面的上云方案，涵盖上云技术架构、业务架构优化、成本效益分析、安全合规等多个维度，以保障上云方案的可行性。企业可以参考前述的CCoE组织架构和角色职责，组建出一个全面且专业的上云方案设计团队，以下为必要的团队成员。 云架构师：来自IT架构部门或具备深厚云技术背景的专家，负责设计云上技术架构，包括选择合适的云服务（IaaS、PaaS、SaaS），基于四架构六要素设计云上目标架构，确保技术选型合理、资源配置最优，并为各项技术决策提供咨询。 数据架构师：由IT主管指派，来自IT部门的大数据团队，负责设计企业在云上的数据架构，包括数据存储、数据处理、数据集成和数据治理。 应用架构师：由业务主管指派，来自业务部门的应用团队，负责设计和管理业务系统在云上的应用架构，包括应用的架构模式、技术选型、部署方式等，确保应用的性能、可扩展性、安全性和可靠性。 业务专家：由业务主管指派，来自业务部门，深入了解当前业务流程，确保方案设计能满足实际业务需求，推动业务价值的实现，提升运营效率和用户体验。 财务专家：由财务主管指派，来自财务部门或具备财务分析能力的专业人士，负责全面评估上云方案的成本结构，包括初期投资、运营成本、潜在节省及长期收益预测。通过量化分析，为决策提供成本效益比、ROI（投资回报率）等关键财务指标。 云安全 专家：来自信息安全部门或具有安全合规认证的专业人士，负责评估云服务商的安全合规性，设计数据保护策略，确保上云方案符合行业安全标准、法律法规要求，有效防范安全风险。 项目经理：来自项目管理办公室（PMO）或具备丰富项目管理经验的个人，负责整个上云方案设计项目的规划、执行、监控和收尾工作。确保项目按时、按质、按预算完成，协调跨部门资源，促进团队协作与沟通。 云服务商顾问：来自选定的云服务商或专业服务公司，提供基于最佳实践的上云方案建议，协助企业量身定制上云方案，包括技术实施细节、最佳实践分享等。 方案设计团队的组建模式同样分为两种场景，在企业自主主导上云方案设计的场景下，上述角色主要由企业内部人员担任，云服务商提供咨询和技术支持；若企业选择购买第三方专业服务进行上云方案设计，则由第三方团队主导，企业提供必要的业务需求和技术信息，企业团队需与第三方紧密合作，确保方案设计符合企业的业务需求，双方紧密合作，共同推进方案设计。 父主题： 方案设计

制定6R策略 6R策略是指将现有的应用程序和数据迁移到云端的六种不同方式，如下图所示。 图1 6R策略 以下是6R策略的含义和适用场景。 表1 6R策略的含义和适用场景 策略 含义 适用场景 Retire 停止使用应用程序或其组件，因为它不再需要或有更合适的替代方案。这并非严格意义上的“迁移”，而是对现有应用的淘汰。 应用程序不再被业务使用。 应用程序的功能已被其他系统取代。 维护应用程序的成本过高，且其业务价值低。 应用程序的技术过时，难以维护和升级。 Retain 将应用程序保持在当前状态，不进行迁移。这通常是针对短期策略或正在进行更广泛的IT战略规划时的临时措施。 应用程序依赖于特定硬件或软件，无法轻松迁移。 应用程序迁移的风险过高，且短期内没有迫切的迁移需求。 Rehost 也称为“直接迁移”或“Lift and Shift”，将应用程序原封不动地从本地数据中心迁移到云平台。通常使用工具将虚拟机或物理服务器转换为云中的虚拟机。 快速迁移到云平台，以降低成本或提高可用性。 需要快速完成迁移，时间紧迫。 缺乏应用程序的深入了解或修改代码的资源。 Replatform 在迁移过程中对应用程序进行少量修改，以适应云平台。例如，将应用程序从使用本地数据库迁移到使用云数据库服务。这通常不涉及修改核心应用程序代码。 希望利用云平台的PaaS服务，例如数据库、消息队列等，以减轻自建数据库和消息队列的运维压力。 需要提高应用程序的性能或可扩展性。 不需要进行大规模代码修改，但希望优化应用程序在云平台上的运行。 Rearchitect 对应用程序代码进行重写或重构，以更好地适应云原生架构。例如，将单体应用程序重构为微服务架构，或者采用Serverless和事件驱动架构。 需要显著提高应用程序的性能、可扩展性和可维护性。 希望充分利用云原生技术，例如容器化、无服务器计算等。 应用程序架构过时，难以维护和扩展。 Replace 使用全新的应用程序或服务替换现有的应用程序。这通常涉及购买 SaaS 产品或其他新应用软件。 现有的应用程序无法满足业务需求。 维护现有应用程序的成本过高，且有更合适的替代方案。 市面上有成熟的 SaaS 产品可以满足业务需求。 希望快速部署新的功能和服务。 在6R策略中，真正涉及迁移到云的策略只有Rehost、Replatform和Rearchitect，这三种策略的对比情况如下表所示，企业可以根据业务需求和实际的应用场景，并综合比较每种策略的迁移风险、周期、成本、难度和业务收益选择最合适的迁移策略。 表2 迁移策略对比 迁移策略 迁移风险 迁移周期 迁移成本 迁移难度 业务收益 Rehost 低 短 低 小 低 Replatform 中 中 中 中 中 Rearchitect 高 长 高 大 高 父主题： 方案设计

应用迁移上云简介 应用上云迁移是指将应用的接入层、应用层、中间件层和数据层迁移到云端的过程，迁移策略采用Rehost或Replatform，不含Refactor（应用改造），数据层包含对象存储、块存储、文件存储、关系型数据库、非关系型数据库。 应用上云迁移遵循如下的流程： 图1 应用迁移小循环 上述流程的执行对象是应用迁移分组，一个迁移批次通常包含一个或多个应用迁移分组，需要重复执行上述流程，才能将一个迁移批次的所有应用迁移到云端，如下图： 图2 分批迁移流程 用小循环的每个阶段概述如下： 调研：对应用的技术架构进行详细的调研，详细到具体的技术组件和版本信息。 设计：深度调研结果，给出云上的技术架构和规格选型，输出详细的迁移方案和切换方案。 部署：创建云上资源，上云适配改造（如涉及），并做目标环境测试。 迁移：将源端应用和数据迁移到云上目标环境。 验证：进行数据和业务验证。 切换：进行切换演练，刷新Runbook，实施正式切换。 保障：业务切换后进行一段时间的实时监控和特别运维保障。

功能介绍 HBase通过ConnectionFactory.createConnection(configuration)方法创建Connection对象。传递的参数为上一步创建的Configuration。 Connection封装了底层与各实际服务器的连接以及与ZooKeeper的连接。Connection通过ConnectionFactory类实例化。创建Connection是重量级操作，而且Connection是线程安全的，因此，多个客户端线程可以共享一个Connection。 典型的用法，一个客户端程序共享一个单独的Connection，每一个线程获取自己的Admin或Table实例，然后调用Admin对象或Table对象提供的操作接口。不建议缓存或者池化Table、Admin。Connection的生命周期由调用者维护，调用者通过调用close()，释放资源。 建议业务代码连接同一个CloudTable集群时，多线程创建并复用同一个Connection，不必每个线程都创建各自Connection。Connection是连接CloudTable集群的连接器，创建过多连接会加重Zookeeper负载，并损耗业务读写性能。

代码样例 以下代码片段是创建Connection对象的示例： private TableName tableName = null;private Connection conn = null;public HBaseSample(Configuration conf) throws IOException { this.tableName = TableName.valueOf("hbase_sample_table"); this.conn = ConnectionFactory.createConnection(conf);}

场景说明 假定用户开发一个应用程序，用于实时记录和查询城市的气象信息，记录数据如下表： 表1 原始数据 城市 区域 时间 温度 湿度 Shenzhen Longgang 2017/7/1 00:00:00 28 54 Shenzhen Longgang 2017/7/1 01:00:00 27 53 Shenzhen Longgang 2017/7/1 02:00:00 27 52 Shenzhen Longgang 2017/7/1 03:00:00 27 51 Shenzhen Longgang 2017/7/1 04:00:00 27 50 Shenzhen Longgang 2017/7/1 05:00:00 27 49 Shenzhen Longgang 2017/7/1 06:00:00 27 48 Shenzhen Longgang 2017/7/1 07:00:00 27 46 Shenzhen Longgang 2017/7/1 08:00:00 29 46 Shenzhen Longgang 2017/7/1 09:00:00 30 48 Shenzhen Longgang 2017/7/1 10:00:00 32 48 Shenzhen Longgang 2017/7/1 11:00:00 32 49 Shenzhen Longgang 2017/7/1 12:00:00 33 49 Shenzhen Longgang 2017/7/1 13:00:00 33 50 Shenzhen Longgang 2017/7/1 14:00:00 32 50 Shenzhen Longgang 2017/7/1 15:00:00 32 50 Shenzhen Longgang 2017/7/1 16:00:00 31 51 Shenzhen Longgang 2017/7/1 17:00:00 30 51 Shenzhen Longgang 2017/7/1 18:00:00 30 51 Shenzhen Longgang 2017/7/1 19:00:00 29 51 Shenzhen Longgang 2017/7/1 20:00:00 29 52 Shenzhen Longgang 2017/7/1 21:00:00 29 53 Shenzhen Longgang 2017/7/1 22:00:00 28 54 Shenzhen Longgang 2017/7/1 23:00:00 28 54 Shenzhen Longgang 2017/7/2 00:00:00 28 54 Shenzhen Longgang 2017/7/2 01:00:00 27 53 Shenzhen Longgang 2017/7/2 02:00:00 27 52 Shenzhen Longgang 2017/7/2 03:00:00 27 51 Shenzhen Longgang 2017/7/2 04:00:00 27 50 Shenzhen Longgang 2017/7/2 05:00:00 27 49 Shenzhen Longgang 2017/7/2 06:00:00 27 48 Shenzhen Longgang 2017/7/2 07:00:00 27 46 Shenzhen Longgang 2017/7/2 08:00:00 29 46 Shenzhen Longgang 2017/7/2 09:00:00 30 48 Shenzhen Longgang 2017/7/2 10:00:00 32 48 Shenzhen Longgang 2017/7/2 11:00:00 32 49 Shenzhen Longgang 2017/7/2 12:00:00 33 49 Shenzhen Longgang 2017/7/2 13:00:00 33 50 Shenzhen Longgang 2017/7/2 14:00:00 32 50 Shenzhen Longgang 2017/7/2 15:00:00 32 50 Shenzhen Longgang 2017/7/2 16:00:00 31 51 Shenzhen Longgang 2017/7/2 17:00:00 30 51 Shenzhen Longgang 2017/7/2 18:00:00 30 51 Shenzhen Longgang 2017/7/2 19:00:00 29 51 Shenzhen Longgang 2017/7/2 20:00:00 29 52 Shenzhen Longgang 2017/7/2 21:00:00 29 53 Shenzhen Longgang 2017/7/2 22:00:00 28 54 Shenzhen Longgang 2017/7/2 23:00:00 28 54

场景说明 假定用户开发一个网站系统，test_tbl用于实时用户访问网站的记录，记录数据如下表： 表1 原始数据 timestamp type error_code error_msg op_id op_time 2024-03-26 10:36:00 1 404 Resource Not Found 998756 2024-03-26 11:36:00 2024-03-26 10:35:00 1 404 Resource Not Found 998756 2024-03-26 11:35:00 2024-03-26 10:33:00 1 404 Resource Not Found 998756 2024-03-26 11:33:00 2024-03-27 09:10:00 1 200 ok 998756 2024-03-27 10:10:00 2024-03-25 11:08:00 1 404 Resource Not Found 998756 2024-03-25 12:08:00 2024-03-12 22:35:00 1 404 Resource Not Found 998756 2024-03-12 23:35:00 2024-03-12 20:32:00 1 404 Resource Not Found 998756 2024-03-12 21:32:00 2024-03-21 14:39:00 1 404 Resource Not Found 998756 2024-03-21 15:39:00 2024-03-20 19:35:00 1 404 Resource Not Found 998756 2024-03-20 20:35:00

代码样例 public void dropTable() { LOG .info("Entering dropTable."); Admin admin = null; try { admin = conn.getAdmin(); if (admin.tableExists(tableName)) { // Disable the table before deleting it. admin.disableTable(tableName); // Delete table. admin.deleteTable(tableName);//注[1] } LOG.info("Drop table successfully."); } catch (IOException e) { LOG.error("Drop table failed " ,e); } finally { if (admin != null) { try { // Close the Admin object. admin.close(); } catch (IOException e) { LOG.error("Close admin failed " ,e); } } } LOG.info("Exiting dropTable.");}