私有云项目管理软件带宽存储怎么估？从零讲清

私有云项目管理软件要买多大带宽、留多少存储，答案不在厂商的推荐表里，而在你的使用方式里。带宽看同一时刻有多少数据在传，存储看一年能沉淀多少数据。两者都不是按注册人数乘一个系数就能得到的结果。

这篇文章从零拆开这两个问题：一套可复算的公式、一个 800 人团队的完整示例，以及上线后判断是否该扩容的指标。文中示例都标明了假设，示例只演示算法，不是禅道的推荐配置。

先分清四个量：注册人数、在线人数、并发请求、峰值带宽

很多估算一开始就错了，因为把“有多少人用”直接当成“同时有多少数据在传”。四个量要分开看。

注册人数决定上限，在线人数决定活跃度，并发请求决定带宽，峰值决定你该买多少。 单位也要统一：带宽用 Mbps，下载速度常用 MB/s，两者差 8 倍，100 Mbps 约等于 12.5 MB/s。存储按可用容量算，不要把标称容量当成全部可用空间。

带宽怎么估：一条公式，三步落地

带宽估算的核心不是“多少人”，而是“每秒要传多少数据”。拆成页面和附件两部分：

页面带宽（Mbps）= 峰值每秒请求数 × 平均单次响应大小（MB）× 8

附件带宽（Mbps）= 同时传输的附件数 × 平均附件大小（MB）× 8 ÷ 目标传输时间（秒）

峰值请求数 ≈ 峰值并发用户数 ÷ 平均操作间隔（秒）。做法分三步：取峰值并发；实测页面和附件大小；代入公式，乘协议与突发系数 1.2～1.5、增长系数 1.5～2。

示例：800 个注册用户，峰值 160 人同时在线，平均每 20 秒操作一次，页面 0.3 MB；4 个附件同时传输，平均 2 MB，目标 5 秒；系数取 1.3 和 1.5。

• 峰值请求数 ≈ 160 ÷ 20 = 8 次/秒
• 页面带宽 = 8 × 0.3 × 8 = 19.2 Mbps
• 附件带宽 = 4 × 2 × 8 ÷ 5 = 12.8 Mbps
• 规划带宽 =（19.2 + 12.8）× 1.3 × 1.5 ≈ 62 Mbps

在这个假设下，公网出口按 70 Mbps 左右规划，采购时落到 100 Mbps 档位更稳妥；内网链路通常按 1 Gbps 规划。上行和下行要分开看：下载附件消耗出口，上传附件消耗入口。

项目管理场景里，页面多为文本和结构化数据，附件更容易推高峰值。批量上传设计稿、测试报告或日志包，短时间占用的带宽可能超过几十个用户日常浏览所需，估算时要把附件单独列一行。

存储怎么估：把总容量拆成四本账

存储最常见的错误，是只算数据库或只算附件。总容量至少包括数据库、附件、日志与临时文件、备份四本账。

数据库：记录数 × 单条占用 × 索引与历史系数

数据库年增量 ≈ 日活用户 × 人均日新增记录数 × 单条记录占用 × 年工作日 × 索引与历史系数。

示例：500 个日活用户，人均每天新增 8 条需求、任务、Bug、评论，单条连同索引按 4 KB，250 个工作日，系数取 2：

500 × 8 × 4 KB × 250 × 2 ≈ 8 GB/年。

附件：人均附件数 × 平均大小 × 工作日

附件年增量 ≈ 日活用户 × 人均日新增附件数 × 平均附件大小 × 年工作日。

示例：500 个日活用户，人均每天 0.5 个附件，平均 1 MB：

500 × 0.5 × 1 MB × 250 ≈ 62.5 GB/年。

附件是最容易被低估的部分。 截图、设计稿、测试报告、安装包，单个文件可能从几百 KB 到几十 MB，要按实际习惯抽样。

日志与临时文件：按留存策略算

按“每天生成量 × 留存天数”估算，再给清理策略留余量。合规要求留存更久时，单独列账。

备份：按主数据的倍数算

备份容量 ≈（数据库 + 附件 + 日志）× 备份保留系数。系数取决于全量/增量、保留份数、压缩率和是否异地存放，按 1.5～2.5 倍做初始规划比较常见。备份要覆盖数据库和附件，只备份数据库，恢复时附件会缺。

这张表只演示算法。 人均附件或平均附件变大，三年容量会成倍上升，先测真实习惯再决定买 1 TB 还是 2 TB。

还要算 RAID、文件系统和快照开销。RAID 1/10 的可用容量通常只有裸容量一半，RAID 5/6 有校验盘开销。按可用容量倒推裸容量，不要拿硬盘标称容量直接当可用空间。

把结果落到配置：三种常见场景

对私有云项目管理软件来说，下面只是示例起点，不是厂商最低配置，也不是行业标准。

中型团队只在内网使用时，公网带宽可以只保留远程接入和补丁下载余量。大型团队要把附件上传下载分开看。集团型团队不要只买一条大带宽，链路冗余、跨地域访问和备份传输会同时占用出口。

