云服务器产品页缺的四个数字：超售比、IOPS、保障带宽与 IP 属性怎么问出来

前两篇讲的是超售和端口限速。这一篇讲一个更前置的问题：为什么你在产品页上找不到真正需要的那几个数字。翻十个套餐页，能看到核数、内存、硬盘、带宽、流量——但看不到超售比、看不到 IOPS 配额、看不到保障带宽、看不到 IP 属性。而这些恰恰是决定体验的。这篇讲清这些数字为什么不在页面上，以及怎样通过反问把它们问出来。

先放对照入口：

云途 —— 产品线分得较细，适合对照「同一配置不同产品线」的差异。

isvoro —— 档位按流量阶梯排列，可观察标注项的取舍。

sixtynet —— 独服线，属性加价的定价模型最清晰。

rabisu、spartanhost、justg、zji、景文互联、数脉科技 —— 其他方向对照。

本文讨论产品页信息与选购沟通的一般方法，不针对任何具体商家，也不对任何产品作质量评价。文中给出的提问话术、判读标准与示例均为通用参考；各商家的公开披露程度、销售响应方式与政策口径差异很大，实际答复可能与示例不符。本文不构成对任何商家的服务承诺或质量保证。

一、产品页上缺的四个数字

还有一个缺失项比这四个更隐性：「同一台机器上还有谁」。

你无法知道这台宿主机上跑了哪些客户、跑什么业务。

而这件事决定了实际体验。如果邻居在跑批量计算，你的磁盘和 CPU 都会被拖累。

这个信息永远不会披露，因为涉及其他客户隐私。但它可以通过「性能波动的规律」间接推断——如果波动与你的业务周期无关，那波动来自邻居。这就是为什么「稳定的性能」比「优秀的峰值」更难得：前者需要宿主机上的邻居都很安分。

还有一个隐藏字段：迁移和降级政策。

产品页只讲「怎么升级」，不讲「怎么降级」。

而实际使用中，降级需求很常见。业务缩小、预算削减、项目结束，都需要降配。

有些产品允许降配但不退差价，有些完全不允许降。

这个政策不写在页面上，但它影响的是「试错成本」。

如果允许降配，那买大一点的风险就低；如果不允许，买大了就是沉没成本。

所以买之前要问一句：能不能降配，降配后费用怎么算。

这个问题在选独服时尤其重要。因为独服的配置是固定的，降配往往意味着退租重买。

再看一个特殊的缺失：退款和试用。

绝大多数云产品不提供试用，退款政策也各有不同。

而这直接影响「验机」这件事的可行性。如果不能退款，那验机的成本就是整月的费用。

所以验机的实际成本，取决于退款政策。

这一点值得在下单前明确。因为它决定了「试错预算」是多少。

把现有 192 个档位的字段过一遍，会发现缺失有规律。

字段	披露率	为什么不说
超售比	几乎为零	说了会暴露共享本质
IOPS 配额	极少	多数平台不设硬配额
保障带宽	独服有、云主机无	云主机只承诺端口上限
IP 属性	需另查	属性要额外查证才能确定

这张表最该注意的是第一行：超售比是唯一一个「所有人都想知道、所有人都不会说」的数字。

原因很直接。一旦公布超售比，等于承认「你的 2 核不是真 2 核」。

所以这个数字永远不会出现在产品页上。但它是可以间接测出来的——通过 CPU steal 时间、通过同配置机器的性能对比、通过不同时段的性能波动。这就是为什么「验机」这件事无法省略：核心信息只能自己获取。

第二行的 IOPS 更微妙。

很多平台确实「不设 IOPS 配额」，因为它们的存储是分布式共享的，配额由底层自动分配。

这种情况不是隐瞒，是确实没有固定值可以公布。

但后果是一样的：你无法从产品页判断磁盘性能。

第三行的差异最有意思。独服会写「30Mbps 保障」，云主机只写「1Gbps 端口」。

这个差异不是商家故意隐藏。是产品性质决定的：独服的物理端口有明确的带宽配置，而云主机的虚拟端口没有「保障」这个概念。

