企业官网建设流程全解析

搞了大半个周末，总算是把云计算作业2这颗硬钉子拔下来了。这门课从第一章开始就在讲云基础设施机制，老师说得很直白：云基础设施机制是云环境的基础构件块，针对计算、存储、网络三个方面。当时听着觉得挺抽象，但作业2一布置下来，“抽象”立刻变成“具体”——这次的作业不只是背概念，而是要求自己动手搭一个最小可用的云环境，把计算、存储、网络三样基础构件都落地，在环境里跑一个小业务，最后还要用“云覆盖度”这个指标量化评估当前环境到底覆盖了哪些需求、哪些地方还缺着。整个过程中踩了不少坑，但也正是因为这些坑，之前课本上那些云部署模型、云服务模型、资源池化、弹性伸缩的概念才真正对上号。这篇就当一份复盘笔记，把做作业2的思路、实操细节和踩坑记录都写出来，给后面选这门课、或者想认真折腾云环境的同学一个参考。不管你是零基础还是有点经验，只要照着这个思路走一遍，至少不会被作业2的文档吓到。

1. 作业需求拆解：先想清楚要做什么，再动手

1.1 作业2到底考什么

第一次看到作业2的题目，我的第一反应是“这真的是一门概论课该布置的作业吗”。一整页的需求文档，没有一句废话，核心就一句话：搭建一套能体现云基础设施机制的最小云环境，并在上面运行业务应用，最后完成云覆盖度计算。老师说得很清楚——云基础设施机制是云环境的基础构件块，针对计算、存储、网络。换句话说，这门课默认你已经理解了云计算的基本概念，作业2要考察的就是你能不能把概念翻译成真正的环境。

我把需求拆成了三层。底层是资源层，要把物理机的CPU、内存、磁盘、网卡抽象成可分配的资源池，这对应教材里的计算机制、存储机制、网络机制。中间是服务层，要能基于资源池创建虚拟机实例、分配存储卷、配置虚拟网络，这对应云环境对外提供的IaaS能力。顶层是验证层，要在搭好的环境里部署一个小应用，可以是博客系统，可以是简单的Web服务，只要能证明“云平台之于业务是可以用的”就行。

关键的一点在于：需求文档里反复强调“云覆盖度”。这个指标不是课本概念，而是需要你自己定义、自己计算、自己解释的东西。我一开始完全没头绪，后来查了一些资料，又看了一些云运维相关的文章，才意识到它在真实行业里其实对应着“配置覆盖率”和“服务覆盖度”的评估思路——简单说，就是拿一套需求清单，逐项检查当前云环境能不能满足，最后算出一个比例。这个思路贯穿了作业2的整个后半段，也是拉开分数差距的地方。

1.2 为什么作业会这样设计

我后来复盘，觉得这个作业的编排非常有意思。作业1基本考概念和计算题，让你把什么是IaaS、PaaS、SaaS，什么是水平扩展和垂直扩展，什么是SLA和可用性这些概念弄得滚瓜烂熟。作业2直接跳进基础设施层，强迫你把抽象概念变成可运行的东西。到了作业3，内容大概率会延伸到容器化、编排或者运维自动化，等于一条线走完云平台从底层资源到上层应用的完整建设路径。

这种设计思路其实和真实云平台的架构一模一样。底层不牢，上层全是空中楼阁；底层太复杂，又没人愿意用。所以课程选择了一个“足够难但又不至于劝退”的平衡点——不要求你部署一套生产级云平台，但要求你至少理解一台虚拟机是怎么从资源池里“长”出来的。

做完之后我的体会是：动手搭一次环境，比背十遍教材都有用。比如“资源池化”这个词，书上解释是“将物理资源聚合成池，按需分配”。听起来很抽象，但当你用virsh命令给一台虚拟机分配内存时，看到空闲资源从2560MB变成512MB，你对“池子”的理解就彻底具象化了。云覆盖度计算也一样，不评估一遍，你永远觉得自己的环境是完整的；真拿需求清单逐条核，才会发现网络策略漏了三条、存储快照没有自动化、监控告警根本没人看。

