新业务上线前怎么估容量：压测该盯哪几个指标，扩容触发线定在哪

距离上线还有两周，老板在周会上问了一句：「这套系统到底要买几台？」会议室里安静了几秒，有人说按日活估，有人说先上两台跑跑看，管市场的翻出竞品的公开数据说人家一天几百万访问。这时候如果你回答「我估一下峰值 QPS」，这场评估基本就偏了。

容量评估这件事，行业里最常见的失败不是算错一个数，而是根本没建模型——把「买几台」当成猜一个数，最后靠上线当晚有人守着、扛不住再加。真正能落到执行层的容量评估，要建立的其实是三件事：单实例到底能承载多少 → 这个上限由哪一项资源决定 → 触发线设在几成。第三件尤其容易被跳过，而恰恰是它决定了扩容是「从容加机器」还是「半夜救火」。

下面把这套东西从头拆一遍。所有出现的数字都是假设场景里的示例，用来讲换算关系和方法，不是任何真实业务的运行数据。

为什么「估峰值 QPS」这件事本身就容易错

先说这条路为什么靠不住：大家习惯一上来就把话题收敛到「峰值多少 QPS」，但 QPS 是个结果指标，它是「请求形态 + 用户行为 + 依赖链路」共同算出来的产物，把它当成输入去估容量，等于把一个被平均过的结果又反过来当原因用。

峰值 QPS 掩盖了请求之间的成本差异

假设某业务的接口里有一个列表页和一个详情页。假设场景：列表页单次请求大约 8 毫秒 CPU 时间、查 3 次缓存、生成 40KB 页面；详情页单次请求 60 毫秒 CPU 时间、查 1 次数据库加 5 次缓存、生成 12KB 页面。如果按请求数算，两者都算「1 QPS」，但后者消耗的服务端资源是前者的好几倍。你要是按「峰值 2000 QPS」去配，然后按列表页的权重去测，详情页占比一旦上来，机器立刻不够。

这不是极端情况。绝大多数业务都有一条「重接口」，它占总请求数的比例可能只有百分之几，但吃掉的资源可能占到三成以上。估 QPS 这个动作会把这条重接口抹平。

峰值不是均匀分布的，而 QPS 是一个二维压缩后的描述

另一个问题是时间维度上的压缩。一天的流量有明显的波峰波谷，一周里有工作日和周末的差别，一年里有大促和常态的差别。「峰值 QPS」这四个字把「峰有多尖、持续多久、上升速率多快」全压掉了。而这三件事恰好决定了你要不要用弹性：

假设场景：两条曲线的日峰值都是 1500 QPS。第一条曲线在上午十点和下午三点各有一个小时的平缓高峰，前后各有二十分钟爬坡；第二条曲线因为一次推送，在三十秒内从 200 QPS 拉到 1500 QPS，持续四分钟之后回落。按同一套静态容量去配，第一条曲线很舒服，第二条曲线会在爬坡的那三十秒内就开始超时——不是因为机器总数不够，是因为你没有给「扩容动作本身的时间」留位置。

依赖链路会把一个请求放大成 N 个

第三个容易漏的是放大系数。用户看到的「一次页面加载」，服务端可能是 1 次入口请求 + 4 次内部微服务调用 + 12 次缓存查询 + 2 次数据库查询 + 1 次外部调用。容量规划如果只对入口流量建模，内部服务和连接池的容量就会被算漏。这类漏算在上线前的静态评估里几乎看不出来，只有压测和线上真实流量才能暴露。

所以正确的顺序不是「估峰值 → 配机器」，而是反过来：先量出单个实例在各项资源上的承载上限，再由这个上限去反推需要多少台，最后把业务侧的流量预估只当作校验项。

把容量拆成三条线：并发连接、吞吐、单请求资源占用

