云计算应用赛项这类比赛，真正拉开差距的往往不是谁敲命令快，而是谁对公有云资源的整体规划、网络连通性设计和故障排查路径想得更清楚。这套赛卷5的公有云部分，核心考的就是在限定时间内完成从基础环境搭建到业务上线的全链路操作，涉及计算、存储、网络、安全组、负载均衡等多个模块的协同。我带过几届参赛选手，也做过校内的模拟评审，发现很多同学卡住的地方并不是某个命令不会敲，而是对"为什么要这样配"缺乏理解，导致环境一变就手足无措。下面我按实际备赛和带训的经验，把这套赛卷的公有云部分拆开讲透，从整体设计思路到每个环节的实操细节，再到常见坑点的排查方法，尽量做到你拿着就能照着练、照着改。

1. 赛项整体设计与公有云模块定位

1.1 这套赛卷到底在考什么

公有云赛项的本质，是在模拟一个真实的中小企业上云场景。赛卷给出的通常是一组业务需求描述，比如"某单位需要部署一套Web应用，要求具备一定的高可用能力，数据库与Web服务分离，对外通过统一入口访问"，然后要求选手在云平台上把这一整套环境搭出来并验证连通性。它不像传统运维考试那样给你明确的命令清单，而是给你目标和约束条件，让你自己决定用哪些云产品、怎么组网、怎么配安全策略。

从赛卷5的公有云部分来看，考核点集中在几个方向：云服务器（ECS/云主机）的创建与初始化配置、虚拟私有网络（VPC）与子网的规划、安全组规则的精细化配置、弹性公网IP的绑定、负载均衡的挂载与健康检查、对象存储的挂载或访问、以及云数据库的部署与连接测试。这些模块单独拿出来都不算难，难的是它们之间的依赖关系和先后顺序——网络没通，后面所有服务都连不上；安全组没放行，健康检查永远显示异常。所以备赛的第一课，永远是先把整体架构在纸上画出来，理清依赖链，再动手。

我见过不少选手一上来就急着创建云主机，结果子网网段和后续要连的数据库网段冲突，或者安全组默认拒绝所有入站导致后面反复调试。这种返工在赛场上极其致命，因为时间就那么点。所以我的建议是，拿到赛卷先花五到八分钟做架构设计，把VPC网段、子网划分、各主机角色、端口开放清单全部列清楚，再开始操作。

1.2 为什么公有云部分要这样设计考核结构

赛项设计者的逻辑其实很清晰：公有云运维的核心能力不是记住某个按钮在哪，而是具备"资源规划—部署实施—连通验证—故障定位"的完整闭环思维。所以赛卷把考核拆成了几个递进的层次。第一层是基础资源创建，考的是你对云平台控制台的熟悉程度和参数理解；第二层是网络与安全配置，考的是你对VPC、子网、路由、安全组的整体把握；第三层是应用部署与联调，考的是你把多个云服务串起来解决实际问题的能力；第四层往往还埋了一些故障场景，考的是排查思路。

这种结构决定了备赛策略：不能只练单项操作，必须练整套流程的连贯性。我通常让选手做限时全流程模拟，从零开始到业务可访问，记录每个环节耗时，找出瓶颈。很多人单项操作很熟，但一到全流程就手忙脚乱，问题就出在环节之间的衔接上——比如创建完云主机忘了绑定公网IP，或者负载均衡后端挂载时选错了端口。这些衔接点才是拉开分数的地方。

1.3 公有云与私有云部分的衔接关系

这套赛卷通常公有云和私有云两部分是有关联的，公有云部分搭的是对外业务入口和弹性计算资源，私有云部分可能是内部管理系统或数据支撑。理解这个衔接关系很重要，因为有些赛卷会要求公有云和私有云之间做网络互通或者数据同步。虽然赛卷5的具体要求要以卷面为准，但从备赛角度，我建议把"跨环境连通"作为一个专项来练，包括对等连接、路由配置、安全策略放行这些操作。哪怕这套卷子没直接考，练熟了对你理解整体架构也有好处，而且这类考点在历年赛卷中反复出现。

2. 基础资源规划与网络设计的关键细节

2.1 VPC与子网划分：先把地基打对