1.3 我给这次作业定的验收标准

开始动手之前，我给自己列了一份验收清单，防止做着做着就跑偏。清单一共五条。

第一条，资源池可见：计算、存储、网络资源必须以“池”的形式能够通过命令或界面查看总量、剩余量和分配量，而不是散落在各台物理机上。第二条，实例可生命周期管理：能用命令创建、启动、停止、销毁一台虚拟机，并且重启之后数据不丢。第三条，网络可互通：同一子网内的云主机能互相访问，对外能访问外网，且具备最基本的访问隔离。第四条，业务可运行：在云环境里部署一个小型Web应用，能通过浏览器或curl访问，并且数据能持久化存储。第五条，覆盖度可量化：按需求清单算出云覆盖度，给出明确数值、计算过程和优化建议。

这五条验收标准完全是从作业评分维度反推出来的。需求文档虽然没明说要怎么做，但它要求“体现云基础设施机制”“运行业务应用”“完成云覆盖度计算”——三句话对应三条核心评分点，我把它们进一步拆细，就成了上面五条可执行的验收线。事实证明，这个清单救了我好几次，每次卡壳的时候，我只要问自己“这一条对应的验收标准是什么”，就知道下一步该往哪走。

2. 云环境搭建：把计算、存储、网络三块地基打好

2.1 技术选型：自己搭还是用现成平台

做作业之前，我花了整整半天做方案对比。老师说得很开放：“工具不限，只要能体现云基础设施机制，能运行业务应用即可。”常见的路线有三条：一是用OpenStack部署一套完整私有云，二是用KVM加Libvirt手搓一套轻量虚拟化环境，三是直接使用云计算平台的免费额度在线创建资源。

三条路线的优缺点，我直接拉了一张表：

我最后选了KVM加Libvirt这条路线。原因很直接：作业要求体现云基础设施机制，如果我拿到一朵现成的云上点点鼠标，那看到的所有能力都是封装好的成品，底层怎么调度、怎么池化、怎么隔离，全部黑盒，报告根本没法往深里写。而KVM和Libvirt能让我一层一层把虚拟化、存储池、虚拟网络拉出来，每一层都有命令输出可以贴进报告，评分老师一看就知道你真的动了手、理解了机制。

需要注意的是，选型要考虑机器条件。KVM虚拟化要求CPU支持硬件虚拟化扩展，终端用户用笔记本跑会有点吃力，我实际是在实验室的服务器上做的。如果你手上只有普通笔记本，可以先用VirtualBox这种轻量方案临时体验，或者用公有云免费额度做补充验证，但作业报告里的底层机制分析，建议还是尽量基于真实操作来写。

2.2 计算资源池：把CPU和内存变成“池”

计算资源池化是KVM这类Hypervisor最擅长的事情。安装完libvirt之后，默认会生成一个连接，你可以用virsh命令看到宿主机的总资源情况。我当时做的第一件事，就是确认宿主机资源足够：

$ virsh nodeinfo CPU model: x86_64 CPU(s): 16 CPU frequency: 2400 MHz CPU socket(s): 2 Core(s) per socket: 4 Thread(s) per core: 2 NUMA cell(s): 1 Memory size: 33554432 KiB

这台服务器是16核、32GB内存，跑一个最小云环境是足够的。计算资源池化之后，每台虚拟机就是从这个“池”里划走一部分CPU和内存。我当时规划了三台实例：一台控制与业务节点、两台工作节点。控制节点给2核4GB，工作节点给4核8GB，规划时让每台节点至少保留20%的余量，避免资源争抢影响验收。

为什么资源池这个概念很重要？因为在没池化的物理环境下，一台机器跑一个应用，资源是绑死的；而池化之后，资源变成了可调度、可弹性伸缩的状态。你可以先创建一台2核4GB的实例，跑起来觉得CPU吃紧，就再把它调整到4核8GB，整个过程业务无需重装。这种能力在作业验收时也是加分项——我当时的做法是：先用2核2GB创建了一台实例跑Nginx，然后现场演示热调整到2核4GB，再截个图证明调整生效，老师看到这种细节，基本都会给高分。

