企业官网建设流程全解析

简介：这份华为云计算3.0培训教材面向备考HCIE-Cloud Computing V3.0的学员及云计算从业者，可用于认证复习、知识体系梳理和政企上云方案理解。内容从云计算发展背景切入，讲解华为云Stack的特性、架构与高阶云服务，并覆盖基础设施云化、应用使能、数据使能和统一管理四条主线，结合数字经济、数字主权、东数西算及行业转型背景，帮助读者建立从趋势到平台能力的认知框架。资源包共1个PDF文件，约32.05MB，篇幅集中，便于按章节阅读和检索。已有175人学习，说明其在备考群体中具有一定参考价值。教材对政企上云关键需求、云Stack分层架构及12类80+云服务的展开，可用于对照考试大纲查漏补缺，也能为理解金融、政府、能源、交通等场景的落地思路提供支撑。

1. 从一次模拟面试卡壳说起：这套教材该按什么顺序啃

前阵子陪一个准备 HCIE-Cloud Computing V3.0 的同学过模拟面试，他能把华为云计算培训教材里“12 类 80+ 云服务”一口气背完，被问到“一个跨 VPC 的业务访问不通，你先看哪一层”时却卡住了。这份华为官网教材真正的价值不在服务清单，而在于把政企上云拆成了四层架构、七条网络通路、四级灾备演进这样能直接套用的骨架。下面的拆法针对两类人：要拿这套教材备考的，和要照着它交一份云平台课程设计或交付方案的。先把骨架立住，再往里填服务和参数，笔试题、实操题和答辩都能接得住。

2. 考纲与架构对齐：四条主线怎么落进四层架构和八个分区

2.1 四条主线与教材章节的对应关系

教材前言列了四个目标：了解传统 IT 和企业数字化转型的趋势、了解华为云Stack 是什么、了解华为云Stack 的架构、了解高阶云服务。正文把特性拆成基础设施云化、应用使能、数据使能、统一管理四条主线。

这四条在教材里是并列排的，但学的时候不能并列。我一般建议按“基础设施云化 → 统一管理 → 数据使能 → 应用使能”的顺序走，理由很朴素：后三条都长在第一条上，基础设施云化没吃透，后面讲大数据和容器就是背名词。

把这张表当成学习进度表用，每学完一行，就在“能交付什么”那一列写一句自己的话。这个过程看着土，但到了答辩现场，考官问的往往就是“你学完这条线，能给出什么结论”。

2.2 四层架构的记忆方法：从物理设备问到管理入口

教材把解决方案分成四个层次。基础设施层适配多元算力，支持 x86、鲲鹏、飞腾、海光，支持 GPU，支持分布式存储、集中式存储、交换机、负载均衡器、防火墙；资源池层通过云平台系统软件完成硬件资源的池化和操作，分别实现 IaaS 资源控制、容灾备份资源控制、大数据和数仓资源控制；云服务层构筑云服务能力，做云服务的使能和管控；最上面是展现层，ManageOne 面向租户和运营运维管理，通过 Console Home 集成各云服务 Console 提供统一入口，同时提供系统级运维能力，对云服务端到端监控，覆盖云服务自身、租户资源和依赖的基础设施（计算、存储、网络），收集并展示告警，再基于这些数据做报表、大屏和高级运维分析。

我的记法是自下而上问三个问题，每个问题对应一层：

1. 这个资源归谁管？——资源池层。虚机、容器、物理机、GPU 加速、AI 加速、高性能卸载转发、普通 IO 转发，都是这一层发出的形态。
2. 业务看到的是什么？——云服务层。用户不关心物理硬件类型和位置，只按需提资源诉求，隔离性、安全性、弹性伸缩、按需计量计价在这一层兑现。
3. 谁负责开门？——展现层。所有申请、审批、监控、告警、报表从这个入口进出。

一条完整的调用链长这样：用户从 ManageOne 的 Console 发起申请，请求落到云服务层，云服务层调度到资源池层某个 KVM 主机组或裸金属组，最终落到基础设施层的服务器和存储上，网络流量从网络区的 BR、vRouter 出去。能把这句链路复述清楚，架构题基本不会失分。

2.3 标准逻辑部署架构：八个分区各放什么

Global 与 Region 融合部署是个高频考点，教材说得很明确：Global 组件管理面与 Region 组件管理面部署在同一个 OpenStack 资源池内，按不同业务特性部署在不同的网络区域。DMZ 区部署 LVS、Nginx 等组件；External_OM 区部署运营运维服务、高阶服务、基础服务、跨云管理服务；OM_Service 区部署远程接入组件；计算-管理下沉区部署高阶服务管理面；计算-租户区部署计算 AZ（KVM/BMS）；网络区部署网络节点与网元；存储区部署块存储和对象存储。

