2. 资源类型与分类：计算、存储、网络

做配额管控，第一件事就是搞清楚你到底在管什么。我见过不少团队，一上来就拍脑袋定配额，结果CPU限死了内存没管，磁盘爆了IO没限，最后线上事故一查，全是资源打架。说白了，你得先把资源分门别类，才能对症下药。

我个人习惯把资源分成三大类：计算资源、存储资源、网络资源。每一类下面还有细分项，咱们一个一个说。

2.1 计算资源：CPU 与内存

计算资源是系统的“大脑”和“工作台”。CPU负责算，内存负责存中间结果。这两者通常要一起看，因为它们是典型的“木桶效应”——CPU再强，内存不够照样卡死。

2.1.1 CPU 配额管控要点

• 核心数（vCPU）：最直观的配额。但注意，超线程环境下，1个物理核可能对应2个vCPU。我建议按实际可用的逻辑核来算。
• 使用率（Utilization）：长期跑在80%以上就要警惕了。我曾经遇到过某业务CPU使用率一直99%，结果一查是死循环，配额设了等于没设。
• 时间片（Shares/Quota）：在容器或虚拟机场景下，CPU时间片分配比核心数更精细。比如Kubernetes里的requests和limits，就是典型的配额控制。

2.1.2 内存配额管控要点

• 容量（Capacity）：GB级别，直接限制最大可用内存。
• 交换分区（Swap）：很多团队会忽略这个。我建议在配额管控里明确禁止或限制Swap使用，否则内存配额形同虚设——业务可以偷偷用磁盘当内存，性能暴跌。
• 大页内存（HugePages）：数据库或高性能计算场景下，大页内存需要单独配额。我记得有一次给MySQL配了16GB大页，结果没在配额里预留，导致其他业务OOM。

2.2 存储资源：磁盘与 IO

存储资源是系统的“仓库”。但仓库再大，搬货速度慢也不行。所以磁盘配额要分两块：容量和IO性能。

2.2.1 磁盘容量配额

嗯，这里要注意：很多人只盯着容量，忘了inode。我曾经见过一个日志系统，磁盘还剩500GB，但inode用完了，新文件写不进去。所以配额管控里，inode数一定要单独设。

2.2.2 IO 性能配额

IO性能比容量更难管，因为它是“共享资源”。一块物理磁盘，多个业务抢着读写，谁抢得多谁就爽，其他人就卡。

• IOPS（每秒读写次数）：适合小文件、高并发场景。比如数据库的随机读写。
• 吞吐量（Throughput）：适合大文件、顺序读写场景。比如视频转码、日志归档。
• 延迟（Latency）：这个通常不直接做配额，但监控必须跟上。一旦延迟飙升，说明IO配额可能不够了。

2.3 网络资源：带宽与连接数

网络资源是系统的“血管”。带宽决定能跑多快，连接数决定能同时服务多少人。这两者经常被低估，直到线上出现“带宽打满、连接超时”才想起来。

2.3.1 带宽配额

• 入带宽（Ingress）：外部请求进来的流量。比如用户上传文件、API请求。
• 出带宽（Egress）：系统返回数据的流量。比如视频流、下载文件。
• 突发带宽（Burst）：允许短时间超过配额。我建议设一个“峰值上限”，比如平均带宽100Mbps，突发允许200Mbps持续30秒。

2.3.2 连接数配额

连接数是个容易被忽略的坑。你以为带宽够用就行，但连接数一多，系统光维护连接状态就把CPU吃掉了。

为什么会这样？因为每个TCP连接都要占用内存（内核的socket buffer）。我曾经遇到过一个问题：业务只开了100个连接，但每个连接都发大包，结果带宽没超，内存先爆了。所以连接数配额一定要和带宽配额配合使用。

2.4 三类资源的关系图

下面这张图把三类资源的核心维度串起来了。你可以看到，每个资源都有“容量”和“性能”两个维度，而且它们之间会互相影响。

2.5 资源分类的落地建议

光知道分类还不够，你得能落地。我个人总结了一套“四步法”：

1. 盘点：把所有资源列出来，按计算、存储、网络分类。别忘了那些“隐形资源”，比如inode、连接数、Swap。
2. 打标：给每个资源打上标签，比如“核心业务”、“离线任务”、“测试环境”。不同标签的配额策略不一样。
3. 设限：根据历史数据和业务需求，设定配额上限和预留值。我建议先松后紧——刚开始配额设宽一点，观察一段时间再收紧。
4. 监控：配额设了不监控等于白设。每个资源维度都要有对应的监控指标，比如CPU使用率、磁盘IOPS、网络带宽利用率。