私有云验收：装好了不等于能用起来

结论先行：私有云验收如果只验证「系统装上了、虚机起来了」，运行成本会留到运维期慢慢显形。更完整的验收分三块来验：功能与兼容，确认该装的都装得上、不能迁的逐条写明；性能与稳定，在真实业务负载下复测而不是在空环境里跑通；可运维性，把升级方式、回退路径与监控接入写进验收条件。三块都对完，再谈终验。

为什么「能跑起来」这种验收会留下后患

验收通过不等于运行成本合理。常见的后遗症有三种：平台功能齐全，但每次升级都要停机，交付半年后运维成本反而上升；性能验收在空环境完成，业务真正压上来才发现瓶颈；文档与账号没有移交完整，接手的人从头摸一遍架构。

这些问题的共同点是：它们都不影响「能不能开机」，所以很容易被验收清单漏掉。

验收分三块来验

三块里最容易被简化的通常是第三块。理由也好理解：它不影响上线，验收现场看不出差别。但恰恰是它决定了交付一年后的日常体验。

文档与账号的移交清单

验收不仅是技术指标的确认，也是一次交接。建议至少移交这几样：项目文档与实施方案、网络与部署配置说明、系统管理账号、硬件资产清单、验收报告。同步要写清楚的是服务范围与责任分界——哪些由服务方负责、哪些属于客户侧协同义务、维保期的时效口径与备件安排。清单缺失的部分，往往在故障当天才被发现。

验收之后还有一个动作：纳入既有管理面

新系统上线不等于管理到位。备份任务、监控告警、补丁与变更流程、资产台账，都应当在验收环节就纳入既有体系，而不是等运行一段时间再补。纳入的动作本身不复杂，但漏掉之后，往往是下一次盘点才发现「这套系统没人盯着」。

边界与前提

三点需要说明。其一，资源利用率、性能提升一类指标属于参考值，最终以真实业务负载下的验证结果为准，不宜直接写进承诺。其二，试点与试运行不能替代业务高峰验证，两者所处的压力条件不同。其三，验收标准要写进需求文档与合同并逐条对照，凭印象验收是后续争议的主要来源。

落地清单

• 在需求文档阶段就把三块验收内容与判定方式写清楚。
• 列出兼容性清单，逐项标注可迁、需改造、不可迁。
• 把性能与稳定性验证安排在真实负载或业务高峰时段。
• 把升级方式与回退路径列为验收条件，而不是可选项。
• 按移交清单核对文档、账号与资产，缺项写明补齐时间。
• 验收同期把备份、监控、变更流程与资产台账纳入既有体系。

验收清单列得越细，运维期越省事。奇摩在私有云与数据中心基础架构项目中，习惯把验收条件与后续维保口径放在同一轮确认，避免交付之后才发现前提没对齐。需要梳理验收与移交清单，欢迎 预约咨询。