一个实例的承载能力，不要用一个笼统的「能扛多少」来问，要拆成三条互相关联但不等价的线。这三条线分别卡在不同的地方，谁是木桶的短板，取决于你的业务形态。

第一条线：并发连接数

这条线问的是「同时挂着多少个连接」。它由文件描述符上限、网络栈参数、内存里的连接结构、以及中间件的连接池配置共同决定。长连接业务（WebSocket、推送、IM、物联网上报）这条线通常最先出事：连接数上去了，但每个连接上跑的请求很少，CPU 可能闲得很，机器却已经不肯再加连接了。

估算思路：并发连接数 ≈ 活跃用户数 × 单用户平均持有连接数 ×（1 + 短连接重连冗余）。短连接业务还要额外算 TIME_WAIT 状态的堆积，一次突发背后可能多出几倍的半开连接。

第二条线：吞吐

吞吐有两个口径，别只看 QPS 那个。

一个是请求吞吐，即单位时间处理的请求数，它主要被 CPU 和下游耗时绑住。另一个是字节吞吐，即单位时间出去多少 MB，它被网卡带宽、内核协议栈、TLS 加解密能力绑住。小包多的业务（短请求、大量重定向、高频心跳）还要看 PPS，也就是每秒包数——包数先到上限而带宽还很空闲的情况并不少见。

估算思路：字节吞吐 ≈ QPS × 单请求平均响应体大小 ×（1 + 协议与握手开销系数）。HTTPS 场景别忘了把 TLS 握手和会话复用的成本算进去，单次握手的计算开销相当于若干次普通请求。

第三条线：单请求资源占用

这是把前两条线和硬件连起来的中间量。所谓单请求资源占用，就是把一个请求在整个链路上消耗的资源，按 CPU 时间、内存峰值、磁盘 IO 次数、下游查询次数分别记下来。有了这组数，原本讲不清的部分就有了可以换算的依据。

具体来说，你要对每个主要接口量四个数：服务端 CPU 时间（毫秒）、处理过程中额外分配的内存（KB，注意是增量不是进程总量）、产生的磁盘读写次数、以及产生的下游调用次数。

拿到这些数之后，单实例上限就能算了：

CPU 口径的上限 ≈ 可用核数 × 目标 CPU 水位 ÷ 单请求 CPU 时间 × 1000。这里「目标 CPU 水位」不是 100%，一般留到六到七成，原因后面讲触发线时再说。

内存口径的上限 ≈ 可用内存 ÷（单请求内存增量 × 并发数 + 常驻连接内存）。注意常驻部分要单独算，它跟请求数不是线性关系。

这三个口径算出来的数取最小的那个，才是这台机器的实际承载上限。剩下两条线只是「还没到」，不代表不存在。

压测到底该盯哪几个指标

明确了结构和换算，压测才有靶子。压测的价值不在于「跑出一个数字」，而在于验证上面的估算，并且找出估算没覆盖到的那一项。

服务端侧必须采的指标

CPU 要看使用率、负载均值、以及上下文切换速率三项，只看使用率会漏掉锁竞争。内存要看已用、缓存占用、换页情况和常驻集大小，Java 类服务还要把堆外内存和 GC 停顿一起记。磁盘看读写吞吐、IOPS、平均等待时间和队列深度。网络看出入带宽、包速率、连接数、重传率。

这些是资源侧的。业务侧要同时采四条：吞吐量（成功量而非发出量）、延迟分布、错误率、以及超时占比。成功量和发出量一定要分开统计——失败的请求也是消耗了资源的，只统计发出量会让失败的请求看起来「免费」。

延迟必须看分布，不能看平均

这一点在容量压测里比在性能调优里更重要。平均值会把长尾藏起来：假设一千个请求里九百九十个是 20 毫秒，十个是 3 秒，平均值只有 50 毫秒左右，看起来好得很，但那十个用户已经在点关闭了。

