1. 项目启动与需求分析

AMD EPYC 虚拟化计算平台的建设，第一步不是采购服务器，也不是安装虚拟化软件，而是把"要建什么、为谁建、建到什么程度算合格"讲清楚。项目启动与需求分析阶段的核心交付物是一份可评审、可追溯、可作为后续验收依据的《需求规格说明书》。它决定了后续选型（CPU 型号、内存容量、存储介质、网络带宽）、架构设计（超融合还是分离式、是否启用 SEV 加密虚拟化）以及容量规划的上限。如果这一阶段含糊，后面所有工程决策都会失去判断基准。

一、明确建设目标与业务场景

建设目标要落到可衡量的表述上，而不是"提升资源利用率"这类空话。以典型的企业私有云场景为例，可以这样定义：将现有 60 台物理服务器上运行的约 420 台虚拟机整合到 8 台 AMD EPYC 双路节点上，在保持业务性能不下降的前提下，把机柜占用从 3 个降至 1 个，并把虚拟化平台的单节点故障恢复时间控制在 5 分钟以内。

业务场景需要分类梳理，因为不同场景对 CPU、内存、存储和网络的要求差异很大。常见分类包括：

• 通用业务型：Web 前端、中间件、内部管理系统，特点是 vCPU 与内存配比均衡，对单核性能敏感。
• 计算密集型：编译构建、批处理、数据分析，特点是长时间高 CPU 占用，需要高主频与多核心。
• 内存密集型：内存数据库、缓存集群，特点是内存容量需求大，vCPU 与内存比可达 1:8 甚至更高。
• IO 密集型：日志采集、消息队列，特点是磁盘 IOPS 与网络吞吐要求高。
• 安全敏感型：涉及个人信息或受监管数据，需要启用 AMD SEV/SEV-ES 内存加密，虚拟机之间强隔离。

场景分类完成后，应给出每类场景的虚拟机数量、单机规格和增长预期，这是后续容量计算的输入。

二、性能指标与容量估算

性能指标要区分"平台级"和"业务级"。平台级指标包括：单节点可承载虚拟机密度、vCPU 超分比、内存超分比、存储 IOPS 与吞吐、东西向网络带宽、虚拟机启动时间、迁移时间。业务级指标则由各业务方提出，例如某数据库要求 P95 查询延迟不超过 20ms。

容量估算可以用一个简化的示例说明。假设 8 台双路节点，每颗 CPU 为 64 核 128 线程，则单节点逻辑处理器为 256 个，8 节点共 2048 个逻辑处理器。若通用业务型允许 1:4 超分，计算密集型允许 1:1，内存密集型允许 1:2，按场景加权后得到可分配 vCPU 总量。内存方面，单节点配置 1TB，扣除虚拟化层约 32GB 开销，可用约 992GB，8 节点约 7.9TB。存储按每虚拟机平均 200GB 有效容量、3 副本或纠删码开销折算，得出裸容量需求。这些数字在需求阶段是估算值，必须在设计阶段用实际业务负载验证。

三、合规与安全要求

合规要求往往被忽视，却直接影响架构。需要确认：数据是否涉及等保三级、是否要求国密算法、是否要求虚拟机磁盘加密、是否要求审计日志留存 6 个月以上、是否禁止虚拟机跨安全域迁移。AMD EPYC 的 SEV-ES 可以在硬件层加密虚拟机内存，但需要虚拟化平台和 Guest OS 支持，且会影响部分性能，这些约束必须在需求阶段写明，否则设计阶段会出现"功能无法落地"的返工。

四、需求规格说明书的组织与评审

需求规格说明书建议包含：项目背景与目标、业务场景清单、性能指标表、容量估算与假设、合规与安全要求、接口与集成要求、验收标准、风险与假设。每条需求应有唯一编号，便于后续设计、测试和验收追溯。评审时应邀请业务方、安全、运维和采购共同参与，重点确认性能指标是否可测量、合规要求是否可验证。

五、可直接使用的需求条目示例

下面给出一份需求条目表的片段，字段包括编号、类别、需求描述、指标值、验证方式。实际项目中可按此结构扩展。

评审通过后，这份说明书即成为设计阶段的输入基线。任何后续变更都应走变更流程，并同步更新受影响的条目编号，确保从需求到验收的链路始终可追溯。需求分析做得越扎实，后续选型、部署和调优的返工就越少。