我每年都要批几百份云计算培训作业坦白讲大部分作业一眼就能看出来是临时找命令拼出来的——截图很工整流程也顺利得不像话但问到为什么这么设计、为什么选这个规格、为什么开两个实例而不是一个就答不上来了。作业的真正价值不是证明你敲会了十条命令而是逼着你按一个真实项目的方式去思考网络怎么划、资源怎么配、服务怎么部署、出了问题怎么查。这份作业做得好不好几乎直接决定了你之后能不能干好云计算运维工程师这行。这篇文章就围绕一份典型的“云上高可用Web应用部署”培训作业展开把我带新人、批作业时反复强调的东西整理出来。从方案设计、核心知识点到用免费资源把作业跑通、写成文档再到最容易踩的坑和加分项全都会讲到。适合正在赶培训作业的学生、想转云计算运维的初学者也适合带新人的团队Leader。如果你把这篇从头读到尾并且照着做一遍我保证你交出去的作业跟别人不在一个层次。1. 先想清楚这份作业到底在考你什么很多人拿到作业题就开始开虚拟机、瞎装环境装完发现资源不够用或者文档写了一半不知道怎么写下去。这其实是因为没想清楚一件事作业题的长篇要求背后到底在考你的哪几种能力。1.1 一份典型的云计算培训作业长什么样我见过太多版本的作业题去掉壳子核心几乎都是这个套路“假设你所在的小组要把一个内部管理系统迁移到公有云要求你完成一份云资源规划与部署说明并登录云平台真实创建资源来验证方案。要点包括网络划分、计算资源选型、数据库配置、高可用设计、监控告警、安全加固和成本预算。”你仔细拆一下就会发现它表面上是在让你部署一套东西实际上考的是四层能力。第一层是需求分析你得搞清楚这个系统是给谁用的、大概多少人访问、跑的是Web服务还是计算任务。第二层是架构设计网络怎么划、要不要跨可用区、哪些组件非上不可。第三层是资源选型CPU内存给多少、数据库选哪个引擎、用按量还是包年。第四层才是动手实施创建资源、部署服务、验证效果。绝大多数人栽就栽在最前面两层。他们不做需求分析上来就创建一台8核16G的大实例看起来豪华实际上既浪费钱也暴露了“没有真实项目概念”的短板。反过来你先花半小时想清楚“这个系统只需要2核4G的Web服务器再加上一台2核4G的数据库就够了”文档里讲明白理由老师对你的评价会完全不同。1.2 为什么我建议你先画一张架构图再动手画架构图不是形式主义它是逼你把依赖关系理顺的最快方式。你画一笔“应用服务器需要访问数据库”就会想到安全组必须放行数据库端口画一笔“公网用户要访问负载均衡”就会想到SLB需要公网IP后端服务器反而只需要内网访问。这些思考如果不画图你在创建资源的时候很容易漏掉。具体到一个人做作业的场景我建议先列一个组件清单并给每个组件标注“必须”还是“加分”。比如VPC与子网、安全组、两台云主机、负载均衡、云数据库、对象存储、云监控这些是必须项它们构成了一个完整的“最小闭环”。弹性伸缩、CDN、堡垒机、容器服务则是可选加分项免费额度够的话可以加不够关掉也不影响作业核心。这里有一个很关键的经验先跑通最小闭环再往里面加料。很多同学一上来就开五六个服务安全组规则互相引用端口放行得一塌糊涂最后根本没时间排错。我自己的习惯是第一版作业只做“两台ECS加一台SLB加一个RDS”验证通过之后再决定要不要加OSS存静态文件、再决定要不要加容器。这样即使中间出问题范围也小得多排查起来很快。组件作用对应考察点VPC 子网隔离网络规划网段网络设计能力安全组控制入方向和出方向流量安全加固意识2台云主机ECS跑应用服务计算资源选型负载均衡SLB分发流量实现高可用架构设计能力云数据库RDS托管MySQL等数据库PaaS服务理解对象存储OSS存放静态资源、备份存储服务理解云监控CPU、内存、磁盘告警运维监控意识这个表格里每一项都是我批作业时必看的点。你不在文档里体现老师就只能怀疑你只是把官方教程点了一遍“立即购买”。2. 必须吃透的核心知识点不知道原理作业就是抄命令如果让我给作业档位分类能画出完整架构图的是中等偏上能把每个组件讲清楚为什么这样选才是真正的高分档。这一章我讲三个最核心的知识点它们基本覆盖了所有公有云作业的考查范围。2.1 三大服务模式IaaS/PaaS/SaaS选型不能只写名词解释我批过的作业里十个有八个会在开头写一段“云计算分为基础设施即服务、平台即服务和软件即服务”然后就没了。这跟没写一样。你要做的是在资源选型里自然体现出你对服务模式的理解。拿生活做饭类比。IaaS是你在菜市场租了个摊位炉子、锅、水管、电都得自己搞定你想怎么做怎么做PaaS是直接进了中央厨房锅灶餐具调理台都配好了你只管按菜谱操作SaaS是去餐厅点菜人家做好端上来你甚至不用知道后厨在哪。回到作业里你选择ECS跑应用再选择RDS当数据库这就是一套很聪明的组合。第一应用环境复杂、依赖多你自己用IaaS掌控整个运行时出了问题能排查这展示了你对底层的掌控力。第二数据库是高维护成本的组件你没必要自己搭主从、做备份、修补丁直接用PaaS托管平台帮你搞定高可用你只需要把连接串填进配置文件。两行字一写老师一眼就知道你懂IaaS和PaaS的分工。反过来如果你把数据库也部署在ECS里自己装作业也不是不能跑但架构上就落了下乘因为真实生产环境里没人这么干。2.2 虚拟化与容器实例规格为什么是2C4G而不是4C8G云主机不是真机器它是物理服务器上通过虚拟化切出来的虚拟机。你选的CPU和内存就是这台虚拟机从宿主机分到的份额。所以选规格从来不是“越大越好”而是“够用且可扩展”。作业里最常见的规格是2核4G原因很朴素一台跑Nginx或轻量Java应用的测试服务器2C4G完全够用而且能用免费或低价套餐跑起来。你要是写4C8G甚至8C16G就得在文档里给出说服人的理由比如“预计并发2000需要支撑实时数据处理”否则只会暴露你对资源规划没概念。我见过太多新人以为配置越高越显得专业实际恰恰相反。容器在这里可以当加分项用。你可以用Docker把应用打成镜像在ECS上用docker run把服务跑起来然后在文档里补一句容器解决了环境一致性问题镜像一经构建在任何安装了Docker的机器上都能跑。这句话虽然短但它证明你了解容器和虚拟机的本质区别——虚拟机虚拟的是硬件容器虚拟的是操作系统层。2.3 高可用不能只写“多副本”负载均衡、健康检查、会话保持“高可用”这三个字写起来容易做起来全是细节。你创建了两台ECS然后停掉一台让负载均衡把流量全部打到另一台这个“故障转移”的过程能跑通你的作业就已经赢了一大半。但光有故障转移还不够你需要把负载均衡的细节吃透。健康检查是核心负载均衡每隔几秒会去探测后端的指定路径比如/或者/health如果连续多次探测失败就把这个节点摘除等它恢复后自动加回。我在作业里一般建议把健康检查的超时设为3秒、间隔5秒、连续2次失败判为异常这组参数不容易把偶发抖动误判成故障。会话保持也是高频追问点。如果你的系统有登录态而负载均衡没有开启会话保持用户A第一次请求打到节点1第二次刷新被分到节点2节点2没有他的登录session直接把人踢回登录页。这个坑在真实项目里非常容易出现。作业里你不需要真的模拟登录页面但在文档里主动写一句“本方案开启会话保持避免登录态在多节点间跳转失效”老师就会知道你踩过这条路。高可用只做到“两台机器”其实是不够的我建议你把两台ECS放在两个不同的可用区。可用区你可以想象成同一座城市里不同的机房跨可用区部署意味着即使整个机房断电你的服务还能被另一机房的机器接住。作业里创建资源时这一步几乎零成本却能让你的架构描述从“多副本”升级到“跨可用区容灾”。3. 实操干起来用免费资源把作业跑通理论说得再多不落地都是零。这一章我带你从注册账号开始完整走一遍作业实操流程。预算为0也能做关键是选对平台和资源类型。3.1 免费云计算平台怎么选除了Colab这几个也够用很多人一说免费试算就是Colab但Colab更适合跑Python和机器学习不适合模拟一台完整的云服务器。做云计算培训作业你需要的是能创建VPC、安全组、云主机、负载均衡这些完整网络资源的平台而且最好有免费试用额度。我比较推荐的做法是优先用国内公有云的免费试用或开发者体验套餐因为访问方便、文档齐全、遇到问题更容易找到人问。阿里云、腾讯云、华为云都有针对新用户的免费试用和体验实验室基本覆盖一台1核2G或2核4G的轻量云主机外加免费的云数据库小规格。新用户实名后一般能领到1到3个月的试用够你交作业了。如果你想让作业“国际化”一点也可以考虑国际主流云的免费层。AWS Free Tier提供12个月内每月750小时的1核1G实例Google Cloud有90天试用赠金和永远免费的轻量实例Oracle Cloud的免费层是永久性的给ARM架构的实例额度还不错跑个测试Web服务绰绰有余。这里要注意这类平台通常需要绑定信用卡做身份验证只是验证不会扣费但一定要看清额度说明避免超用量产生账单。另外如果学校用的是在线实践教学平台比如头歌这类云计算实验环境那我建议你直接在上面做。因为环境已经内置好了默认账号和网络都配置齐全你少踩至少一半的环境搭建坑。平台选择没有绝对好坏核心原则是以最快速度拿到一台能创建云资源的账号然后立刻开始做而不是纠结“哪个平台更好”纠结一下午。3.2 从零搭建作业环境的完整步骤下面这套步骤我以国内某公有云为例但每个平台的界面都大同小异你迁移到任何平台都能照做。整个过程的目标只有一个通过负载均衡访问到两台Web服务器验证轮询和高可用。第一步注册账号并完成实名认证然后在控制台找到免费试用入口按列表领取云主机、云数据库、负载均衡的试用名额。这里务必注意看清试用周期和额度比如“有效期30天、金额80元”意味着你只在这个范围内超量才付费。第二步规划网络。创建VPC网段用172.16.0.0/16然后在里面建两个子网分别放在可用区A和可用区B网段可以切成172.16.1.0/24和172.16.2.0/24。子网规划的意义是让你后面的云主机可以各取一个网段、放在不同可用区。第三步创建安全组入方向放行22SSH和80HTTP来源地址按需填0.0.0.0/0这就是“允许所有人访问Web”出方向默认全放行。然后把这组规则在文档里写清楚。第四步创建两台云主机。选Ubuntu 22.04或CentOS Stream都行规格2C4G分别加入刚才两个子网同时绑上安全组。如果没有免费实例额度就买最便宜的按量付费作业做完马上释放成本也就是一两块钱。第五步SSH连上每台机器安装Nginx并写一个区分页面的测试页。命令如下# 更新系统包索引 sudo apt update # 安装Nginx sudo apt install -y nginx # 写入节点标识页面node1和node2分别写不同的内容 echo h1Web Server Node-1/h1 | sudo tee /var/www/html/index.html # 启动并设置开机自启 sudo systemctl restart nginx sudo systemctl enable nginx第二台机器只需把Node-1改成Node-2。第六步在每台机器上验证一下本机访问curl http://localhost看到Web Server Node-1或Node-2说明服务和防火墙正常。第七步创建负载均衡实例。类型选“公网”监听协议选HTTP端口填80。添加后端服务器组时把两台ECS加进去权重均等端口是80健康检查按我之前说的参数设。第八步创建云数据库RDS选MySQL 8.0规格可以选最小的免费或低价规格设置管理员账号和密码然后把“允许访问的IP”添加成两台ECS的内网IP网段。这一步很多人会漏RDS默认白名单只允许自己的IP访问你应用服务器连不上多半就是白名单没加。第九步验证核心功能。浏览器访问负载均衡的公网IP第一次刷新看到Node-1再刷新看到Node-2这就说明轮询和健康检查都在正常工作。然后到控制台把其中一台云主机关机再连续刷新几次你会发现流量全部落到了存活的那台。把“故障转移成功”的结果截图这比任何文字都更有说服力。第十步配置云监控告警。在云监控里创建两条规则一条是CPU使用率超过80%持续5分钟则告警另一条是磁盘使用率超过85%告警通知方式填邮箱。把告警规则截图放进文档这就是“运维闭环”里的一环。3.3 把每一步都记录下来作业文档怎么写出含金量文档不是流水账它是一份你交给导师甚至交给面试官看的“项目交付物”。我建议按这个结构组织先写背景与目标再贴总体架构图然后是资源清单表格接着按“网络、计算、存储、数据库、负载均衡、监控”分章节写实施步骤最后要有一段功能验证和一段问题记录。写实施步骤时记住三个原则。第一每个关键命令都要带一行注释说明这条命令是干什么的。第二每完成一个环节就贴一张核心截图截图里要能看出来是你在操作不能只是官方文档的截图。第三不要让步骤看起来“太顺”真实项目实施一定会有波折所以问题记录这一段特别重要。有一个经验我想单独说一下老师批作业的时候最反感的不是笨而是“假”。如果整份作业毫无失败记录全程一次成功那大概率是照着教程抄的。你如实写上一两个你实际遇到的故障比如“第一次安全组忘了放行80端口导致浏览器访问超时通过telnet排查发现端口不通最后检查安全组规则才发现问题”这种真实的排障记录比十个“成功截图”都加分。4. 作业里最容易踩的坑这些坑我都替你趟过我批作业这些年发现大家踩的坑高度一致。下面这五个坑你只要提前知道就能省下大半天排查时间。4.1 实例在公网连不上按“链路顺序”一层层查最常见的故障就是云主机创建好了用SSH或者浏览器怎么都访问不通。这时候你按链路顺序一层层查不要瞎试。第一层查云平台安全组看22和80端口是否放行以及来源IP是否合法第二层查子网关联的网络ACL看有没有隐含的拒绝规则第三层查操作系统防火墙CentOS看firewalldUbuntu看ufw第四层查服务本身有没有监听在正确地址上。给你一套排查命令# 查Nginx是否在运行 systemctl status nginx # 查80端口是否在监听 ss -lntp | grep 80 # 查本机防火墙规则CentOS iptables -L -n # 用本机IP直接访问测试 curl http://你的内网IP按我经验70%的“连不上”出在安全组或OS防火墙只有少数是服务没启动。所以别一上来就重装系统冷静按顺序查半小时内必定位。4.2 免费资源到期被强制回收免费试用一定是有期限的常见的是30天。交完作业一周后平台监测到你试用到期会把资源回收你没来得及导出的配置和数据库就全没了。我建议从做作业第一天起就建立一个备份习惯一台机器的Nginx配置、应用代码、数据库Dump文件边做边导出到本地或对象存储。作业提交前把关键截图、资源清单、配置文件全部整理归档一次。还有一点在文档的“资源与成本管理”小节里主动写一句“本方案考虑到试用期限制建议在生产环境中使用包年包月或按量付费搭配弹性伸缩作业完成后释放非必要资源以避免额外费用”。这句话能让老师一眼看出你有运维成本意识是很典型的高分表达。4.3 负载均衡健康检查一直失败健康检查失败的表现是负载均衡的后端服务器状态一直是“异常”流量永远进不去。最常见的两个原因一是后端服务监听的端口跟健康检查端口不一致。比如Nginx监听80你却给健康检查配了个8080那必然失败二是健康检查路径不对比如后端应用在/路径返回的是403而非200探测就认为失败。排查方法特别简单登录每台ECS本机curl一下你填的健康检查路径确认返回状态码是200。如果返回是403或302就把路径换成精确存在的资源比如单独建一个/health.html静态文件内容随便写然后健康检查路径填/health.html。这个小技巧在线上项目里也特别实用。4.4 作业文档“太过完美”反而像抄的这一点值得你反复琢磨。一份真实完成的作业中间一定会有“一开始这么部署有问题后来改成那样解决了”的记录。它不是为了假装努力而是展示你排障的思考链条。老师批了几百份作业扫一眼就能看出哪些是截图拼出来的。所以你哪怕只写一个真实的小问题也强过通篇“点击创建、立即生效”的顺滑流程。4.5 常见问题速查表现象可能原因排查命令/方法SSH连不上安全组未放行22端口控制台检查安全组入方向规则浏览器访问超时安全组未放行80/443或OS防火墙开启curl http://本机IP本机验证负载均衡后端异常健康检查路径返回非200curl http://127.0.0.1看状态码RDS连接被拒白名单未加应用IP控制台白名单添加ECS内网IP数据库慢查询规格太小或未走索引看慢查询日志加索引实例被回收免费试用到期提前导出备份关注到期提醒收到账单超出免费额度登录费用中心查看明细并关闭实例这张表可以直接放进你的作业附录里既能帮你自查也能让文档显得更完整。5. 从“作业”到“作品”让老师多给你加分的三个细节前四章讲的都是“把作业做完”这一章讲怎么“把作业做好”。做完和做好之间差的其实就是这几个细节。5.1 用一张把组件全部串起来的架构图架构图不需要多精美但至少要把VPC边界、子网、安全组、ECS、SLB、RDS、OSS、监控这些组件画出来并用线标清数据流向。比如用户从公网访问SLBSLB将请求分发到两台ECSECS通过内网连接RDS同时把静态文件上传到OSSMonitoring服务采集两台ECS的指标。线上工具用draw.io、ProcessOn、Excalidraw都行关键是标注每个资源属于哪个网段、哪个可用区、监听什么端口。我批作业时最欢迎这种图因为它一秒钟就让我知道这份作业的架构是什么样。反过来如果作业最后一段才放一张没标网段的截图我对整体方案的印象分就会大打折扣。5.2 用脚本把部署过程自动化如果你的作业里全是手动点击创建资源的过程那它顶多是一份“操作录屏”。但是你在文档里放一段部署脚本整个感觉就不一样了。脚本意味着你对“部署即代码”有概念意味着你的方案可以重复交付这是运维工程师的基本功。下面是一段最基础的Web服务部署脚本你可以直接拿来放到作业里#!/bin/bash # deploy_web.sh - 一键部署Nginx测试服务 set -e # 出错立即退出 echo [INFO] 更新系统包索引... sudo apt update -y echo [INFO] 安装Nginx... sudo apt install -y nginx echo [INFO] 写入节点测试页面... hostname /var/www/html/index.html echo [INFO] 启动Nginx并设置开机自启... sudo systemctl restart nginx sudo systemctl enable nginx echo [INFO] 部署完成本机验证 curl -s http://127.0.0.1你不需要把这脚本做得多复杂能在两台ECS上分别跑一遍并给出不同结果就足以说明你已经掌握了基础的自动化部署思路。要再加分可以提到“后续可以使用用户数据脚本在创建ECS时自动执行该脚本实现实例初始化即部署”。5.3 成本与性能分析让作业像一份真实的交付物一份好的运维交付物一定会回答两个问题这套系统要花多少钱它能扛住多少并发所以你可以在文档里加两个小节。成本方面列出资源清单和估算费用比如两台2C4G按量付费实例按0.5元每小时、每天运行8小时计算月成本约240元一台小规格RDS按150元每月估算负载均衡按100元每月估算。不用算得特别准关键是展示你有成本意识并且知道哪些资源是主要开销。性能方面用ApacheBench做一次简单压测# 安装压测工具 sudo apt install -y apache2-utils # 模拟1000个请求、50并发访问负载均衡IP ab -n 1000 -c 50 http://负载均衡公网IP/关注两个输出指标Requests per second代表每秒能处理的请求数Failed requests代表失败数。如果RPS在几百到上千且没有失败请求说明这套架构作为测试作业完全达标。把压测结果贴进文档再简单分析一句“单台ECS在无缓存的情况下RPS约为xxx两台通过负载均衡后整体提升不明显瓶颈可能在Nginx配置或实例规格生产环境可结合弹性伸缩扩容”这样的分析水准已经超过大多数培训班学员了。最后再补充一个覆盖度自检的技巧。交作业前拿一张纸列出云计算的几个能力域计算、存储、网络、数据库、安全、监控、自动化然后对照你的文档看每一项有没有覆盖到。如果发现某领域只写了名词解释没有实操就补一段“该服务在本方案中的使用说明”。这叫作业覆盖度计算目的不是写更多字而是确保老师要考察的每一点你都给出了自己的答案。我个人这几年批作业最大的感触是能把作业当成一个真实小项目认真对待的人后面面试聊架构时从来不虚。不是因为记了多少命令而是因为他们真正经历过“设计、部署、出错、修复、复盘”这个循环。你交上去的作业本质上就是一份微缩版的运维简历哪怕只是用免费资源搭了两台Nginx只要你把为什么这么设计、踩过什么坑、怎么排查的都写清楚就已经比大多数只会贴官方教程截图的人强出一个身位。希望这篇内容能帮你把作业做成作品。