压测里至少记录 P50、P90、P95、P99 四个分位。判断「到顶了」的信号通常是 P99 开始快速抬升，而不是中位数变差。一旦 P99 随着并发增加呈非线性上翘，说明系统里某个环节开始排队了，容量已经越过经济区间，再往上加并发换来的只是排队时间。

顺便说一句，错误率和延迟是联动的。很多超时错误本质上是「延迟超过了等待阈值」，把超时阈值放宽不会让系统变快，只会让排队更长，然后线程池被占满，错误从超时变成拒绝。压测时如果看到放宽超时后错误率下降但吞吐没涨，基本可以确定是排队型瓶颈。

压测自身会骗人：四种常见失真

压测数据不可信，绝大多数时候不是工具的问题，是场景搭错了。下面这四种失真几乎每家都踩过。

压测机自己先到瓶颈

这是最典型的一种。你看到并发从 500 加到 2000，QPS 曲线走平了，就以为服务端到顶了——其实先到顶的是压测机：它的 CPU 跑满、端口耗尽、或者垃圾回收跟不上。

怎么判断：同时看压测机的资源率和一个「外部见证指标」。如果压测机 CPU 已经到八成以上、而服务端所有的资源率都还很低且水位不再上升，那瓶颈在压测端。另一个更可靠的判据是看服务端自己的各项资源是不是随并发一起涨：干活的机器，资源消耗一定会跟着并发走；不跟着涨，说明压力根本没打进去。

解决办法是加多台压测机分担，同时给压测机留出至少一半余量。压测脚本本身也要轻：别在压测进程里做耗时的断言、打详细日志、或者每请求都新建 TLS 会话（除非你要测的就是握手段）。

缓存命中率失真

压测脚本通常只用几十个 ID 反复请求，或者干脆全打同一个接口。这种情况下缓存命中率接近百分之百，而线上真实场景的命中率可能只有六七成。结果是压测数据漂亮得很，上线之后数据库直接被打穿。

修法是构造符合真实访问分布的键集合：键的总量要足够大，分布要贴合业务特征（多数内容有长尾，热点只占少数）。如果拿不准分布，宁可按不利方式估——把缓存全失效的情况单独压一轮，这一轮测出来的数才是「缓存崩了以后你还活不活得下去」的答案，这个数字通常才是决定数据库该配多大的依据。

数据分布失真

这一条比缓存更隐蔽。建测试库时大家习惯塞几万条干净数据，字段取值均匀，表很小，索引完全在内存里。真实生产环境里数据量可能是两个数量级以上，热点高度集中，还带着历史脏数据。

数据量本身会改变查询结果的特征：索引能不能常驻内存、优化器会不会换执行计划、扫描行数差多少，这些都会随数据量变化。所以测试库的数据量至少要做到同量级，字段取值也要按真实分布构造，特别是那些会被用在 WHERE 条件和 JOIN 上的字段。

还有一个常被忽略的：写操作会在库里留下东西。只读压测跑一个小时和写入压测跑一个小时完全不是一回事，后者会让表膨胀、索引碎片化、binlog 堆积、主从延迟上升。容量评估如果要覆盖写入场景，压测时长要比只读场景长得多，短跑是看不出慢的。

热身不足

JIT 编译还没完成、连接池还没建满、缓存还是冷的，这时候采到的数据全是启动期的，偏低地离谱。反过来，如果压测一上来就猛灌，连接池瞬间打满，采到的是抖坡期的崩溃数据，也不准。

规范做法是：先用一到两成目标压力跑一段热身时间，等各项目指标稳定住（不再持续上升也不再下降）之后再开始计数；每一档压力之间留出足够的稳定时间；正式取样区间要排除掉预热段和收尾段。

找木桶项：哪一项先到拐点，怎么认出来

压测跑完之后，手上有十几个指标曲线。找木桶项的方法不是逐个看谁的数字大，而是看谁先停止跟随压力增长。

