一、为什么不能直接照抄厂商的参考配置
选型阶段最常见的动作，是让每一家候选厂商交一份服务器配置清单，然后横向比价。这个动作本身没问题，问题在于把它当成决策依据。厂商给出的推荐配置，通常来自它自己标准压测环境下的结论：固定的并发模型、固定的数据分布、固定的读写比例。而你的实际情况是一组变量——同一时段有多少人在提交单据、一年产生多少张单据、每张单据挂几个附件、月结要不要在系统里跑、报表要跨几年数据取数。这些变量叠加起来，把最终需要的配置拉开一倍以上并不罕见。
更务实的顺序是倒过来：先用自己的历史数据把量级算出来，再把厂商的推荐配置当作校核项。如果两者差出一个档位以上，要讨论的不是「听谁的」，而是要求厂商说明它的压测假设是什么，再判断这个假设与你的业务是否吻合。这个要求写进方案评审纪要，比事后争论有用得多。
本地化部署还多一层约束：硬件是采购方自己买、自己扩容、自己承担折旧的资产。买小了，业务量上来只能提前换整机；买大了，一次性投入和之后每年的电费、维保、机柜空间都是白付的。这笔账只有在采购前算清楚才划得来，上线之后再调整，代价会高出一个量级。
二、四条推算式：先把业务量变成可度量的输入值
把「要买多大机器」换成四个可以量化的输入值，配置估算就从经验判断变成可以复核的算术题。每条推算式都需要一个业务参数作起点，也各自有一个最容易被想错的地方。
| 涉及维度 | 要先确认的输入值 | 换算思路 | 最常见的误判 |
|---|---|---|---|
| 并发访问 | 峰值时段的同时操作人数与提交频率——从系统的登录日志、单据提交日志里统计，不要用账号总数推算 | 按峰值时段的每秒请求数与单个请求的平均处理时间，估算所需的应用线程数与 CPU 核数 | 按账号总数配算力，结果是平时大量资源闲置、真正的高峰期又不够用 |
| 单据写入 | 年单据总量、月结期间的单日峰值、凭证批量生成的并发条数 | 峰值日的单据量除以有效处理时长得到每秒写入量，用来校核数据库的写入承载与日志空间 | 只算年平均，忽略月结那几天集中产生的批量写入与凭证生成 |
| 附件存储 | 单张单据的平均附件体积、年度单据数、各归档年度对应的留存年限 | 先算出裸容量，再为 RAID 冗余、快照与备份副本分别预留空间 | 只算当年新增量，忘了历史数据迁移进来的一次性占用，以及备份本身也要占容量 |
| 报表与批处理 | 常用报表的最大取数跨度、月结是否在系统内运行、是否需要出具合并报表 | 报表所需内存与数据跨度近似成正比；批处理按峰值 CPU 与临时表空间单独留量 | 把报表和在线交易挤在同一台机器上，月结期间互相拖慢 |
四条算式里，第三条和第四条最常在方案评审时被跳过。附件存储的增长是单调的——一旦启用电子会计档案，留存期就决定了它只会增加不会减少；报表与批处理则属于「平时不占资源、关键时刻占满资源」，如果不单独留量，月结那几天所有人的操作都会变慢，而这类问题几乎不可能在功能验收测试里暴露出来，等发现时项目早已上线。
三、三档量级锚点与它们的适用边界
下面三档只提供量级坐标，具体数值必须按上一节的四个输入值回算。给出档位的价值在于，预算讨论时有一个可参照的起点，而不是在「厂商说够了」和「看起来太贵」之间来回拉扯。
| 量级 | 典型特征 | 应用与数据库 | 存储与备份 | 部署时的注意点 |
|---|---|---|---|---|
| 并发在百人以内、年单据数在数万量级 | 单法人、单组织，附件以票据影像为主 | 两台（应用与数据库分离，也可虚拟化合并部署） | 固态数据盘数 TB 起步，另配同等容量备份介质 | 可以采用虚拟化，但数据库必须使用独立数据盘，不与操作系统混放 |
| 并发在百人到数百人、年单据数十万量级 | 多组织、多账套，启用预算控制与商旅对接 | 应用两台做负载均衡，数据库主备两台 | 全闪数据盘，备份使用独立介质并保留多份 | 数据库必须与报表、批处理资源隔离，避免月结影响在线业务 |
| 并发在数百人以上、多法人合并报表 | 集团多法人、多币种，月结批处理负荷重 | 应用三台以上，数据库主备加只读副本 | 全闪存储按五年数据量规划，容量与性能分别留量 | 需要独立的备份与容灾环境，不建议与业务系统混合部署 |
档位之间不是台阶式跳变，实际需求常常落在两档之间。这时的取舍原则是：优先把存储和内存配足、把 CPU 的单机升级空间留出来。原因是存储扩容通常最简单，内存次之，而 CPU 往往受主板与整机规格限制，加不上去就只能换整机。
四、三项不能省的余量
留白的三个位置
- CPU 与内存留三成以上余量：本地化部署没有云上的弹性可以依赖，负载上限就取决于采购时那台机器
- 存储按五年规划并预留扩展位：启用电子会计档案后附件与版式文件只会持续累积，扩容要能在不影响业务的前提下完成
- 网络与安全设备单独列预算：出口带宽、日志审计、堡垒机、数据库审计在等级保护要求下不是可选项，临时采购往往来不及走完流程
这三项在预算评审中常被当作「浪费」砍掉，但事后补救的成本远高于预留成本。尤其是网络与安全设备：测评提出的整改项一旦落到具体设备上，采购、部署、配置、复测会串成一条时间线，而上线时间通常已经对外承诺锁死，届时只能在预算之外想办法。
五、机房等级与合规要求不能等到上线前再补
硬件放在哪里，遵循的是一套独立于财务业务的标准体系。数据中心与机房的设计通常参照《数据中心设计规范》（GB 50174-2017，住房和城乡建设部发布，2018 年 1 月 1 日实施），该规范从使用性质以及数据丢失或网络中断在经济、社会上造成的损失程度出发，把数据中心划分为 A、B、C 三级：A 级的基础设施宜按容错系统配置，B 级宜按冗余系统配置，C 级按满足基本需要配置，等级越高可靠性与投资同步上升。机房等级应当与业务连续性要求、系统定级一并确定，而不是先按预算装修、上线前再对标标准。
合规侧有两条要求会直接影响硬件与设备清单。《会计信息化工作规范》（财会〔2024〕11 号，财政部 2024 年 7 月 26 日印发，2025 年 1 月 1 日施行）第四十条要求，单位应当按照国家网络安全等级保护制度，全面落实安全保护管理和技术要求。而等级保护的基本要求由《信息安全技术 网络安全等级保护基本要求》（GB/T 22239-2019，2019 年 5 月 10 日发布，2019 年 12 月 1 日实施）规定。把这两条翻译成采购语言就是：测评可能触发的整改项——日志留存时长、访问控制、入侵防范、审计设备——每一项都对应具体的软硬件投资，它们应当出现在第一版预算里，而不是在上线前临时追加。
六、写进采购合同的四件事
- 可扩展方式：机箱是否有空闲盘位、内存槽位上限是多少、能否在不更换主板的前提下增加 CPU，这决定了三年后是加东西还是换整机
- 备件与响应：关键部件的备件来源、到场时限，以及是否包含在维保范围之内
- 资源隔离约束：数据库使用独立数据盘、不与操作系统混放；如采用虚拟化部署，需明确资源不超卖的书面约束
- 扩容的计价方式：后续按节点扩容还是按容量扩容，单价是否随年份调整，有没有最低采购量限制
把这四条写进合同，再加上前面四条算式得出的输入值，配置这件事就不再依赖某位顾问的个人经验。以后无论是换厂商、换产品还是扩容，这套输入值与换算逻辑都可以直接复用到下一轮评估，评审时也不必再从头争论一遍。
资料来源：《数据中心设计规范》（GB 50174-2017，住房和城乡建设部，2018 年 1 月 1 日实施）；《会计信息化工作规范》（财会〔2024〕11 号，财政部，2024 年 7 月 26 日印发，2025 年 1 月 1 日施行）第四十条；《信息安全技术 网络安全等级保护基本要求》（GB/T 22239-2019，2019 年 5 月 10 日发布，2019 年 12 月 1 日实施）。