2. 故障应急响应机制

数据库故障真正造成损失的，往往不是故障本身，而是"发现慢、判断乱、升级迟、复盘空"。一套可执行的应急响应机制，本质上是把"谁在什么时候做什么判断"提前固化下来，让值班人员在压力下不必临场发明流程。本节围绕告警分级、值班响应、故障定级、信息收集、决策树、升级路径与事后复盘七个环节展开，重点讲清楚每一环的输入、判断依据和输出。

一、告警分级：先解决"哪些必须半夜叫醒人"

告警分级的目的不是给告警贴标签，而是决定通知方式和响应时限。SQL Server 场景下建议按"业务影响 + 可自愈性"两个维度划分四级：

分级必须落到具体阈值上，否则形同虚设。例如 P1 的"日志满"应明确为：sys.dm_db_log_space_usage 中 used_log_space_in_percent > 95 且日志无法自动增长；P2 的"阻塞链"应明确为：sys.dm_exec_requests 中 blocking_session_id <> 0 的会话数 > 3 且最长等待时间 > 300 秒。阈值要随业务基线调整，不能照搬。

二、值班响应与故障定级

值班表应明确"一线 DBA 值班 + 二线专家待命 + 三线厂商支持"三层。一线负责接警、初步信息收集和 P3/P4 处理；二线负责 P1/P2 的决策与执行；三线在涉及内核错误、数据页损坏等场景介入。值班交接必须包含未闭环告警清单，避免"交接即失忆"。

故障定级不是一次性的，而是随信息更新动态调整。定级依据三条：影响范围（单库/单实例/整个可用性组）、业务后果（只读降级/写入中断/数据丢失风险）、恢复可控性（能否自愈、是否有可用副本）。例如一个只影响报表库的查询超时，即使报错频繁，也应定为 P3；而主库写入中断哪怕只持续 30 秒，也应立即定为 P1。

三、信息收集清单：让判断有据可依

故障现场最忌讳"凭感觉猜"。建议在值班手册中固化一份最小信息收集清单，一线在 5 分钟内完成采集：

• 实例与版本：SELECT @@VERSION，确认补丁级别；
• 当前时间与故障起始时间，以及最近一次变更（发布、索引重建、参数修改）；
• 错误日志关键片段：EXEC sp_readerrorlog 0,1,'错误关键字'；
• 会话与阻塞：sys.dm_exec_requests 中 blocking_session_id、wait_type、wait_time；
• 资源水位：CPU、内存、数据/日志盘剩余空间、PAGEIOLATCH 等待占比；
• 可用性组状态：sys.dm_hadr_availability_replica_states 的 synchronization_state 与 role；
• 备份与日志链：最近一次完整备份、日志备份时间，是否存在断链。

这份清单的价值在于：它把"故障是什么"转化为"哪些证据支持哪种判断"，后续决策树才有输入。

四、决策树与升级路径

决策树解决"先做什么"。以"业务反馈写入超时"为例：先确认实例是否可连接 → 若不可连接，检查服务状态与 AlwaysOn 角色，判断是否需故障转移；若可连接，检查是否存在阻塞链 → 有阻塞则定位头阻塞会话，评估是否 KILL；无阻塞则检查日志空间与磁盘 → 日志满则扩容或切换恢复模式；磁盘满则清理或扩容。每一步都对应明确的观察点和动作，避免在多个方向间反复横跳。

升级路径与决策树配套：一线在 15 分钟内无法定位根因，或判断涉及数据丢失风险、需要故障转移、需要厂商介入时，立即升级二线；二线在 30 分钟内无法恢复业务，升级三线并同步业务方与管理者。升级不是"甩锅"，而是把决策权交给更有权限和资源的人。

五、事后复盘：把一次故障变成一次能力升级

复盘不是追责会，而是把故障转化为可复用的判断资产。建议在故障恢复后 48 小时内完成，输出四样东西：时间线（从首个异常信号到业务恢复的每个关键节点）、根因（区分直接原因与系统性原因，例如"日志满"是直接原因，"日志增长监控缺失"是系统性原因）、改进项（每项必须有责任人和完成时间）、预案更新（把本次新发现的判断条件补进决策树和告警阈值）。

例如某次主库写入中断，复盘发现根因是日志备份作业被误停导致日志持续增长。改进项应包括：为日志备份作业增加"连续两次未成功即告警"的监控；在决策树中增加"日志使用率 > 80% 时提前介入"的分支；把该场景写入值班手册的 P2 案例。这样下一次同类故障可能在 P3 阶段就被拦截。

把七个环节串起来看：告警分级决定"叫不叫醒人"，值班响应决定"谁来看"，故障定级决定"多严重"，信息收集决定"凭什么判断"，决策树决定"先做什么"，升级路径决定"什么时候换人"，事后复盘决定"下次能不能更快"。这七环缺一不可，任何一环缺失，都会让应急响应退化为临场救火。