华为云用户手册

安全架构设计简介 云安全 和传统IT安全虽然目标都是保护数据和系统安全，但在基础架构、安全责任、安全管理、合规与审计等方面存在显著差异。 在基础架构方面，传统IT安全主要针对企业自建的物理硬件和网络设施，安全措施集中于物理环境和内部网络的防护，包括部署防火墙、入侵检测系统和防病毒软件等。云安全则基于虚拟化技术和云服务商的基础设施，安全防护需要考虑虚拟化层、多租户环境下的数据隔离、API接口安全等新挑战。 在安全责任方面，传统IT环境中，企业对所有的安全层面负全责，涵盖物理硬件、网络、操作系统、应用程序和数据等。而在云环境下，采用的是安全责任共担模型。云服务商负责基础设施层面的安全，包括数据中心的物理安全、网络和虚拟化平台的安全；企业作为云服务的租户，则需要负责其在云上部署的操作系统、应用程序和数据的安全配置和管理。 在安全管理与技术实现方面，传统IT安全更多地依赖于硬件设备，安全策略的实施和更新通常需要手动完成，周期较长。云安全则借助于云服务商提供的丰富安全工具和服务，如身份与访问管理（ IAM ）、虚拟防火墙、安全组、加密服务等，支持自动化和可编程的安全管理，能够快速响应和调整安全策略，提高了安全管理的效率。 在合规与审计方面，传统IT需要企业自行确保满足相关的安全合规性，需投入大量资源进行审计和认证。云服务商通常已经通过了多项国际安全认证，企业可以借助云服务商的合规基础，但仍需对自身的应用和数据进行合规管理。 华为云对云安全整体设计和实践更侧重于为您提供完善的、多维度的、按需定制和组合的各种安全和隐私保护功能和配置，涵盖基础设施、平台、应用及数据安全等各个层面。同时，不同的云安全服务又进一步为您提供了各类可自主配置的高级安全选项。这些云安全服务需要通过深度嵌入各层云服务的安全特性、安全配置和安全管控来实现，并通过可整合多点汇总分析的、日趋自动化的云安全运营能力来支撑。 综上所述，云安全与传统IT安全的关注点和实现方式存在显著的区别。企业在云化转型的过程中，需要重新审视和调整原有的安全策略和安全架构，充分利用云服务商提供的云原生安全能力，适应云环境下的安全管理模式，保障业务和数据的安全。 父主题： 安全架构设计

整体架构设计 华为云基于自身实践和大量Landing Zone项目的成功交付经验总结了如下图所示的Landing Zone解决方案整体参考架构，涵盖组织与账号管理、身份权限管理、集中网络管理、共享服务管理、统一安全管理、统一合规审计、统一运维管理、统一财务管理和数据边界总共9个领域。 图1 Landing Zone解决方案参考架构 这九大领域的实施需要在特定的账号内完成，比如组织与账号管理是在主账号（管理账号）中完成，而集中网络管理主要是在网络运营账号中完成。下表是九大领域对应的主要账号。 表1 九大领域对应的主要账号 九大领域 对应的主要账号 组织与账号管理 主账号（管理账号） 身份与权限管理 主账号（管理账号） 集中网络管理 网络运营账号 共享服务管理 公共服务账号 统一安全管理 安全运营账号 统一合规审计 安全运营账号、日志账号 统一运维管理 运维监控账号 统一财务管理 主账号（管理账号） 数据边界 主账号（管理账号）、沙箱账号（用于测试各种控制策略） 组织与账号的设计方案在前面已经详细阐述了，后面将分别展开介绍其他8个领域的设计方案。 父主题： Landing Zone参考架构

去中心化运营模式 去中心化运营模式是常见运营模式中最简单的一种，如下图所示。在这种运营模式中，所有业务系统都由专门的应用团队独立运营，应用团队不仅负责应用的设计、开发、测试、部署和运维工作，还需要负责业务系统所需IaaS和PaaS资源的部署和运维，同时要确保业务系统的安全性和云资源的成本管理。中心IT团队仅负责制定统一IT标准和IT流程，通过发文的方式让各个业务系统采纳，并监管业务系统的执行情况，但没有办法强制业务系统执行这些标准和流程。在这个运营模式下，基本上不需要专门成立CCoE团队。 图1 去中心化运营模式 去中心化运营模式的优点如下： 敏捷性高：各业务单元根据自身需求快速部署和扩展资源，加快创新速度。 贴近业务：应用团队更了解业务需求，可以更好地定制云解决方案。 责任明确：各业务单元对自己的云环境负责，更容易追溯问题和优化性能。 去中心化运营模式的缺点如下： 缺乏一致性：各业务单元独立部署和运维所需的云环境，缺乏统一的IT标准和安全策略，可能导致标准不统一，安全策略不一致，增加管理难度。 成本增加：缺乏中央协调，容易导致重复建设和资源浪费，进而增加云成本。 缺乏整体视图：难以获得企业整体的云资源使用情况，阻碍战略决策和优化。 基于上述优缺点分析，去中心化运营模式适合那些需要完全控制云资源创建和运维的创新业务系统，这些创新业务系统需要紧贴业务需求进行快速创新和迭代。 父主题： 云运营模式

什么是平台工程 平台工程（Platform Engineering）是一种通过构建和运营自助式内部开发平台（IDP，Internal Developer Platform）来优化软件交付和生命周期管理的工程学科。其目标是通过标准化和自动化的方式，减少开发人员与底层基础设施之间的复杂交互，从而提高开发效率和交付速度。Gartner在2023年和2024年连续将其列为十大重要战略技术趋势，并预测到2026年将有80%的大型软件工程组织将建立平台团队为开发者提供可重用的服务、组件和工具。平台工程对企业带来的价值如下： 提升开发者体验: 平台工程提供自助服务功能，简化了基础设施配置、应用部署和管理等流程，让开发者更专注于业务逻辑的开发，而不是底层基础设施的管理。 加速软件交付: 通过提供预先配置好的环境、自动化流程和可重用的组件，平台工程可以显著缩短软件交付周期，更快地将产品推向市场。 提高运营效率: 平台工程通过自动化和标准化，减少了手动操作和人为错误，提高了运营效率，并降低了运营成本。 增强安全性合规性: 平台工程可以内置安全策略和合规性检查，确保应用和基础设施符合安全标准和法规要求。 促进创新: 平台工程为开发者提供了更灵活、更便捷的开发环境，鼓励他们尝试新技术和新方法，从而促进创新。 父主题： 平台工程