公有云环境里，VPC就是你的专属虚拟网络，子网是VPC内的网段切分。赛卷通常会给出网段约束，比如"使用10.0.0.0/16作为VPC网段"，然后要求你划分出Web子网、应用子网、数据子网等。这里第一个关键决策是子网掩码怎么定。我的经验是，Web层子网可以给/24（254个可用地址），应用层给/24，数据层给/24，这样每个子网都留足余量，同时便于用安全组做分层隔离。如果赛卷明确要求节省地址空间，那再考虑/25或/26，但一般比赛环境不会卡这么死。

划分的时候有个容易忽略的点：子网网段不能重叠，而且要和后续可能用到的对等连接、专线网段错开。我见过有选手把VPC设成10.0.0.0/16，子网用了10.0.1.0/24和10.0.2.0/24，结果赛卷后面要求和对端10.0.1.0/24互通，直接冲突。所以规划时最好把整个10.0.0.0/8的空间在脑子里过一遍，给未来留出扩展余地。

具体操作上，创建VPC时填好名称和网段，然后逐个创建子网，每个子网指定所属VPC、可用区、网段。可用区选择上，如果赛卷要求高可用，Web层子网可以跨两个可用区各建一个，后面挂负载均衡时后端就能分布在不同可用区。如果赛卷没要求，单可用区也能满足基本功能，但建议至少把数据层和应用层放在同一可用区以减少延迟变量。

2.2 安全组设计：最小权限原则的落地

安全组是公有云里最容易被配错、也最容易丢分的地方。它的本质是有状态的虚拟防火墙，控制进出云主机的流量。赛卷通常会要求"仅开放必要端口"，这就是在考最小权限原则。我的做法是先列一张端口清单表，把每个角色需要开放的入站端口写清楚，再逐条配规则。

这张表看着简单，但实操中很多人会图省事直接开0.0.0.0/0全放行，赛卷如果明确要求最小权限，这样配直接扣分。更隐蔽的坑是安全组的方向搞反——入站和出站规则要分清，数据库只需要接受应用层的入站，出站一般默认全放行即可。还有一点，安全组是有状态的，意味着你放行了入站请求，对应的响应流量会自动放行，不需要额外配出站规则，这个特性要理解清楚，不然会配出一堆冗余规则。

另外，安全组可以关联多台主机，也可以一台主机关联多个安全组，规则取并集。利用这个特性，可以把"基础管理规则"做成一个安全组复用到所有主机，再给每台主机叠加角色专属安全组，管理起来更清晰。赛场上时间紧，提前想好这种复用策略能省不少操作。

2.3 弹性公网IP与带宽规划

公网IP的分配策略也是考点之一。通常赛卷会要求Web层或负载均衡绑定公网IP对外提供服务，而后端应用和数据库不直接暴露公网。这里要注意，弹性公网IP是可以解绑再绑定的，赛卷有时会考"将公网IP从A主机迁移到B主机"这类操作，所以别把IP和主机绑死思维。

带宽方面，比赛环境一般给固定带宽或按流量计费，选按带宽计费时给个适中值即可，比如5Mbps，够用又不浪费。如果赛卷明确要求"保证业务访问流畅"，可以适当调高到10Mbps。这里有个实操细节：绑定公网IP后，云主机的网卡需要确认是否自动获取到了公网地址，有些平台是NAT方式，主机内看到的还是私网地址，但对外可达，验证时用curl访问外部地址测试即可，别在主机内ifconfig里找公网IP，找不到是正常的。

3. 云主机创建与初始化配置实操

3.1 镜像选择与规格匹配

创建云主机时，镜像和规格的选择直接影响后续操作效率。赛卷一般会指定操作系统，比如CentOS 7.x或某国产Linux发行版。如果没指定，我建议选你平时最熟的发行版，因为后面要敲大量命令，熟悉的环境能减少失误。规格上，Web层给2核4G足够，应用层2核4G，数据库层建议4核8G（如果赛卷允许），因为数据库启动和查询对内存敏感。比赛环境资源通常有限，别一上来就选最高配，够用就行，把资源留给关键角色。

镜像选择还有个细节：有些平台提供"已预装环境"的镜像，比如预装好Nginx或MySQL的，用这种能省安装时间。但如果赛卷要求"从纯净系统开始配置"，那就老老实实选基础镜像。我建议备赛时两种都练，因为不同赛卷要求不一样，而且从纯净系统装一遍能加深对依赖关系的理解。

3.2 登录方式与初始化脚本

登录方式通常有密码和密钥对两种。比赛环境建议用密钥对，更安全也更符合规范，但如果赛卷没强制要求，密码方式操作更快。创建时设置好密码或下载密钥，登录后第一件事是更新系统时间（timedatectl set-timezone Asia/Shanghai）和确认网络连通（ping网关和外网地址）。时间不同步会导致后面证书、日志、数据库连接出各种诡异问题，这个坑我踩过不止一次。

