时间序列基础：概念、趋势、周期性、季节性

做接口行为基线，说白了就是跟时间打交道。你监控的数据——请求量、响应时长、错误率——每个点都带着时间戳。把这些点按时间顺序一排，就是时间序列。我刚开始做监控时，总觉得把数据画成折线图就够了，后来踩过不少坑，才明白时间序列里藏着趋势、周期和季节这三个核心成分。不把它们拆开看，异常检测很容易误判。

什么是时间序列？

时间序列，就是在等间隔或不等间隔的时间点上，按顺序记录下来的观测值集合。比如 API 每 5 分钟的调用次数、每日的峰值延迟、每周的错误率曲线。它的关键特征是什么？相邻值之间不独立——今天的流量往往跟昨天相似，这一小时的数据会影响下一小时。这跟普通表格数据完全不同。

我在项目里遇到过这种情况：新同事把接口响应时间当普通样本做均值±3σ 检测，结果全是告警，因为数据有明显的日周期。时间序列的特异性就在这里——你不考虑时间结构，基线就是错的。

三个核心成分

任何一个稳定的时间序列，都可以拆成三个部分：趋势、周期性、季节性。还有一个随机波动叫残差。你看下面这张图会更直观：

我们一个个来说。

1. 趋势（Trend）

趋势是时间序列在长周期内整体向上或向下的运动方向。它不是短抖动，是几个月甚至几年的方向性变化。比如用户量稳定增长 -> 接口调用量趋势向上；又比如某个历史接口被逐步废弃 -> 调用量趋势向下。

我曾经犯过一个错：把三个月的数据直接做均值基线，结果每次月底流量冲高都告警。后来一看，业务本身在增长，趋势线没去掉，阈值自然总被突破。所以做基线前，第一步就是判断趋势——有没有？有多强？是线性还是非线性？

2. 周期性（Cycle）

周期性指非固定的、长度可能变化的波动模式。比如经济周期、产品版本迭代引起的流量起伏。它跟季节性的区别是：周期长度不固定，通常也没固定振幅。

在接口监控里，周期性相对少见。我遇到过一种情况：某电商接口在双十一前后有 3-4 周的流量拉高，但每年双十一日期不同，且持续时长也不同——这就是典型的周期性，不是季节性。

3. 季节性（Seasonality）

季节性是指以固定周期（日、周、月、年）重复出现的波动。在 API 行为中，季节性最常见。

• 日季节：早高峰、午休、晚高峰调用量明显不同
• 周季节：工作日 vs 周末的流量模式差异
• 月季节：月初/月底业务结算导致调用量上升

你想想看，如果日季节性不作处理，你拿所有时刻数据算一个阈值，夜间低流量时的正常波动就会触发告警。我自己的习惯是：拿到任何接口时序数据后，第一件事就是画出 7 天的按小时热力图，一眼就能看出日周期和周末差异。

如何把这三个成分拆开？

经典方法叫 STL 分解（Seasonal-Trend decomposition using Loess）。它用局部加权回归来分离趋势和季节，还能处理不规则情况。代码实现也很简单：

# Python 示例：statsmodels 的 STL 分解
import pandas as pd
from statsmodels.tsa.seasonal import STL

# data 是 pandas Series，index 为 datetime，频率为 1H
stl = STL(data, period=24)  # 24 小时周期
result = stl.fit()

trend = result.trend      # 趋势分量
seasonal = result.seasonal # 季节分量
resid = result.resid       # 残差分量

分解后，正常基线应该用 趋势 + 季节 来构建，残差则是异常检测的标靶。如果残差中出现大幅偏离，那就是异常。我用这招抓出过好几起「机器时钟漂移导致时序错乱」的奇葩问题。

三个成分的对比

避坑：两个概念别搞混

周期性 vs 季节性，新人最容易混。我教你一个死记硬背的方法：季节性对应「日历上的规律」——每天同一时间、每周同一天、每月同一天。周期性对应「业务上的规律」——比如新产品发版后两周流量攀升然后回落，这个「两周」不是固定两周，可能因为市场反应不同变成三周。所以周期性不能用固定位数来分解，需要更复杂的模型（比如小波分析）。

在接口行为基线建设中，我建议优先处理季节性。因为大部分 API 都受日内/周内节律影响。等你把季节抹平了，再看趋势要不要单独建模型。顺序不要搞反。

结语

时间序列的三个成分——趋势、周期性、季节性——是理解接口行为变化的基石。你建的基线，本质上就是「趋势 + 季节」的拟合；异常，就是残差中那些不应该出现的毛刺。下回你拿到一段时序数据，别急着一锅炖，先拆开看看。这个习惯，能救你无数次告警疲劳。