一次版本升级，把那套基线全废了

结论先行：性能告警的基线是按历史数据算出来的，而应用每次改版都会改变这份历史的前提：接口拆了、入口多了、缓存换了、实例数变了。基线不及时重算，告警会同时出现两种相反的失真——该响的没响，不该响的连成一片。可行的做法是把「基线重算」绑进发布流程，在发布单上加一栏，而不是等告警乱成一团再回头查。

改版为什么会动到基线

监测平台的动态基线，通常是按过去一段时间的同期数据拟合出来的。它隐含了几个前提：这套接口的调用量与耗时分布稳定、依赖关系稳定、实例规模稳定。四种变化会直接推翻这些前提。

• 接口拆分与合并。一个慢接口拆成三个，原来那条「三秒」的基线就不再有对应对象，新接口从零开始学，学的那几天没有基线可用。
• 入口结构变化。新增一个批量入口，整体调用量结构变了，平均值被拉低，原本正常的小幅波动突然越界。
• 依赖替换。缓存换了一层、下游服务换了实现，耗时分段整体下移或上移，旧基线的上下界同时失效。
• 实例规模变化。扩容之后单实例平均耗时下降，缩容之后上升。基线如果按实例算，每次伸缩都要重来。

两种失真，方向相反

第二种更常见，危害也不小。一套被忽略的告警渠道，等于没有。而团队往往用「再加一条规则」的方式补救，规则越多，越没人看。

三个可以先看的信号

其一，告警量在某个时间点前后出现台阶式变化，而业务没有对应变化。其二，同一个接口的告警在改版后的头几天密集出现，随后自行消失——这通常是基线在学习，而不是故障。其三，有几条接口的基线一直是空的，说明新接口还没学够数据，这段时间等于没有告警能力。

把重算写进流程

这件事的方法不复杂：在发布单上加一栏「本次改版是否影响监测口径」，影响的列出受影响的接口与依赖，发布后由监测负责人确认基线重算或临时观察。三个配套动作值得一起做：重算期间对受影响的接口临时放宽或单独观察；旧基线与新基线保留一段时间做对照，便于判断是真实变化还是口径变化；把「新接口进入基线学习期」写进发布后的检查项。

边界与前提

这套做法适用于有动态基线能力的监测平台。只用固定阈值、且阈值定得比较宽松的环境，版本变化的影响没有那么即时，但阈值该复看的周期同样要定。另外，本文说的基线是性能与调用量类指标，安全侧的异常行为基线是另一套逻辑。

本文只谈版本变更与基线重算的关系，不谈探针怎么部署、也不谈告警规则怎么配，这两件事的评估口径与本文不同。

深圳市奇摩计算机有限公司在推进监测接入时，会把「发布与监测联动」这一条写进交付文档：改版影响哪些接口、重算谁来确认，交付时一次说清，避免上线后每个月都要重新排查一轮告警噪声。

如果最近的告警量出现过说不清的台阶，可以先对照一下发布时间点，这类问题往往一次就能对上。 预约咨询