2.3 存储资源池：镜像格式、数据盘与快照

存储这块，我一开始差点踩坑。KVM后端存储支持多种格式，课程里最常用的是raw和qcow2。raw格式简单直接，性能好，但空间占用太高——创建20GB的raw盘，立刻就要占20GB真实磁盘；qcow2格式是写时复制，创建20GB的盘，实际只占用实际写入的那部分空间，对作业环境这种“看起来大、用得小”的场景非常合适。

# 创建qcow2格式的存储卷，虚拟大小20G $ qemu-img create -f qcow2 /var/lib/libvirt/images/web-data.qcow2 20G Formatting '/var/lib/libvirt/images/web-data.qcow2', fmt=qcow2 size=21474836480 ...

除了镜像格式，存储池也是作业里要展示的内容。Libvirt原生支持目录池、逻辑卷池、磁盘池、NFS池等多种类型。我实际配置的是一个目录池，把宿主机上挂载的独立数据盘作为虚拟机的存储目录：

$ virsh pool-define-as --name data_pool --type dir --target /data/images Pool data_pool defined $ virsh pool-start data_pool Pool data_pool started

存储这块我犯过一个低级错误：第一次创建存储卷时忘记指定格式，默认生成了raw格式，导致同一台机器同时存在qcow2和raw两种镜像，磁盘空间很快报警。这里提醒一下，如果你也对空间敏感，尽量统一用qcow2，并且在创建卷时显式加--format参数。后来我加了快照功能，在对业务做变更前先给虚拟机打快照，这样万一改坏了可以秒回滚：

$ virsh snapshot-create-as vm-web-01 snap-before-upgrade --description "before nginx conf change"

快照的价值在写作业报告时特别明显：你可以截图展示“变更前快照—变更—出问题—回滚—恢复”的完整闭环，这直接对应了云运维里的备份管理机制。评分老师看到这个，至少知道你是真在思考存储和数据可靠性，而不只是把服务跑通就完事。

2.4 虚拟网络：NAT模式、桥接网络与访问隔离

网络是这轮作业里最让我头疼的部分，也是覆盖度计算里扣分最多的地方。Libvirt装完之后，默认会创建一个名为“default”的NAT网络。NAT模式的特点是虚拟机可以访问外网，但外部要访问虚拟机，必须通过端口转发，这在验证“业务对外可访问”时非常麻烦。

我当时想要的拓扑是：宿主机作为网关，三台虚拟机组成一个内部子网，虚拟机之间能互相通信；宿主机对外提供业务入口，通过iptables或Nginx反向代理把流量转发到工作节点。为了实现这个拓扑，我新建了一个自定义桥接网络：

$ sudo virsh net-define /etc/libvirt/qemu/networks/bridge-net.xml $ sudo virsh net-start bridge-net $ sudo virsh net-autostart bridge-net

network XML 内容我简化如下，IP段规划成192.168.100.0/24，网关指向宿主机：

<network> <name>bridge-net</name> <forward mode='nat'/> <bridge name='virbr1' stp='on' delay='0'/> <ip address='192.168.100.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.100.100' end='192.168.100.150'/> </dhcp> </ip> </network>

安全隔离这块，我给自己定义了一套最简单的规则：内部子网内完全互通，外部默认拒绝入站，只有特定端口（比如80、443、22）通过宿主机转发进来。这套规则在真实云平台上对应“安全组”和“网络ACL”，虽然我用iptables实现得比较简陋，但逻辑是同一套。覆盖度计算里网络这一项，我就是在评估策略是否覆盖了这些安全要求。

3. 云覆盖度计算：作业里最容易懵的一个点

3.1 先搞清楚“覆盖度”到底在算什么

“云覆盖度”这个词，在教材里没有标准定义。第一次看到需求文档里出现这个词，我其实是懵的——后来查了资料，又结合我自己对云工程的理解，才找到一个说得通的口径：云覆盖度是指当前云环境的能力，在多大程度上覆盖了预先定义的业务需求和技术需求。