初始化脚本方面，我习惯在创建时就通过"用户数据"注入一段启动脚本，自动完成基础配置，比如关闭防火墙（注意：公有云环境通常用安全组代替主机防火墙，主机内firewalld可以关掉避免冲突）、安装常用工具、配置时间同步。这样主机一启动就是可用状态，省去逐台登录配置的时间。用户数据脚本用cloud-init格式，开头加#!/bin/bash，内容就是普通shell命令，平台会在首次启动时执行。这个技巧在批量创建多台主机时特别有用。

#!/bin/bash timedatectl set-timezone Asia/Shanghai systemctl stop firewalld systemctl disable firewalld yum install -y vim net-tools curl wget echo "init done" > /tmp/init.log

这段脚本看着简单，但能帮你省下每台主机好几分钟的手动操作，多台主机累积起来就是可观的時間优势。

3.3 主机名与hosts规划

多台主机协同时，主机名和hosts解析能大幅简化后续配置。我习惯按角色命名，比如web01、app01、db01，然后在每台主机的/etc/hosts里写好对应关系。这样后面配负载均衡后端、数据库连接串时直接用主机名，不用记IP，也不怕IP变动。赛卷如果要求用IP直连，那就在hosts里也写上，双保险。

hosts配置示例：

10.0.1.10 web01 10.0.2.10 app01 10.0.3.10 db01

这个操作花不了一分钟，但后面能避免大量"这个IP是哪台机器"的困惑。尤其是排查连通性问题时，用主机名ping一下就知道解析对不对，比翻控制台查IP快得多。

4. 负载均衡与应用部署联调

4.1 负载均衡的监听与后端配置

负载均衡是公有云赛卷的高频考点，核心是配好监听器、后端服务器组和健康检查。监听器配协议和端口，比如HTTP:80；后端服务器组挂载实际提供服务的云主机和端口；健康检查定期探测后端，异常时自动摘除。这里的关键参数是健康检查的路径和间隔。路径要指向一个能返回200的页面，比如/health.html或首页；间隔一般给5秒，超时3秒，不健康阈值3次，健康阈值2次，这套参数在比赛环境足够灵敏又不会误判。

实操中常见的错误是健康检查路径配了但后端没这个文件，导致一直显示异常。解决办法很简单，在后端Web服务器的站点根目录放一个静态文件，内容随便写个ok，确保能访问。另外，后端端口要和实际服务监听端口一致，我见过配了8080但服务跑在80上的，排查半天才发现端口对不上。

负载均衡的安全组也要注意，它需要能访问后端服务器的服务端口，所以后端安全组要放行来自负载均衡网段（或负载均衡实例IP）的入站流量。如果后端安全组只放行了公网来源，负载均衡的健康检查流量会被拒，后端永远显示异常。这个依赖关系一定要在规划阶段就理清。

4.2 Web服务部署与验证

Web层通常部署Nginx或Apache，赛卷可能要求部署特定应用或静态页面。部署完成后，先在主机内用curl localhost验证服务正常，再通过负载均衡的公网地址访问验证。如果主机内正常但负载均衡访问异常，问题基本锁定在安全组或健康检查配置上。这个分层验证的思路很重要，能把问题范围快速缩小。

Nginx的基础配置不复杂，关键是站点根目录、监听端口、以及如果有反向代理需求时的proxy_pass配置。赛卷如果要求Web层反向代理到应用层，那proxy_pass要指向应用层的内网地址和端口，同时应用层安全组要放行Web层网段的访问。这一层层的依赖，就是前面强调要先画架构图的原因。

