简介：面向华为 HCIE-Cloud Computing V3.0 认证备考者与云计算从业人员的培训教材，围绕华为云Stack解决方案与政企上云知识体系组织内容，适合需要系统理解认证考点和典型行业场景的学习者。压缩包内含 1 个 PDF 文件，大小约 32.05MB，便于集中阅读、离线查阅和按章节复习。目前已有 175 人学习。教材从云计算发展背景切入，介绍华为云Stack的定位、整体架构与高阶云服务，并围绕基础设施云化、应用使能、数据使能、统一管理四条主线展开，结合数字经济、行业数字化转型与政企智能升级需求，说明平台在合规部署、平滑上云和云上创新中的支撑作用。读者可据此建立解决方案的全局认识，对照考纲梳理架构层次与关键能力，并在备考和实际项目理解中查漏补缺。

1. 一朵政企云的门槛不在虚拟化，而在"管理面和业务面能不能切开"

把服务器虚拟化、再发几台虚拟机出去，这件事开源方案半小时就能跑通。真正卡住政企上云进度的从来不是 KVM 能不能起来，而是另外三件事必须同时成立：几十种异构硬件能被同一套调度吃掉，多租户之间的网络该通的通、该断的断，以及任意一个部件挂掉时业务还能在分钟级爬起来。HCIE-Cloud Computing V3.0 这份华为云Stack 培训教材反复在讲的，其实就是这三件事的实现路径，而不是产品清单。

云计算在政企场景里最容易被低估的一点是：它首先是一套"隔离与边界"的工程，其次才是一套"资源池"的工程。教材里 12 类 80+ 云服务的背后，真正的硬骨头是四层架构怎么切、管理面往哪放、网络在哪一层做策略、灾备在哪一层做切换。把这几个边界想清楚，再看那些云服务名字，就不再是一张背不完的表。

2. 四层架构与分区部署：ManageOne 为什么必须站在最外层

华为云Stack 的系统整体架构被切成四层，这个切法不是按"功能归类"来的，而是按"变化频率"和"信任边界"来的。基础设施层收敛硬件差异，资源池层把硬件翻译成可调度的资源，云服务层把这些资源包装成有 SLA 的服务，展现层则是唯一面向人的出口。层次越往下，变更越慢、越重；越往上，迭代越快、越轻。

2.1 四层各自负责什么，边界划在哪里

最底下是基础设施层，适配多元算力，支持 X86、鲲鹏、飞腾、海光四种 CPU 架构，支持 GPU，支持分布式存储与集中式存储、交换机、负载均衡器、防火墙。这一层的职责只有一个：把物理世界的差异吸干，让上面看到的永远是"一类资源"而不是"某个型号的机器"。

第二层是资源池层，教材的原话是"通过云平台系统软件实现硬件资源池的使能和操作"。注意"使能"和"操作"是两个动作——使能是把裸硬件变成受管资源，操作是对受管资源做生命周期管理。这一层分别实现了 IaaS 的资源控制、容灾备份的资源控制、大数据与数仓的资源控制。也就是说，容灾不是云服务层临时拼出来的功能，它在资源池层就已经有独立的控制通路，这也是后面 RPO=0 能成立的前提。

第三层是云服务层，构筑 Service 能力，实现云服务的使能和管控。ECS、EVS、VPC、CCE、OBS、CloudDNS、EIP、QoS 这些 IaaS 服务，EI、PaaS、数据库、安全、ROMA 这些高阶服务，都落在这一层。第四层是展现层，ManageOne 是租户与运营运维的统一入口。

提示：判断一个云平台是否"分层"，最简单的办法是看它换一款 CPU 或换一款存储时，需要改动到第几层。如果改一层就够，分层是真的；如果要连服务层一起改，那只是画了个分层图。

2.2 ManageOne 为什么站在最外层而不是塞进服务层

ManageOne 的职责有两块，教材写得很清楚：一是云服务的运营集成能力，通过 Console Home 集成各云服务 Console，给用户统一的云服务使用界面入口；二是云平台的系统级运维能力，实现对云服务端到端的监控，监控对象包括云服务自身、租户资源和云服务所依赖的基础设施（计算、存储、网络），并基于这些监控与告警数据提供报表、大屏以及高级运维数据分析能力。