这张表建议默写。虚拟网络故障定界的第一步从来不是抓包，而是先确认故障点落在哪个分区，分区错了，后面全白做。

3. 基础设施云化：一云多芯的算力池划分与四级灾备演进

3.1 算力池划分：一台服务器该进哪个 AZ

教材给的例子是 AZ1-x86 资源池、AZ2-ARM 资源池、AZ3-裸金属资源池，往下一层是虚拟化资源池、BMS 资源池、GPU 资源池、容器资源池、Hadoop 资源池。到了一台新服务器进场，判断逻辑我一般按四条走：

1. CPU 架构。x86、鲲鹏、飞腾、海光不能混进同一个主机组做迁移，这是硬边界。教材提到管理网络节点支持海光服务器，管理网络节点加高阶服务支持飞腾 2500、海光 7280/7260 等多款异构服务器，这类信息要单独记，因为它决定了管理面能不能落在国产算力上。
2. 实例形态。KVM 虚机、BMS 裸金属、GPU/NPU 实例，三种形态对宿主的要求不一样。教材里 GPU 云主机支持英伟达 A40、A100（40G），这类卡只能进 GPU 池。
3. 业务等级。稳态业务和创新业务分池，避免一批跑批量计算的虚机把在线业务的宿主抢满。
4. 网络平面。管理流量和业务流量分不分池，直接影响后面故障定界的难度。

3.2 算力池规划清单与自检脚本

规划阶段我最怕的是“主机组跨 AZ 复用”和“同 AZ 混架构”这两类错误，它们不会在部署时报错，只会在半年后变成性能玄学。所以我会先把规划写成一份清单，再用脚本跑一遍。

# 算力池规划清单（示意，字段名按实际平台调整） availability_zones: - name: AZ1-x86 cpu_arch: x86_64 purpose: 稳态业务与数据库 host_groups: [hg-prod-x86, hg-db-x86] instance_types: [KVM, GPU] - name: AZ2-ARM cpu_arch: aarch64 purpose: 云原生与国产化应用 host_groups: [hg-cce-arm] instance_types: [KVM] - name: AZ3-BMS cpu_arch: x86_64 purpose: 裸金属与高性能计算 host_groups: [hg-bms-x86] instance_types: [BMS]

字段含义：cpu_arch是架构边界，同一个 AZ 内必须唯一；purpose写清楚这个池服务谁，答辩时这一列比架构图管用；host_groups是主机组清单，同一个主机组不允许出现在两个 AZ 里；instance_types约束这个池能发什么形态的实例。

# 校验算力池规划：同 AZ 架构唯一、主机组不跨 AZ 复用 import sys import yaml def check(path): plan = yaml.safe_load(open(path, encoding="utf-8")) errors = [] az_arch = {} host_owner = {} for az in plan["availability_zones"]: name, arch = az["name"], az["cpu_arch"] # 同一个 AZ 内出现两种 CPU 架构，后续迁移必然出问题 if name in az_arch and az_arch[name] != arch: errors.append(f"AZ {name} 内出现两种架构：{az_arch[name]} / {arch}") az_arch[name] = arch for hg in az["host_groups"]: # 主机组被两个 AZ 同时引用，资源归属就说不清了 if hg in host_owner and host_owner[hg] != name: errors.append(f"主机组 {hg} 同时挂在 {host_owner[hg]} 和 {name}") host_owner[hg] = name return errors if __name__ == "__main__": errs = check(sys.argv[1]) print("\n".join(errs) if errs else "规划校验通过")

这段脚本解决的是“人肉核对容易漏”的问题，逻辑就两层：第一层按 AZ 聚合架构，发现冲突就记一条；第二层用字典记录主机组的归属，第二次出现时比对 AZ 名。跑法很直接，python check_plan.py plan.yaml即可，输出为空就是通过。字段有增减时，同步改check里的取值路径就行，不用重写结构。实际项目里这套东西通常挂在变更流程前面，规划清单一改就自动跑一遍，比事后查主机组归属省事得多。

3.3 国产化生态兼容矩阵怎么用

教材的表述是：基础算力已经完成以国产化架构为核心的适配，同时和业界主流的操作系统、数据库、中间件做了兼容性验证，操作系统层面覆盖 CentOS、Ubuntu 及国产操作系统，数据库覆盖 MySQL、PostgreSQL 及国产数据库，中间件覆盖国产中间件产品；操作系统之上提供编译器与工具链，编译器如 GCC、JDK，语言有 C、C++、Java、Python、Ruby、Go；向上还联了政府、金融、公共安全、企业、运营商等行业的 ISV 做应用适配，对接行业合作伙伴超过 50 家，形成行业联合解决方案超过 60 个。

把它压缩成一张选型表更实用：

这张表容易被当成选修课跳过，实际部署阶段最常见的“说不清原因”的启动失败，八成能追到某个版本对不上。