概述 上云调研不是一次完成的，而是持续整个上云过程，需要进行多次调研，持续迭代，每个阶段调研的信息都不同。本章主要介绍调研分析的思路和方法，在上云的每个阶段都可以参考此方法进行调研。如果上云工作不是企业自己主导，企业也可以基于此调研思路更好地配合第三方进行高效调研。但注意，同一阶段，能合并调研的要尽量合并调研，减少调研次数，尤其是访谈次数。 基础环境的调研：是在云上架构设计之前进行的，包括整体IT技术架构以及IT治理现状和需求。 应用的调研：持续整个上云过程，在评估规划阶段只需要调研业务全景图，而在迁移试点和大规模上云阶段，则需要打开到每个应用系统的详细技术架构，收集每个应用系统的技术组件的详细信息，如组件版本信息，组件相关配置参数等。 大数据调研：先调研大数据的整体技术架构，然后逐步打开调研详细的信息。 每次的调研工作按照以下6步执行： 根据上云阶段，确定调研目的，梳理需要调研的信息。 对齐已有信息，避免重复调研。 对准调研目标，识别还缺哪些信息，为什么要调研这些信息，以及这些信息的获取方式。 基于企业组织架构和分工，判断能提供这些信息的干系人。 制定调研访谈提纲和调研模板，制定沟通策略和计划。 依照干系人认可的授权方式获得需要的信息，并进行信息的整理，完成调研。 图1 调研方法 调研的总体思路是先易后难，先粗后细，持续迭代，具体含义如下： 先易后难（调研的方式）：是指调研方法的难易，调研有多种方法，我们要优先选择简单快速的调研方式。 先粗后细（调研的内容）：是指调研到的信息详细程度，评估规划阶段获取的信息比较粗，实施阶段获取的信息最为详细。 持续迭代（调研的过程）：是指调研不是一次完成的，需要持续迭代，尤其在大规模迁移阶段，详细信息的调研可按迁移批次有序执行。 父主题： 调研评估

赋能和协同运营模式 赋能和协同运营模式综合了上述两种云运营模式的优点，既允许一定程度的集中化管理，也确保业务系统的敏捷性。如下图所示，在赋能和协同运营模式中，CCoE团队负责集中建设和维护Landing Zone，包含云上的骨干网、IAM和合规审计系统等，同时负责制定统一的IT标准、IT流程和IT架构，以及对企业范围内的云环境进行集中化的IT治理。CCoE团队赋能应用团队全权负责业务系统所需云资源的部署和运维，这样既可以减轻CCoE团队的负担，又可以提升应用团队的自主性，进一步提升应用系统的敏捷性。为避免各业务单元独立部署和运维云资源带来的标准不统一问题，CCoE团队需要制定相应的IT治理策略强制各个业务单元遵守相应的IT标准，CCoE团队还可以制定统一的服务目录，应用团队只能使用经过CCoE团队授权的云服务来开发和部署业务系统。 CCoE团队和应用团队要紧密协同，共同保障业务系统在云上的安全稳定运行并实现最优的成本效益。在运维方面，CCoE团队负责云上IT基础设施（包括骨干网、IAM和合规审计系统等）的日常运维，各个业务单元的应用团队负责应用及所需云资源的日常运维，业务系统出现故障后两边协同进行故障定位和修复。在安全运营方面，CCoE团队负责平台层面的安全防护和集中安全运营，各业务单元的应用团队需要关注应用层的安全防护，如防止SQL注入等；在成本管理方面，CCoE团队负责集中化的成本管理，包括集中化的成本计划、成本监控、成本分析和成本优化等，各业务单元的应用团队需要负责针对云资源打上成本标签。 图1 赋能和协同运营模式 赋能和协同运营模式兼具上述两种运营模式的优点： 平衡集中控制和敏捷性：既能保持集中化管理和控制，又能赋予业务单元一定的自主权，提升业务敏捷性。 紧密协同：CCoE团队与业务单元的应用团队紧密协同工作，避免出现问题时的互相推诿，提升整体运营效率。 成本优化：通过统一搭建公共资源、集中采购和资源整合，提升资源利用率，降低总体成本。 全局视图：CCoE团队集中监控和分析整个企业的云资源使用情况，可以进一步优化资源配置。 赋能和协同运营模式的缺点如下： 实施复杂度高：需要制定复杂的IT治理措施，强制各个业务单元执行统一的IT标准，另外还需要额外定义和管理统一的服务目录。 能力要求高： 成功实施需要组织具备成熟的管理能力和丰富的IT 治理实践，同时对CCoE团队成员的技能要求更高，需要承担布道师角色，赋能和推动应用团队按照最佳实践去部署和运维云资源。 基于上述优缺点分析，赋能和协同运营模式更适合敏态的业务系统，这些业务需要快速迭代发布新功能，以满足快速变化的市场需求，如自研的数字化营销系统。另外，如果稳态业务系统拥有IT能力较强的独立应用团队，也可以采用这种运营模式。 需要注意的是，上述三种云运营模式适合不同的业务系统和组织特征，而在一个大型企业里面，很有可能同时存在这些业务系统，所以需要混合使用这几种云运营模式来支撑这些业务系统的敏捷迭代和安全稳定运行。 云运营模式将深刻影响应用生命周期管理流程，下一个章节将会展开介绍。 父主题： 云运营模式

两地三中心高可用设计 对于业务连续性要求较高的业务，可以考虑两地三中心的高可用性方案，如下图所示。 提供最高程度的业务连续性和数据可用性，在超大规模地域级自然灾害的时候都能保护数据和业务。 RPO 时间取决于数据库复制间隔； 由于容灾站点一直运行，RTO 依赖容灾切换时间，通常取决于 DNS 缓存刷新时间，一般为分钟级，如果采用 GSLB 自动探测切换可进一步降低故障恢复时间。 图1 三AZ高可用设计 设计要点： 生产数据中心和容灾中心分别部署在华为云 2 个不同 Region。 生产中心采用双AZ部署（双活、热备），容灾中心单AZ。 在生产和容灾中心分别部署RDS数据库实例，数据库 1:1:1 主备复制。 生产和容灾中心产生的配置、日志、快照和备份等，通过 OBS 实现跨区复制。 生产站点某个AZ故障时，切换到另一个AZ，数据库主备切换。 生产站点全体故障时，切换数据库的主备状态，然后将 DNS 授权修改为容灾站点（生产站点 0%，容灾站点为 100%）。 生产站点修复后，数据库切换回主库，DNS 切换回主站点（生产站点 100%，容灾站点为 0%）。 为提高容灾中心利用率，可将只读和数据分析业务放到容灾站点。 高可用容灾能力构建是一个复杂的系统工程，涉及入口流量控制、业务层改造、中间件和数据库的控制，以及整体机制的协同，所以整个体系打造是存在一定门槛的；如果客户缺乏相关的经验，又期望快速构建高可用的容灾体系，可以考虑使用华为云提供的多云高可用服务（Multi-cloud high Availability Service 简称 MAS），它源自华为消费者业务多云应用高可用方案，提供从流量入口、应用层到数据层的端到端的业务故障切换及容灾演练能力，保障故障场景下的业务快速恢复，提升业务连续性。详见华为云MAS高可用服务。 父主题： 可用性设计

大数据集群设计 设计云上的大数据集群部署架构时，建议参考原则如下： 优先用大数据云服务：如果源端是自建的大数据集群，在目标云平台上有对应的云服务，且功能、性能、兼容性都满足，经评估改造工作量很小，建议设计大数据集群部署架构时，优先采用大数据云服务。如果目标云平台上没有对应的大数据集群组件，部署架构设计时，可以考虑继续采用自建的方案。如果目标云平台上有对应的大数据集群组件，但兼容性较差，经评估可能需要较大的改造工作量，部署架构设计时，可以考虑继续采用自建的方案。 最小改造原则：如无特别的业务驱动，要尽量避免进行大规模改造。大数据集群的组件要1：1对标设计，版本尽量一致，有版本升级需求的需要评估适配改造工作量。 弹性扩展和自动伸缩：设计云上的大数据集群时，应考虑集群的弹性扩展和自动伸缩能力。这意味着集群可以根据工作负载的需求自动增加或减少计算和存储资源，以提高性能、效率并节约成本。 容错和高可用性：云上部署的大数据集群应具备容错和高可用性，以保障系统的可靠性和稳定性。这可以通过使用多个副本、冗余节点和故障转移机制来实现，以确保在硬件或软件故障情况下的数据和任务的持久性。 数据安全和合规性：在云上部署的大数据集群需要有严格的数据安全和合规性保障。采用适当的 数据加密 、身份验证、访问控制和数据隔离措施，以保护敏感数据免受潜在的安全威胁。 成本效益：在云上部署大数据集群时，需要考虑成本效益。云服务提供商可以提供弹性的计算和存储资源，避免了对物理硬件的直接投资和维护成本。同时，通过根据需求进行资源的优化和调整，可以最小化成本，提高资源利用率。 父主题： 大数据架构设计

