1 云服务器回答什么问题：按需租用的虚拟机
在 C3 中，虚拟化把物理机器的计算、内存和设备能力分成了多个虚拟机。现在把视角移到使用者：如果需要让一个程序持续运行，能否直接获得一台可以登录、安装软件、保存文件的机器，而不先采购服务器、装机和接电？云服务器回答的就是这个问题。它通常是一台由云平台托管的虚拟机，用户通过控制台或 API 创建实例，选择规格、镜像、网络和磁盘，再按产品规则付费。
这里的“托管”有明确边界。云平台维护机房、物理设备和虚拟化基础设施；你通常仍需维护客户操作系统、应用、访问凭据以及数据。实例创建成功，只说明平台交付了资源，不表示应用已经正确安装，也不表示数据已经备份。相较于自己管理物理机，云服务器减少了硬件交付环节；相较于容器，它通常提供独立客户操作系统，容器则通常共享所在主机的内核。
理解一台实例，可以把它拆成计算外壳和连接的资源。规格决定可用的 vCPU 与内存，镜像提供启动系统的起点，网卡连接网络，块盘保存系统与业务文件。实例有编号，网卡、磁盘、公网地址也可能各有编号。这些资源看起来属于同一台“机器”，却不一定共享寿命：机器释放后，某块盘可能保留，某个公网地址也可能继续占用并计费。
选型应从负载轮廓开始。先写程序做什么、请求何时到来、每次请求消耗多少计算、需要多少常驻内存、哪些文件必须保留，以及谁需要访问它。持续编译代码与偶尔接收回调，即使平均请求数相近，对规格的要求也可能不同。把“我要一台大服务器”改成“我要运行一个常驻内存约 1.5 GB、白天请求较多的 API”，后面的选择才有依据。
同样的方法也适用于一组云主机。给每台实例记录用途、负责人、环境和资源关联，比只记住公网 IP 更可靠。IP 可能改变，实例编号才是查事件、账单与关联磁盘的重要线索。本课先把单台机器的交付、使用和回收讲清楚；管理多台时，可以复用同一份规格表、镜像版本和初始化过程，而不必依靠逐台手工记忆。
2 规格族与镜像：算力、架构与启动盘
规格族是面向不同负载的资源配比。通用型适合计算与内存需求比较均衡的服务；计算型提供偏向 CPU 的配比，适合计算工作较多的程序；内存型适合需要较大工作集的服务；GPU 型面向能使用相应加速器的软件。族名只帮助缩小候选范围，同样标着 4 vCPU 的机器，处理器代际、共享限制和实际性能也可能不同，最终仍要以目标程序的测量结果判断。
vCPU 是虚拟机可见的处理器执行资源计量单位，不应直接理解为独占的物理核心。内存也不是“越大越快”：程序只用到 2 GB 时，把容量从 8 GB 加到 32 GB，未必改善请求耗时；如果程序已因内存不足频繁退出，增加 CPU 又解决不了问题。先识别瓶颈，再调整配比，比同时把所有选项调大更容易解释效果。
镜像是创建启动盘和操作系统环境的模板，可能包含操作系统、驱动及预装软件。先确认应用与镜像的 CPU 架构一致，例如 x86-64 与 Arm 的可执行文件不能无条件互换；再确认系统版本仍有安全更新、软件仓库可用、所需运行时受支持。官方基础镜像通常便于知道起点是什么，自定义镜像便于复用环境，但需要记录构建来源和更新日期。镜像也不能替代持续产生的业务数据备份。
做一个有边界的数字例子。假设某 API 在 2 vCPU、4 GB 上，每个请求平均消耗 20 毫秒 CPU 时间，暂不考虑外部依赖，则计算能力的理想上界约为 2 ÷ 0.02 = 100 请求/秒。这个数字不是可承诺吞吐，因为还有系统开销、请求差异和等待；当到达速率接近处理能力时，请求更容易排队，响应尾部会明显变慢。换成 4 vCPU、8 GB 后，只有应用能并行且其他环节未受限，计算上界才可能接近翻倍。
再假设这 2 个规格的计算单价分别为 0.30 元/小时与 0.60 元/小时，持续运行 720 小时分别为 216 元与 432 元，不含磁盘和网络。低负载时多花的钱可能主要购买空闲；接近饱和时，增加可用处理能力可能减少排队。这里用假想单价比较思路，不代表任何厂商报价，更不能据此断定规格翻倍就一定使延迟减半。
交互中的“忙碌程度”只说明资源压力的方向。真实选型还应观察 CPU、可用内存、错误率和响应耗时，并使用接近实际的请求组合。若 CPU 很空闲而请求仍慢，应继续检查数据库、外部调用或磁盘，而不是直接购买更大的计算规格。测试时保留镜像版本与配置记录，才能知道改善来自规格还是环境变化。
3 网络接口与地址：私网、公网与安全边界指针
主网卡是实例连接网络的主要接口，通常在创建时获得私网 IP。私网地址用于所在私有网络内的通信，但“有私网 IP”不等于可以与任意另一台云主机互通，还取决于网络归属、路由和访问规则。VPC 的网络组织与规划留到 C9，本课只要求在创建前确认实例放在哪个现有网络、哪个可用区，以及它要与哪些资源通信。
公网访问是另一项选择。有的平台直接为实例提供公网地址，有的平台使用可单独申请、绑定和解绑的弹性公网 IP。公网地址可能通过平台映射到网卡的私网地址，因而不一定出现在客户操作系统的接口列表中。不要仅凭系统里只看到私网 IP，就认定实例没有公网入口；应同时核对控制台中的地址关联关系。
把通信拆成 2 个方向更容易判断是否需要公网地址。入站是外部用户或管理员主动访问实例；出站是实例下载更新、拉取软件或访问外部接口。实例可能不接收公网入站，却通过已有的共享出站设施访问互联网。反过来，绑定了公网地址，也不代表所有连接都会成功：路径、端口监听以及访问规则都必须匹配。公网 IP 是地址资源，不是“网络全部配置完毕”的标记。
安全组是实例网络访问边界的重要控制点，先遵循仅开放所需来源与端口的原则，规则细节见 C10。操作系统内的防火墙和应用监听地址也会影响结果。例如 API 只监听 127.0.0.1 时，服务即使在本机测试正常，其他机器也无法直接通过网卡地址访问。解决方法应基于部署意图选择监听接口，并核对允许访问的范围。
登录路径也需要事先设计。学习环境可使用仅允许管理者当前出口地址访问的公网入口；生产环境可以采用已部署的堡垒机、私网连接或平台管理通道。所谓“当前出口地址”是云端看到的来源，通常不是笔记本在家用路由器下的局域网地址。出口变化后，应更新授权来源，而不是为了方便永久开放所有来源。
对一组实例，地址最好服务于明确角色：哪些需要接收业务请求，哪些只接受管理访问，哪些仅与内部依赖通信。资源清单应写出这个决定和理由。不要为了“以后可能有用”给每台机器都申请公网 IP；这既扩大暴露面，也增加了需要核对的计费资源。
4 登录、元数据与初始化
以 Linux 云服务器为例，常见登录方式是 SSH 密钥认证。创建实例时把公钥交给平台或写入镜像支持的账户配置，私钥留在管理者受控的设备中。登录时同时匹配目标地址、系统用户名和私钥：不同发行版默认用户可能不同，不能假定全部使用 root。私钥文件应限制本地访问权限，团队也应明确密钥归属与离职后的撤销方式。
首次连接还要检查服务器身份。SSH 提示的主机指纹用于识别对端，应通过控制台等可信渠道核对。实例重建后指纹可能变化，但遇到变化时仍应确认实例编号和操作记录，不能习惯性删除记录后直接接受。登录成功的最低验收是进入预期主机、确认操作系统与实例身份，再检查应用所需的目录和进程，而不只是看到一个终端提示符。
实例元数据是平台向实例提供的环境信息，例如实例标识、区域或被授予的临时身份信息，通常通过实例内部可访问的专用机制取得。它不等同于随意可公开的普通网页。应采用平台推荐的访问保护方式，限制不受信任程序借助实例发起任意请求；应用若能利用实例身份访问其他云资源，也应只获得完成任务所需的权限。
cloud-init 是许多 Linux 云镜像使用的初始化工具，可根据平台提供的数据完成账户、公钥、软件包与启动命令等配置。它解决的是“操作系统第一次起来后怎样达到约定状态”，不负责证明业务接口一定可用。有些步骤还依赖软件仓库、DNS 或外部下载，所以控制台显示实例运行时，初始化可能仍在继续。
初始化内容应小而可追踪：设置时区、建立服务账户、安装明确版本的运行时、创建目录、登记服务并留下日志。不要把长期访问密钥写进镜像、用户数据或示例命令；这些内容可能被复制、留存或被具有相应权限的人读取。需要调用云服务时，优先使用受限的实例角色与临时凭据，敏感配置通过适当的秘密管理方式在运行时取得。
初始化还要考虑失败与重试。下载失败后应有明确错误记录，重复执行目录创建或服务配置时不应破坏已有数据。不要笼统假定所有 cloud-init 配置每次重启都会执行，其执行频率取决于模块与配置。批量创建实例时，统一使用带版本的初始化配置，记录每台实例的完成结果；发现失败先找日志，避免把手工修补后的机器当作可重复交付的模板。
从镜像到可服务至少有 3 个不同检查点：平台交付成功、系统初始化完成、业务检查通过。最后一个检查应访问真实业务接口并验证返回内容。只测 SSH 可达，无法发现应用缺配置；只看进程存在，也无法确认应用能访问依赖。把检查点分开，才能在故障时知道该找平台事件、系统日志还是应用日志。
5 块盘挂载入门：系统盘与数据盘
系统盘承载操作系统和启动所需文件，数据盘用于保存需要独立管理的业务文件。区分它们不是说系统盘不能写数据，而是要把重建系统的动作与保留业务数据的要求分开。应用程序可以重新安装，用户上传文件或本地业务记录却可能无法重新生成。即使把文件放进名为 /data 的目录，也只有在该目录确实挂载了预期数据盘时，才获得了这种分离。
块盘交付的是块设备，挂载则让文件系统进入操作系统目录树。通常需要经历“创建并附加磁盘、识别设备、确认文件系统、挂载到目录”这几个步骤。新空盘可能需要分区或建立文件系统；已有数据的磁盘不能照抄新盘流程重新格式化。附加成功仅代表设备已连接，不代表系统已经能在目标目录读写文件。
动手时先在控制台记下盘编号、容量和可用区，再在系统中用 lsblk -f 查看设备、文件系统和挂载点，必要时用 blkid 核对 UUID。这里的关键是把“我要使用的盘”与“系统发现的设备”对应起来，不能只凭某个设备名猜测。对新盘执行任何格式化操作前，必须确认盘内没有需要保留的数据；本课不提供可以直接套用到任意设备的格式化命令。
确认文件系统后，将盘挂载到预先建立的目录，再用 findmnt 和 df -h 检查实际来源与容量，并以应用账户做一次小文件写入、读取和删除。若要求重启后自动挂载，可按系统规范配置持久挂载，通常用文件系统 UUID 比容易变化的设备名更稳妥。修改后应先校验挂载配置，并确认挂载失败时应用不会把大量业务数据写进同名的系统盘目录。
磁盘的持久性必须落实为资源策略。创建时检查系统盘与数据盘是否设置为随实例释放删除，不要推断所有平台、所有盘类型都相同。某些本地临时盘的寿命与宿主或实例操作强相关，应按产品说明理解，不能当作持久块盘使用。跨可用区重新附加也可能受限制，所以盘的位置和类型都应进入资源清单。
重要数据还需要独立恢复手段。保留数据盘可以防止某些实例删除操作造成数据消失，但不能防止程序误删、文件损坏或误格式化。快照提供另一个时间点的恢复来源，涉及一致性、恢复步骤和保留策略，C6 会继续展开；这里先记住“盘还在”和“数据可恢复”是 2 个需要分别验收的条件。性能指标如 IOPS 的深入比较也留到 C6。
6 生命周期与计费：创建、停机、释放
创建实例会分配计算资源，并按选择生成或关联磁盘、网卡和地址。运行表示虚拟机处于工作状态，停止表示它不再执行客户操作系统，释放表示实例资源被删除。重启通常仍是同一台实例的运行过程；释放后重新创建则是新实例，身份、地址与资源关联都可能变化。不要把“应用进程停止”“操作系统关机”和“控制台已进入停止状态”当作同一条证据。
费用要按资源行拆开。为便于推理，以下假设采用按量计费：运行时按小时收取计算费；在控制台执行支持免计算费的停止操作，且平台确认计算资源已回收后，不再收取该部分费用；块盘、保留公网 IP 与快照仍按各自规则计费。实际产品若为包年包月、保留宿主资源或特殊规格，停止后的计算费可能不同，必须先查所用产品的明确规则。
沿用假想单价，一台实例运行 24 小时，计算费为 24 × 0.30 = 7.20 元；若系统盘与数据盘合计折合 1.20 元/天，保留公网 IP 为 0.48 元/天，则这天基础合计为 8.88 元，尚未计入流量。按上述停止规则停止满 1 天，计算费降为 0，但保留磁盘和地址仍可能产生 1.68 元。停止的是计算执行，不是所有关联资源的商业关系。
释放之前，先确认数据去向，再确认资源去向。保存必要日志，检查数据盘保留设置、恢复来源和所需配置，随后才执行实例释放。操作完成后到资源列表核对盘与地址的状态，不能只看实例列表中那行记录消失。反过来，若希望保留地址用于后续迁移，就应在清单上标明保留理由、负责人和预计结束时间，并接受相应费用。
对一组开发测试主机，可以逐台记录“最后使用时间、是否需要运行、关联盘、关联地址、回收负责人”。批量停止前确认任务已结束、数据已落盘；批量释放前分别核对持久数据。统一标签有助于按项目查账，但标签不会自动改变删除保护或计费规则，资源编号和实际状态仍是核对依据。
重新启动也要验收。某些停止方式会释放原先占用的计算资源，重新启动可能受到容量可用性影响；非固定公网地址也可能变化。启动后应再次确认挂载、服务状态与访问地址。需要暂停环境时，把“以后能重新启动”与“以后还能按原入口恢复服务”都写入计划，避免只节省了眼前的计算费，却丢失恢复路径。
7 常见坑：规格过大、公网暴露、系统盘当数据盘
第 1 个坑是先买最大规格，再去找负载。它的直接后果不只是账单高，还会掩盖程序问题：低效查询暂时被更多内存遮住，内存泄漏暂时晚一点出现。开始时选择能容纳已知工作集的合理规格，跑代表性请求，留下资源和延迟记录，再决定是否调整。调整规格前还要确认是否需要停机、镜像架构能否兼容以及目标可用区是否提供该规格。
第 2 个坑是为了排查 SSH，把来源长期设为 0.0.0.0/0。它表示允许来自任意 IPv4 来源的匹配连接，并不是“只让自己的电脑能连”。即使用密钥认证，过宽的入口也会带来持续扫描和额外攻击面。先确认自己的出口地址、访问路径与目标端口；如需临时扩大范围，应有明确结束时间并及时收回，同时考虑是否存在独立的 IPv6 入口。
第 3 个坑是把重要数据只留在系统盘。重建系统、替换镜像、清理实例时，操作者容易把系统盘当作可丢弃环境。把业务文件移到数据盘是改进的起点，还要验证挂载是否生效、释放是否保留以及是否存在恢复副本。否则，“我已经创建数据盘”可能只是控制台多了一项资源，应用实际上仍把文件写在系统盘上。
还有一个容易贯穿上述操作的误区：依赖控制台中的绿色状态。绿色运行状态不能证明应用已初始化，绿色磁盘状态不能证明文件系统可写，显示解绑也不能证明地址已释放。每一步都应补上与目标对应的证据，例如业务请求成功、应用账户能写入正确挂载点、账单资源已进入释放状态。这样日常操作才会留下可排查的事实。
8 案例：Web API 的首台云主机选型
假设团队要上线一个日均 50 万请求的 Web API。程序已经可以在 Linux 上运行，主要读取远端数据库，偶尔处理少量计算，不保存用户上传文件。先把日请求数换成平均速率：500000 ÷ 86400 ≈ 5.8 请求/秒。这个平均值只能描述全天总量，不能直接作为机器容量目标；若活动时段较集中，短时流量会明显高于平均。
假设历史记录显示峰值约为平均的 8 倍，则先用约 46 请求/秒组织试验，并将正常目标取整为 50 请求/秒，另做 80 请求/秒的短时压力观察。若没有历史证据，8 倍只是一项待验证假设，需要上线后更新。还要记录请求组合、请求体大小和外部依赖，否则用一个极轻的健康检查接口压测，得到的吞吐并不能代表真实业务。
试运行测得目标请求平均消耗约 10 毫秒 CPU，常驻内存约 1.5 GB，50 请求/秒对应约 0.5 个 CPU 核心的平均计算需求。这个结果支持把 2 vCPU、4 GB 作为首个候选，而不构成容量承诺：运行时、并发连接、缓存和操作系统仍需空间。若实测内存持续逼近上限，或计算消耗与估计不同，再比较 4 vCPU、8 GB；若慢在远端数据库，先验证依赖耗时。
镜像选择应用已验证的、仍受支持的 Linux 版本，架构与程序包匹配。使用带版本的 cloud-init 安装运行时、创建服务账户和登记进程，不在镜像中预埋长期密钥。网络决策取决于服务入口：本案例假设公网客户端直接访问这台首台主机，因此申请公网入口，只开放必要业务端口，管理访问限制来源；若组织已有统一入口且能转到私网，则这台实例可不单独持有公网地址。
盘布局采用 40 GB 系统盘与 100 GB 数据盘作为预算假设。数据盘保存需要跨重建保留的运行文件与有限保留期的日志，数据库数据仍由既定数据库系统负责。不要因为 API 自身无状态，就把所有诊断材料都视为可丢弃；也不要把机器本地日志当作唯一审计来源。若实际几乎不需要本地持久文件，可以缩小或取消数据盘，但应在规格表中写明依据。
验收交付物是一份能让另一个人复核的规格表。至少填写：2 vCPU、4 GB 的候选规格及实测结果；镜像版本和架构；SSH 用户、公钥归属及管理路径；公网是否必要和允许入口；系统盘与数据盘的用途、挂载点和释放策略；实例、盘、地址的编号及负责人。50 请求/秒下业务返回正确、错误率符合约定，且 95% 请求耗时低于团队设定的 200 毫秒目标，才算通过本次假设下的应用验收。
成本也写成可替换的假算。按 0.30 元/小时、每月 720 小时，计算费为 216 元；假设系统盘 12 元/月、数据盘 24 元/月、公网 IP 14.40 元/月，则固定部分合计 266.40 元/月。再单列按实际出站量计算的流量、备份及其他依赖费用，不把固定部分误称为总成本。记录单价适用条件与估计用量，上线后用账单验证，比只报一个整月总数更容易发现偏差。
9 排查案例：登不上、突然变贵、盘只读/丢失
某次发布后，值班同学收到 3 个反馈：“SSH 登不上”“测试环境昨天已经不用了，今天仍扣费”“应用说数据目录只读”。先记录各自的实例编号、发生时间和最近操作，再分别取证。不要先重装系统或重新格式化磁盘；这些操作可能销毁解释问题所需的信息，也可能把原本可恢复的问题变成数据损失。
登不上时，先区分连接阶段。如果 SSH 已返回认证拒绝，至少说明连接已经到达某个 SSH 服务，应核对是否为预期主机，再核对镜像默认用户、公钥和实际使用的私钥；可用 ssh -vv 查看协商与认证阶段，但分享日志前应去除敏感信息。此例发现操作者使用了旧镜像的用户名，改用当前镜像约定的用户后登录成功。若是连接超时，则沿路径 A 检查管理来源和安全组端口指针，具体规则操作参见 C10，不能把所有超时都归因于密钥。
路径 B 检查地址与路由：控制台是否仍绑定所用公网 IP，客户端是否误用旧地址，实例所在网络是否具备预期通信路径。此例另一台测试机已经解绑地址，而维护记录仍保留旧 IP。核对地址关联事件、客户端连接测试及网络配置后，改用已批准的管理通道。若返回“连接被拒绝”，通常已收到对端或中间设备的主动拒绝，应继续检查端口监听和拒绝规则，而不是简单断言网络全通。
路径 C 检查系统是否就绪。平台事件显示机器刚创建不久，串行控制台中系统已启动，但 cloud-init 日志表明软件仓库下载失败，SSH 配置步骤或应用准备尚未完成。先验证初始化日志、磁盘空间与服务状态，再修复失败步骤并重新验收。若客体网络或 SSH 不可用，可用平台提供的受控控制台诊断；不能因为实例显示运行，就排除操作系统内的问题。
“突然变贵”则先看账单行，不先猜流量攻击。按项目和资源编号拆开后，发现测试应用虽然停了进程，实例仍在运行，计算费没有停止；另一台实例虽已释放，原公网 IP 却只是解绑，地址费用仍在产生。控制台操作事件分别证明了这 2 个状态。完成数据与用途确认后，按产品计费规则停止或释放不需要的计算资源，并释放不再保留的地址，随后观察后续计量时段；账单展示有延迟，修复不会抹掉已经发生的用量。
“盘只读”需要先确认是哪一层拒绝写入。用 findmnt 核对挂载来源和选项，再看文件系统空间、应用账户权限及系统日志。权限不足、容量耗尽与文件系统只读不是同一种问题。若系统因检测到文件系统错误而转为只读，应保留日志、停止无谓写入并按恢复流程处理，不能直接反复强制改为可写。此例检查发现数据盘因文件系统错误只读，转入维护与恢复流程，业务先暂停写入。
另一个“盘丢失”报告发生在重建实例后。先查盘资源是否仍存在：若盘在但未挂载，按编号核对并重新附加、挂载；若盘仍在且设备可见，进一步查挂载失败与目录遮蔽；若事件明确显示随旧实例一起删除，就不能靠重新创建同名目录找回内容。此例释放记录证明盘已误删除，只能检查已有快照或备份的恢复条件。最后把事故对应回创建表中的释放策略，修正模板并实际验证恢复步骤，才算完成处置。
放进方案里
把云服务器放进方案，先用一段负载轮廓说明它要承担的工作。记录服务类型、平均与峰值请求、单请求计算消耗、常驻内存、外部依赖和需要保留的文件。每个缺乏证据的数字都标成假设，并约定用什么试验或上线指标更新；日均请求只能帮助估算总量，不能单独支持峰值容量结论。
规格与镜像表应写明候选族、vCPU、内存、架构、操作系统版本和初始化配置版本，再附上代表性请求下的资源与响应结果。说明为什么当前规格足够，以及什么现象会触发重新评估。交付标准包含系统初始化完成与业务接口返回正确，不能只写“实例已运行”。管理账户、公钥归属和撤销责任也要可追溯。
地址与暴露面要能从一张清单看明白：实例所属网络、主网卡、私网地址、公网入口是否必要，以及管理员从哪里进入。对每个入口写明用途和允许来源；已有统一入口时，说明实例怎样通过私网接收请求。把网络组织与访问规则分别指向 C9、C10 的进一步设计，避免在实例规格表里隐藏未解决的访问条件。
盘布局应列出系统盘与数据盘的容量、用途、挂载点、保留设置和恢复来源。验收既检查盘资源关联，也检查应用实际写入的文件系统。明确实例重建后哪些文件可重新生成、哪些必须恢复，以及由谁执行恢复。保留磁盘只解决部分生命周期问题，重要数据还要有经过验证的独立恢复路径。
最后给出生命周期与成本约定。按运行时长、盘容量、公网地址和流量分别估算费用，标明停止后免除计算费的适用条件。写清停机窗口、释放前的数据确认、地址保留期限与负责人。对一组主机复用同一套编号、标签和资源清单，定期核对闲置项；发生故障或费用偏差时，用控制台事件、连接测试和账单行把每项决定与实际结果对应起来。
10 小结：走向弹性伸缩（C5）与块存储（C6）
云服务器把虚拟机变成可按需申请和回收的资源。用好它，需要把规格、镜像、网卡、磁盘、登录与生命周期连成一条可验证的交付链，并明确每项资源何时保留、何时删除、何时继续计费。
检查自己的方案：停止实例后还会为哪些资源付费？系统盘重建后，业务文件从哪里回来？SSH 超时时，如何区分认证、网络路径与系统未就绪？能用资源编号和操作证据回答这些问题，才算掌握了首台云主机。
C5 将继续讨论负载变化时如何调整实例数量；C6 将深入块存储的性能、快照与恢复。本课留下的负载测量、盘布局和资源清单，就是进入这 2 个主题的起点。
下一课转向 C6 块存储：把本章验收过的结论带进后续主题，写成可检查的方案约束。