把这一层独立出来、并且放在最外面，解决的是一个很现实的问题：云服务是不断新增的，如果每个新服务都自带一套登录、鉴权、计费、告警界面，运维人员的工作量会随服务数量线性增长。Console Home 集成各云服务 Console，意味着新增一个服务只需要接入这套框架，而不是重新造一套门户。这跟浏览器插件模型是一个思路——宿主提供容器和权限，插件只提供内容。

2.3 Global 与 Region 融合部署时的分区逻辑

真正体现设计功力的是部署架构。在 HCS Global 与 Region 融合部署场景下，Global 组件管理面与 Region 组件管理面部署在同一个 OpenStack 资源池内，但按不同的业务特性部署在不同的网络区域内。这句话的含金量在于：物理上共用一套资源池，逻辑上必须按信任等级切开。

DMZ 区部署 LVS、Nginx 等组件，还有 HAproxy、DNS、NTP、API 网关、应用发布这些对外入口类组件；External_OM 区部署运营运维服务、高阶服务、基础服务、跨云管理服务；OM_Service 区部署远程接入组件，包括堡垒机、前置服务器、升级代理、部署代理；再往下是计算-管理下沉区部署高阶服务管理面，计算-租户区部署计算 AZ（KVM/BMS），网络区部署网络节点与网元（BR/vRouter），存储区部署块存储和对象存储。整体上还有可信区与半可信区的划分，DGC、ISAP、ModelArts、DevCloud 这类数据与 AI 相关的服务落在更靠内的位置。

这里有个容易被忽略的设计：计算-管理下沉区单独存在。高阶服务（比如数据库服务、大数据服务）自身也需要算力，如果把这些管理面算力放进租户 AZ，就会带来两个问题——占用租户可售容量，以及管理面与租户流量混在一张网里。管理下沉区的本质是把"平台自己用的资源"和"卖给租户的资源"在拓扑上分开，这样租户看到的 AZ 容量是干净的，平台扩容管理面也不会影响租户配额。

用 OpenStack 原生命令可以直观看到 AZ 与主机聚合的对应关系，这也是后续排查"虚机为什么落在这台机器上"的起点：

# 载入管理面凭据，变量字段以现场实际为准 export OS_AUTH_URL=<管理面Endpoint> export OS_USERNAME=<管理员账号> export OS_PASSWORD=<口令> export OS_PROJECT_NAME=service export OS_USER_DOMAIN_NAME=Default # 列出可用分区：AZ 决定了一台虚机能落在哪一类硬件上 openstack availability zone list --long # 查看主机聚合：aggregate 是把"特性相同的主机"聚成一组的手段 # metadata 里通常写着 cpu_arch、是否支持绑核、是否 GPU 节点等信息 openstack aggregate list --long openstack aggregate show <聚合组名>

availability zone list --long输出里的Hosts字段告诉你这个 AZ 由哪些计算节点组成，openstack aggregate show的properties字段告诉你调度器靠什么把规格和主机匹配起来。后面所有关于"一云多芯"的讨论，落地点都是这两条命令的输出。

3. 一云多芯：X86 与鲲鹏凭什么能在同一朵云里各干各的活

教材里 HCS 8.1.1 把"一云多芯"列为云底座的第一条能力：组合鲲鹏、X86、海光、飞腾多种 CPU 架构基础设施，提供灵活的混合部署管理能力，结合多种算力优势，提供 KVM 虚拟化、BMS 等基础实例以及 GPU、NPU 等 AI 场景实例。这段话听起来像宣传语，但它背后有一堆不解决就跑不起来的工程问题。

3.1 "能装上去"和"能被调度吃掉"是两回事

把一台鲲鹏服务器纳管进 OpenStack，技术上只是加一个 nova-compute 节点。但真正的一云多芯要求是：一个租户在同一个 VPC 里，可以既有跑在 X86 上的虚机，也有跑在 ARM 上的虚机，两者之间二层互通，安全组策略一致，镜像和规格各自匹配，计费口径统一。这就要求调度层能识别架构差异，而不是让用户自己去猜。

教材给出的落地形态是 AZ 划分：AZ1-x86 资源池、AZ2-ARM 资源池、AZ3-裸金属资源池，各自挂载对应的计算资源池（KVM 主机组、裸金属）。资源池的形态还不止虚机——虚拟化资源池、BMS 资源池、GPU 资源池、容器资源池、Hadoop 资源池并存，用户无需关心真实物理硬件的类型和位置，只按需向资源池提出诉求。