应用部署架构示例 下图是音频类应用的云上部署设计参考架构： 图1 应用部署架构设计示例 设计要点： 用户接入采用多线路动态BGP，实现公网访问线路的自动容错，可靠性高； 华为云ELB采用集群跨可用区高可靠部署，单数据中心机房故障对业务无影响； 应用接入层采用跨可用区集群部署，单可用区的故障不会影响到全局业务； 业务容器POD多副本均衡的跨AZ部署，通过华为云CCE容器引擎的调度策略实现，从而确保业务负载跨数据中心高可靠； D CS Redis跨AZ主备部署，确保跨可用区的高可靠；DMS Kafka构建跨双可用区或三可用区集群，确保消息的高可靠； CSS 云搜索引擎服务可以跨AZ集群部署，单AZ的故障不影响业务运行； RDS for MySQL采用主备部署方式，主备实例之间的数据实时同步，如果主实例出现故障，备实例可以快速升为主实例； Redis、Kafka、CSS 云搜索 、RDS for MySQL都支持把数据备份到OBS桶，应对数据误操作之后的风险； 云主机/云硬盘可通过CBR云备份服务实现整个云主机或者云硬盘的备份。 父主题： 应用部署参考架构

组建实施团队 在企业上云的实施阶段，组建一支高效且专业的实施团队是确保项目成功的关键。该团队将负责执行上云计划和具体的上云实施工作，保障各项上云任务的顺利进行。上云实施团队应由来自不同领域的专业人员组成，企业可以参考前述的CCoE组织架构和角色职责，组建出一个全面且专业的上云实施团队，以下为必要的团队成员。 项目经理：来自项目管理办公室（PMO）或具备丰富项目管理经验的IT部门成员，负责整个上云实施的项目管理，确保项目实施按计划进行，同时协调资源解决实施过程中的问题。 迁移实施工程师：来自IT部门或具备云迁移经验的IT专业人员，负责具体的迁移实施工作，包括数据迁移、应用迁移、系统配置、业务割接等，确保迁移过程的数据一致性、安全性和性能。迁移实施工作属于一次性工作，经常会外包给云服务商或者云实施专业服务提供商。 云架构师：来自IT架构部门或具备深厚云技术背景的专家，负责云上架构的部署和优化，为实施团队提供技术支持和指导。 云基础设施管理员：来自IT部门的运维团队，负责管理云基础设施，建立和实施云运维流程，以支持云环境的管理、监控和优化。 云安全专家：来自信息安全部门或具有安全合规认证的专业人士，专注于云安全和合规，确保上云过程中遵循行业规范、法律法规和企业内部管理要求，同时制定和实施安全策略，识别潜在风险并提出相应的解决方案。 应用开发工程师：来自业务部门的应用团队，负责业务上云的适配改造和应用现代化改造，确保应用能够在云环境中高效、稳定、安全运行。 应用测试工程师：来自测试团队，负责业务的功能、性能、可用性、可扩展性测试，配合迁移切换演练和正式的上云切换操作。 父主题： 采用实施

调研方式 调研方法有很多，企业要结合自身的实际情况，从调研的效率、调研获取信息的完整度和真实度三个方面评估，选择最合适的调研方式。通常情况下，优先推荐CMDB调研法，CMDB中缺少的信息再通过云管平台或调研访谈的方式补齐。 如下是常见的调研方式，建议企业遵循由易到难的调研思路进行调研。有些服务商可能会提供大量的调研表格让企业反馈，这是低效的、易错的，若企业有类似CMDB等信息化系统，建议优先通过CMDB等信息化系统支持调研。为了安全起见，企业可以提供只读账号让调研人员自行登录CMDB获取信息或者企业直接导出相关信息给调研人员。 表1 不同调研方式的适用场景 序号 调用方式 适用场景 优势 不足 1 现网CMDB平台 客户有CMDB平台，且包含应用调用模块 所见即可得，高效，可直接获取详细资源清单、数据层-数据层、数据层-应用层关联关系 1.有些传统的CMDB系统信息更新不及时 2 现网云管平台 客户有CMP或虚拟化管理平台 能够获取准确的资源详情 无法获取应用架构、关联关系等信息 3 现有文档 客户有比较完整的设备档案，包括设计文档，实施方案等。 可快速获取现网信息 文档的及时性和完整性无法保证 4 安装工具（RDA\第三方） 客户同意安装工具agent 可较快获取详细资源清单 1.需要客户现网环境安装agent，较敏感； 2.针对数据库、中间件等获取信息较少，且无法获取应用调用关系。 5 调研访谈 客户人力和时间充足，且愿意配合 客户业务团队对资源清单及应用调用关系负责 1.调研周期不可控； 2.调研信息准确性及完整性不可控 不同的调研方式获取信息的效率、完整度和真实度是有区别的，总体来说，CMDB法是最高效的调研方式。 表2 不同调研方式的综合对比 调研渠道 应用架构调研 技术架构调研 方法评估 业务 全景 业务域 业务 系统 应用系统模块 应用关联关系 技术 架构 （整体） 技术架构 （按业务域打开） 技术架构 （按业务系统打开） 技术架构（按应用系统模块打开） 技术架构（技术组件详情） 效率 完整度 真实度 现网CMDB √ 需整理 √ 需整理 √ √ √ √ 需整理 √ 需整理 √ 需整理 √ √ 高 高 中高或高 现网云管平台 - - - - - - - - - √ 高 低 高 现有知识库 √ 可能有 √ 可能有 √ 可能有 √ 可能有 √ 可能有 √ 可能有 √ 可能有 √ 可能有 √ 可能有 √ 可能有 高 低中高 都有可能 低中高 都有可能 RDA工具收集 - - - - - - - - - √ 中 低 高 调研&访谈 √ √ √ √ √ √ √ √ √ √ 低 高 中高 父主题： 调研评估