第四行 IP 属性。这个最需要主动查，因为它影响的是「能不能用」而不是「快不快」。

四个缺失字段的共同点是：它们都不影响「看起来值不值」，只影响「实际好不好用」。

这就是为什么产品页不写它们——写了不利于销售。

二、超售比：三个间接测法

三个方法之外，还有一个「免费」的参照：看商家的产品线宽度。

产品线很宽（十几档）的商家，通常需要覆盖从低价到高价的全区间。

而低价档往往靠超售换成本，高价档靠独占换价格。

所以「同一家商家的最低档」通常超售最严重。这不是猜测，是产品组合的必然结果——如果最低档也低超售，它会吃掉高价档的市场。所以买最低档的人，本质上是在为「便宜」付「共享」的代价。

这个判断能帮助定预算下限。如果你的业务对稳定性有要求，别买同系列最便宜的那一档，往上一到两档。

再看一个实测技巧：跑「单核」和「多核」的对比。

如果单核性能正常，多核性能明显不成比例（比如 4 核只有 2.5 倍的单核成绩），说明核之间在抢资源。

正常情况：4 核的多核成绩应该是单核的 3.5 到 4 倍。

如果只有 2 到 2.5 倍，说明超线程或超售在起作用。

这个测试很有价值。因为它把「核数是否真实」量化了。

两条命令，先跑单核再跑多核，对比吞吐量：

# 单核测试
sysbench cpu --threads=1 --time=30 run

# 多核测试（按核数）
sysbench cpu --threads=4 --time=30 run
# 对比两者的 events per second

判读要点：多核吞吐 ÷ 单核吞吐，应该在 0.9 × 核数以上。

低于这个比例，说明核之间共享了物理执行单元。

还有一个方法：看 CPU 型号。

不同的 CPU 型号性能差异很大。而产品页通常不写 CPU 型号。

所以装好机器后第一件事是看 lscpu。如果型号很老（比如五六年前的架构），性能会明显低于新款。

这个信息对判断性价比很关键。同样 4 核，老架构和新架构的性能可能差一倍。

这个数字问不出来，只能测。三个方法，成本递增。

方法一：看 CPU steal。最简单，五分钟出结果。

# 看 CPU 各时间占比，重点看 st（steal）
mpstat 5 10
# 关注 %steal 列：长期 >5% 说明有抢占，>20% 说明共享严重

判读要点：steal 高说明邻居在抢你的时间片。

这个方法的价值在于「不需要任何外部参照」——它直接测量了你被抢占的比例。但它有一个局限：只能测到你的机器被抢了多少，测不到宿主机整体超售多少。比如一台宿主机超售 8 倍，但邻居都很闲，你的 steal 依然是 0。

方法二：看性能波动。需要多次测试，跨时段。

在同一台机器上跑同一个基准测试，每天同一时间跑一次，连续跑一周。

判读要点：如果结果波动超过 15%，说明共享压力不稳定。

这个方法的成本高，但能看到「真实的分配」——如果超售严重，性能一定会有规律性波动。

方法三：横向对比同配置。需要买两台机器。

在不同商家买同配置的机器，跑同一个测试。

判读要点：差距超过 30% 说明其中一家的超售更严重。

三个方法叠加，基本能判断出一台机器的实际可用算力。

但它们都需要时间。所以「验机」这件事的正确做法是：先用方法一快速筛，再用方法二确认稳定性。

还有一个现成的参照：看价格是否明显低于同行。

同配置下价格低 30% 以上，大概率是超售更严重。

这不是绝对规律，但是在信息不对称时，它是唯一可用的信号。

三、IOPS 和磁盘性能

磁盘这块还有一个「隐藏参数」：是不是本地盘。

本地盘（直接装在宿主机上）和网络盘（通过网络挂载）的性能差别很大。

本地盘的延迟通常在 0.1 到 1ms，网络盘的延迟通常 1 到 5ms。