具体做法是：逐步提高并发，每个资源项的资源率都会跟着涨。某一档开始，吞吐不再线性上涨、而其他资源还在涨——说明多出来的压力没变成有效产出，而是变成了排队。这时候去看哪一项目的资源率在这一档已经进入高位并且曲线开始变平，那就是当前的瓶颈项。

几种典型特征的识别方法：

CPU 型：CPU 使用率接近饱和，同时负载均值明显高于核数，上下文切换频繁。这时候延迟会随并发快速上升，但错误率初期不高。这类瓶颈最容易缓解，加核或加实例通常线性有效。

内存型：内存用量抬到接近上限，同时伴随换页上升，磁盘 IO 里出现了与业务无关的读写。这类瓶颈的表现是周期性卡顿——垃圾回收或缓存淘汰时会有一段延迟尖峰。加实例有效，但要注意如果是单实例内存泄漏，加实例只是推迟出事的时间。

连接与 IO 等待型：CPU 不高、内存也不满，但吞吐上不去，进程里有大量线程在等待。这时候去看网络重传率、磁盘平均等待时间、下游响应时间。这类瓶颈加 CPU 完全没用，得改连接池配置、改查询、或者给下游扩容。

锁与串行化型：加并发之后 CPU 使用率不升反降，延迟却变长，错误率上升。这种情况下系统在忙争而不是忙干活，扩容基本无效，得先解决串行段。

另外一个容易被忽略的事实是木桶项会换人。你解决了 CPU，下一个可能是数据库连接池；给数据库加了从库，下一个可能是网卡。每次扩容之后都要重跑压测重新定位，这是容量工作里最容易被省掉、也最容易导致后续误判的一步。

容量模型表

把上面的方法固化下来，就是下面这张表。它不是标准答案，是一个填报模板——每一项都要用你自己的压测数据填进去，有空缺项的就不是合格的容量模型。

表里的触发线数值是通用建议起点，不是行业标准，也不是承诺值。它们的前提是「扩容动作需要几十分钟到数小时」，如果你的扩容是分钟级（例如镜像已经备好、实例可在控制台直接加开），可以在实测后适当上移；如果扩容要采购、要上架、要走流程，那就要往下压。

触发线怎么定：为什么不能等到九成

这是全文最值钱的一段。绝大多数扩容事故的原因不是没设阈值，而是阈值设得太高。

把「扩容所需时间」算进触发线

触发线的本质是：在资源耗尽之前，留出足够把扩容动作做完的时间。这是一道很简单的算术题，但只要漏算，阈值就形同虚设。

把三段时间加起来：

第一段是从指标越线到有人知道的时间。告警采集有周期，告警通知有延迟，值班响应也不是零延迟。基础监控分钟级采集加上一两次重试判定的话，这一段可能就是几分钟。

第二段是从知道到决策的时间。要不要扩容、扩多少、谁来批，这一步人参与越多越慢。晚上和假期更慢。

第三段是从决策到生效的时间，也就是扩容本身的耗时。这里差距巨大：弹性云加开一台可能是分钟级；物理机采购上架是天级到周级。这一段的量级，直接决定了触发线该在哪里。

再去乘一个增长速率。如果平时是缓慢爬升的，那你有充裕的时间；如果是推送带来的三十秒直线拉升，那前两段时间加起来就已经错过了。所以触发线不是一条固定的百分比，它是「扩容准备时间 × 当前增长速率」推导出来的。扩容所需时间越长，触发线就得越低。

为什么六十到七十成是常见的稳妥区间

在这个逻辑下，六到七成是一个偏保守但不荒谬的起点。它同时满足了三个条件：

其一，留出了观察和决策的余地。水位在六到七成的时候，你还可以先看看是不是偶发波动、是不是某个接口的异常调用导致的，而不必立刻做不可逆的动作。