云实施团队 云实施团队负责将企业内各个业务系统迁移或者直接部署到云上，这要求对企业现有的IT基础设施和业务系统进行详细的调研和评估，设计并实施技术方案。技术方案的设计由云架构团队负责，交给云实施团队负责方案实施，云实施团队通常包含调研评估工程师、迁移实施工程师，职责和技能要求如下表所示。需要注意的是，这两个角色所负责的工作不是持续性的，业务系统全部上云之后也就不再需要了，所以这两个角色可以由IT部门内具备相关技能的工程师临时承担，或者外包给云迁移实施的专业服务提供商。 表1 云实施团队的角色和职责 角色 职责 技能要求 来源 调研评估工程师 现状调研：对企业现有的IT基础设施、业务系统、应用架构、数据存储、安全策略等进行全面的调研和文档记录，包括硬件配置、软件版本、依赖关系、性能指标、安全漏洞等。 需求分析：业务部门沟通，了解其对云化转型的需求和期望，例如性能提升、成本优化、灾备恢复等，并将这些需求转化为具体的技术指标。 可行性评估： 评估将现有系统迁移到云平台的可行性，包括技术可行性、成本效益、风险评估等。 容量规划：根据业务需求和未来发展趋势，对云资源进行容量规划，例如计算资源、存储资源、网络带宽等。 成本估算：根据云服务商的 定价 模型，估算迁移到云平台的成本，并与传统IT架构的成本进行比较，为决策提供依据。 熟悉主流的云平台及云服务。 具备扎实的IT基础设施知识，包括服务器、网络、存储、数据库、中间件等。 熟悉各种操作系统和应用软件。 了解不同的迁移策略和方法。 具备一定的IT基础设施和业务系统的调研和评估经验。 具备良好的沟通和团队协作能力。 IT部门或者外包给云实施专业服务提供商 迁移实施工程师 迁移方案实施：根据架构师设计的技术方案和调研评估工程师提供的报告，具体实施业务系统的迁移和部署工作，包括环境搭建、数据迁移、应用部署、配置调整等。 测试和验证：对上云后的系统进行全面的测试和验证，确保系统功能正常、性能稳定和安全可靠。 故障排除：及时处理实施过程中出现的各种问题和故障，确保实施工作的顺利进行。 精通主流的云平台及云服务，并具备相关的认证资质。 熟悉各种迁移工具和技术，例如数据迁移工具、容器化技术、自动化部署工具等。 熟悉各种操作系统和应用软件。 具备扎实的脚本编写能力（例如Shell、Python等），能够实现自动化操作。 具备良好的沟通和团队协作能力。 IT部门或者外包给云实施专业服务提供商 父主题： 云卓越中心

接入层迁移方案 接入层为应用的外部访问提供了访问入口，常见的接入层技术4种，分别是Nginx/Openresty、硬件或软件负载均衡器，微服务网关Kong/Zuul、DNS。通常采用重新配置的方式进行迁移，具体如下： 表1 接入层迁移方式 技术组件 功能说明 迁移方式 nginx/openresty 使用nginx或openresty做流量转发 方案1：使用 SMS 主机迁移工具将nginx或openresty服务运行的服务器迁移到华为云，并修改对应的转发策略。 方案2：在华为云ECS服务上重新部署nginx或openresty，然后拷贝源端配置文件到目的端，并修改配置文件的转发策略。 负载均衡器 提供4层或7层流量转发 将源端的负载均衡策略重新配置到华为ELB Kong/Zuul网关等 微服务网关 方案1：使用SMS 主机迁移 工具将Kong/Zuul网关服务运行的服务器迁移到华为云。 方案2：在华为云ECS重新部署Kong/Zuul网关，然后拷贝源端配置文件到华为云ECS，并修改转发策略 DNS 域名 解析 解析应用的内外部域名 方案1：使用华为云平台的DNS服务替代源端的DNS，并重新配置DNS解析地址。 方案2：在华为云的ECS上部署DNS服务，并重新配置DNS解析地址。 方案3：使用SMS工具将源端DNS服务器迁移到华为云并修改DNS配置。 父主题： 设计迁移方案

制定云化转型战略 在识别驱动力、评估云化成熟度、制定云化目标和分析云化收益之后，您需要正式制定云化转型战略。制定云化转型战略通常包含以下步骤：设计云化转型的愿景、明确具体的云化目标、与干系人对齐目标、邀请高层正式发布战略，以及在组织范围内进行战略宣贯。关键在于确保与所有干系人进行充分的沟通，以在组织内部达成一致意见。这个过程可能需要经过多轮的讨论、平衡和修正，才能最终形成一致的战略方向。 设计云化转型的愿景 首先是设计云化转型的愿景。愿景是组织对未来的期望和蓝图，是全体员工共同努力的方向。在制定愿景时，需要结合组织的使命、价值观以及对行业发展的洞察。愿景应该具有前瞻性、鼓舞性和指导性。例如，一个有力的愿景可以是：“通过云化转型，我们将构建一个灵活、高效、安全的数字化平台，赋能业务创新，提升客户体验，最终成为行业领先的智能化企业。”这个愿景明确了云化转型的目标——构建数字化平台，强调了灵活性、高效性和安全性，突出了赋能业务创新和提升客户体验，最后指向成为行业领导者的愿景。这种清晰而有感染力的愿景能够激励员工，为他们提供清晰的奋斗目标。在制定愿景的过程中，领导团队需要深入思考组织的核心竞争力，以及云化转型将如何增强这些竞争力。同时，还需要考虑行业趋势、技术发展和客户需求，确保愿景的现实性和可行性。 明确具体的云化目标 接下来，明确具体的云化目标是将愿景转化为可执行行动的关键一步。云化目标应该符合SMART原则，并且与组织的业务战略保持一致。例如，可以制定如“在两年内，将IT基础设施运营成本降低15%”或“在一年内，实现业务系统的弹性扩展能力，提高资源利用率30%”等目标。这些目标都有明确的衡量标准，便于后续的跟踪和评估。详细内容参考制定云化目标 。 与干系人对齐目标 云化转型需要得到高层领导和各个干系人的支持和认同，因此需要与他们进行深入的沟通，确保云化转型的目标与各个干系人的目标一致。在这一步，组织可以召开高层战略会议，邀请CEO、CIO、各业务部门负责人以及关键的干系人参与。在会议上，详细介绍云化转型的愿景和业务目标，讨论转型对各部门的影响和预期收益。例如，IT部门可能关心技术架构的变化，而业务部门则关注云化如何支持业务增长。通过这样的沟通，可以使各方了解云化转型的重要性，认同其价值，并提出他们的建议和意见。在这个过程中，组织需要倾听干系人的关切，及时回应他们的问题，调整策略以适应实际情况。这种对齐过程有助于减少转型阻力，确保各部门协同合作。 邀请高层正式发布战略 在与干系人对齐目标之后，组织需要正式将云化转型战略公之于众。这一举措不仅可以展示高层对云化转型的重视程度，还能够提高全体员工对战略的理解和认同。组织可以策划一次全员大会或线上直播活动，由CEO或其他高层领导正式发布云化转型战略。在发布会上，高层领导可以阐述云化转型的愿景和业务目标，分享他们对未来的期待，并表达对员工的期望。例如，CEO可以说：“云化转型是我们迈向数字化未来的重要一步，它将赋能我们的业务创新，提升客户体验。我相信，在大家的共同努力下，我们一定能够实现这个目标。”这种正式的发布能够增强战略的权威性，激发员工的参与热情。 战略宣贯 在组织范围内进行战略宣贯是确保云化转型战略深入人心的关键步骤。战略宣贯需要针对不同层级、不同部门的员工，采用多种方式进行。组织可以开展一系列宣讲会、培训课程，制作宣传手册、视频等，详细讲解云化转型的意义、目标和具体举措。例如，组织可以在内部网站开设云化转型专栏，定期发布相关信息和进展。同时，各部门负责人应当积极向团队成员传达战略内容，结合部门实际情况，解释云化转型将如何影响他们的工作，以及他们可以做出哪些贡献。通过这些努力，组织能够增强员工对战略的理解和认同，形成全员参与的良好氛围。 综上所述，制定组织的云化转型战略是一个系统性、全面性的过程。通过制定清晰鼓舞的愿景，明确具体的业务目标，与干系人对齐目标，邀请高层正式发布战略，并在组织范围内进行深入的战略宣贯，组织能够为云化转型奠定坚实的基础。面对数字化时代的机遇和挑战，组织需要以战略性的眼光，积极拥抱云计算技术，走在行业的前列。 父主题： 制定战略