这条"用户无需关心"是有代价的：调度器必须能在发放阶段完成一次过滤。下面这段代码还原了这个过滤链的核心逻辑，它解释了为什么规格里必须带架构信息：

# 调度过滤链的简化还原：一台虚机最终落在哪个 AZ，取决于规格与主机聚合的匹配 def filter_hosts(flavor, aggregates, hosts): candidates = [] for host in hosts: agg = aggregates.get(host["aggregate"]) if agg is None: continue # 1) 架构必须匹配：规格里声明 arm64，就不能落到 x86 聚合组 if flavor["arch"] != agg["metadata"].get("cpu_arch"): continue # 2) 特性必须匹配：需要 GPU / NPU / 绑核 / 大页的规格，落到不支持的主机就是发放失败 required = set(flavor.get("traits", [])) if not required.issubset(set(agg["metadata"].get("traits", []))): continue # 3) 容量过滤：预留水位，避免把一台宿主机压到无法做 HA 切换 if host["free_vcpu"] < flavor["vcpus"] * 1.2: continue if host["free_mem_mb"] < flavor["ram_mb"] * 1.2: continue candidates.append(host["name"]) return candidates aggregates = { "agg-arm": {"metadata": {"cpu_arch": "arm64", "traits": ["npu"]}}, "agg-x86": {"metadata": {"cpu_arch": "x86_64", "traits": ["gpu", "hugepage"]}}, } hosts = [ {"name": "compute-arm-01", "aggregate": "agg-arm", "free_vcpu": 64, "free_mem_mb": 262144}, {"name": "compute-x86-01", "aggregate": "agg-x86", "free_vcpu": 12, "free_mem_mb": 32768}, ] # 一个 8 核 32G、需要 NPU 的规格，只可能落在 ARM 聚合组里 print(filter_hosts({"arch": "arm64", "vcpus": 8, "ram_mb": 32768, "traits": ["npu"]}, aggregates, hosts))

这段逻辑里三个过滤条件对应三类真实故障：架构不匹配会直接报镜像无法启动（同一份 qcow2 镜像通常不能跨架构跑）；特性不匹配会在发放成功之后才暴露性能问题，比如该绑核的没绑核、该用大页的走了普通页；容量水位不留余量，会导致单机故障时 HA 切不走，虚机飘不起来。第三条最容易被忽略，也最容易在大促或批量上线时炸。

3.2 混合部署与"保护投资"的真实含义

教材强调"X86、ARM 资源池混合部署，保护投资"。这句话的实质是：政企不会一次性把存量 X86 全部替换掉，新采购的 ARM 机器要和旧的 X86 机器在同一朵云里共存若干年。所以多芯能力的关键指标不是"支持几种架构"，而是"不同架构的资源能不能被同一套配额、同一套 VPC、同一套运维视图管理"。

同理，异构不只发生在 CPU 上。教材提到管理网络节点支持海光服务器，管理网络节点与所有高阶服务支持飞腾 2500、海光 7280/7260 等多款异构服务器，管理网络节点和所有高阶服务支持 icelake 服务器，GPU 云主机新增支持 A40、A100(40G)。这些细节说明一件事：连平台自身的组件也要能在国产化算力上跑，否则"全栈自主可控"只覆盖了租户侧，管理面还是个缺口。

兼容性清单也是同一逻辑的延伸：操作系统层面与 CentOS、中标麒麟、深度、Ubuntu 做过兼容性验证，数据库层面有 MySQL、PostgreSQL、南大通用、达梦，中间件有东方通/金蝶，编译器与工具链有 GCC、JDK，语言覆盖 C、C++、Java、Python、Ruby、Go。往上，教材提到对接行业合作伙伴超过 50 家、形成行业联合解决方案超过 60 个。这些数字的意义在于：一朵云能不能落地，取决于存量应用能不能不改代码跑上去，而不是取决于架构图画得多漂亮。

3.3 多核架构带来的性能增量从哪来

教材给了两个性能口径：云原生应用业务性能提升 80%，基于昇腾的 AI 云服务性能提升 2 倍以上。这两个数字背后的机制不一样。前者主要来自容器化之后减少的虚拟化开销与更细的调度粒度——虚机里跑容器和直接在裸金属上跑容器，网络转发路径和中断处理的开销差别很大；后者主要来自 NPU 的专用算力与算子库适配，通用 CPU 去做矩阵运算是纯粹的浪费。