其二，覆盖了「单实例故障」的场景。三台机器跑在七成，挂掉一台剩下两台要扛到超过满载。如果平时就跑在九成，一台挂掉等于全站雪崩。冗余不是浪费，冗余是可用性的一部分。

其三，资源在非满载区的性价比是最高的。绝大多数服务在七成以上进入排队区，每增加一单位资源换来的有效吞吐下降、延迟上升。把机器跑到九成，你省下的机器钱很可能已经在用户体验上赔出去了。

触发线要分两级：预警线和行动线

单一阈值的告警系统最后一定会变成噪音，然后被人关掉。正确的做法是两条线。

预警线设在扩容所需时间的两倍余量处，它的作用是让人开始准备，而不是必须马上动手。这个告警可以要求「工作时间查看」。

行动线设在扩容所需时间刚好够的位置，一旦越线必须立刻执行扩容动作，不论几点、不论是否在假期。这条线要配一份可以直接照做的执行清单：谁有权限批、加几台、从哪个镜像起、测完哪一项算成功。

两条线都要写清「持续时间」条件，例如「持续五分钟高于六成」而不是「瞬时高于六成」。瞬时值会因为一次定时任务、一次爬虫、一次数据导出而越线，只看瞬时值的告警一周响几十次，两周之内必然被静音。

还有一条常被忘的：要给数据库连接池、消息队列堆积量这类非硬件资源单独设触发线。它们会先于硬件资源报警，而且修起来通常比加机器更快。

扩容动作本身也要提前准备好

触发线的可用性，最终取决于「扩容能不能快」。这也是为什么在做容量评估的时候，要把供货侧的能力一起算进去。

举个偏保守的工程做法：上线前就把镜像、初始化脚本、配置模板、负载均衡挂载流程全部准备好并演练一遍，让扩容变成一个不需要临场思考的操作。真正到半夜要加机器的时候，任何需要现场思考的步骤都会翻倍耗时。

在机房一侧，扩容速度也是选型的一部分。像深耕 IDC 19 年（成立于 2007 年）的一万网络这类服务商，自营机柜支持最快 1 分钟上架，这一项的意义不在于平时，而在于它把第三段「从决策到生效」的时间压到了很短——第三段短了，触发线就可以往上抬，同样的机器数是能承载更高的水位的。容量评估里最有价值的一平米，往往不是多买的那台机器，而是把扩容耗时缩短的那几十分钟。

上线后的校准：第一版容量必然不准

上线前做的所有估算，本质上都是有偏的。偏差来自请求构成变了、某个接口的调用比例变了、用户实际停留时长和设想的不一样。承认这一点，然后把校准做成流程。

校准一：用真实流量重算单请求资源占用。上线一两周、有了完整的业务周期（至少一个自然周，最好覆盖到周末）之后，重新统计一遍各接口的 CPU 时间和资源占用，跟你压测时的数据对比。差异大的地方回头重做压测模型，而不是调比重。

校准二：核对峰谷比。上线前对业务曲线形状的判断，通常是最不准的一项。拿到实际曲线之后重新算一遍需要的余量，特别是看爬升速率，因为它直接决定触发线的高低。

校准三：核对容量折算系数。上线前推的「每台机器能扛多少」，跟上线后实测的值一定会差。这个差如果超过三成，说明模型里有某一项算错了，要回头找，而不是简单把结果打个折。

校准四：用一次真实的压力事件验证触发线。第一次营销活动、第一次被爬虫扫、第一次节日流量高峰，都是验证告警和扩容流程的好机会。事后复盘两件事：触发线是否提前了足够多的时间，以及扩容流程里哪一步最慢。

校准的节奏建议是：上线后的第一个月每周做一次，之后转入月度；业务形态发生重大变化、或者连续三个月没有经历过一次真实峰值，也要重跑。

避坑指南

坑一：只压单接口，不压混合场景