多云战略的驱动力 当前多云战略正在成为一种主流趋势，越来越多的组织选择将业务系统部署在多个云服务商的云平台上，而不是依赖单一的云服务商。这种趋势的背后是多种因素的驱动，以下是一些主要的驱动力： 避免单云故障：将业务部署在单一云平台上存在单点故障风险。如果该云平台出现故障，例如大规模宕机或区域性灾难，企业的业务将受到严重影响。多云战略可以通过将业务系统部署在多个独立的云平台上，实现跨云容灾，避免单一云平台故障带来的业务中断。即使一个云平台出现问题，其他云平台上的业务仍然可以正常运行，保障业务连续性。 避免厂商锁定：将所有业务都放在一个云服务商的云平台里会造成厂商锁定，使企业在未来的谈判中处于劣势，并且难以迁移到其他平台。多云战略可以避免这种情况，保持企业在选择云服务商方面的灵活性。 降本增效：多云战略可以引入竞争机制，通过与多个云服务商合作，企业可以根据自身需求选择最合适的云服务，并利用云服务商之间的竞争来降低成本。此外，不同的云服务商在不同区域或服务上的定价策略可能存在差异，多云战略可以帮助企业优化资源配置，提高成本效益。 充分利用不同厂商的优势能力：不同的云服务商在技术、服务和功能方面各有优势。例如，某个云服务商可能在人工智能和机器学习方面拥有更强的技术实力，而另一个云服务商可能在数据库服务方面更具优势。多云战略允许企业根据自身业务需求，选择最合适的云服务商及其优势服务，从而最大化地发挥云计算的价值。 合规遵从：某些国家和地区有特定的数据存储和处理的法规要求，但每家云服务商的全球布局和合规遵从程度不一样。多云战略可以帮助企业选择最合适的云服务商来满足这些法规要求，例如将敏感数据存储在特定地区的云平台上。 多云战略的采用是为了提高业务连续性、成本效益和安全性。虽然多云战略也带来了管理复杂性等挑战，但随着云管理工具和技术的不断发展，这些挑战正在逐渐得到解决。 父主题： 识别云化驱动力

Runbook设计原则 Runbook是上云迁移过程中一个非常重要的文档，用于指导切换当天多人协同进行切换操作，规定了业务切换的流程和详细步骤。Runbook主要包括两部分，Runbook checklist和Runbook操作步骤，下面将从几个方面详细介绍如何设计切换Runbook。 Runbook设计原则如下： 一个Runbook对应一次切换操作。 Runbook要详细描述切换步骤、操作人、确认人，并预估开始时间、结束时间、执行时长。 Runbook执行步骤要尽量细化，确保每个执行步骤对应1个操作人和1个确认人，尽量避免发生1个步骤多个人确认的场景。 Runbook要细化到每个执行命令，尽量脚本化或工具化，操作人直接执行即可，不需要现场临时定制，避免出现人为事故。 Runbook步骤中有并行操作和串行操作，要标记好串并行顺序，避免人为操作不当影响切换时长和切换结果。 Runbook的每个切换操作都可能会执行失败，要提前分析每个步骤发生执行失败时的决策项，细分失败场景，决策是回退还是继续进行，防止切换当天决策组讨论时间较长，无法决策的情况发生。 回退决策点设计原则如下： 每个切换阶段设计最晚的执行完时间，超时需要决策是否进行回退。 核心表数据比对结果不一致，需要决策是否回退。 核心的P0测试用不通过，需要决策是否回退。 性能验证不达预期，需要决策是否回退。 父主题： 设计Runbook

中间件层迁移方案 当前企业业务中使用比较多的中间件类型为缓存中间件和消息中间件。中间件作为数据存储的临时场所，数据一般不用迁移，但在切换时，为了确保源端和目的端数据的一致性，需要等中间件消息队列中的消息完成消费后再切换。如果中间件缓存数据是持久化的，即作为数据库使用，此场景需要进行数据的迁移。所以中间件的迁移方案需结合业务使用情况进行具体分析，下面将详细介绍各类中间件的迁移方案。 Redis迁移方案 确定Redis使用场景 Redis使用场景主要有2种，将Redis用作缓存或者将Redis用作数据库。不同使用场景的Redis迁移方案不同，详见下表所示。 表1 Redis迁移场景 Redis使用场景 迁移方式 Redis实例中的数据用作缓存 业务切换时，为防止Redis后端的数据库被击穿，可基于数据库性能判断使用哪种迁移方案： 方案1：不迁移，将Redis缓冲数据提前预热 方案2：使用Redis迁移方案迁移缓冲数据 Redis实例中的数据是持久化的，作为数据库使用 使用Redis迁移方案迁移持久化数据 Redis迁移方案 表2 Redis迁移方案 迁移方案 迁移方式 特点 适用场景 DCS迁移工具（推荐） 全量+增量迁移 源端业务停机时间短、操作简单、支持在线实时同步增量 适用于源端是自建Redis或其他云厂家Redis实例迁移至华为DCS的场景 RDB/AOF文件备份恢复 全量迁移 离线迁移，操作复杂，源端业务停机时间长，需要源端业务停机后制作RDB/AOF文件，不支持增量同步数据 所有 消息中间件迁移方案 确定消息中间件的切换场景 表3 消息中间件切换场景 适用产品 切换窗口 迁移方式 Kafka RabbitMQ RocketMQ ActiveMQ 切换时间窗充足 切换时间充足，业务评估在切换时间窗口内可以完成消息消费，此时，消息中间件中的数据不需要迁移，等待消费者将消息消费完成即可 切换时间窗有限 切换时间有限，业务评估在切换时间窗口内无法完成消息消费，请参考消息中间件迁移方案进行消息迁移 消息中间件迁移方案 表4 消息中间件迁移方案 迁移方案 迁移方式 特点 适用场景 开源工具MirrorMaker 2.0 全量+增量 1.部署复杂，操作繁琐 2.支持消费队列offset偏移量的同步 所有 华为云SmratConnect工具 全量+增量 1.工具界面化，操作简单 2.支持消费队列offset偏移量的同步 适用于自建kafka或云服务迁移到华为云kafka 父主题： 设计迁移方案

