解读

面试官想验证三件事：

1. 你是否理解 Cloud SQL 磁盘“只能升不能降”这一国内合规与商业限制带来的风险；
2. 能否把“预测”抽象成可落地、可解释、可灰度的算法，而不是堆砌 buzzword；
3. 是否熟悉 Google Cloud 观测体系（Cloud Monitoring、Cloud Logging、Metric Export）与国内多云对比下的工程取舍。
   回答时要体现“算法—阈值—业务”闭环，并给出可回滚的灰度方案，避免“一告警就扩容”造成成本投诉。

知识点

1. 磁盘使用率核心指标：
   • database/disk/bytes_used（Cloud Monitoring 预定义）
   • database/disk/quota（上限，仅升不降）
2. 预测算法选型：
   • 双指数平滑（Holt-Linear）：适合线性增长，计算量小，可解释性强；
   • STL+ARIMA：适合周期+趋势，需离线训练，国内夜间低峰时段明显；
   • LSTM/Prophet：适合多维度特征（QPS、备份窗口、binlog 保留时长），但模型备案与可解释性成本高。
3. 残差与置信带：
   • 用99% 置信区间而非 95%，避免国内“大促+红包”突发流量击穿；
   • 残差>阈值自动降级为“线性外推”，保证算法回退策略。
4. 触发规则：
   • 预测在未来6小时达到 85% 触发“通知”
   • 预测在未来2小时达到 95% 触发“高优工单+自动扩容预案”
5. 冷启动：
   • 新实例7天数据不足时，采用“同业务线模板模型”+3倍标准差保守策略，防止过早告警。
6. 国内特殊场景：
   • 等保要求日志留存180天，binlog 保留时长被拉长，需把mysql.binlog_size作为外生变量输入模型；
   • 春节、618、双11 期间启用节假日哑变量，否则预测值偏低。

答案

预测性告警的算法原理分四层：
1. 数据采集层
Cloud Monitoring 每 60 秒推送 disk_bytes_used 与 disk_quota 到 Pub/Sub，国内 Region 通过跨境专线同步到 BigQuery，延迟<5 秒；同时拉取关联指标：write_ops_count、backup_size、binlog_hours。

2. 特征工程层

• 构造“可写余量”remain = quota - bytes_used
• 对 remain 做一阶差分去除漂移，再用RobustScaler抑制极端值；
• 把“备份窗口”与“红包活动”标记为 0/1 哑变量，解决国内突发写放大问题。

3. 预测层
线上采用Holt-Linear 双指数平滑，原因：

• 计算复杂度 O(n)，函数即服务（Cloud Run） 冷启动 <200 ms；
• 参数 α、β 用网格搜索+滑窗交叉验证（窗口 7 天，步长 1 小时），目标函数为加权绝对百分比误差 (WAPE)，权重近 24 小时占 60%，保证“越近越重要”；
• 输出6 小时与 2 小时两个点的预测值及 99% 置信上界。

若残差连续 3 个周期超出 3σ，自动降级为线性外推，并发出“模型失配”事件，提示运维人工介入。

4. 决策层

• 预测值≥85% 且置信下界≥80% → 企业微信机器人+钉钉卡片双通道通知 DBA；
• 预测值≥95% 且置信下界≥90% → 触发 Cloud Workflow：
  a. 调用 Cloud SQL Admin API 发起磁盘扩容（步长为当前 20%，上限 30 TB）；
  b. 扩容前自动备份，并打上 predictive-alert 标签，方便后续成本归因；
  c. 在 ITSM 系统创建高优工单，附带预测曲线截图，满足国内审计要求。

整个链路从指标到达至工单创建P99 延迟 <45 秒，且支持一键回滚：若业务方在 30 分钟内提交“误报”工单，系统调用快照回滚磁盘并关闭模型 4 小时，防止振荡。

拓展思考

1. 如果实例开启只读副本，主库磁盘增长模型需把副本延迟 replica_lag 作为外生变量：延迟升高往往伴随 relay_log 堆积，预测值需额外增加 5%–8% 余量。
2. 国内金融客户要求两地三中心，磁盘预测模型需分别训练“主—备—灾备”三个实例，并做联合置信度判断：仅当任意两个实例同时触发 95% 阈值才执行扩容，避免单点误报造成跨城冗余成本。
3. 成本优化：对非核心测试库，可把告警阈值动态调到“预测 12 小时达 95%”，并采用抢占式实例+自动逻辑备份的“先 dump 后缩容”策略，节省 30% 以上磁盘费用；但需提前在财务预算系统备案，防止财务审计挑战。