而产品页上通常只写「SSD」，不写是本地盘还是网络盘。这个差别对数据库业务是决定性的——同样标 SSD，本地盘的查询延迟可能是网络盘的五分之一。所以「SSD」这两个字在产品页上几乎没有区分度。

怎么判断？看延迟的稳定性。

本地盘的 4K 随机读延迟非常稳定，波动通常在 20% 以内。

网络盘的延迟波动很大，可能从 0.5ms 跳到 8ms。

所以跑 fio 时要看「延迟的分布」，不只看平均值。

# 看延迟分布（关注 p99 和 max）
fio --name=randread --ioengine=libaio --rw=randread --bs=4k     --numjobs=1 --size=256M --runtime=60 --time_based --iodepth=32     --direct=1 --latency_percentiles=50,90,99,99.9

判读要点：p99 远高于平均值，说明尾部延迟差。

而尾部延迟才是用户感知到的「卡顿」。平均值好看但 p99 很差的盘，实际体验不好。

还有一个测试要看：并发下的表现。

单线程测试好看的盘，多线程可能立刻崩。

因为共享存储的带宽是有限的，多线程会把这个限制暴露出来。

所以测试要分单线程和多线程两轮。单线程看基础性能，多线程看共享程度。

两轮结果一对比，就能判断磁盘是独占还是共享。

还有一个实用建议：把数据库文件和系统盘分开。

如果只有一个盘，系统运行时的日志写入会和数据库读写抢 IOPS。

分开之后，两者的干扰会明显减少。

这个做法成本不高，但对数据库业务的提升很明显。

磁盘是四层里最不透明的，因为它的数字通常不给。

但磁盘恰恰是最容易被实测的。一个 fio 测试就能看出真实水平。

# 4K 随机读（数据库场景最关心）
fio --name=randread --ioengine=libaio --rw=randread --bs=4k \
    --numjobs=1 --size=256M --runtime=60 --time_based --iodepth=32 --direct=1

# 1M 顺序写（备份、文件传输场景）
fio --name=seqwrite --ioengine=libaio --rw=write --bs=1M \
    --numjobs=1 --size=1G --runtime=60 --time_based --direct=1

判读要点：4K 随机读的延迟，<1ms 是独占或高配额 SSD，1–5ms 是共享 SSD，>5ms 是被严重争抢。

这个数字对业务的影响是决定性的。数据库查询延迟从 0.3ms 涨到 10ms，一个页面要查 30 次，总时间就从 9ms 变成 300ms——用户能明显感觉到。而厂商在产品页上永远不会写「4K 随机读延迟 10ms」，因为那等于劝退。

所以磁盘的验收方法是自己测，不看标注。

还有一个实用技巧：看云盘容量和 IOPS 的关系。

很多平台的 IOPS 按容量比例给（每 GB 给 30 IOPS 左右）。

所以20G 的盘只有 600 IOPS，100G 的盘有 3000 IOPS。

这意味着「磁盘慢」的解决办法可能是「加容量」，不是「换机器」。

这个思路能省不少钱。很多人为了 IOPS 换了更贵的机器，其实只要把盘从 20G 加到 100G 就解决了。

但这条规律不适用于所有平台。有的平台 IOPS 是固定的，跟容量无关。

所以要先确认：问你买的这个产品，IOPS 是固定值还是按容量比例。

这个问题比问「超售比」容易得到答案。因为 IOPS 配额是个技术参数，不涉及商业秘密。

四、保障带宽：云主机没有这个概念

还有一个相关概念容易混淆：「带宽保证」和「带宽优先」。

带宽保证是「承诺最小值」；带宽优先是「拥塞时优先转发」。

后者不承诺具体数值，只承诺「比别人的优先级高」。

这个区别很实际：带宽保证的产品，你在任何时候都能跑到承诺值；带宽优先的产品，在没人抢的时候看不出差别，在大家都抢的时候你能分到更多。所以「优先」这种承诺，价值取决于机房的拥堵程度——如果出口经常拥堵，优先权很值钱；如果不堵，优先权毫无意义。

所以问的时候要区分：是「保证」还是「优先」。