类比一下就知道思路了。你搬家之前会列一张家具清单，搬完后逐项检查“空调有没有装、衣柜有没有到位”，最后算出“入住完成率”。云覆盖度干的就是这件事：把需求列成清单，逐项检查当前云环境是否具备对应的能力，最后汇总成一个比例。

这个口径在真实运维场景里是有对应实践的。业界讲的“配置覆盖率”“服务覆盖度”“巡检覆盖率”基本都是同一套思想。作业要求做云覆盖度计算，本质上是训练这种“需求到能力的映射”能力——你不光要会搭环境，还要会客观评估自己搭的环境到底有多少斤两。

3.2 覆盖度模型：给需求打分，加权算综合值

我把计算分成四步。第一步，明确需求清单，把作业要求覆盖的能力逐条列出。第二步，逐条评估当前环境的满足程度，打分规则很简单：完全支持记1分，部分支持记0.5分，不支持记0分。第三步，给不同维度设置权重，突出核心能力的重要性。第四步，加权汇总，算出综合覆盖度。

我实际用的是这样一张评估表：

这样一共9个需求项，综合覆盖度不能简单平均，因为我希望突出“业务可运行”这个核心目标。我给的权重是计算层0.4、存储层0.3、网络层0.3。计算方式如下：

计算层覆盖度 = (0.5+0.5+0)/3 ≈ 0.33 存储层覆盖度 = (1+0.5+0)/3 = 0.50 网络层覆盖度 = (1+0.5+0.5)/3 ≈ 0.67 综合覆盖度 = 0.4×0.33 + 0.3×0.50 + 0.3×0.67 = 0.483

算出来只有48.3%，我自己都吓了一跳。这个数值很重要——它说明“覆盖率低”不等于“环境没用”，而是说明评估模型里有很多需求项（高性能计算、对象存储、自动弹性伸缩）本来就不是这个最小环境能承担的。所以作业报告的结论不能只写“48.3%”，还要解释清楚：哪些扣分项属于设计范围外，哪些是后续可以迭代补齐的。

3.3 怎么让覆盖度数据更有说服力

云覆盖度计算容易犯的错，是给自己打个虚高的分数。我见过有同学每一项都写1分，最后覆盖度100%，看起来很漂亮，但老师一追问“你的自动弹性伸缩呢？”“你的对象存储呢？”当场就露馅。所以我的思路是：宁可分数低一点，也要让每一项打分都有据可查。

具体做法是给每一条评分配一个“证据”。比如“持久化存储=1分”，证据就是创建挂载卷、写入数据、销毁实例、重新挂载后数据仍在的完整命令记录；“安全组控制=0.5分”，证据就是iptables规则列表和一次外部访问被拒的日志。有了证据链，低分反而比虚高的满分更可信，报告的说服力也会更强。

另外，建议把覆盖度做两层。第一层是“当前能力覆盖度”，就是上面算出来的48.3%；第二层是“业务场景覆盖度”，单独针对你实际部署的那个业务（比如博客系统）来评估，看它需要的计算、存储、网络能力是否全部满足。业务场景覆盖度通常更高，因为场景更聚焦。两层指标放在一起，既能体现环境的通用性不足，又能体现对特定业务的支撑能力，报告的逻辑就立体了。

4. 核心实操过程：从初始化到业务验收

4.1 环境初始化：一台干净服务器该装什么

我的环境是Ubuntu 22.04 Server，宿主机禁用桌面环境，全是命令行操作。初始化的第一步是更新系统并安装虚拟化相关的软件包：

sudo apt update && sudo apt upgrade -y sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virtinst

安装完成后，确认KVM模块是否正常加载。这一步很多人会忽略，但如果不检查，后面创建虚拟机的时候会报一堆莫名其妙的错：

systemctl status libvirtd

如果libvirtd状态是"active (running)"，就可以开始干活了。另外还要把当前用户加入libvirt组，不然每次操作都要sudo：

sudo usermod -aG libvirt $USER newgrp libvirt