单接口压测跑出来的数很好看，但没有参考价值。真实流量是混合的，重接口会抢走资源，轻接口的成绩会被拉下来。压测场景必须按线上的接口比例搭，并且在正式压测之外，还要单独压一遍「重接口占比翻倍」的不利情况。为什么坑：你配出来的容量如果只在理想比例下成立，那它一上线就不成立。怎么避：从上线后的日志或者同类业务的经验中取一次实际的接口分布，把它写进压测脚本。

坑二：把压测结果当成稳定值

同一个脚本跑两次结果不一样的情况很正常，差个一成以内不必纠结，但如果你看到差异在三成以上，那一定是场景或环境变了，比如缓存冷了、后台有任务跑、或者压测机接管了。压测结论应该是多次结果的分布，不是某一轮的峰值。为什么坑：用最好的那一轮数据做容量规划，等于按运气上线。怎么避：每档压力跑多轮，取中位数做模型输入，并记录标准差。

坑三：忽略依赖方的容量

你把应用层扩到了十台，结果数据库只有一台。这类「只有一层扩容」的情况非常常见，具体表现是加了机器之后吞吐完全不涨甚至下降（因为数据库被更多连接打得更惨）。为什么坑：你找瓶颈只盯着自己的实例，忘了它不是独立存在的。怎么避：每一层都要有自己的容量模型和触发线，扩容时自上而下检查整条链路。

坑四：把「能跑」当成「够用」

压测跑到某个并发，系统没崩，于是就当成容量上限了。这是最接近自我保护的一个错觉——没崩不代表体验可用，那些延迟已经五秒的请求虽然返回了，用户早就走了。为什么坑：容量指标真正的底线是用户体验，不是系统有没有活着。怎么避：在上限定义里同时写进「P99 延迟不超过多少」和「错误率不超过多少」，两个条件先到哪个，那个就是真正的上限。

坑五：没有给告警本身做容量评估

上线前监控还没配全，只看了 CPU 和内存，其他项目全空。等真出问题的时候，你手上没有定位数据。为什么坑：评估阶段没采的数据，事后再也补不回来。怎么避：在压测前先确认采集覆盖到表里的每一项，压测时顺带验证采集本身在高负载下会不会丢点。

容量评估里最容易被问住的六个问题

没有真实流量，压测模型怎么建？

从业务侧拿三样东西：预期用户量和使用频率、主要接口清单、页面到请求的映射关系。然后用同类公开数据或者相似业务的历史数据做参考，把请求比例拼出来。这一步不准是必然的，所以不要试图一次性建准——先建一个粗略模型跑一轮压测，看看哪个接口的资源占比最重，然后重点去做那一块的细化。模型的价值不在于一次建准，而在于它能指出下一步该精修哪里。上线后按实际日志重新校准，一般两周内就能收敛到一个可用的模型。

压测机自己先到瓶颈，怎么判断？

三个判据同时看：一看压测机的 CPU、内存、端口使用是否已经接近上限，二看服务端的资源水位是不是还在随并发上升——如果服务端水位不涨了而压力还在加，那压力一定卡在了某个中间环节（常常就是压测机自己），三看服务端的连接数和实际处理量有没有继续增加。三者一致指向「压力没进去」就可以确认。一个很实用的习惯：压测机的资源水位要和服务端一起画在同一块看板上，肉眼就能看出谁先饱和。解决上加压测机、加出口，压测脚本本身也要尽量轻量。

触发线定在七成还是八成？

没有标准答案，因为它取决于你的扩容耗时和增长速率，而不是取决于业务类型。算法是：扩容全程耗时乘以当前最陡的增长斜率，得到「从触发到耗尽之间你需要的余量」，再用这个值去反推水位线。举一个假设例子：扩容要三十分钟，最坏情况下水位每十分钟涨一成，那你需要至少三成的余量，触发线就不能高于七成。反过来，如果扩容是分钟级的、且平时增长很平缓，八成甚至更高也可以接受。唯一不能做的是拍一个数，然后永远不改。上线后每次压力事件都要回头复核一次。

