故障演练重在练真本事，核心是暴露系统弱点、确保恢复可控可测可优化；需每季度实战演练核心链路，配套止血阈值、平台化操作、还原报告；应急响应分角色、有节奏、留痕迹；预案须为经验证的可执行脚本；复盘聚焦监控、预案、架构三类改进。

故障演练：不是“演”，而是“练真本事”

故障演练的核心目标不是走流程、填表格，而是暴露系统真实弱点。重点不在“是否能恢复”，而在“恢复过程是否可控、可测、可优化”。建议每季度至少开展一次面向核心链路的实战演练，例如模拟主库宕机、网络分区、慢SQL拖垮连接池等典型场景。

关键做法包括：

• 提前定义明确的止血阈值（如P99响应超5秒持续30秒即触发降级）
• 所有操作必须通过统一运维平台执行，禁止手工连库或直接改配置
• 每次演练后生成《故障还原报告》，重点记录：从告警到定位耗时、决策依据、回滚副作用、监控盲区

应急响应流程：分角色、有节奏、留痕迹

稳定性的底线是“不因人而异”。应急响应不能依赖某个DBA的经验记忆，而要靠结构化流程驱动。建议按角色划分三类响应动作：监控岗（盯指标）、决策岗（判策略）、执行岗（跑脚本）。

典型流程节点建议：

• 0–2分钟：自动触发多维告警（数据库连接数、复制延迟、慢查询突增、CPU/IO饱和），同步推送至值班群并语音呼叫第一响应人
• 2–10分钟：完成初步定界——是SQL问题？实例资源问题？还是上游调用风暴？使用预置诊断SQL快速验证（如SELECT * FROM pg_stat_activity WHERE state = 'active' AND now() - backend_start > interval '5 minutes'）
• 10–30分钟：执行预案（如限流、只读切换、临时索引、连接池收缩），所有操作需在工单系统留痕并关联故障单号

预案不是文档，是可运行的代码片段

纸上预案等于没有预案。每个常见故障类型必须配套可一键执行的检查脚本和处置脚本，并经过至少两次沙箱环境验证。例如“主从延迟突增”预案应包含：

• 延迟确认脚本（查pg_replication_slots、pg_stat_replication、WAL堆积量）
• 根因初筛命令（如SELECT pid, query FROM pg_stat_activity WHERE state = 'active' ORDER BY backend_start LIMIT 5）
• 安全止损操作（如临时暂停大事务、清理膨胀表、调整max_standby_streaming_delay）

所有脚本需带参数校验、执行前二次确认、失败自动回滚机制，并与CMDB联动获取目标实例元信息。

复盘不是追责，是重建防御水位线

每次故障后48小时内必须召开技术复盘会，聚焦三个问题：为什么没提前发现？为什么预案没生效？为什么恢复花了这么久？输出物不是“责任人处理意见”，而是三条具体改进项：一条监控补丁、一条预案更新、一条架构优化点（如引入读写分离中间件、增加连接池健康探测）。

特别注意将高频人工干预步骤沉淀为自动化能力。例如人工kill慢查询频次超过每月3次，就应推动上线自动识别+审批式终止功能。