真正值得记住的是资源融合那一层的表述：服务化内部把计算、网络、存储资源，以虚机、容器、物理机、GPU 加速、AI 加速、高性能卸载转发、普通 IO 转发等形式提供给用户。这里的"高性能卸载转发"和"普通 IO 转发"并列出现，说明转发路径是可选的——需要极致网络性能的业务（比如高性能计算、高频交易类场景）走卸载路径，普通业务走通用路径。这种"同一朵云里两种转发平面并存"的设计，是资源池层必须承担的复杂度。

4. 虚拟网络的四道边界：安全组、ACL、Peering、Endpoint 各管一段

云网络最让人困惑的不是功能少，而是功能太多、每种的生效范围和状态特性都不一样。教材把云内互通拆成七条、云外云间互通拆成四条，这十一条能力如果按边界归类，其实只有四道：实例边界、子网边界、VPC 边界、数据中心边界。搞清哪道边界由谁负责，排障时间能省一大半。

4.1 实例边界与子网边界：安全组和网络 ACL 的分工

教材第一条：子网内默认二层互通，同时提供安全组能力，可以基于实例端口边界做安全访问控制。第三条：同 VPC 内跨子网默认三层互通，同时提供网络 ACL 能力，基于子网边界做安全访问控制。

两句话点明了本质区别——安全组挂在端口上，网络 ACL 挂在子网上。这带来的直接后果是：安全组可以做到"同一子网里 A 能访问 B、B 不能访问 A"这种粒度，而网络 ACL 只能做到"整个子网进出的流量统一规则"，子网内部的互访它管不着。

常见的实现思路是：安全组有状态，规则放通入方向之后回程自动放通；网络 ACL 无状态，进出方向要各自写规则。我一般会这么理解——安全组像每台机器自己的门卫，网络 ACL 像楼层的大门，楼层门禁不会记得你刚才是不是从这儿出去的。所以只放通一个方向，跨子网访问就会变成单向通、回程被丢，表现为"能连上但没响应"。

4.2 VPC 边界：Peering 配路由，Endpoint 不配路由

第四条和第五条是容易被混用的两个能力。VPC Peering 用于多部门数据快速共享、跨 VPC 的 VM 互通，关键动作是"按需配置路由"——Peering 只建立了通道，路由没配就是黑洞。VPC Endpoint 用于服务安全访问，跨 VPC 访问 VM/容器/APIG 等，特点是无需配置路由，但需要额外配置安全访问控制。

这个差异决定了选型：如果是两个 VPC 之间大量主机互相访问，用 Peering 加路由；如果是多个 VPC 集中访问某一个服务（典型的是把公共服务集中部署，其他 VPC 来调），用 Endpoint 更合适，因为不需要在每个 VPC 的路由表里维护条目，规模上去之后路由条目本身就是运维负担。

第六条容易被忽略：VPC 内支持精细化路由能力，可把业务流量引流至特性云主机（如安全软件），实现云内流量调度，满足第三方安全模块引流诉求。这条能力的存在说明一件事——云平台没有试图把所有安全能力都做进自己肚子里，而是留了引流口子，让第三方安全虚机能以"下一跳"的形式插进转发路径。这是很务实的设计取舍。

4.3 数据中心边界：EIP、NAT、专线、二层桥接、云连接

云外与云间互通有四条路径，各自解决的问题完全不同：

# 排查跨 VPC / 跨 Region 不通时的固定动作：先看路由，再看策略 # 1) 查 VPC 路由表：Peering、专线、引流规则最终都体现在这里 openstack router show <router-id> -f json | jq '.routes' # 2) 查端口上的安全组绑定，确认策略挂在了预期端口上 openstack port show <port-id> -f json | jq '{sg: .security_groups, fixed_ips: .fixed_ips}' # 3) 查子网关联的 ACL，注意 ACL 无状态，进出方向都要有规则 openstack network show <network-id> -f json | jq '.tags'

第一段命令的输出是排障的分水岭：如果有去程路由没回程路由，表现是"能发出请求、收不到响应"，和 ACL 只放通单向的现象一模一样，但修法完全不同。这也是为什么网络排障必须按边界逐层收敛，而不是一上来就抓包。