这里有个小坑：在部分云服务器或者本身是虚拟机的环境里，宿主机没有开启嵌套虚拟化，qemu-kvm装了也白装。判断方法很简单，一行命令看CPU标志位：

egrep -c '(vmx|svm)' /proc/cpuinfo

如果输出是0，说明当前宿主机不支持硬件虚拟化，或者嵌套虚拟化没开，这种情况下只能改用软件模拟方式，性能差很多但至少能跑通作业流程。我当时在实验室服务器上是正常的值，但在自己笔记本上就遇到过一次0，后来去虚拟机软件的设置里勾选“启用嵌套虚拟化”才解决。

4.2 创建第一批云主机实例

环境就绪后，第一件事是创建一台业务节点。我用的是virt-install命令，参数非常直观：

sudo virt-install \ --name vm-web-01 \ --memory 2048 \ --vcpus 2 \ --disk path=/var/lib/libvirt/images/vm-web-01.qcow2,size=20,format=qcow2 \ --network network=bridge-net \ --os-variant ubuntu22.04 \ --cdrom /home/user/iso/ubuntu-22.04-server-amd64.iso

各参数的含义我给你拆一下：--name是实例名，--memory和--vcpus分别指定内存和CPU，--disk指定镜像路径、大小和格式，--network指定要接入的网络，--os-variant告诉libvirt操作系统类型，--cdrom指定安装镜像。第一次执行这个命令，会进入交互式安装界面，跟装普通系统一样，装完重启就得到了一台云主机。

这里要特别提醒：创建虚拟机之前，一定要先确认存储卷路径所在的目录有足够空间，别学我拿root分区塞镜像，装了三台机器就把根分区挤爆了。我当时单独挂载了一块数据盘到/data/images，然后把存储池建在这里，这样系统盘和数据盘的占用是分开的，后面做大数据量实验也不会影响宿主机稳定性。

创建完三台实例后，可以用下面这条命令看到所有实例的状态：

$ virsh list --all Id 名称 状态 ----------------------- 2 vm-web-01 运行中 4 vm-app-01 运行中 5 vm-app-02 运行中

4.3 部署业务应用：把“云环境”和“业务”连起来

光有虚拟机还不够，作业要求“运行业务应用”。我的方案很简洁：一台业务节点部署Nginx作为入口，两台工作节点部署一个简单的静态网站，再配一下端口转发，让宿主机IP的8080端口能访问到内部网站。

在vm-app-01和vm-app-02上，我写了一个最简单的部署脚本：

#!/bin/bash sudo apt update sudo apt install -y nginx echo "<h1>This is instance $(hostname)</h1>" | sudo tee /var/www/html/index.html

然后回到业务节点vm-web-01，用Nginx做反向代理：

