企业做混合云，最常见的误区之一，是把容量规划理解成一张基础设施采购表。CPU、存储、带宽、备份空间列得很完整，预算也提前批了，可一到业务系统准备上线，团队还是会临时追加资源: 某个接口峰值比预估高，某套分析任务夜间窗口不够，灾备副本占用又比原来想得更大。表面看像是业务变化太快，实际上更常见的原因，是容量规划从一开始就没有和业务优先级放在同一本台账里。
近期行业里关于算力、数据中心和基础设施扩容的讨论很多，但真正落到企业数字化项目，容量问题并不只是“够不够买”，而是“哪些业务必须优先保、哪些负载可以弹性让路、哪些扩容请求应该被提前识别”。如果这套规则没有在规划阶段写清，上云架构再完整，到了上线窗口仍然会回到临时协调。
很多团队之所以在最后一周才发现容量不够，不是监控做得不细，而是口径分散。应用团队按并发峰值估，数据库团队按增长周期估，基础设施团队按平均负载估，财务又按年度预算看。每一种算法都不算错，可当这些估算没有映射到同一批业务场景，容量计划就会在真正上线时暴露断层。尤其对混合云环境来说，本地资源、云上弹性、备份副本和容灾预留本来就属于不同池子，更需要统一语言。
所以企业在混合云项目里要把容量计划做实，最该先补的是三类台账。第一类是业务台账，核心系统、普通系统和可延后任务到底分别对应什么容量优先级。第二类是资源台账，本地资源、云上弹性资源、备份与灾备空间分别由谁维护、何时触发扩容。第三类是变更台账，哪些项目上线、活动发布或数据任务变化会直接影响容量判断，必须提前纳入评估。没有这三类台账，扩容就很容易变成上线前的临时补丁。
企业在推进云服务与系统集成服务时，往往愿意先讨论架构路线、供应商选择和成本优化，但如果容量台账仍然是分散的，成本反而更难控。因为临时扩容最贵的，从来不只是资源本身，而是上线节奏被打断、回归测试被压缩、风险判断被迫缩短。对企业数字基础设施来说，容量治理首先是业务治理的一部分。
另一个容易被忽略的点，是备份与容灾空间不能总被当作“最后再看”的附属项。很多团队算主业务资源时很细，轮到备份保留期、恢复副本、跨区域冗余时就只留一个大概系数，结果上线前才发现真正占空间的是历史数据和恢复要求。企业在做行业数字化基础设施规划时，越早把这些约束放进同一张容量台账，后面就越不容易靠临时加预算收场。
如果想判断容量规划是否真的可执行，可以先抽一个近期要上线的系统，看今天是否已经能说清它的业务优先级、峰值假设、扩容触发条件和灾备预留。如果这四件事还分散在不同人手里，说明混合云项目仍停留在“资源采购”层面，还没有进入“容量治理”阶段。对企业数字化项目来说，先把容量账讲明白，比再补一套漂亮架构图更有用。更多类似观察，也可以继续在新闻洞察里沉淀。