这个区分能避免误解。因为两个词在宣传里经常混用。

还有一个参数值得问：「单流」和「多流」的差别。

有的产品对单个连接限速，但多个连接可以叠加。

这种情况单线程测出来慢，多线程跑满。

对下载工具友好（多线程），对单连接的实时应用不友好。

所以问要具体：单连接的上限是多少，总带宽是多少。

两个数字都有意义。只看总带宽会误判。

再看一个实践问题：怎么验证保障带宽。

拿一个明确标注保障带宽的产品，在最拥堵的时段持续测试。

如果速率稳定在承诺值附近，说明保障是真的。

而这个测试要在「最差时段」做。平时测没有意义，因为不堵的时候谁都能跑满。

所以验收的时间点选择，比测试方法更重要。

这一节说清一个最容易被误解的差异。

「保障带宽」的意思是「商家承诺你不会低于这个速度」。

「端口速率」的意思是「你的网卡上限是这个速度」。

两者方向相反。而云主机产品几乎全部只写端口速率。

所以「1Gbps 端口」这句话，最准确的解读是「你最多能跑到 1Gbps」，而不是「你能跑到 1Gbps」。这个区别在晚高峰会被放大到十倍以上。而独服的「30Mbps 保障」是另一个含义——它承诺最差也有 30Mbps，虽然数字小，但它是确定的。

怎么问出保障带宽？三个话术，从软到硬。

话术一：「这个端口是独享还是共享？」

这是最基础的问法。答案如果是「共享」，那就没有保障带宽。

话术二：「晚高峰能保证多少？」

这个问题比较尖锐，但好的销售会给个估计。

话术三：「有没有保障带宽的产品或者套餐？」

这个问法最明确。如果对方说有，那就直接问价格。

三个话术的效果递增。而大多数情况下，得到的答案是「端口共享，实际能跑多少看情况」。

这个答案本身就有信息量。它说明没有保障，所以要按「最坏情况」规划业务。

还有一个间接判断方法：看产品是否区分「峰值」和「均值」。

如果产品页写「100Mbps 峰值 / 50Mbps 均值」，那是比较诚实的标注。

而只写一个数字的，通常是峰值。

这个判断能快速筛掉一批夸大的标注。因为愿意写均值的商家，至少在产品定义上是清楚的。

五、IP 属性怎么查

查 IP 还有一步容易被跳过：查历史使用情况。

一个 IP 可能被前任租户用过，留下垃圾邮件记录、被封禁的历史。

而这些历史不会因为换了租户就消失。

所以「新 IP」和「回收 IP」的价值不同。回收 IP 便宜，但可能带着黑历史。判断方法：查公开的黑名单数据库，看这个 IP 是否在列；或者查 IP 的注册时间，如果注册很久但最近才分配给你，那可能是回收的。

这个问题在邮件业务上尤其关键。一个 IP 有垃圾邮件历史，发出去的邮件会大量进垃圾箱。

所以邮件业务必须查 IP 信誉，而且要用专门的信誉查询工具，不是普通的归属地查询。

再看一个「IP 数量」的问题。

产品页通常写「含 1 个 IPv4」，但不说「能不能加」。

而加 IP 的价格差别很大。有的商家免费给，有的每个 IP 每月几十元。

所以需要多 IP 的业务，要把这部分成本算进去。

估算方法：需求的 IP 数 × 单价 × 12，就是年成本。

这个数字在大规模部署时很可观。比如需要 32 个 IP，每个 20 元/月，一年就是 7680 元。

而独服通常自带几个到几十个 IP。这就是为什么多 IP 业务倾向独服。

所以「IP 需求」是选型里一个独立维度。它不属于配置，也不属于带宽，但会影响总成本。

还有一个细节：IPv6 的支持情况。

部分产品带 IPv6，部分不带。而 IPv6 的价值取决于业务是否需要。如果只需要 IPv4，那 IPv6 可有可无；如果需要双栈，那必须确认。

查证方法很简单：装好机器后 ping6 一个已知的 IPv6 地址。

