计划维护的三步
把计划维护做成标准动作：提前公告时间与影响范围，按范围建限时静默，结束后核对窗口内被压制的告警。核心可用性告警要保留一条窄通道，一旦出现意外随时可以叫停维护。缺口通常不在技术上，而在收尾——窗口内的真实故障没人回头确认。
三步动作
| 公告 | 写清维护时间、影响范围、联系人，提前通知相关方 |
|---|---|
| 静默 | 按服务或实例范围建限时静默，只覆盖本次维护对象 |
| 收尾 | 核对窗口内被抑制的告警，逐条确认影响并要求确认 |
维护窗口流程
维护窗口流程
1 公告: 2026-10-15 02:00-04:00 数据库版本升级
2 静默: matchers [service="db-proxy"]，期限 3 小时
3 盯防: 主干告警（全站探针）保持可用，异常时叫停维护
4 收尾: 导出窗口内被压制的告警，逐条确认是否有真实故障收尾核对项
- 导出窗口内所有被静默的告警，逐条确认是预期还是真故障
- 核对维护目标是否达到，失败时按预案回滚并重新公告
- 确认静默已到期或手工撤销，避免窗口过去仍持续压制
- 把本次维护的时间、影响与结论记入值班日志
- 维护前的静默由自动化在变更单进入执行状态时创建，减少人为遗漏
- 维护结束前留出观察窗口，确认服务指标恢复平稳后再关闭静默
- 静默时长比计划结束时间多留一段缓冲，避免收尾阶段仍有告警外发扰乱判断
静默与勿扰时段的选择
| 场景 | 推荐手段 | 原因 |
|---|---|---|
| 一次性割接升级 | 临时静默 | 范围与时长明确，结束后自然失效 |
| 周期性备份或批量任务 | 勿扰时段（mute timings） | 按星期与时间循环生效 |
| 范围较大的发布窗口 | 两者结合 | 固定惯例用勿扰，单次特殊用静默 |
整个维护窗口静默一切，割接出错时也没有告警兜底；主干可用性告警必须保留可用通道，异常时能立刻叫停。