EIP 解决的是内外同时主动访问（双向），SNAT 解决内网主动访问外网（单向出），DNAT 解决外网主动访问内网（单向入）。三者不是替代关系，而是三种流量方向模型，选错了不是不通，而是通得不对——比如本该用 SNAT 的场景配了 EIP，虚机直接暴露在公网，安全组漏一条规则就是事故。

专线解决 VPC 与本地网络互通；二层桥接解决传统应用快速上云——本地网络内的应用迁移上云且 IP 保持不变，靠的就是二层桥接；云连接解决跨 Region 私网互通，支持跨 Region 网络互通和跨云 VPC Peering。二层桥接这个能力看着不起眼，实际是政企上云的关键一环：大量存量系统的配置文件里写死了 IP，改 IP 等于改应用，二层桥接让这批系统能在不改代码的前提下先上云。

4.4 ELB 的 7 层能力为什么单独列一条

教材把"ELB 服务支持跨云间的负载能力，并支持 7 层高级路由"单独列出来。7 层路由意味着可以按域名、路径做转发决策，而不只是按四元组做四层负载。这在多云/混合云场景下价值很大——同一套域名，一部分流量留在本地资源池，一部分送到云上，靠 7 层规则切分，业务侧不用改任何配置。

把上面这些能力串起来看，会发现一个规律：云内互通解决的是"隔离前提下的连通"，云外云间互通解决的是"连通前提下的合规"。前者防止租户之间串流量，后者保证数据该在哪就在哪。这两件事的方向是相反的，所以必须用两套机制而不是一套。

5. 网络排查：从手工 tcpdump 到秒级定界的五条踩坑记录

教材对传统排障方式的描述非常直白：数据中心网络出现异常时，运维人员需要手工登录各个节点，上传 TCP DUMP 工具进行命令行抓包，抓包完成后下载抓包文件到本地排查；操作繁琐、耗时耗力、容易出错，当需要在业务流的多个点同时抓包时，需要同时操作多个命令行，还需要一定的操作能力。这段话描述的是真实痛点，不是客套话。

5.1 定界的本质是缩小嫌疑范围，不是找到根因

CloudNetDebug 集了拨测和抓包两个功能，用于处理数据中心内可能出现的各种网络问题。通过拨测工具可自动化检测业务网络是否出现断流、是否出现丢包，通过抓包功能可实现自动化抓包，支持基于业务流的多点协同抓包，支持灵活的单点虚拟机网卡抓包和主机网卡抓包。

它的四类典型用途教材写得很清楚：检测网络断流、丢包问题；网络故障时用于定界虚拟网络和物理网络的故障边界，自动化定界是哪个网元节点的问题；当无法确认是应用还是网络的问题时，用于排除网络问题。注意第三条——"排除网络问题"本身就是一种结论。运维最怕的不是故障，而是不知道锅在谁身上，应用团队和网络团队互相等对方举证。

这套工具在能力上的增量也很具体：新增 vpcep、natgw、elb 拨测能力，快速定界流量中断点；新增 VIP 流量抓包，支持 EIP/VPC/DC/VPC-PEERING 等网络流量类型运维场景；加固主动链路探测，新增 ELB 主动链路，持续监测重要流量。拨测覆盖到 vpcep 和 natgw 这两个组件，意味着 Endpoint 和 SNAT/DNAT 这两条最容易出问题的路径被纳入了自动检测。

5.2 HawkEye Agent 的布点决定了能抓到什么

采集侧靠的是 HawkEye Agent，部署位置决定了观测视角。教材列出的布点包括：CNA（计算节点代理）、BM（裸金属）、GW（网关）、vRouter/软 NAT、EGF/内核态 NAT 网关、UGW/EGF、BR、ELB、EulerOS Endpoint、UGW/EGF Backend。控制侧是拨测+抓包 server，包含 HkeController、hkeAnalyzer、Redis 主备、GaussDB。通道有四类：REST API、RPC 信息查询通道、DB 数据通道、物理网络 ERSPAN。

这张布点图解释了一个关键事实：抓包不发生在虚机里，而发生在虚机所在宿主的 vRouter 上、网关的软 NAT 上、ELB 的转发路径上。这既是能力也是限制——虚机内部协议栈的问题，这套工具看不到；但虚机之外的每一跳，它都能看到。Redis 主备加 GaussDB 的组合说明拨测是有历史数据的，不是一次性探测，故障复盘时可以回看当时链路状态，这一点比事后抓包有价值得多。