server { listen 80; server_name _; location / { root /var/www/html; index index.html; } location /api/ { proxy_pass http://app01:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这段配置里，/api/路径的请求被转发到应用层，其余走静态页面。赛卷如果没这么复杂的要求，配个静态站点即可，但反向代理这个技能建议练熟，因为它是Web层与应用层解耦的标准做法。

4.3 数据库部署与连接测试

数据库层通常部署MySQL或同类关系型数据库，赛卷可能要求创建指定库、用户和授权。部署后关键验证两点：一是数据库服务正常启动并监听端口，二是应用层能通过网络连接到数据库。第一点用systemctl status和ss -tlnp确认，第二点用应用层主机上的mysql客户端测试连接。

连接测试命令：

mysql -h db01 -P 3306 -u appuser -p -e "show databases;"

如果连不上，按这个顺序排查：数据库服务是否启动、数据库是否监听0.0.0.0（而不是仅127.0.0.1）、数据库安全组是否放行应用层网段、应用层到数据库的网络路由是否通。这个排查顺序是从内到外，先确认服务本身没问题，再查网络和安全策略，效率最高。

数据库配置文件里bind-address这个参数经常被忽略，默认可能是127.0.0.1，只允许本机连接，改成0.0.0.0或具体内网地址才能被远程访问。改完记得重启服务。另外，创建用户时授权范围要写对，'appuser'@'10.0.2.%'表示只允许应用子网段连接，比'appuser'@'%'更符合最小权限要求，赛卷如果考安全规范，这样配更稳妥。

5. 常见故障排查与避坑经验实录

5.1 连通性问题排查速查表

公有云环境里的连通性问题占了故障的大头，我把常见现象和排查方向整理成表，赛场上按表走能省不少时间。

这张表是我带训时反复用的，基本上八成连通性问题都能在里面找到方向。核心思路就是分层排查：先确认服务本身正常，再查主机防火墙，再查安全组，最后查路由和公网绑定。从内到外，逐层排除。

5.2 几个容易丢分的细节

第一个细节是资源命名规范。赛卷有时会要求按特定规则命名资源，比如"VPC名称包含考生号"或"主机名按角色+序号"。这种要求看着琐碎，但没做到直接扣分，而且评审时一眼就能看出来。我的习惯是创建任何资源前先看一眼赛卷的命名要求，统一按规则来，别嫌麻烦。

第二个细节是操作留痕。有些赛卷要求提交操作截图或配置文档，这时候如果你操作时没截图，事后补很麻烦。建议养成习惯，每完成一个关键环节截一张图，按环节命名存好，最后统一整理。这个习惯在真实工作中也有用，变更记录是运维的基本素养。

第三个细节是时间管理。公有云部分通常有时间限制，我建议把时间切成几块：规划5分钟、基础资源创建15分钟、网络与安全配置10分钟、应用部署20分钟、联调验证15分钟、留10分钟缓冲。这个分配不是死的，但要有意识控制节奏，别在某个小问题上卡太久。遇到卡壳超过5分钟的，先跳过做后面的，最后回头处理，保证整体完成度。

5.3 赛前模拟训练建议

备赛阶段最有效的训练方式是全流程限时模拟。我通常让选手按赛卷要求从零搭一遍，全程计时，记录每个环节耗时和卡壳点。第一遍肯定慢，可能超时一倍，没关系，重点是找出不熟的环节。第二遍针对薄弱环节专项练，第三遍再全流程，一般三遍下来就能稳定在时限内完成。

模拟时还要刻意制造故障。比如故意配错安全组、故意把健康检查路径写错，然后练习排查。这种"自找麻烦"的训练方式能大幅提升赛场应变能力，因为赛卷里埋的故障点往往就是这些常见错误。练到看到现象就能条件反射地想到排查方向，基本就稳了。

另外，建议把常用命令和配置片段整理成一个速查文档，赛前反复看。公有云操作虽然以控制台为主，但主机内的配置还是靠命令行，熟记常用命令能省下大量查文档的时间。这个速查文档不用很正式，就是你自己看得懂的笔记，越精简越好。

6. 对象存储与扩展服务的实操要点

6.1 对象存储的访问配置

赛卷5的公有云部分如果涉及对象存储，通常考的是创建存储桶、上传文件、配置访问权限、以及通过API或命令行访问。对象存储的核心概念是桶（Bucket）和对象（Object），桶是命名空间，对象是实际文件。创建桶时要注意区域选择和访问权限设置，赛卷如果要求"仅授权用户可读"，那就配私有权限加临时授权，别图省事配公有读。

通过命令行访问对象存储一般用平台提供的客户端工具，配置好访问密钥后就能上传下载。这里的关键是密钥管理，赛卷如果给了密钥就用给的，没给就在控制台创建一对，注意密钥只在创建时显示一次，务必当场保存好。我见过选手创建完密钥没保存，后面只能重新创建，浪费时间。

上传文件后验证访问权限是个考点。私有桶的文件直接访问会返回403，需要用带签名的临时URL访问，或者通过授权账号访问。这个机制要理解清楚，不然会误以为上传失败。赛卷如果要求"生成一个有效期1小时的下载链接"，那就是考临时签名URL的生成，客户端工具一般都有对应命令。

6.2 云监控与告警配置

部分赛卷会考云监控的基础配置，比如给云主机设置CPU使用率告警。这个操作不复杂，但要注意告警规则的参数设置：监控项选CPU使用率，阈值设80%，持续3个周期，通知方式按赛卷要求配。参数本身不难，难的是理解"持续周期"的含义——它表示连续几个采集周期都超过阈值才触发，避免瞬时波动误报。这个细节理解了，配起来就不会错。

告警配置完成后，赛卷可能要求验证告警能正常触发。验证方法是在主机内跑个压测命令把CPU打高，等几个周期看是否收到告警。压测用stress工具或简单的死循环脚本都行，注意别把主机跑挂了，适度压测即可。这个验证环节很多人会跳过，但赛卷如果明确要求"验证告警有效性"，跳过就丢分了。

6.3 弹性伸缩的基础认知

弹性伸缩在赛卷中出现频率不算最高，但属于加分项。核心是配置伸缩组、伸缩策略和冷却时间。伸缩组定义最小、最大和期望实例数，伸缩策略定义触发条件（如CPU高于70%扩容），冷却时间防止频繁伸缩。这套机制理解起来不难，但配置时容易漏掉负载均衡关联——伸缩组创建的实例要自动挂到负载均衡后端，否则扩容了也没流量进来。

如果赛卷考弹性伸缩，建议先把基础环境跑通再配伸缩，因为伸缩涉及镜像、启动配置、负载均衡关联多个环节，基础不牢容易连环出错。配置完可以用手动调整期望实例数的方式验证伸缩是否生效，比等CPU触发快得多。

7. 收尾验证与交付检查

7.1 端到端验证清单

所有配置完成后，必须做一遍端到端验证，确保整条链路通畅。我习惯按用户访问路径走一遍：从公网访问负载均衡地址，看是否返回预期页面；从Web层访问应用层接口，看是否正常响应；从应用层连数据库，看是否能查询数据。每一步都确认，别假设"应该没问题"。

验证清单可以列成表，逐项打勾：

• 公网访问负载均衡地址返回200
• 负载均衡后端健康状态全部正常
• Web层反向代理到应用层接口正常
• 应用层连接数据库查询正常
• 各主机安全组规则符合最小权限
• 资源命名符合赛卷要求
• 关键操作截图已保存

这张清单花五分钟走一遍，能避免大量"以为配好了其实没通"的问题。赛场上最怕的就是自我感觉良好，结果评审一测全是问题。

7.2 配置文档整理

如果赛卷要求提交配置文档，那就在验证通过后立即整理，别拖到最后。文档内容一般包括架构说明、资源清单、关键配置截图、验证结果。架构说明用文字描述各层角色和依赖关系，资源清单列清楚每台主机的规格、IP、角色，关键配置截图按环节贴好。文档不用写得多漂亮，清晰完整就行，评审看的是内容不是排版。

整理文档时顺便做一次自查，看看有没有遗漏的配置项或者不符合要求的地方。这个过程往往能发现一些操作时忽略的细节，比如某个安全组规则多开了一个端口，或者某台主机命名不规范。发现就改，改完再更新文档，确保文档和实际环境一致。

7.3 赛场心态与节奏控制

最后说点软性的东西。公有云赛项操作量大，节奏快，心态很容易崩。我的经验是，进场先深呼吸，把赛卷通读一遍，用笔在纸上画出架构和步骤清单，然后按清单走。每完成一项划掉一项，这种可视化的进度能有效缓解焦虑。遇到卡壳别慌，按排查表走，实在搞不定先跳过，保证整体完成度优先。

还有一点，别跟旁边的选手比进度。每个人节奏不一样，你看到别人做得快可能只是他跳过了某些步骤，最后验证时问题一堆。专注自己的清单，稳扎稳打，比盲目求快靠谱得多。我带过的选手里，最后拿高分的往往不是操作最快的，而是每一步都验证到位、交付完整的。

这套赛卷的公有云部分，说到底考的是系统性的工程思维和扎实的基本功。把架构规划、网络设计、安全配置、应用联调这几块练透，再通过全流程模拟把节奏磨稳，赛场上正常发挥就能拿到不错的成绩。平时练习时多问自己"为什么这样配"，比死记操作步骤有价值得多，因为赛卷年年变，但底层的原理和排查思路是不变的。