3. 升级需求分析与评估方法
服务器基础设施升级最容易犯的错误，是"先定硬件、再找理由"。正确的顺序恰好相反：先弄清业务要什么，再摸清现状有什么，然后找出真正卡住业务的瓶颈，最后把升级目标写成可验证的数字。本节围绕这四步展开，重点讲清楚每一步"实际怎么做"。
一、业务需求收集：从业务语言翻译成基础设施语言
业务需求收集不是发一张问卷让业务部门填"你要多少 CPU"，而是把业务侧的诉求转译成可度量的基础设施指标。常用的做法是访谈 + 业务量基线两条线并行。
访谈时建议围绕四类问题展开：业务未来 12～24 个月的量级增长预期（用户数、订单量、并发峰值）、关键业务时段与峰值形态（是否有大促、月末结算、批量跑批）、可接受的停机窗口与恢复时间目标（RTO/RPO）、以及合规或架构约束（是否要求双活、数据是否必须本地留存）。
业务量基线则用真实数据说话。例如某订单系统当前日均订单 80 万笔，峰值 QPS 约 1200，业务方预期一年后增长 60%，则目标峰值 QPS 约为 1200 × 1.6 ≈ 1920。这个数字就是后续容量测算的输入，而不是拍脑袋的"升一档"。
二、现状调研：把资产、配置与运行数据摸清
现状调研要回答三个问题：有什么、跑得怎么样、还剩多少余量。建议按资产层、配置层、运行层三个维度采集。
资产层记录服务器型号、序列号、机架位置、上架时间、保修状态、所属业务系统。配置层记录 CPU 型号与核数、内存容量与通道数、磁盘类型与 RAID 级别、网卡速率与绑定方式、HBA/RAID 卡型号、固件与驱动版本。运行层则采集近 30 天的 CPU 使用率、内存使用率、磁盘 IOPS 与吞吐、网络带宽、以及关键业务响应时间。
采集工具上，联想服务器可借助 XClarity Controller（XCC）与 XClarity Administrator 批量导出硬件清单与健康状态；操作系统侧用 sar、iostat、vmstat、nmon 等采集性能基线。建议统一采集窗口，例如连续 30 天、每 5 分钟一个采样点，避免用单点瞬时值做判断。
调研输出应形成一份现状清单，至少包含：设备台账、配置基线、性能基线、以及"当前余量"判断。余量判断常用方法是看 P95 使用率而非平均值——平均值 40% 但 P95 达到 85% 的系统，实际上已经接近瓶颈。
三、性能瓶颈识别：区分"真瓶颈"与"假繁忙"
瓶颈识别最忌讳只看 CPU。服务器是 CPU、内存、磁盘、网络四条资源链协同工作的系统，任何一条链饱和都会拖慢整体。判断方法是从业务响应时间出发，逐层向下定位。
一个实用的判断顺序是：先看业务响应时间是否劣化，再看应用层线程池/连接池是否排队，然后看操作系统层四条资源的饱和度，最后看是否存在配置不当（如 RAID 写策略、网卡未开启多队列、NUMA 跨节点访问）。
常见的瓶颈特征包括：CPU 的 %iowait 偏高说明瓶颈在磁盘而非 CPU；内存的 swap 使用率上升说明内存不足；磁盘 await 明显高于 svctm 说明队列积压；网络出现丢包或重传说明带宽或链路质量有问题。把这些特征与业务时段对齐，才能确认瓶颈是否真实影响业务。
四、升级目标量化：把"要更快"变成可验收的数字
量化目标的核心是"指标 + 基线 + 目标值 + 验收方式"四要素齐全。缺少基线，目标值无从判断是否达成；缺少验收方式，目标就只是口号。
指标选择上，建议覆盖容量、性能、可用性三类。容量类如 CPU 峰值使用率、内存使用率、存储可用容量；性能类如峰值 QPS、P95/P99 响应时间、批处理窗口时长；可用性类如 RTO、RPO、年可用率。指标不宜过多，一般每个业务系统 5～8 个即可，过多会导致验收时无法聚焦。
目标值的设定要留出合理余量。工程上常用"目标峰值不超过资源能力的 70%"作为规划原则，即如果测算出目标峰值需要 100 核，实际配置应不低于 140 核左右，以应对突发流量和单点故障后的负载转移。这个 70% 是规划经验值，不是硬性标准，具体应结合业务波动性调整。
下面给出一份可直接参考的升级需求评估表模板，字段按本节四步组织，可根据实际项目增删。
| 评估维度 | 采集内容 | 示例值 | 用途 |
|---|---|---|---|
| 业务增长 | 未来 12～24 个月增长倍数 | 1.6 倍 | 容量测算输入 |
| 峰值形态 | 峰值时段、持续时长、突发倍数 | 每日 20:00～22:00，突发 1.3 倍 | 确定规划峰值 |
| 现状配置 | CPU/内存/磁盘/网卡型号与数量 | 2×16C / 256GB / 8×960GB SSD / 2×10GE | 余量计算基础 |
| 性能基线 | 近 30 天 P95 使用率 | CPU 78%、内存 82%、磁盘 IOPS 65% | 识别瓶颈 |
| 瓶颈定位 | 饱和资源链及证据 | 内存 swap 上升，磁盘 await 偏高 | 确定升级重点 |
| 量化目标 | 指标、基线、目标值、验收方式 | 峰值 QPS ≥1920，P95 ≤300ms | 验收依据 |
五、评估结论的常见判断依据
完成上述四步后，通常会得到三类结论之一：一是"现有资源余量充足，仅需优化配置"，例如瓶颈来自 RAID 写策略或网卡多队列未开启，调整后即可满足；二是"局部扩容即可"，例如仅内存不足，增加内存条并调整 NUMA 绑定；三是"需要整机或平台级升级"，例如 CPU 架构老旧、内存通道已满、磁盘接口成为硬约束。
判断依据可以简化为：若目标峰值下任一资源链的预测使用率超过 80%，且该资源已无扩展空间（插槽满、通道满、接口满），则应考虑整机升级；若仍有扩展空间且成本可控，优先局部扩容。这个 80% 同样是规划经验阈值，实际应结合业务对性能波动的敏感度确定。
最后需要强调的是，需求分析与评估不是一次性动作。业务增长、应用版本迭代、数据量累积都会持续改变资源画像，建议把上述评估表作为季度例行工作，每次升级前重新采集一次基线，使升级决策始终建立在最新数据之上。