解读

在国内金融、政企及互联网核心系统面试中，面试官常通过“维护拒绝期”这一细节，考察候选人对 Cloud SQL 高可用机制、SLA 边界及运维灰度的理解。
维护拒绝期（Maintenance Deny Period） 是 Cloud SQL 在高可用实例上自动设置的一段“锁定期”，在此期间平台不会发起任何计划性维护事件，也不会触发主动故障转移。其本质是 Google 为避免在业务高峰或关键时段因维护操作而引发“二次故障”所设计的保护策略。
候选人必须回答出：

1. 拒绝期的起止逻辑（与维护窗口、业务高峰的关系）；
2. 对自动故障转移（HA Failover）与手动触发故障转移的差异影响；
3. 对 RTO、SLA 及运维排障的实际约束；
4. 在国内监管场景下如何与“变更窗口审批制度”对齐。

知识点

1. 维护拒绝期定义：Cloud SQL 在 HA 实例的主备节点上，默认在预定维护窗口开始前 7 天至维护事件完成后 1 小时进入拒绝期；期间拒绝任何计划性主备切换。
2. 自动故障转移：仅对非计划性故障（如宿主机宕机、磁盘损坏）生效，不受拒绝期限制；RTO 通常 <30 s。
3. 手动故障转移：属于“计划性操作”，在拒绝期内被 API 直接拒绝，返回 400 错误码“Operation is denied during maintenance deny period”。
4. SLA 边界：拒绝期本身不降低 SLA，但若客户业务高峰与拒绝期重叠，手动转移路径被堵死，只能等待自动故障转移或维护窗口结束，间接拉长可预期的恢复时间。
5. 国内合规延伸：人行《金融 IT 基础设施管理规范》要求“变更前须可回滚、可灰度”，拒绝期相当于平台侧强制灰度锁，面试时可主动提及如何提前 7 天通过 Terraform 把维护窗口调到低峰，避免拒绝期撞车重大业务发布。

答案

“维护拒绝期”是 Cloud SQL 高可用实例在计划性维护事件前后自动生效的保护区间，期间禁止任何手动触发的故障转移，但不影响因底层故障触发的自动故障转移。
具体影响可分三层：

1. 对自动故障转移：零影响。当主节点发生非计划性故障时，Cloud SQL 仍能在 30 s 内完成强制切换，RTO 与 SLA 保持不变。
2. 对手动故障转移：直接拒绝。运维人员若在拒绝期内执行 gcloud sql instances failover 或在控制台点击“故障转移”，API 会返回 400 错误，导致主动演练、容灾切换、性能压测等计划性操作被迫推迟，可能与国内监管要求的“月度演练”冲突。
3. 对业务连续性设计：拒绝期锁死了“人为控制恢复时间”这一路径，架构师必须在设计阶段就把维护窗口与业务低峰对齐，提前至少 7 天通过 Terraform 或 Deployment Manager 调整 maintenanceWindow，或采用跨区域只读实例承担读流量，降低对主备切换的依赖。

一句话总结：维护拒绝期把“计划性可控”变成“平台强制不可控”，只堵手动、不堵自动，面试时要强调提前规划窗口与多云容灾才是国内核心系统的落地关键。

拓展思考

1. 如果客户业务存在“每月第一天零点清算”这一绝对禁止任何抖动的时间点，如何结合维护拒绝期与维护窗口做双保险？
   答：可在 Terraform 中把 maintenanceWindow 设为每月 15 日 04:00-05:00，并设置 denyMaintenancePeriods 覆盖每月 28 日 00:00 至次月 2 日 00:00，实现“主动锁 + 平台锁”双层防护；同时把只读实例升级为跨区域 HA，确保清算期间即使主实例故障也能通过读库兜底。
2. 国内部分券商要求“RPO=0、RTO<15 s”，而 Cloud SQL 自动故障转移 RTO 约 30 s，如何在拒绝期内弥补这 15 s 差距？
   答：可引入 Parallel Query + Regional Persistent Disk 双写 的极端方案，或改用 AlloyDB for PostgreSQL（其 RTO <10 s），但需接受更高成本；面试时抛出“技术 + 成本”权衡，可体现资深架构视角。