3.4 灾备四级演进：从本地高可用到两地三中心

教材对灾备的描述是全地域、全场景、租户自助：覆盖本地、同城、异地、两地三中心，覆盖数据、网络、应用三个场景。落到方案上是一条四级演进路线。

设计要点在于节奏，不是一步到位。教材原话是按建设节奏逐步演进，支持 0-1、1-N 的容灾数据中心叠加，支持单 AZ 到双 AZ 的 CSHA 演进。这句话翻译成方案语言就是：一期先把本地高可用做扎实，二期在同一区域内加第二个 AZ 做 CSHA，三期再考虑跨地域。很多方案翻车就翻在“一上来就画两地三中心”，结果连本地备份窗口都没跑通。统一灾备管理平台方舟承担的是编排角色，向导式自助服务和一键式切换，租户可以定期做容灾演练，这一点在答辩里很有说服力，因为它把灾备从“写进文档”变成了“可以演给你看”。

4. 网络互连设计：VPC 内七条通路到云外云间的四种接入

4.1 云内租户互通的七种手段

教材把云内互通拆成七条，按边界控制方式可以归成三类。这个归类方式建议记住，因为题目里经常只给场景不给手段，让你自己选。

①②③ 是默认行为，④⑤⑥⑦ 是显式配置。这个区分很重要：考试里问“跨子网为什么不通用”，答案往往不是没配路由，而是网络 ACL 拦了；问“为什么到服务端的访问在服务端看不到来源 IP”，答案大概率是走了 VPC Endpoint 而不是 Peering。

4.2 云外与云间：四种接入方式加一种特殊场景

教材把云外、云间的互通拆成四类：云内 VM 和 Internet 互通，配 EIP 实现内外同时主动访问，配 SNAT 实现内网主动访问外网，配 DNAT 实现外网主动访问内网；云内 VM 和专网、本地网络互通，配专线；传统应用快速上云或互通，云内 VM 和第三方资源池二层互通，配二层桥接，适用场景是本地应用迁移上云且 IP 地址保持不变；跨区域私网互通，配云连接，按需配置路由实现跨 Region 的 VPC 子网间互通，也支持跨云 VPC Peering。

这四种方式的选择逻辑其实是一条判断链，我在方案里一般这么写：

1. 只要单向出网，选 SNAT，成本最低。
2. 需要外部主动访问进来，选 DNAT，别直接给 EIP。
3. 双向都要主动访问，才上 EIP。
4. 对端是客户本地机房，走专线；如果应用迁移要求 IP 不变，再叠加二层桥接。
5. 跨 Region 或跨云，走云连接，路由按需下发。

4.3 一份跨 VPC 访问的期望状态配置

跨 VPC 访问不通是实操题里出现频率最高的场景，原因是配置分散在 peering、路由、安全组、ACL 四个地方。我习惯先把期望状态写成一份描述，再逐项核对。

# 跨 VPC 服务访问的期望状态（示意，字段按实际平台命名调整） peering: name: peer-app-to-svc local_vpc: vpc-app # 发起方 peer_vpc: vpc-svc # 服务提供方 local_cidr: 10.10.0.0/16 peer_cidr: 10.20.0.0/16 routes: - vpc: vpc-app destination: 10.20.0.0/16 # 必须写对端网段，写单台主机地址会漏掉扩容后的实例 next_hop: peer-app-to-svc - vpc: vpc-svc destination: 10.10.0.0/16 # 回程路由，漏了就是典型的单向通 next_hop: peer-app-to-svc security: security_group: sg-app egress: - protocol: tcp port: 8080 cidr: 10.20.0.0/16 # 放行网段而不是单个 IP acl_rule_order: deny_first # ACL 顺序错会表现为“偶尔通”

三个参数值得展开说。destination一定是对端网段，不是对端某一台虚机，否则对方扩容后新实例直接不可达；next_hop指向 peering 名称，很多平台的路由表要求下一跳写成连接名而不是 IP；security.egress.cidr同样用网段，单 IP 放行是排查阶段最常见的人为坑。acl_rule_order这一行是提醒：ACL 是有序匹配的，把放行规则写在拒绝规则后面，效果等于没写。

4.4 用 CloudNetDebug 做定界：先拨测再抓包

教材给了面向运维人员的虚拟网络诊断工具 CloudNetDebug，集成拨测和抓包两个功能。拨测侧新增 vpcep、natgw、elb 拨测能力，可自动化检测业务网络是否断流、是否丢包，快速定界流量中断点；抓包侧新增 VIP 流量抓包，支持 EIP、VPC、DC、VPC-PEERING 等网络流量类型，支持基于业务流的多点协同抓包，也支持灵活的单点虚拟机网卡抓包和主机网卡抓包；底座侧还加固了主动链路探测，新增 ELB 主动链路持续监测重要流量。