配置不是越大越好，而是要有明确的扩容路径。 数据盘能单独扩、带宽能按周调整、备份能迁到独立存储，比一次买满更实用。

上线前怎么验证：三个数字比估算更可靠

估算给起点，验证决定是否够用。上线前至少做三件事。

1. 用真实页面和附件压测。选包含列表、详情、附件上传下载的完整流程，记录 P95 响应时间、吞吐和错误率。压测与公式不一致时，以压测为准，回头修正假设。
2. 固定监控指标。至少看出口/入口带宽峰值、并发会话数、数据库大小、附件目录大小、备份耗时和磁盘使用率。连续一周峰值超过采购带宽 70%，或磁盘使用率超过 75%～80%，就该准备扩容。
3. 做恢复演练。备份文件存在不等于能恢复。把数据库和附件一起恢复，确认历史需求、任务、Bug 和附件都能打开。只恢复数据库、不恢复附件，是最常见的“备份成功、恢复失败”。

高可用设计也要一起验证。单机部署可用，但要写清恢复时间、数据丢失窗口和备份存放位置；多节点或主备方案要验证切换后附件是否可访问。故障域、应用入口和数据恢复的拆分，可参考 私有云项目管理软件4个高可用设计要点。

六个常见误区

1. 用注册人数乘人均带宽。注册人数只是规模上限，带宽要按峰值并发和请求速率算。
2. 把 Mbps 当成 MB/s。100 Mbps 约等于 12.5 MB/s，差 8 倍。
3. 只算页面，不算附件。附件上传下载更容易推高峰值。
4. 只算主数据，不算备份、日志和快照。备份通常按主数据 1.5～2.5 倍占空间。
5. 按平均流量买带宽。平均值会掩盖高峰。
6. 一次买满，不做监控。没有阈值就没有扩容依据。

估算错通常不是公式错，而是输入假设错。 把假设写下来，后面才有修正依据。

在禅道私有化部署里，估算要落到哪些具体位置

禅道这类一体化研发管理平台，数据不只是任务记录，还包括需求、用例、文档和附件，估算时要把这些一起算进数据库和附件两本账。

部署环境上，禅道官方文档明确说明，推荐 Linux + Apache + PHP 7.0 以上 + MySQL 5.5 以上或 MariaDB；21.7 版本之后，MySQL 需要 8.0 以上。实际要求以所选版本和官方文档为准，安装步骤见 禅道使用手册。

附件存放在 zentao/www/data/ 目录下，一键安装包的上传目录示例为 /opt/zbox/app/zentao/www/data/upload/1/。附件和数据库是两套数据，备份和扩容要分别考虑。把附件目录放在独立数据盘，扩容不用动系统盘；迁移时同时备份数据库和附件目录。

备份分成配置文件、修改过的代码、数据库和附件四部分。后台备份、整目录打包、脚本备份都可以用，但恢复时不能只导入数据库。先确认备份覆盖了哪几部分，再做恢复演练，比只看备份文件大小更有意义。 官方说明见 备份禅道。

内网链路通常不是瓶颈，但远程办公、跨地域访问、附件上传下载都会走出口。把出口峰值单独监控，才能判断该扩带宽还是该优化附件。

常见问题

10 Mbps 带宽能支持多少人？

没有固定人数。10 Mbps 约等于 1.25 MB/s。按 100 人同时操作、页面 0.3 MB、每 2 秒加载一次算，需要 100 × 0.3 × 8 ÷ 2 = 120 Mbps；即使操作间隔拉长到 20 秒，页面带宽也要 12 Mbps，再叠加附件，10 Mbps 仍可能不够。中大型研发团队不宜按 10 Mbps 规划。关键不是人数，而是同一时刻有多少数据在传。

存储按每人 1 GB 估算可以吗？

只能做最初粗算。1 GB/人没有区分数据库、附件和备份，也没考虑保留年限；按 500 人算只有 500 GB，三年内附件增长快仍可能不够。按四本账拆开，再用真实附件抽样替换假设。

附件能不能放到对象存储？

是否支持、如何配置，要以所选版本官方文档和实施方确认为准，不要把社区文章当成产品能力。无论附件在本地盘还是独立存储，备份和恢复流程都要一起验证。

最后：把估算变成一张可更新的表

对私有云项目管理软件来说，容量估算不是一次性采购，而是持续校准的运维工作。建议每季度更新一张表，记录峰值并发、操作间隔、页面大小、人均附件数与大小、数据库和附件增量、备份保留策略与耗时、带宽峰值利用率和磁盘使用率。

先算峰值，再乘余量；先分四本账，再谈总容量。 这张表不复杂，但能让下一次扩容有依据，而不是等用户抱怨卡顿才行动。

参考文献：

• 禅道官方文档：《备份禅道》https://www.zentao.net/book/zentaopms/42.html
• 禅道官方文档：《搭建Centos环境安装禅道》https://www.zentao.net/book/zentaopms/809.html