解读

在国内互联网与政企上云场景中，磁盘容量预测直接决定 Cloud SQL 实例的预算、扩容窗口与容灾方案。面试官问“季节性分解”，并非考统计学公式，而是验证候选人能否把业务周期从长期趋势里剥离出来，从而提前 1～3 个月给出可落地的采购与扩容节奏，避免“双 11”“春运”“618”等峰值期因磁盘打满触发只读锁死，进而造成 P0 故障。

知识点

1. STL 分解（Seasonal-Trend-Loess）：将 Cloud SQL 实例每日磁盘使用量序列拆成 Trend（长期趋势）+ Seasonal（季节项）+ Residual（随机波动） 三部分。
2. 重采样与对齐：国内业务常以“自然月”“自然周”为财务周期，需把秒级监控数据（Cloud Monitoring 的 database/disk/bytes_used）按 天级聚合，再对齐农历节假日与电商大促日。
3. 季节强度判定：用 季节强度系数 = Var(Seasonal) / Var(Seasonal+Residual)，>0.6 即认为季节主导，必须单独建模；否则可用简单线性外推。
4. 预测融合：对 Trend 做 Holt-Winters 或 Prophet，对 Seasonal 做周期叠加，再用 95% 分位数而非均值作为安全阈值，预留 10% 闪断空间。
5. Cloud SQL 实操：把预测结果写入 BigQuery 的 capacity_planning 表，通过 Looker Studio 向财务与 DBA 双周评审；同时用 Terraform 的 google_sql_database_instance.settings.disk_size 字段提前变更，利用 在线磁盘扩容无中断特性，在业务低峰窗口完成。

答案

在 Cloud SQL 场景下，季节性分解的核心作用是把“大促脉冲”从长期线性增长里剥离，使磁盘预测既不会低估峰值，也不会过度采购。
具体做法：先用 Monitoring API 导出过去 14 个月的磁盘使用数据，按天聚合；再用 STL 拆出季节项，发现每年 6 月和 11 月分别出现 38% 与 52% 的突增；接着对 Trend 做 Holt-Winters，外推 90 天；最后把 Seasonal 加回，得到“双 11”当天磁盘将达 1.9 TB。基于该结果，我们提前 30 天把实例磁盘从 1.5 TB 在线扩容到 2.2 TB，并设置 80% 告警 + 85% 只读保护阈值，既保障峰值安全，又避免浪费 400 GB 持续费用。整个流程通过 Cloud Composer 每月自动重训模型，实现数据驱动的容量闭环。

拓展思考

1. 多云对比：国内金融客户常要求“两地三中心”，若使用 阿里云 RDS + Google Cloud SQL 双活，需把双方监控数据统一到 Kafka + BigQuery，再做跨云季节校准，避免因为时区与促销节奏不同导致预测错位。
2. Serverless 场景：Cloud SQL 企业 Plus 版支持 自动扩容，但最大仍受 30 TB 硬顶；若季节分解显示峰值将破顶，需提前 shard 到多个实例或迁移到 AlloyDB，此时季节项成为分片键选取的重要依据。
3. 成本优化：国内财务审批链路长，可把季节项振幅>20% 的实例标记为 “高波动”标签，在 FinOps 月报中单独呈现，争取预算“先批后审”，防止因流程耽误扩容。