全面云化的IT治理挑战 大型企业的组织结构复杂，往往拥有数十上百个业务单元（如子公司、事业部、产品线、部门或项目组等），每个业务单元负责建设1到多个应用系统。这些应用系统的全面云化转型将导致在云上同时存在数百个业务系统和海量云资源，而且包括企业自有员工、外包员工及合作伙伴的员工在内的大量用户需要访问和操作这些云资源，量变导致质变，资源闲置、误操作、恶意操作、数据泄露和权限错配等风险将随着用云规模呈现指数级增长。大型企业必须构建精益化、集中化和结构化的IT治理体系才能有效控制这些风险，最大化业务收益。CIO和CTO需要在业务系统上云之前就开始着手设计云上IT治理体系。在具体实践中经常会遇到以下各种挑战。 如何做好业务单元的安全和故障隔离，确保业务单元之间的云资源、应用和数据的隔离？ 如何减少单点故障的爆炸半径？ 企业组织架构和业务架构经常调整，云上资源如何灵活应对？ 如何设计跨多个业务单元的网络架构、建立受控的网络连接通道？ 如何统一管控多个业务单元的边界网络出入口？ 如何规划生产、开发和测试环境？ 公共资源如何在多个业务单元之间共享？ 如何统一监控、运维和管控多个业务单元的云资源？ 如何统一管控各业务单元的预算和成本？如何优化云成本？ 如何避免各业务单元过度使用云资源？ 如何将用户进行分组？又应该为用户组设置哪些权限？ 云资源、数据和应用如何满足国家、行业和企业自身的安全合规标准？ 误操作、恶意操作和权限错配在所难免，如何规避由此产生的风险？ 员工密码和密钥容易丢失或泄露，如何避免由此带来的数据泄露风险？ 在尽量保留原有IT治理模式的前提下，如何将其迁移到公有云上？ 要应对上述挑战，需要设计一套全面的云上IT治理方案和最佳实践，对业务单元、用户、权限、云资源、数据、应用、成本、安全等要素进行全面有效管理。华为云通过Landing Zone解决方案来全面应对云上IT治理的挑战。Landing Zone本身是一个航空术语，指直升飞机等飞行器可以安全着陆的区域。是指将企业业务系统安全平稳迁移到公有云的解决方案命名为Landing Zone，目的是系统性解决企业大规模上云所带来的IT治理和安全合规的挑战。 父主题： Landing Zone设计

业务适用原则 首先要根据业务场景选择适用的存储类型，重点考虑如下几个方面： 可用的访问方式：EVS盘或SFS文件系统挂载到主机后，体现为操作系统中的一个文件系统路径，上层应用可以直接访问，而OBS需要业务应用调用专用的SDK或API接口访问，需要了解业务可接受的访问方式。对于数据库类需要直接裸盘映射的应用，只能使用块存储（EVS）。 是否需要共享：EVS支持共享操作，需要在购买时勾选共享特性，并通过专用集群软件管理共享磁盘。而SFS和OBS天然支持共享，因此需要结合业务场景分析要存储的内容是否有多节点共享的诉求。 存储容量：不同的存储类型可以支持的容量不同，需要基于当前业务量和未来发展预估所需的容量级别，以便选择合适的存储类型： 表2 存储服务的最小和最大容量 存储类型 最小容量 最大容量 EVS 10GB 32TB SFS Turbo 20MB/s/TiB 3.6TB 1PB 其他 1.2TB 1PB SFS通用容量型 0 无限制 OBS 0 无限制

可靠性保障 EVS、SFS Turbo、SFS通用型、OBS均是三副本存储，数据持久性可满足业务的要求，但可靠性方面存在一定的差异： EVS、SFS Turbo的三副本均在同一个可用区，若可用区出口或机房出现故障时，会导致业务不可用。 SFS通用型、OBS支持单可用区或多可用区（当前SFS通用型还只有单可用区可选，后续逐步上线多可用区产品），对连续性要求高的业务，可选择多可用区的实例。 EVS支持通过镜像、快照、云备份功能进行数据的快速备份和恢复，SFS Turbo支持通过云备份功能进行备份和恢复，SFS通用型、OBS一般用于超大容量业务场景、暂未规划备份能力。

性能匹配 存储服务的性能指标包括传输带宽、IOPS和时延等，如下表所示，您需要根据业务系统的性能要求和特点选择最合适的存储服务及对应的规格。 另外，EVS和OBS对所存储对象的大小无限制，SFS通用容量型不适合1MB以下的海量小文件应用，SFS Turbo和后续的SFS通用性能型可支撑海量小文件应用。 表3 存储服务的性能指标 存储类型 带宽上限（GB/s） IOPS上限 平均时延级别 EVS 高IO-SAS 0.15 5K 1~3ms 通用型SSD-GPSSD 0.25 20K 1ms 超高IO-SSD 0.35 50K 1ms 通用型SSD V2-GPSSD2 1 128K 1ms 极速型SSD-ESSD 1 128K 亚毫秒级 极速型SSD V2-ESSD2 4 256K 亚毫秒级 SFS Turbo 20MB/s/TiB 20 250K 2~5ms 40MB/s/TiB 20 250K 2~5ms 125MB/s/TiB 100 百万级 1~3ms 250MB/s/TiB 100 百万级 1~3ms 500MB/s/TiB 200 百万级 1~3ms 1000MB/s/TiB 200 百万级 1~3ms SFS通用型 容量型 50 100K 7ms 性能型 200 2000K 5ms OBS TB级 千万级 10ms+

成本优化 存储类型的选择还需考虑成本因素，在满足业务性能要求的情况下降低存储成本。 满足业务性能要求的情况下，优先选择存储单价低的存储服务。 按规格计费的存储（EVS及SFS Turbo）做好业务增量预测和容量监控告警，建议预留15%~20%作为扩容阈值即可，避免初始购买的容量规格过大造成资源浪费。 按量计费的存储（SFS通用型及OBS）做好使用量规划，适当购买资源包抵扣使用量，可以进一步降低成本。 支持生命周期管理的存储（SFS通用型及OBS）做好生命周期策略规则，及时将冷数据转入低频存储，可以进一步降低成本。 对于存储容量需求较大、数据保存周期较长的业务，通过业务应用层的改造，根据不同类型存储的特点组合使用（例如组合EVS/SFS Turbo和OBS），可以在保证业务性能要求的情况下优化成本。

云项目经理 云项目经理在指导委员会的授权下，负责领导和管理整个云化转型项目，确保项目在预算内按时完成，并符合质量标准。其主要职责包括： 项目计划与目标设定: 制定云化转型的整体计划，包括项目范围、目标、时间计划、预算和验收要求等。 项目执行与进度管理: 监督项目的执行过程，确保各阶段任务按计划完成；跟踪项目进度，识别潜在问题并及时采取措施，确保项目按时交付。 预算与成本控制：监控云资源的使用和成本，确保项目在预算范围内运行；识别并实施成本优化措施，提升云化转型的经济效益。 质量管理：确保交付成果符合既定的质量标准和业务需求；组织质量评审，确保技术方案的稳定性、安全性和可扩展性。 沟通和协作: 与利益相关者（包括业务部门、IT部门、财务部门、云服务商等）进行有效沟通，确保项目信息透明，并获得各方支持。 风险管理: 识别、评估和管理项目风险，制定应急计划，并将风险最小化。 变更管理: 管理项目变更，确保变更得到适当的评估和批准，并对项目的影响最小化。 云项目经理是一个综合管理角色，不仅需要有扎实的项目管理能力，还要求具备一定的云技术知识和业务理解能力，其技能要求如下： 项目管理技能: 具备扎实的项目管理知识和经验，熟悉PMBOK项目管理方法论，能够熟练运用项目管理工具和技术。 云技术知识: 深入理解云计算的概念、架构和服务，熟悉不同的云部署模型（公有云、私有云、混合云），了解主流云平台的特点和优势。 沟通和协调能力: 优秀的沟通、协调和人际交往能力，能够有效地与不同团队和利益相关者沟通协作，具备跨部门沟通和协调能力。 问题解决能力: 能够快速识别和解决项目中出现的问题和挑战，具备分析问题、制定解决方案和推动落地的能力。 领导力: 能够领导和激励整个云化转型项目团队，确保团队高效协作，营造积极的团队氛围。 业务理解能力: 能够理解业务需求，并将业务需求转化为技术方案，确保云化转型项目能够真正为业务带来价值。 成本管理能力: 具备成本意识，能够有效地控制项目成本，并在项目生命周期中进行成本优化。 父主题： 云卓越中心