缓存命中率在压测里失真怎么办？

两层做法。一层是把 key 集合做对：key 的量级、分布、热点集中度都要贴近真实，不要只用几十个 key 轮询。另一层是把「低命中率」当成必须覆盖的场景单独压一遍——全量穿透到数据库的那一轮跑出来的数，才是你给数据库配容量的依据。缓存是提高上限的杠杆，不是容量本身，把杠杆当成地基是很多上线事故的直接原因。另外记得测一下缓存集体失效之后的恢复过程，那一瞬间数据库承受的往往是平时的数倍。

数据库连接池算不算容量的一部分？

算，而且常常是最先报警的那一项。池的最大连接数是一个硬上限，越过它请求就开始排队或者直接报错，这时候 CPU 和内存可能都很闲。评估时把它单独作为一条线：根据单请求的数据库耗时估算一台应用实例需要多少连接，再乘以实例数，得到池的总需求，然后核对数据库侧的最大连接数是否够。特别要注意加了应用实例之后，总连接需求会同步上升，横向扩容不做池侧调整，等于把压力原样搬到数据库上。池的相关指标要单独设触发线，通常建议看池使用率和等待队列长度。

扩容要多久，触发线要不要把这段算进去？

必须算，而且这是决定触发线高低的第一变量。把「指标越线到被发现」加「发现到决策」加「决策到新实例承接流量」这三段的时间加起来，再乘以这段时间内水位的上升幅度，就是你要预留的余量。扩容越慢，触发线就必须越低。顺带一句：能压短的往往不是前两段，而是第三段——镜像提前备好、初始化脚本演练过、控制台能直接加实例，这些都能把第三段从天级压到分钟级。所以在选型阶段就把扩容速度考虑进去，比事后调阈值有效得多。

新业务该不该直接用弹性扩缩容？

弹性是手段不是免死牌，它解决的是「来不及手动扩容」和「峰谷差异大浪费钱」这两个问题，但它代替不了容量评估。理由很简单：弹性也要有时间才能起来，也要依赖镜像就绪、依赖下游扛得住。而且弹性会带来一批新问题——实例频繁启停导致缓存持续失效、健康检查误判、以及账单失控。建议的做法是：基线容量按静态评估配足常驻流量，弹性只用来覆盖超出基线的那部分波动，同时对 elastic 层的规模设上限，避免异常流量带来意外账单。

结论

回到会议室那个问题。「到底要买几台」这个问题本身就没有直接答案，能回答的是另外三个子问题：一台能扛多少、它由哪一项决定、到什么水位必须动手。容量评估的产物不该是一个数字，应该是三样东西：一组单实例上限数据、一张填齐的容量模型表、以及一套带两级阈值的告警和执行清单。

这中间最容易偷懒也最要命的一步是触发线。许多人把容量评估做成一次性交付，估完就结束，阈值随手填个八十，然后上线后再也没人回头看。等到真出事的时候，扩容要两小时而阈值还剩五分钟就到了——这时候加机器已经来不及了。所以宁可把触发线压低一点、余量留多一点，也不要追求机器利用率最大化。机器闲置的成本看得见，用户流失的成本看不到。

还有一句提醒：这份东西做完之后要记得它是一次快照。业务变了、接口变了、依赖变了，重新跑一遍压测、重新校准一遍模型，这套东西才会一直有用。

容量模型里的数字是怎么来的

本文中涉及的判断方法、换算关系均为通用的工程方法说明；文中所有数字均为用于演示换算过程的假设示例值，不代表任何真实业务的运行数据，也不构成任何性能承诺。涉及一万网络的描述限于官网公开明示内容：深耕 IDC 19 年（成立于 2007 年）、自营机柜最快 1 分钟上架。实际的资源规格、可用区、交付时间与费用以签约时最新报价与合同为准。