Claude Code 赋能容量规划：从被动应急到主动预测

长期以来，我所在公司的容量规划，就是盯着仪表盘，直到某个指标变成橙色，然后购买更多已经耗尽的资源。数据库存储空间逐渐逼近上限，就有人升级套餐。业务繁忙的一周里队列出现积压，就有人增加一个 worker。单独来看，每个决定都没错，但整套做法依然只是被动响应：永远落后于那些已经开始造成影响的问题一步。

令人不安的是，这其实根本算不上规划。所谓规划，是在真正需要之前，就知道自己将需要什么。而我当时做的，只是在资源短缺发生之后才注意到它，再把补救措施称为“计划”；实际上，那不过是问题出现与痛苦降临之间间隔更长的应急处置。

Claude Code 改变了这一点：它让我们能够以很低的成本，在增长发生之前对其建模，而不是等增长已经迫使我们做出决定后才去测量。容量规划背后的数学从来都不是难点。真正困难的是定期坐下来，在指标变成橙色之前，对所有重要资源都实际执行一遍分析——没有人有时间做这件事。下面就是这套工作流。

为什么被动扩容一开始感觉没问题，直到问题真正发生

从狭义上说，被动扩容确实有效：变成橙色的仪表盘最终会恢复正常，系统也能继续运行。但它无法给任何人留下充分时间去做出明智的决定。数据库套餐只能在压力之下升级，被迫接受当时的价格和迁移风险，而不是在提前选定的从容时机完成升级。

更深层的问题在于，被动扩容把每种资源都视为彼此独立的对象。存储有人监控，计算资源也有人监控，却没有人关注它们之间的关系。因此，真正的约束——随着业务持续增长，最先耗尽的那项资源——在引发事故之前始终不可见。

增长也不是线性的。按照上个季度增长率制定的计划，可能会悄无声息地偏离现实，却无人察觉。某条流量曲线可能在一年里一直表现为每月稳定增长 10%，但一次功能发布或一个新客户群体，就可能让它在一夜之间改变形态。旧的容量模型仍会报告余量充足，直到事实证明它已经错了。

一个从未对未来容量进行预测的系统，并不存在所谓的安全余量。它只有一段未经测量的余量，而未经测量的余量看上去与健康余量完全相同——直到它失效的那一周。

下面这套工作流，可以把容量规划从由橙色仪表盘触发的被动救火，变成一项常规预测工作，让规划始终走在增长前面，而不是落在后面。

如果你还想了解系统遭遇从未建模过的负载时会发生什么，可以参阅《Claude Code for Load Testing》。它回答的是系统当前的极限在哪里，而这套工作流回答的是：业务增长将在什么时候触及这个极限。

增长建模 Skill

第一个 Skill 会为实际使用趋势建立一幅真实图景，覆盖所有重要资源：存储、计算资源、数据库连接、队列吞吐量和请求量。它会在足够长的时间窗口内提取历史使用数据，以区分真实趋势与噪声；同时分别拟合每项资源的增长曲线，而不是假设所有资源都以相同速度增长。

这一点很重要，因为各种资源并不会同步增长。请求量可能保持不变，存储却会因为数据不断积累而稳定增长。某个特定功能可能导致计算资源用量骤增，而数据库连接数依然保持稳定。把增长视为一个统一数字，恰恰会掩盖那些最终带来意外的分化。

这个 Skill 还会标记近期增长曲线形态发生变化的资源，因为斜率变化意味着上游发生了某种改变——可能是新功能、新客户群体，也可能是使用模式发生变化——原有预测已经不再适用。

只有把增长曲线与实际限制放在一起，了解增长曲线才有意义。第二个 Skill 会把每项资源映射到它真正的上限：数据库套餐达到极限的位置、队列吞吐量无法继续跟上负载的位置，以及计算集群必须在响应时间恶化之前增加节点的位置。

这个 Skill 考虑的也是实际运行上限，而不是理论上限。数据库在技术上或许支持更多连接，但在达到理论上限之前，查询延迟就可能已经开始上升，真正重要的是后一个数字。存储同样如此：性能往往会在磁盘真正写满之前就开始下降。

把增长曲线与真实阈值结合起来，最终会得到真正重要的数字：预计日期。不是“存储使用率达到 70%”，而是“按照当前增长速度，存储将在大约七周后越过性能开始下降的临界点”。百分比告诉你现在身处何处；预计日期则告诉你应该采取什么行动，以及最晚何时采取。

成本预测 Skill

忽略成本的容量规划，只完成了一半工作，因为大多数扩容决策本质上都是披着技术外衣的成本决策。第三个 Skill 会使用相同的增长曲线，预测每项资源升级到未来各个扩容档位时的成本，而不仅仅判断是否需要扩容。

这样一来，“基础设施支出正在增长”这种模糊感受，就会转化成带有明确日期的具体数字：如果什么都不改变，三个月后的账单会是多少；在每种现实可行的扩容方案下，账单又会是多少。它还能揭示纯容量视角完全看不到的选项：有时，面对即将触及的上限，答案并不是升级到更大的套餐，而是通过架构调整来避免升级。只有把成本与容量放进同一份报告，这种权衡才会显现出来。