云卓越中心的演进 上述CCoE组织是针对企业大规模上云、用云和管云而建立的全功能团队，企业并不需要在云化转型早期就组建一个完整的CCoE组织。 云化转型早期主要是把第一批业务系统迁移或直接部署在云上，这个时候可以建立一个小型化CCoE组织，如下图所示，把必要的角色加入进来，足以支撑第一批业务系统的云化就可以。 我们认为在早期的小规模CCoE组织中应该包含指导委员会、云项目经理、应用架构师、应用开发工程师、应用测试工程师、云架构师、调研评估工程师、迁移实施工程师等关键角色。通过这些角色的协同努力将第一批业务系统逐步云化，快速获取业务收益，从而推动企业将更多的业务系统逐步云化。 图1 小型化CCoE组织架构 当企业云化转型的规模逐步变大，云化转型进入运维治理阶段的时候，可以将小型化的CCoE组织逐步扩大，增加更多的运维治理阶段所需的关键角色，如云基础设施管理员、云网络管理员、数据库管理员、 应用运维管理 员、云治理专家、安全运营工程师、云成本运营工程师等，逐步演进到如下全功能的CCoE组织。 图2 全功能CCoE组织架构 父主题： 云卓越中心

集中化运营模式 去中心化模式更强调的是快速创新而不是集中控制，集中化运营模式正好相反，强调的是集中控制而不是快速创新。如下图所示，在集中化运营模式中，CCoE团队负责集中建设和维护Landing Zone，包含云上的骨干网、IAM和合规审计系统等，同时对企业范围内的云环境进行集中化的IT治理。业务系统所需的云资源也由CCoE团队负责集中部署和运维，所以CCoE团队更容易识别出各个业务系统所需要的公共资源，进而集中部署和管理这些公共资源，同时也需要通过集中化的手段统一管理所有业务单元下的云资源，并进行集中的安全运营和成本管理。应用团队完全不用关心基础设施和云资源的部署和管理，可以将主要精力放在应用的设计、开发、测试、部署和运维工作上。 图1 集中化运营模式 集中化运营模式的优点如下： 集中化管理：集中化管理确保一致的安全策略、合规性和标准化流程，降低风险，相比分散管理，集中化管理还可以降低运营复杂度，提高效率。 成本优化：通过统一搭建公共资源、集中采购和资源整合，提升资源利用率，降低总体成本。 全局视图：CCoE团队集中监控和分析整个企业的云资源使用情况，可以进一步优化资源配置。 集中化运营模式的缺点如下： 缺乏敏捷性： 所有云资源请求都需要经过CCoE团队，可能导致响应速度慢，影响业务的敏捷性。 瓶颈风险： CCoE团队的工作负荷过重，无法及时满足各业务单元的需求，影响效率。 缺乏业务理解：CCoE团队可能不理解具体业务场景，导致资源配置不匹配业务需求。 难以满足多样化需求：统一的标准可能难以满足不同业务单元的特定需求。 基于上述优缺点分析，集中化运营模式适合稳态的业务系统，这些业务系统的更新频率比较低，例如企业采购的SAP等商业软件，或者企业自研的进入成熟期的业务系统。集中化运营模式也适合那些由IT部门统一建设和运维的业务系统。 父主题： 云运营模式

基础设施调研 基础环境调研的主要是企业当前的IT基础架构的现状和上云需求，包括资源信息、组网信息、安全架构、运维架构、访问权限管控、资源计量计费等。调研的方式主要是从IT系统导出（如CMDB、CMP、虚拟化管理软件），并结合问卷访谈。基础环境的调研主要是找企业的运维团队。调研人员会与企业的运维团队合作，收集与基础环境相关的数据和信息。 一种常见的调研方式是通过企业内部的IT系统导出信息，例如配置管理数据库（CMDB）、云管理平台（CMP）、虚拟化管理软件等。这些系统可以提供有关硬件设备、网络拓扑、操作系统、应用程序以及相关配置和版本的信息，帮助调研人员了解企业的IT基础架构。 此外，问卷调查和访谈也是常用的调研方法。调研人员可以设计问卷，收集关于资源使用情况、组网配置、安全架构、运维流程以及访问权限管控等方面的信息。他们还可以与运维团队进行面对面的访谈，深入了解企业的实际情况、挑战和需求。 在调研过程中，调研人员应与运维团队充分沟通，确保准确获取和理解企业的IT基础环境信息。他们需要考虑敏感性和机密性的问题，并遵循企业的安全和保密要求。 基于调研结果，企业可以更好地了解自身的IT基础架构现状和上云需求，有针对性地进行规划和决策。通过评估资源使用情况、组网配置、安全架构等方面的数据，企业可以制定合适的云迁移策略，优化资源配置，提高运维效率，并确保访问权限的管控和资源计量计费的准确性。 总而言之，基础环境调研是为了深入了解企业的IT基础架构现状和上云需求，通过与运维团队合作，结合从IT系统导出和问卷访谈等方式，收集相关数据和信息。这样的调研工作可以为企业未来的IT规划和迁移决策提供有价值的参考。 父主题： 调研评估

为什么需要Landing Zone 为了实现业务单元的安全和故障隔离，华为云的推荐做法是将不同业务单元的应用系统分别部署在不同的账号中。华为云账号具备以下三个属性。 华为云账号是一个资源容器，用户可以在其中部署任意云资源和上层业务应用系统，不同的账号相当于不同的资源容器，账号之间是完全隔离的。因此在一个账号中的故障和安全风险不会影响和传播到其他账号。 华为云账号也是安全管理边界，每个账号都有独立的身份和权限管理系统，一个账号内的用户只能访问和管理本账号的资源，未经显式的授权，一个账号内的用户不能访问其他账号的资源、数据和应用。 华为云账号还可以作为独立的账单实体，每个账号可以单独在华为云上充值、消费云资源、结算和开票。 因此华为云账号可以针对业务单元进行有效的故障和安全隔离，还可以进一步进行管理和财务隔离。单一账号存在两个严重的问题： 单一账号的爆炸半径太大，如该账号崩溃将导致企业所有业务系统不可用。 云平台上账号的资源配额是有上限的，不能在一个账号内无限扩容云资源。 为了减少单点故障的爆炸半径，核心办法就是不要把所用业务系统及其云资源部署在单一账号，也就是不要“把鸡蛋放在一个篮子里”，而是应该按照不同的业务单元映射到不同的华为云账号，如下图所示。 图1 多账号部署 因此当企业的全面云化转型需要采用多账号架构。按照康威定律，企业的多账号架构通常会与其组织架构或业务架构保持一致，即按照业务单元、地理单元、职能单元等维度划分账号。采用多账号架构后可以实现职责分离，不同的账号负责不同的事情、承载不同的业务，每个账号的管理员可以对本账号内的资源进行自治管理。但从IT治理角度，不能让每个账号成为“信息孤岛”，必须在公司范围内进行统一IT管控，比如多账号的集中身份权限管理、集中运维管理、集中安全管控、集中网络管理、集中财务管理和公共资源管理等。针对这些核心诉求，华为云提出了Landing Zone解决方案来帮助企业在云上构建安全合规、易扩展的多账号运行环境，实现多账号的资源共享和“人财物权法”的统一管控。 人的管理：多账号环境下对业务单元、账号、用户、用户组、角色等进行统一管理； 财的管理：多账号环境下对资金、预算、成本、发票、折扣等进行统一管理； 物的管理：多账号环境下对计算、存储、网络、数据、应用等云资源进行统一运维、监控和管理； 权的管理：多账号环境下对云资源的访问权限进行统一管理，确保访问权限符合最小授权原则； 法的管理：多账号环境下对安全合规进行统一管理，确保符合国家、行业和企业自身的安全合规要求，集中构建全方位数据边界，避免敏感数据泄露。 企业成功实施了Landing Zone解决方案之后，可以有效规避大规模上云之后的管理失控、安全失控、成本失控的风险，全面应对各种IT治理挑战，帮助企业建立分统结合的IT治理体系和完善的安全合规体系。 分统结合的IT治理体系：即在分权分域分级管理的基础上进行一定程度的统一管控，如集中运维管理、集中安全管控等； 完善的安全合规体系：云上运行环境（包括云资源、数据、应用等）满足国家、行业和企业自身的安全合规标准。 父主题： Landing Zone设计