IP 属性是四个缺失字段里最特别的一个：它不影响性能，只影响能不能用。

而它的查证方法很具体。三个步骤。

第一步：拿到测试 IP。买之前向商家索取。

第二步：查归属。用公开的 IP 归属查询工具，看这个 IP 登记在谁名下。

判读要点：登记在数据中心或云服务商名下的，是机房 IP；登记在宽带运营商名下的，是住宅 IP。

第三步：查风险评级。很多平台会公布 IP 的风险等级。

这一步很关键，因为「住宅 IP」这个说法没有统一定义。有的商家指的是「登记在运营商名下的 IP」，有的是「真实家庭宽带出口」。两者的实际可用性差很多——前者可能已经被大量使用过，风险评级很高。所以只看「住宅」这两个字不够，要看具体的归属和评级。

还有一个陷阱：「原生 IP」和「住宅 IP」不是一回事。

原生 IP 指的是「IP 的注册地和机房的物理位置一致」。

而住宅 IP 指的是「IP 的归属类型是家庭宽带」。

两者可以同时成立，也可以只有其一。而宣传里经常混用。

所以问的时候要具体：这个 IP 是运营商段还是机房段、注册地在哪、风险评级大概什么水平。

三个问题问完，才能判断它是不是你要的。

还有一点：IP 属性可能是会变的。

有的 IP 一开始评级不错，被大量使用后评级会下降。

所以买之前查一次，用一段时间后再查一次。

这个习惯能避免「刚开始好用，后来被封」的情况。

六、怎么问才有答案

讲完四个字段，最后说方法：怎样问，才能得到有用的回答。

原则一：问具体的技术参数，不问评价。

「你们家稳定吗」这种问题永远得到「很稳定」的答案。

而「有没有 CPU 时间限制、限制多少」这种问题，必须给具体答案。

这个原则的本质是「把开放式问题改成封闭式问题」。封闭式问题（是/否、多少、哪种）无法用模糊话术应付，而开放式问题（好不好、稳不稳）总能被糊弄过去。所以提问的设计比提问的数量重要。

原则二：一次问一个，不要列清单。

列五个问题，通常只回答前两个。

所以分开发，一次一个，得到答案再问下一个。

原则三：问「如果不能做到会怎样」。

比如「如果流量超了，是限速还是计费」。

这个问题比「流量多少」更有信息量。

因为它暴露了商家的处理策略。而策略往往比参数更能反映服务水平。

原则四：问政策的书面来源。

「这个条款在服务协议哪一条」。

能指出来的是真政策，指不出来的是口头承诺。

四个原则配合使用，通常能在三轮对话内得到足够的信息。

还有一个技巧：看对方的回答里有没有「数字」。

有具体数字的回答（比如「限 20% CPU」「IOPS 3000」）可信度高。

全是形容词的回答（「很充足」「足够用」）可信度低。

这个判断标准很简单，但很有效。

最后回到开头：产品页缺四个数字。

超售比、IOPS 配额、保障带宽、IP 属性——这四个都不写在页面上，而它们决定体验。所以选购不是「看页面比价格」，是「看页面筛掉不合适的，再用提问和实测补齐关键信息」。这一步省不掉，因为没有任何商家会主动告诉你。

本文讨论产品信息获取与选购沟通的一般方法，不针对任何具体商家，也不对任何产品或服务作质量评价。文中给出的测试命令、判读阈值、提问话术与判读标准均为通用参考；实际结果受虚拟化方案、宿主机负载、同机邻居行为、时段、机房政策与销售响应方式影响，同一台机器在不同时段的表现可能完全不同，不同商家的答复口径也可能差异很大。文中所有阈值（如 steal 5%、延迟 5ms、波动 15%）均为经验参考值，非行业标准。本文全部内容不构成任何性能承诺、服务保证或购买建议，亦不代表本站立场，也不代表对任何具体产品的推荐。选购前请自行核实商家的书面条款，因信息不符或实际表现不符合预期而产生的直接或间接损失，作者及本站不承担任何责任。