upstream backend { server 192.168.100.101:80; server 192.168.100.102:80; } server { listen 80; location / { proxy_pass http://backend; } server_name _; }

这里演示了两个云计算的经典概念：负载均衡和后端实例组。同一套配置，在真实云平台上就是负载均衡器加伸缩组，Nginx在这里只是“手动版”的实现。作业报告里我把这张拓扑图和Nginx配置放在一起，然后说明这对应了云计算弹性负载均衡中的轮询策略，老师立刻就理解了。

验收时我在宿主机上执行：

curl -H "Host: cloud.test" http://192.168.100.1:8080/

连续刷新几次，看到返回内容在“vm-app-01”和“vm-app-02”之间交替，说明负载均衡生效。那一刻挺有成就感的——课本上的“负载均衡”“实例组”“反向代理”第一次在亲手搭的环境里跑通了。

4.4 运维脚本与基础监控

作业做到后面，我发现手动操作太痛苦，于是写了一个简单的环境状态检查脚本，顺便也作为“云计算运维”的素材写进报告：

#!/bin/bash echo "===== 宿主机资源 =====" free -h echo "" echo "===== 所有实例状态 =====" virsh list --all echo "" echo "===== 存储池信息 =====" virsh pool-list --details echo "" echo "===== 网络信息 =====" virsh net-list --all

这个脚本本身不值钱，但它对应了云运维里的“巡检”动作。后来我又加了一个简单的资源监控循环，把CPU、内存、磁盘的历史走势记录到日志里：

while true; do top -bn1 | head -5 >> /var/log/node_monitor.log sleep 60 done

作业验收的时候，我直接在老师面前跑了一遍巡检脚本，输出三块信息：宿主机资源、实例状态、存储网络状态。这种“一屏看完整套环境”的感觉，比贴十页截图更能说明你理解了运维要关注什么。

5. 常见问题与排查技巧实录

5.1 实例创建失败：先查内存、再查CPU标志位

做作业那几天，最崩溃的一次是创建第三台虚拟机时，virt-install直接报错，提示内容大致是“cannot get domain”，加上一条“internal error: process exited while connecting to monitor”。这类报错在KVM环境里非常典型，原因通常是两类：内存不够，或者CPU虚拟化标志位没识别到。

排查建议按这个顺序来。第一，用free -h看宿主机内存，给多个实例分配的内存总和不能超过物理机内存，并且要给宿主系统留余量。第二，用egrep -c '(vmx|svm)' /proc/cpuinfo检查CPU虚拟化是否开启，如果值是0，大概率是嵌套虚拟化没开。第三，用journalctl -u libvirtd查看libvirtd日志，它会记录更具体的错误信息。我当时就是第一台机器给了8GB，第二台给了8GB，第三台还想给8GB，直接超了物理机32GB的配额，减到4GB之后一切正常。

5.2 虚拟机起不来但没报错？看日志

virsh start的时候，有时候会看到一个很正常的“Domain started”，但等两秒虚拟机就自动挂掉了。这种情况比较隐蔽。我遇到一次，表现为实例状态反复从running变成shut off。排查时先virsh list --all确认状态，再virsh dominfo vm-web-01看启动时间，最后最有效的一招是看QEMU日志：

tail -f /var/log/libvirt/qemu/vm-web-01.log

日志里能看到QEMU进程的真实报错，比如内核panic、磁盘路径不存在、BIOS加载失败等等。我的那次问题出在磁盘镜像路径被移动过，libvirt配置还指向旧路径，改了XML里的source file路径后就恢复了。记住一句话：虚拟机层面的问题永远先看libvirt和QEMU日志，不要瞎猜。

5.3 业务访问不通：拆成“路由、防火墙、端口”三层排查

业务部署完之后，最常遇到的情况是“内部能访问、外部访问不了”，或者反过来。我给自己总结了一套排查口诀：先ping网关，再ping对端，再看防火墙，最后看监听端口。

具体操作顺序是：

# 1. 看宿主机路由和NAT是否正常 ip route # 2. 看iptables的FORWARD链是否有拦截 sudo iptables -L -n # 3. 看nginx是否在监听 ss -tlnp | grep 8080 # 4. 看实例上服务是否启动 systemctl status nginx

有次我配了Nginx反向代理后一直502，排查了半天发现是防火墙的FORWARD链把转发流量DROP掉了，iptables规则顺序有问题。后来用iptables -I FORWARD 1 -j ACCEPT临时放通，再把规则保存成持久化配置。这类问题在作业里出现频率非常高，如果你也遇到502，先别怀疑Nginx配置，先想想宿主机的IP转发是否打开：

sysctl net.ipv4.ip_forward

如果输出是0，那就要改成1，不然虚拟机的出站流量根本到不了NAT网关。很多同学在作业报告中写“网络不通”，其实第一步就是忘记开启IP转发，非常基础，但很致命。

5.4 云覆盖度评分如何避免“自嗨”

云覆盖度计算不是自娱自乐，报告里如果全是1分，老师大概率会觉得你在自嗨。我的经验是：对每一条低于1分的需求，都要写清“当前缺什么、为什么缺、如果要补齐用什么方案”。比如我的环境里没有对象存储，那就写清楚“对象存储服务未部署，当前业务缺少静态资源海量存储能力，可通过部署MinIO等私有对象存储补齐”。

另外，覆盖度结果要和业务场景结合起来看。计算层覆盖度偏低不代表环境失败，你得说明“本次业务场景不涉及高性能计算，因此该维度权重较低”或者“后续可以引入Kubernetes补充弹性伸缩，将计算层覆盖度提升到0.8”。总之，覆盖度不是越高越好，重点是你能不能自圆其说，能不能把数据和工程决策串起来。

5.5 问题排查速查表

我把这次作业中遇到的典型问题整理成一张速查表，放在报告附录里，也方便你自己排查：

6. 从作业到工程：用“云工程模型”的视角再想一层

6.1 作业里的模型和真实云平台的对应关系

作业做完之后，我试着把自己搭的这套最小环境，和商业云平台做了个映射，发现对应关系意外的清晰。KVM加Libvirt里的计算资源池，对应商业云平台里的虚拟机规格和弹性伸缩组；我手动创建的存储卷和快照，对应云硬盘和云备份服务；我用iptables和Nginx实现的安全组与负载均衡，对应商业云平台里的安全组、VPC和负载均衡器。像华为云、阿里云这些平台，控制台里点几个按钮就能创建一台云主机，背后其实就是和这套机制类似的调度系统在运作。你上手过一遍底层，再回头看任何一个云平台的控制台，就不会觉得那些按钮是魔法了。

这也是为什么我一直建议认真做作业2：它不是一道普通的课设题，而是一个缩小版云平台的搭建实践。课程里讲的部署模型，私有云对应我宿主机上这套环境，公有云对应云厂商公开售卖的API，混合云对应我之后想把云上服务和本地环境打通的那种形态。这些概念在真实行业里每天都在用。

6.2 后续可以往哪些方向扩展

如果你做完作业2还有余力，我建议往三个方向扩展。第一个方向是容器化：在KVM虚拟机之上装Docker，再往上一套Kubernetes，把资源调度从虚拟机级别下沉到容器级别，这是目前行业的主流趋势。第二个方向是自动化运维：补上Ansible或者Shell脚本，把环境部署过程从手动命令变成一键脚本，这也是运维岗非常看重的能力。第三个方向是监控告警：引入Prometheus和Grafana，把资源使用、业务可用性、云覆盖度这些指标做到可视化看板上，形成“指标→告警→处理”的闭环。

这些方向其实和当前云计算领域的学术、工程热点是一致的。业界对云计算基础设施、数据中心节能、智能运维的讨论越来越深入，各类技术会议这几年也都在这些方向上征稿，比如聚焦云计算、大数据应用与软件工程方向的国际会议，就会经常讨论基础架构机制和落地案例，CBASE这类会议今年也在开放投稿，如果你有继续深造或者做科研的想法，从作业里挑一个点深入研究，比如改进云覆盖度的评估模型，或者做一套自动化巡检工具，都是能做出论文的切入点。

我个人做完作业2之后，已经在考虑把“云覆盖度计算模型”再细化一下，尝试把它做成一个简单的脚本工具：输入需求清单，自动扫描当前环境的资源池、存储卷、网络策略，生成覆盖度报告。这个想法如果能落地，作业2就不只是一次作业，而是一个能放到代码托管平台上展示的mini项目了。

最后说点个人的体会。做完作业2，我最大的感受是：会敲命令和懂机制是两回事。最初我以为搭一套KVM环境，把虚拟机创建出来就完事了；但真到云覆盖度计算的时候才发现，之前那些自认为“完成”的功能，很多都只是勉强能用，离“覆盖需求”还差得远。这种“以为会了，一评估才发现差距”的体验，其实特别值钱。它逼着我把环境从“能跑”往“可评估、可解释、可优化”的方向推了一步。如果你也在做类似的作业，我给三条建议：第一，动手前一定先列验收清单，不然很容易陷入“环境搭好了但报告写不出”的困境；第二，云覆盖度别给自己打满分，留几个明显可优化的点，反而显得思考深入；第三，所有关键操作都留日志和截图，写报告的时候你就知道这些东西有多香。祝大家都能顺利过关，最好还能在这门课里找到一点对云计算的实感。