之前在传统环境里排查这类问题，运维要手工登录各个节点，上传 tcpdump 工具跑命令行抓包，再下载文件回本地分析，多个点同时抓还要开多个终端，操作繁琐且容易出错。CloudNetDebug 把这一步做成了平台能力，排障流程可以固定成四步：

1. 拨测先行。针对 vpcep、natgw、elb 三类关键网元发起拨测，看是否断流、是否丢包，先把故障范围压到一个网元上。
2. 判定边界。用拨测结果区分是虚拟网络问题还是物理网络问题，这一步决定了后面要不要去网络区看 BR 和 vRouter。
3. 多点抓包。沿业务流在源端、目的端、中间网元同时抓包，打开 VIP 流量抓包，按 EIP、VPC、DC、VPC-PEERING 选流量类型。
4. 排除应用侧。当无法确认是应用还是网络的问题时，抓包结果是最后一锤，能直接排除网络因素。

这套流程的价值在于把“玄学”变成可复现的步骤。教材里提到它解决的痛点是秒级故障定界定位、自动化收集网络故障状态与日志，我一般会让团队把它写进故障手册的第一步，而不是最后一步。

5. 常见问题排查：五类最容易翻车的环节

5.1 混部之后性能抖动，查不出原因

现象：业务上线初期一切正常，扩容或者迁移之后，部分虚机出现周期性延迟抖动，监控上看 CPU、内存、磁盘都不高。

原因：主机组和 AZ 的划分没有按架构和业务等级严格执行，虚机漂移到了异构主机或者混部主机上。教材强调一云多芯是为了让不同算力各司其职，不是让它们混在一个池子里抢资源。

解决：回头把算力池规划清单拿出来核一遍，确认目标主机组的cpu_arch和instance_types与虚机要求一致；对延迟敏感的业务加反亲和策略，避免同一业务的多个实例落到同一台宿主；扩容前先跑一遍第 3 章那段校验脚本，别等出问题再补。

5.2 跨 VPC 访问间歇性不通

现象：两台虚机之间 ping 时通时不通，抓包能看到请求出去，回包不稳定。

原因：三种典型情况。路由只加了单向，回程没加；安全组只放行了单台 IP，对端扩容后新实例不在放行范围；ACL 规则顺序写反，拒绝规则排在放行规则前面。

解决：按 4.3 的期望状态逐项核对，先确认双向路由，再确认安全组和 ACL 用的是网段而不是单 IP，最后看 ACL 的匹配顺序。这三步走完还不通，再上 CloudNetDebug 拨测，别一上来就抓包。

5.3 灾备切换成功，业务起来但连不上

现象：容灾演练时切换动作执行成功，虚机也起来了，但前端调用持续报连接超时。

原因：设计阶段没有保证“切换后网络 IP 和接入访问方式不变”。教材对同城双活的描述很明确：实例级故障自动切换，单部件切换后网络 IP 和接入访问方式不变。如果接入层用的是硬编码 IP 或者没做 DNS 切换，业务侧根本感知不到新实例。

解决：设计阶段就把接入方式固定下来，用域名或负载均衡作为统一入口，切换动作里包含接入层的切换；演练时不要只看虚机状态，要从业务侧发起真实请求验证。

5.4 国产化环境组件起不来，日志看不出问题

现象：部署阶段某个中间件或数据库反复启动失败，日志里只有版本相关的报错，没有明确原因。

原因：跳过了兼容矩阵。操作系统发行版、数据库版本、中间件版本三者之间没有做过交叉验证，尤其在内核参数和依赖库版本上容易出问题。

解决：把 3.3 那张选型表当成部署前的强制检查项，每一层都写明版本号，不确定的组合先在小规模环境验证；镜像来源统一走内网源，避免不同节点拉到不同小版本。

5.5 管理面和业务面抢资源

现象：租户业务高峰时，ManageOne 页面打开缓慢，告警延迟推送，升级操作卡住。

原因：部署分区混用。教材把 External_OM 区、OM_Service 区、计算-管理下沉区、计算-租户区分得很清楚，高阶服务管理面应该下沉到管理区，远程接入组件应该独立在 OM_Service 区，一旦混进租户区，业务流量就会挤占管理通道。

解决：按 2.3 的分区表重新核对部署位置，管理下沉区单独划主机组，远程接入通道做带宽和资源隔离；变更前先确认目标分区，别图省事把组件随手装到有空闲算力的地方。

提示：这五条里有四条的共同根源是“规划阶段省了一步”，而不是实施阶段做错了什么。排查时先怀疑规划，再怀疑配置。

6. 验收与答辩：把架构图讲成一条能自证的链路

验收这一步最容易被糊弄过去，交上去的文档写满“已部署完成”，一问细节就露馅。我一般按下面这张清单逐项过，每项都要有可指认的证据，而不是一句“没问题”。

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