云上资源配额与容量预警实战：别让一个应用吃掉所有资源
去年一个客户半夜打电话，声音崩溃：“生产环境全崩了，所有服务都超时，但我们的流量没涨啊。”
我登录控制台一看，CPU、内存全部跑满。再往下钻，发现是一个测试环境的应用，不知道谁改了配置，把CPU跑到了100%。关键是，这个测试环境和生产环境在同一个资源池里，它把CPU吃光了，生产应用抢不到资源，全崩。
这是多租户环境最容易被忽视的问题：一个应用或一个团队，就能把整个系统的资源吃光。
今天聊聊云上资源配额与容量预警。不是那种“配额很重要”的废话，而是帮你理清楚：怎么防止单个应用失控？怎么设配额？配额设多少？预警怎么配？
01 资源配额不是限制，是保护
很多人听到“配额”，第一反应是“限制”。这是误会。
配额不是为了限制你，是为了保护别人。一个应用跑了无限资源，其他应用就没法跑。一个团队超量使用，其他团队就得等。
反常识观点：没有配额的系统，就像没有车道的公路。 一辆车可以横着开，所有车都堵死。
那家客户的问题就在这：没有配额。测试环境和生产环境共享资源池，测试应用把CPU跑满，生产被活活饿死。如果有配额，测试环境最多只能用30%的CPU，剩下70%留给生产，根本不会崩。
02 配额设在哪几个维度？
云上配额通常分四个维度。
CPU配额：限制最多能用多少个vCPU。防止单个应用把CPU跑满。
内存配额：限制最多能用多少GB内存。防止内存泄露拖垮节点。
存储配额：限制最多能用多少GB磁盘。防止日志写满、备份爆炸。
API调用配额：限制每秒最多调用多少次API。防止单个应用打爆共享服务。
Kubernetes环境：用ResourceQuota按命名空间设。比如dev命名空间最多用20个CPU、40GB内存。
云账号级别：AWS Service Quotas、Azure订阅限制，防止单个账号无限开资源。
03 配额设多少？三个原则
配额不是拍脑袋，要按业务算。
原则一：按环境分级
生产环境：配额最宽松，但要设预警。比如总资源的70%给生产，30%预留。
预发环境：中等配额，和生产隔离。
测试/开发环境：严格配额，防止资源浪费。比如单个开发命名空间最多2个CPU、4GB内存。
原则二：按业务优先级
核心业务：高配额，低预警阈值
非核心业务：低配额，高预警阈值
批处理任务：低配额，但允许在资源空闲时“借用”
原则三：预留缓冲
永远不要把所有资源都分配出去。至少预留20%的缓冲，应对突发流量、紧急扩容。
那家客户后来设了配额：生产环境保证70%资源，测试环境最多用20%，预留10%缓冲。再也没出现过“测试把生产挤崩”的事。
04 容量预警：在配额用完之前告诉你
配额是“硬拦截”——到了上限，请求就被拒绝了。但硬拦截可能伤业务。
更好的做法：预警 + 配额
70%预警：快到配额了，通知团队，准备扩容或清理
80%警告：再不动就要拦了
90%紧急：自动触发扩容或降级
预警比配额更重要。 配额是最后一道防线，预警是提前通知。
云厂商都提供了配额预警：
AWS：Service Quotas支持CloudWatch告警
Azure：订阅用量告警
K8s：Kube-state-metrics + Prometheus监控资源使用率
05 容量预测：提前一周告诉你
光有实时预警还不够。一个应用每天增长5%的资源使用，一周后就到配额上限了。你需要容量预测。
怎么做？
采集历史资源使用数据（过去30天）
按天聚合，计算日均增长率
拟合趋势，预测哪天会达到配额
提前通知团队：你还有5天，请优化或申请扩容
工具：Prometheus + 自定义脚本，或云原生预测（AWS Forecast、Azure Monitor预测）。
那家客户后来加了预测告警：当预测未来7天内会达到配额，提前发通知。运维负责人说：“以前是被动救火，现在能提前一周知道要出事。”
06 一个真实案例：配额救了一个大促
一个电商客户，大促前做了资源规划，给每个服务分配了配额。但大促当天，推荐服务突然流量暴涨，CPU冲到120%配额。
如果是以前，它会抢占其他服务的资源，导致订单服务也变慢，连锁雪崩。
但因为设了配额，推荐服务到上限后被限流，只用了分配的资源。订单服务稳稳当当，大促顺利完成。
事后复盘，运维负责人说：“配额救了我们的命。不是因为它让推荐服务不崩，而是让它崩的时候不影响别人。”
写在最后
资源配额和容量预警，不是“限制你”，是“保护大家”。没有配额的系统，一个应用就能搞死所有人。
那家客户的运维负责人后来总结：“以前觉得配额是束缚，现在觉得是安全带。不系也能开车，但出事就完了。”
你的系统，有配额吗？还是等着某个应用吃掉所有资源的那天？