这与《Claude Code for Performance Optimization Patterns》背后的方法论相同，只不过这里关注的是增长将带来多少成本，而不是当前使用量需要多少成本。

规划报告 Skill

第四个 Skill 会把增长曲线、阈值和成本预测转化成团队真正能够据此做出决策的内容，而不是留下一堆数字，等某个人在压力之下进行解释。它会生成一份按紧迫程度排序的报告：哪项资源最先触及上限、届时有哪些可选方案、每种方案的成本是多少，以及安全执行每种方案需要预留多长时间。

这份报告会一次又一次地追踪预测结果，让增长曲线的变化成为清晰可见的趋势，而不是等到关键一周才突然发现的意外。预计日期随着每次发布不断提前，与预计日期长期保持稳定，是两种截然不同的情况；只有持续追踪历史记录，才能看清实际发生的是哪一种。

它还会把容量预测与已知的即将发生的事件关联起来，就像流量模型会与营销活动关联一样。如果增长曲线已经显示数据库将在两个月后逼近上限，同时又有一批新客户即将接入，预计会让曲线进一步加速，那么报告会在问题发生前揭示这次碰撞，而不是等事故发生时才让人意识到它。

这套工作流在实践中如何运行

增长建模 Skill 首先运行，利用当前使用数据刷新每项受监控资源的趋势。阈值 Skill 会把这些曲线映射到真实的运行上限，为每项资源生成预计日期，而不是一个静态百分比。成本预测 Skill 则计算在这条时间线的每个节点上，各种扩容路径分别需要多少成本。

规划报告 Skill 会把所有信息整合成一个统一的优先级视图，并按照既定计划定期刷新，而不是等仪表盘变成橙色才触发。如果某项资源的预计日期即将到来，报告就会提前发出标记，为团队留出足够时间从容决策，而不是紧急处理。

渐渐地，“我们什么时候需要扩容”这个问题，不再得到一个耸肩之后开始手忙脚乱的回答。它变成了一个定期重新计算的具体日期，附带明确成本，也留下足够的提前量，让团队能够选择正确的方案，而不是在压力下被迫选择执行速度最快的方案。

这套工作流如何改变了我的实践方式

第一个变化，是在某项资源成为真正的问题之前两个月，我就发现了它。某个功能发布之后，一条队列的吞吐量增长曲线悄然变陡。报告发现问题时，原先“那条队列没问题”的固有认知其实早已过时。

第二个变化，是扩容决策的制定方式。采用这套工作流之前，扩容决策总是在资源真正耗尽的那一周才做出，并承受由此带来的全部压力。采用这套工作流之后，决策会提前数周完成，团队有足够时间比较各个方案的成本与工作量，而不是选择最快能够启用的那一个。

第三个变化，是基础设施成本不再成为每月账单上的意外。把预计成本曲线与容量曲线放在一起之后，扩容决策和预算讨论成了同一场对话，而不是两场永远无法对齐的对话。

第四个变化也是最大的一项：我不再通过资源本身发出的警报，才发现它已经捉襟见肘；而是通过一份提前数周完成计算的报告得知这一点。这种转变，让容量规划从一件被动发生在团队身上的事，变成团队有意识主动完成的工作。

如果你想全面了解我如何使用 Claude Code 运行生产系统，可以查看 DEV.to 上的完整系列，其中涵盖了我所依赖的每一套工作流，从容量规划、负载测试到混沌工程。

容量预测应该向前看多远？

应该远到足以为耗时最长的扩容方案预留真正的准备时间，无论它需要预算审批、迁移，还是采购硬件。对大多数团队来说，这意味着预测未来两到三个月，并且定期刷新，而不是只计算一次就无限期地相信其结果。

如果实际增长与预测曲线不一致，会发生什么？

这正是工作流需要定期重新运行，而不是只生成一次预测的原因。如果增长曲线改变了形态，下一次运行时，预计日期也会随之变化。这是在提醒团队检查上游究竟发生了什么，而不代表工作流失效。

这能取代关于架构调整与直接扩容之间的判断吗？

不能。它提供的是做出这种判断所需的数据。面对某个容量上限时，正确做法究竟是升级到更大的套餐，还是重新设计架构，仍然需要由团队决定。但与凭借直觉和一个橙色仪表盘做决定相比，依据一份标明日期的预测和成本对比来决策，结果会好得多。

这只对大型基础设施团队有用吗？

不是。从某些角度看，小团队反而能从中获得更多收益，因为小团队几乎没有余力承受被动救火带来的混乱。无论规模大小，提前两个月知道数据库套餐需要升级都很有价值；而预算越紧张，成本预测就越重要。

从被动应对资源短缺，到提前预测短缺的发生，是我在基础设施运行方式上做出的一个并不起眼、却极具杠杆效应的改变。成本是构建四个 Skill，让它们现在可以按计划自动运行，无须我介入；回报则是在截止日期前两个月从容做出决定，而不是等到资源真正耗尽的那一周，仓促做出代价高昂的选择。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。