网络服务选型 华为云提供的网络服务有 虚拟私有云VPC 、企业路由器ER、企业交换机ESW、云专线DC、 虚拟专用网络 VPN、全球加速GA、弹性负载均衡ELB、NAT网关、弹性公网IP等。以下是这些网络服务的选型建议： 云内同区域少量VPC互通用对等连接，跨区域VPC互通用云连接CC，云上云下互通用云专线DC或VPN，需要简化VPC之间、云上云下之间的互通连接和路由管理用企业路由器ER。 云上云下子网网段重叠、IP分开，需要二层互连打通用企业交换机ESW 云上云下子网网段重叠或因管理原因不允许直接打通两端子网段的路由，但业务需要互访，用 私网NAT网关 。 需要在云上自建高可用双机系统，建议两台ECS位于同一子网、跨可用区部署，绑定虚拟IP结合keep-alive实现。 跨境业务需要提升指定区域用户范围跨境资源的体验时，选择云连接CC搭配全球加速GA，使流量通过华为云骨干网实现降低时延的效果。 低并发、大流量基础四/七层负载分发场景建议选择共享型ELB并开启性能保障模式（支持5万并发），购买两个实例、通过域名解析分流可获得更大的并发支持。 超过10万并发、要求全链路HTTPS或高级转发策略支持的场景，建议选择独享型ELB。 ECS需要访问公网时，不建议直接绑定EIP，建议增加公网NAT网关统一走SNAT，便于更灵活的管控。 需要面向公网提供服务时，不建议将公网IP直接绑定到ECS，而是建议绑定到ELB或NAT网关，以便灵活扩展和管控调整。 无特殊情况，EIP的链路类型建议使用缺省的“全动态BGP”。 父主题： 云服务选型

AZ故障域说明 AZ (Availability Zone) 是公有云的一个独立的故障域，一个AZ是由物理上互相隔离的数据中心组成，每个AZ都具有独立的电力供应、网络连接和硬件设施，公有云厂商通常会将不同的AZ部署在不同的地理位置，以提高系统的可用性和故障容错能力，AZ故障域的优点包括： 高可用性：将应用程序和数据部署在多个AZ上，确保即使一个AZ发生故障，其他AZ仍可提供服务，保证应用程序持续可用。 故障容错：在一个AZ发生故障时，可以快速地将应用程序和数据切换到其它正常的AZ上，以确保服务不中断。 地理冗余：将不同的AZ部署在不同的地理位置，可以防止地区范围的故障，例如自然灾害或电力中断对整个系统的影响。 企业可以基于AZ故障域进行应用的高可用性署设计，设计时可以考虑如下方面： 跨AZ部署：将应用程序的不同组件部署在多个AZ中，以确保即使一个AZ不可用，其他AZ中部署的组件仍能正常运行，企业可以使用云服务提供商的工具或容器编排工具来简化多AZ部署的管理。 负载均衡：使用负载均衡将流量分发到不同AZ中的应用程序实例，可以设置合适的转发策略，避免单个AZ过载，以确保即使一个AZ受到高负载或故障影响，其他AZ也能接受并处理流量。 数据冗余和备份：在不同的AZ中实施数据冗余和备份策略，确保数据的可用性和可恢复性，即使一个AZ的数据丢失或不可用，仍能从其他AZ中的冗余数据进行恢复，确保数据的可用性和完整性。 自动故障恢复：设置自动化故障转移机制，在一个AZ发生故障时，自动将应用程序切换到其他可用的AZ上，以快速恢复服务，企业可以利用容器编排工具、自动化脚本或云服务提供商提供的故障转移功能来实现自动故障恢复。 监控和警报：设置监控和报警机制，实时监测每个AZ中的应用程序和基础设施的健康状态，在发生故障时，及时触发告警，并通知有关人员进行故障排查和处理，以减少服务中断时间。 通过基于AZ故障域的高可用部署设计，企业可以提高业务系统的可用性和故障容错能力，最大限度地减少服务中断和数据丢失的风险，并确保业务的连续性。 父主题： 可用性设计

云上高可用方案 公有云上业务的可用性，由应用层的可用性，架构设计的可用性、云服务的可用性共同决定。业务可用性目标的达成是一项系统工程，公有云模式下，业务的可靠性取决于客户对整体业务架构的可用性设计、运维规范管理（如：备份机制、日常演练、人员操作规范等）。 图1 业务可用性方案 华为云上的绝大部分云服务都具备高可用性的方案，提供了从数据中心、硬件、数据、自助服务等多个层次的高可用性构建能力。华为云数据中心布局于全球，可以满足不同地域（Region）的资源需求，每个地域又分多个可用区（AZ），可用区之间的风火水电相互独立，可用区之间的故障相互隔离。企业可在此基础上构建如下场景的高可用体系： 单AZ部署：通常情况云上不建议单AZ部署，除非是对时延特别敏感的业务，无法接受同Region的AZ间时延，这种情况可以考虑单AZ部署，利用云服务主备、集群化部署模式来满足单个业务节点故障时快速恢复业务的需求，主要利用集群内节点故障自动探测和切换的方式来完成故障节点的恢复，消除业务单点，避免单点故障时业务受损。 双AZ（同城）高可用：对业务可用性要求比较高的业务，可以选择同城多机房的方式部署业务，这样可以避免单机房网络、物理设备、电力等故障时导致业务整体不可用；对应到华为云上用户可以采用服务跨多可用区（AZ）模式部署，各可用区之间相互隔离，当一个可用区故障时，可将业务切换到另一个可用区，快速恢复业务。云服务产品基本都具备相关的能力，用户只需在选购时选择对应的能力即可完成部署。 两地三中心高可用：对于一些特大型或者安全要求很高的商业系统，对系统的高可用性提出了更高的要求，跨AZ的高可用方案并不能解决该地域级别的故障，如地震、洪水等。要满足此类业务场景可选择异地机房部署业务，华为云异地灾备方案在同城容灾的基础上，可再搭建异地灾备机房，满足此类业务需求。 跨云高可用：为满足企业对多云高可用的部署需求，华为云同样支持多云容灾部署的能力，企业可以选择以华为云为主站点，其他的云厂商为备站点部署业务，借助多云来满足业务的可用性。 父主题： 可用性设计