解读

在国内金融、政企、电商等场景，“重启时间”≈“业务中断时长”，面试官想确认两点：

1. 你是否理解 Cloud SQL 的“维护窗口”与“可中断维护”是两条独立但可叠加的策略；
2. 你能否把这两条策略翻译成可量化的 RTO 与运维节奏，而不是背文档。

知识点

1. 维护窗口（Maintenance Window）

   • 由用户设定，国内默认建议放在 02:00–06:00（UTC+8），可精确到星期。
   • 只有“重启类”补丁（内核安全、小版本升级）才受窗口限制；非重启补丁（如 SSL 证书轮换）无视窗口立即执行。

2. 可中断维护（Maintenance Release Channel）

   • 在控制台里叫“维护版本标识”，本质上是 Google 侧对补丁紧急程度的标记：
     – 可中断（disruptive）：必须重启实例，最早可在维护窗口开始点触发；
     – 不可中断（non-disruptive）：热补丁，零重启。
   • 用户无法把“可中断”改成“不可中断”，只能通过“拒绝维护”按钮延后 35 天，但 35 天后 Google 强制重启。

3. 重启时间公式
   实际重启时刻 = max(补丁就绪时间, 维护窗口开始点)
   若补丁被标记为“可中断”，重启动作一定落在窗口内；若标记为“不可中断”，重启时间为 0，业务无感知。

4. 高可用版额外逻辑
   国内多可用区实例采用滚动重启：先切换至备用区，再重启主区，业务中断≈10–30 s；若关闭高可用，单节点重启≈1–3 min，窗口长度直接等于业务受损时长上限。

答案

“维护窗口”决定 Google 最早允许重启的时间点；“可中断维护”标志决定是否必须重启。两者共同作用的结果是：

• 当补丁被标记为“可中断”时，重启只会在用户指定的维护窗口内发生，重启时长≈高可用版 10–30 s / 单节点版 1–3 min；
• 当补丁为“不可中断”时，无视窗口、无需重启，业务零中断；
• 若用户未设置窗口，Google 默认在 04:00–06:00（UTC+8）随机触发，可中断补丁仍遵循该默认窗口。
  因此，窗口是时间边界，标志是重启开关，二者叠加后就把“重启时间”锁定在窗口内，RTO 可预测、可审计。

拓展思考

1. 国内监管要求“变更可回滚”，建议把维护窗口拆成两段：
   – 第一段 02:00–02:30 做 staging 实例，验证补丁；
   – 第二段 03:00–03:30 做生产，利用 30 min 间隔完成回滚决策。
2. 若业务为“秒杀场景”，可将窗口压到 5 min 并启用只读库：
   – 主库重启期间，只读库继续提供查询，写请求缓存在 Pub/Sub，重启后回放，把中断转化为“写延迟”而非“写失败”。
3. 对于 Terraform 用户，用 maintenance_window_hour + maintenance_window_day 变量配合 lifecycle ignore_changes = [settings.version]，可在 IaC 层面锁定窗口，防止队友手抖改配置导致重启时间漂移。