凌晨三点，手机在枕头底下震动，值班群里的消息一条接一条：核心业务库CPU 98%，慢查询把连接池打满，应用层错误刷了十分钟。这种半夜爬起来扩容的日子我过了不止一年，后来终于下决心认真做一件事：把“RDS承载力饱和度评估模型 v2.0”落地，让系统在数据库真正被压垮之前就告诉我“它快到极限了，什么时候到、为什么到、该怎么办”。这篇文章就是我对这套模型的完整复盘，包括指标体系怎么筛选、饱和度公式怎么设计、评估任务怎么跑、预警之后怎么闭环，以及从v1.0迁移过来时踩过的坑。适合所有被数据库容量问题折磨过的DBA、运维和负责后端架构的同事参考。
1. 为什么需要一整套模型：被动救火和主动预测是两种工作方式
1.1 一次典型的“看似提前扩容”翻车现场
先讲一个真实发生过很多次的原型场景。某业务近期在推一个专题活动，运营提前三天找过来，说活动峰值预计是平时的三倍，库应该扛得住吧。我们按经验把实例从4核16G升到8核32G，磁盘容量多分了200GB，然后各自忙去了。结果活动第一天下午两点半，慢查询告警先炸，三分钟后CPU饱和度直接拉满，活跃会话数从两百跳到一千多，整个订单模块的超时率肉眼可见地往上走。最后是紧急回滚了一批活动配置，才把库救了回来。
事后复盘，问题根本不在“配置给少了”，而是我们压根没有量化“这个库当前距离瓶颈还有多远”。CPU在低峰期只有10%，谁能想到高峰期会瞬间冲爆？磁盘空间看起来还剩40%，但临时表落盘、慢查询积压、连接数打满这些因素叠加在一起，单个指标怎么看都是健康的，整体容量就是不够的。这种判断方式，本质上是拿单点指标赌未来的流量，赌赢靠运气，赌输就熬夜。
1.2 v2.0希望解决的四件事
做v1.0的时候我们思路比较简单：给每个指标设一个阈值，CPU超过80%就告警，磁盘使用率超过85%就告警，连接数超过80%也告警。跑了一段时间发现误报多到没人愿意看。有一次一个只读实例CPU长期维持在85%，但上面跑的全是批量分析任务，业务完全不受影响；另一次主实例CPU只有40%，但因为一个全表更新锁住了大量行，连接数迅速堆积，真正要紧的时刻反而没有触发任何告警。
所以v2.0在设计之初就定下了四个目标：第一，综合评价，不看单一指标，而是把多个维度的压力合并成一个可比较的饱和度分数；第二，趋势预判，不仅评估当前时刻的状态，还要通过历史窗口外推未来短时间内的变化趋势；第三，分清主次，输出结果不仅要告诉“快不行了”，还要告诉“主要卡在哪个维度”，让接手的人可以直接定位；第四，可回算验证，模型要能跑历史数据，用过去发生的故障来检验它的预警能力，而不是凭感觉说“这个模型好用”。这四个目标基本奠定了后续所有设计的主线。
1.3 模型的输入和输出：定义清楚边界
很多团队做容量评估模型，做着做着就变成一个大而全的监控系统，什么都想预测。我建议一开始就把边界划清楚。我们这套模型的定位是：针对RDS实例的性能承载力与容量接近度评估，不负责诊断具体的SQL问题，也不负责预测磁盘增长到何时的绝对时间，那是容量规划要做的事。
输入固定为两大部分：一是实例维度的监控指标序列，包括CPU、内存、磁盘、IO、连接数、慢查询、临时表、锁等待等，按固定的分钟级粒度和时间窗口取数；二是可选的业务上下文，比如实例的角色（主、只读、灾备）、近30天的同周期基线特征。输出则是三个东西：当前综合饱和度分数（0到100）、等级标签（健康/关注/警惕/危险）、瓶颈维度说明。明确了边界之后，后面所有工作都围绕“如何让这个分数真实反映容量压力”展开。
2. 指标选取：哪些监控项真正决定RDS还能撑多久
2.1 控制台指标一大堆，真正有用的是这几个方向
打开任何一个RDS控制台的监控页面，指标列表都很长：CPU使用率、内存使用率、磁盘空间使用量、磁盘IOPS、网络吞吐、活跃连接数、总连接数、慢查询个数、临时表数量、缓存命中率、锁等待次数和时长……如果把几十个指标全部塞进模型，轻则特征冗余影响可解释性，重则让权重训练完全失控。
我在设计时把指标分成四个方向：计算压力、存储和IO压力、连接压力、查询质量。对应关系大致如下：
| 评估方向 | 代表指标 | 为什么选它 |
|---|---|---|
| 计算压力 | CPU利用率、CPU等待队列 | 直接反映实例处理能力是否接近上限 |
| 存储/IO压力 | 磁盘使用率、IOPS使用率、IO延迟 | 数据量增长和刷盘能力不足时最先暴露 |
| 连接压力 | 活跃连接数、总连接数占比 | 连接耗尽时服务直接不可用 |
| 查询质量 | 慢查询个数/比例、临时表落盘数、锁等待 | 查询效率下降往往是故障的导火索 |
这四个方向不是平均用力，而是后续权重设计的基础。实际落地时，我建议先在控制台把每个指标导出两周以上的历史数据，看一眼分布再做取舍，不要想当然。比如某个实例的慢查询阈值是1秒，但它平时SQL都很快，慢查询只要一出现往往就是大问题；另一个实例慢查询一直被低估，阈值设置不合理。同样一个指标在不同实例上的信息量完全不同，这也是为什么纯靠固定阈值的方案总在误报。
2.2 为什么要剔除缓存命中率和内存使用率这类“伪指标”
这是v1.0留给我印象最深的坑。一开始我们很自然地认为内存使用率越高越危险，缓存命中率越低越危险，结果上线后模型天天在报“内存饱和”。后来查了RDS的内存机制才意识到，数据库进程会优先吃掉内存作为缓存和缓冲池，这是正常且健康的行为，内存使用率长期90%以上不代表内存压力大，反而说明缓存利用充分。
同样的道理，缓存命中率是一个相对指标，它很低可能是因为某类查询模式本来就命中不了缓存（比如大量排序操作），而数据库实例本身离容量上限还远得很。把这些指标纳入模型只会引入噪声。排除它们的逻辑很简单：看指标的突变是否和真实故障时间点吻合。如果历史上多次故障发生时该指标都没有异常变化，那它就没有预测价值。这类分析听起来很基础，但绝大多数人做模型时都跳过去直接选指标，后面返工的成本反而更高。
2.3 相关性分析与指标压缩：让模型专注于独立的信息源
四个方向最终选出的基础指标大概有十来项，但其中不少相关性很高。比如CPU使用率和CPU等待队列强相关，磁盘IOPS使用率和磁盘读写延迟强相关，活跃连接数和慢查询数在故障阶段也常常同步上涨。如果把这些强相关指标都按原始值送进模型，综合分数会因为这些信息的重复放大某一种压力，导致对另一方向的感知变钝。
我们的做法是两步：先计算两两相关系数，保留同一方向里与容量压力更直接的那个指标；再对标准化后的指标做一次主成分分析，用累计解释度超过85%的若干主成分替代原始指标，但这一步只用于参考，最终落地权重时还是回到可解释的方向上，因为容量评估模型的可解释性比纯精度更重要。换句话说，PCA帮我们理解哪些指标在“说同一件事”，理解完之后，模型里留的是代表性子指标，而不是那台机器算出来的晦涩特征向量。
3. 从单指标到综合饱和度：归一化、权重和瓶颈识别
3.1 单指标分数：线性归一化在处理拐点时会骗人
很多文章讲到归一化就直接套最小最大线性映射。CPU使用率10%视为0分、90%视为1分……这种做法在容量评估里并不那么可靠，因为它看不到不同区间的物理意义：CPU到90%以后系统的调度开销、锁竞争、慢查询都会快速放大，这种非线性在80%附近就开始了。
我给单指标打分时采用分段函数，基本形态是：0到70%区间按线性从0分爬到约0.6分，70%到90%区间斜率加大，90%以上直接逼近1分。以CPU为例，可以写成这样：
- 使用率低于70%：得分 = 使用率 / 70 * 0.6
- 使用率处于70%到90%：得分 = 0.6 + (使用率 - 70) / 20 * 0.3
- 使用率高于90%：得分 = 0.9 + (使用率 - 90) / 10 * 0.1
这个分段不是拍脑袋，而是根据慢查询比例和CPU使用率的历史散点图拟合出来的拐点位置。不同的数据库规格和业务类型拐点不一样，比如磁盘IO延迟的拐点就比CPU更陡，因为它一旦排队，服务能力会迅速下降。先看历史数据，再定分段点，至少比一律线性靠谱。
3.2 权重怎么定：经验权重起步，回放校准
综合饱和度是单指标分数的加权和。权重分配是模型里最容易被质疑的部分，也没有标准答案。我们的做法分两层：
第一层是经验起步。基于故障经验，初始权重大致如下：计算压力0.35，连接压力0.25，IO/存储压力0.25，查询质量0.15。这个结构背后有个直觉：RDS的容量问题大多数最终集中在CPU和连接上，IO和查询质量是放大器，存储空间是慢变量。经验权重保证模型一开始不至于太离谱。
第二层是回放校准。取过去半年内每条已确认的故障记录，让模型回放故障前1小时和2小时的数据，用遗传式的网格搜索微调各组权重，目标是让故障实例的饱和度分数普遍达到“危险”等级，同时非故障时段不出现高分。说白了就是拿历史事故当标答，不断调整权重让模型“在考试中得分最高”。这里要提醒：校准后的权重不要用得太久，业务结构变化（比如从交易型变成报表型）后需要重新回放一轮。
3.3 综合饱和度分级与瓶颈因子输出
加权求和得到一个0到1之间的综合饱和度，乘100就是可读的分值。分级阈值我建议宁可复杂一点也别拍脑袋，个人常用的一套是：小于40为健康，40到70为关注，70到85为警惕，85以上为危险。需要说明的是，这些阈值会随实例规格变化：规格越小的实例，同样的业务压力下即使饱和度只有60，也要提前介入，因为它几乎没有弹性空间。
除了总分，模型还必须输出瓶颈因子。方法很直接：计算各方向分数占综合分数的份额，把份额最大的前两个方向识别出来，额外标注“主要瓶颈”和“潜在瓶颈”。比如综合饱和度是78，其中连接方向贡献了45分，那预警信息里会明确写“主要瓶颈：活跃连接数；潜在瓶颈：CPU”。这一步的价值在实际运维中很大，因为接到告警的人能直接锁定方向，而不是对着一个综合分数发呆。
4. 评估执行中的工程细节：采样、基线和历史回放
4.1 采样窗口：不要被平均值骗了
模型最终跑出来的分值取决于喂给它的数据，所以数据处理比模型本身更容易出错。我们最开始用监控接口返回的5分钟平均值作为输入，结果故障当天下午的实例在14:30到14:35之间CPU已经冲到95%，但5分钟平均下来只有82%，模型只打出了“警惕”而不是“危险”，预警被值班同事当成普通告警处理，错过最佳介入窗口。
后来我们调整了采样策略：保留分钟级原始值，用15分钟窗口内的 P95 而不是平均值作为当前值，再叠加一个短期峰值标记。这样做的逻辑是：容量评估应该关注的是“压力峰值是否逼近上限”，而不是“这段时间平均忙不忙”。一个实例如果每隔几分钟就顶到100%，即便平均只有60%，也是在悬崖边缘反复试探，必须按危险处理。用P95之后，误报警报没有明显变多，但关键故障的预警提前量和准确率都上来了。
4.2 基线漂移：模型必须认识业务的“日常”
如果把一套固定阈值用在所有时段，晚上十一点和早上十一点的业务压力显然不是一个量级。v1.0就是踩在这个坑里：白天正常的实例深夜还在报警，因为深夜流量更小，同一个较低的指标值也会被硬套线性归一化扩大成分数波动。
v2.0引入了基线漂移处理。具体做法是给每个实例维护一组合约30天的周期基线：按星期几和小时分组，每个分组计算同一时刻指标值的历史P50和P90，评估时把当前分钟值与对应分组的基线做比值，再把这个“相对压力”代入打分。比如某个实例在同一时刻的历史P90 CPU是35%，当前是50%，相对压力大约是1.43，模型会认为业务量正在偏离日常惯例，这比绝对值更值得报警。基线要每周自动重算一次，否则碰到业务版本升级、流量结构调整，基线慢慢失真，模型又开始胡说。
4.3 历史回放验证：上线前先问模型能不能预测过去
模型上线前必须回答一个问题：如果三个月前就部署了它，那些已经发生过的故障它能提前预警吗？这一步我们称之为历史回放。
操作上并不复杂：把过去半年的故障事件整理成一张表，记录故障开始时间、故障实例、最终处置动作；然后让模型按时序重新计算每个实例每个时刻的饱和度分数，检查故障发生前1小时或2小时，模型是否已经给出“警惕”以上级别的输出。算出三个指标：预警命中率（故障前有预警的比例）、平均提前量（预警时间到故障时间之间的时长）、误报率（非故障时段出现警戒以上分值的比例）。
我们第一次回放时，v1.0的命中率不到40%，误报率高达70%，这就是为什么值班同事已经不愿意看告警了。v2.0经过权重和阈值调优后，在同样的测试集上命中率到了85%左右，平均提前量约60分钟，误报率降到15%以下。这个验证过程必须写进开发文档，因为它是后续每一次调整权重、修改阈值时的“回归测试”，没有回放机制，模型改起来就是盲改。
5. 预警联动与处置闭环：模型的价值在动作
5.1 分级预警与工单信息的标准化
一个评估模型如果每天只在监控大屏上画曲线，那它和漂亮的可视化报表没有区别。v2.0的设计目标是把评估结果直接推进到处置流程里，所以预警信息被标准化成一张固定格式的工单：实例ID、角色、当前饱和度分数、所属等级、主要瓶颈方向、近15分钟走势、建议动作。当模型给出“警惕”级别以上输出时，自动生成工单并推送到对应值班组。
格式标准化这件事很少有人强调，但真的很关键。过去告警通知只有一行“XX实例CPU过高”，接到的人还要自己登录控制台逐个指标排查，光定位就要花十分钟。现在工单里直接写了“饱和度78，连接方向贡献45，慢查询最近15分钟翻了3倍，建议先看活跃会话和锁等待”，值班同事的处理时间明显缩短。信息本身不复杂，难的是把模型结果翻译成可执行的排查入口。
5.2 和扩容流程集成：人工确认仍是底线
模型跑得再准，我也不敢让它全自动扩容。v2.0目前的联动方式是“半自动”：饱和度达到85以上且趋势外推在30分钟内会超过95时，系统自动生成扩容申请单，附上完整的评估依据，推给DBA负责人人工确认；DBA确认后调用云平台的变配接口完成实例规格升级。
在实际部署时我们观察到，人工确认这一步不能省，原因不只是安全，还因为扩容涉及费用和跨可用区资源调度，机器不知道下一个小时业务是否正好进入低谷。而模型存在的价值在于把“判断该不该扩”的证据链完整拉到人面前，让人在五分钟内拍板，而不是纠结要不要去控制台看数据。自动化的边界是辅助决策，不是替代决策。
5.3 误报治理：把每次误报变成模型修正机会
模型上线后一定有误报。我们给自己定了一条规矩：每一次被值班同事标记为“无效告警”的预警，都必须回流分析原因。常见原因有三类：一是采样值异常，比如监控数据本身因为网络问题漏了几分钟，P95被拉高；二是基线还没有适应新业务版本；三是权重或阈值在该实例类型上确实不适用。
针对第一类，我们在采样层加了异常值剔除，连续缺失数据超过窗口30%就跳过本次评估；针对第二类，把基线重算周期从每周一次改成每天增量更新；针对第三类，做实例分组，让不同规格、不同角色的实例使用不同权重参数。这套“告警-反馈-修正”的小循环，才是模型上线后真正拉开运维体验差距的地方。没有反馈闭环的模型，会在两周内被团队默认为“看个大概”，然后退化回手工判断。
6. v1.0到v2.0的迁移笔记：踩过的坑和效果对比
6.1 v1.0为什么那么招人烦
v1.0我们只做了一件事：单指标阈值告警加一张容量趋势图。当时团队成员很多时候是在接到报警后去看趋势图，再决定要不要扩容。实践中它有两个问题：一是阈值很难定，每条实例改来改去维护成本极高；二是它从来不解释“为什么”，CPU告警时不知道到底是查询变烂还是流量变大，只能靠人继续往下查。一个月下来，告警点击率很低，值班同事越来越麻木。
所以我们那时意识到：比阈值更重要的，是模型逻辑对人可解释。这也是v2.0几乎重构而非修补的原因——如果只是在原基础上多叠几个阈值，那不过是从一个容易误报的系统变成一个更容易误报的系统。v1.0存在的意义更像一份反面教材，它让我们明确了一点：堆叠告警不会自动变成评估模型。
6.2 迁移路径：回放、灰度、切换三步走
从v1.0切到v2.0没有采用“新系统直接顶上”的方式，因为模型如果在大促期间给出错误的高分或低分，代价不可控。我们分了三个阶段：
第一阶段是并行回放。v2.0每天用历史增量数据跑分，和v1.0的告警结果并排存在，不开真实告警，只记录“如果当时按v2.0会发什么级别的预警”。观察两周，主要看是否存在v2.0给出高分而v1.0完全没反应的事件，有的话逐条复盘。第二阶段是灰度开启，挑三个最有代表性的实例（一个交易型、一个报表型、一个只读分析型）接入真实预警，其余实例继续并行。第三阶段是全面切换，把v1.0的工单关闭，v2.0的预警全量生效。整个切换过程用了一个月，节奏不快，但每一步都有据可依，团队没有出现过“新模型发神经”的集体恐慌。
6.3 上线后的数字变化和团队工作方式变化
切换v2.0之后，我们盯了几个月的核心数据：预警总量差不多下降了四成，因为大量v1.0式的无效告警消失了；有效预警的占比从不到30%涨到65%以上；故障平均响应时间从人工发现后的十几分钟，缩短到模型预警后的几分钟。最直观的感受是，值班同事不再麻木了，因为每一条预警工单都带着可用于判断的上下文。
团队的工作方式也起了变化。以前数据库容量是被动话题，不炸没人提；现在每周的容量评审会上，直接打开模型回放报告，看哪些实例的饱和度趋势在往上走，哪些实例的基线出现漂移，然后确定下周的扩容或优化计划。这种变化不是工具本身创造的，而是当模型足够可信时，团队愿意把决策节奏从“事后救火”挪到“事前规划”上。
如果让我给正在做类似评估模型的团队一个建议，我会说：别把重心全放在算法上，把更多精力放在数据采样、基线维护和故障回放这三件看起来不性感的工程事上。模型的核心不是调出一个惊艳的权重，而是让每次评估结果都经得起历史检验、每个预警都带着可执行的信息。另外一个小技巧：把每周一次的误报分析会固定下来，不要停。模型上线只是开始，持续校准才是让它真正值回票价的过程。