5.3 五条踩坑记录

注意：下面五条都按"现象 → 原因 → 解决"记录，前三条是策略类问题，后两条是抓包姿势问题。

现象：跨子网访问能建立连接但收不到响应，抓包看到去程报文正常、回程没有。原因：网络 ACL 无状态，只放通了入方向，回程的临时端口被默认规则丢弃；同时安全组有状态，回程自动放通，两套策略状态特性不一致导致误判。解决：ACL 进出方向都显式放通，排查时先看 ACL 再看安全组，顺序反了会绕大弯。

现象：VPC Peering 建好之后两端虚机互 ping 不通，Peering 状态显示正常。原因：Peering 只建立通道，不自动下发路由，两端路由表都缺对方网段。解决：两端路由表互指，配完之后用openstack router show确认路由条目真的生效，而不是只在控制台看到"已创建"。

现象：拨测结果显示链路可达，业务侧仍然报接口超时。原因：拨测验证的是四层可达，ELB 后端健康检查失败但前端监听正常，四层通、七层挂。解决：启用教材里提到的 ELB 主动链路探测，把后端健康状态纳入拨测范围，同时检查 7 层路由规则是否把流量导到了错误的后端组。

现象：故障发生时想抓包，抓包启动之后故障已经恢复，抓到一堆正常报文。原因：故障是瞬时抖动，人工触发抓包永远慢一步。解决：对重要流量常驻主动链路探测，靠 GaussDB 里的历史拨测数据做复盘，抓包只在复现阶段用；多点协同抓包时用五元组对齐各采集点的报文，避免拿不同流的包做对比。

现象：迁移上云后部分老系统连不上数据库，网络层看起来全通。原因：三层互通要求地址段规划不冲突，存量网络与 VPC 网段重叠时会出现路由指向错误，表现为"时通时不通"。解决：上云前做网段冲突检查，冲突且不能改 IP 的系统走二层桥接，这也是教材把二层桥接列为独立能力的现实原因。

6. 灾备分级的取舍：RPO=0 到底是拿什么换来的

教材里灾备能力的表述是"全地域、全场景、租户自助"，覆盖本地、同城、异地、两地三中心；同城双活同时提供应用级与平台级业务连续性保障，支持数据库服务、中间件服务、虚拟机容器等核心组件的双活，做到实例级故障自动切换，单部件切换后网络 IP 和接入访问方式不变，业务完全无感知，RPO 等于 0、RTO 分钟级。异地灾备则提供异地应用容灾、异地云主机容灾、异地数据备份。

这张分级表把取舍摆得很清楚：

RPO=0 的来源是同步复制，而同步复制受光传输时延约束，所以同城的距离被限定在 100 公里这个量级；超过这个距离只能走异步，RPO 必然大于 0。这不是产品能力问题，是物理问题。教材里"支持 0-1、1-N 的容灾数据中心叠加，单 AZ 到双 AZ 的 CSHA 演进"这句话，实际上是在承认：大部分客户不会一步到位建两地三中心，而是先单 AZ、再同城双活、最后异地，平台必须支持这种渐进式演进。

我认为这套设计里最值得琢磨的取舍是"业务无改造，上云即容灾"。要做到业务不改代码就能容灾，平台必须在资源池层就把容灾控制通路做进去，而不是在应用层加 SDK——这正是第 2 章里"资源池层分别实现 IaaS 的资源控制、容灾备份的资源控制"那句话的真正含义。代价是平台复杂度大幅上升，收益是存量系统不用重写就能获得分钟级 RTO。对于一堆跑了十几年的核心系统，这个交换是划算的。

另一个取舍是租户自助。统一的容灾管理平台方舟实现一键式容灾切换、降低运维复杂度，租户甚至可以定期执行容灾演练。把演练权限交给租户，意味着平台要承担"租户误操作"的风险，但换来的是容灾方案真的会被验证——没演练过的容灾方案，和没有容灾方案的区别只在于心理安慰。

从那以后我每次评估一套云平台的灾备能力，都会强制走一遍"距离—RPO—改造代价"这三个问题，而不是先看它支持几种容灾模式。因为模式是无限的，物理约束是有限的，把约束想清楚，方案自然就收敛了。希望帮到你。

本文还有配套的精品资源，点击获取