1. 业务连续性验证工程导入
在 SQL Server 运维体系中，"高可用"与"业务连续性"经常被混用，但两者并不等价。高可用关注的是故障发生时服务能否快速恢复，通常以秒级或分钟级的切换时间来衡量；而业务连续性关注的是业务在故障、灾难、误操作乃至计划内维护期间能否持续对外提供服务，它不仅包含技术切换，还包含数据可恢复性、恢复时间目标（RTO）、恢复点目标（RPO）、切换后的数据一致性以及人员与流程的配合。SQL Server 提供了 Always On 可用性组、故障转移群集实例、日志传送、数据库镜像（旧版本）、备份与还原等多种机制，但这些机制被部署并不等于被验证。业务连续性验证工程，就是把这些"纸面能力"转化为"可证明能力"的系统性工作。
一、什么是业务连续性验证工程
业务连续性验证工程（Business Continuity Verification Engineering，BCVE）是一套围绕 SQL Server 数据平台，对高可用与灾难恢复能力进行设计、演练、度量、取证、改进的工程化方法。它的核心命题不是"我们有没有做 Always On"，而是"当主副本真的宕机时，我们能否在承诺的 RTO 内恢复，且数据丢失不超过承诺的 RPO，并且这个过程有可复现的证据"。
它区别于三类常见做法：一是配置即完成——只检查可用性组是否同步、监听器是否在线，从不真正切换；二是被动救火——只在真实故障后才知道切换要多久、应用连接串是否要改；三是一次性演练——做一次演练、写一份报告，之后环境变更、版本升级、数据量增长，能力早已漂移却无人知晓。验证工程要求把验证变成周期性、可度量、可追溯的常态活动。
二、验证工程的目标、范围与核心价值
验证工程的目标可以归纳为四条：证明能力（用实测数据证明 RTO/RPO 达标）、暴露缺口（发现配置、脚本、流程、权限、监控中的薄弱点）、固化流程（把切换与回切步骤沉淀为可执行手册）、支撑决策（为架构改造、容量规划、SLA 承诺提供依据）。
范围上，验证工程覆盖从实例层到业务层的完整链路：实例与群集层（WSFC 仲裁、节点健康）、数据库层（可用性组同步状态、日志传送延迟、备份链完整性）、连接层（监听器、只读路由、应用连接串）、数据层（RPO 实测、数据一致性校验）、流程层（切换授权、通知、回切）以及观测层（监控告警是否在故障时正确触发）。
其核心价值在于把"不确定"变成"可量化"。例如，某订单系统承诺 RTO≤5 分钟、RPO≤10 秒，验证工程会通过一次计划内手动故障转移，实测从发起切换到应用恢复写入的耗时，并对比切换前最后一条已提交事务与切换后第一条可读事务之间的时间差，从而给出"实测 RTO=2 分 18 秒、实测 RPO≈3 秒"的结论，而不是停留在"应该没问题"。
三、课程整体路线图
本课程共 30 章，按"认知—设计—实施—度量—改进"的工程节奏推进，可划分为五个阶段。
第一阶段（第 1–6 章）建立认知与设计基线。从本章的导入出发，依次讲清 RTO/RPO 的定义与分解方法、SQL Server 各类高可用技术的适用边界、验证工程的组织与角色、验证范围与优先级划分，以及验证环境的搭建原则。这一阶段解决"验证什么、按什么标准验证"的问题。
第二阶段（第 7–14 章）掌握核心验证技术。围绕 Always On 可用性组展开：同步与异步副本的切换验证、监听器与只读路由验证、故障转移条件与仲裁验证、日志传送与备份恢复链验证、数据库一致性校验方法。这一阶段解决"用什么手段验证"的问题。
第三阶段（第 15–21 章）实施故障注入与演练。包括计划内手动切换、计划外强制故障转移、节点与网络故障模拟、存储与 IO 故障模拟、应用侧连接中断与重连验证，以及演练过程的计时与观测方法。这一阶段解决"怎么真实地制造故障并观测"的问题。
第四阶段（第 22–26 章）度量、取证与报告。涵盖 RTO/RPO 实测方法、切换时间线拆解、验证证据的采集与留存、验证报告编写、缺口分级与整改跟踪。这一阶段解决"如何把结果变成可信证据"的问题。
第五阶段（第 27–30 章）持续运营与进阶。包括验证周期与触发条件、自动化验证脚本与工具、验证结果与监控告警联动、能力漂移检测与持续改进。这一阶段解决"如何让能力长期不退化"的问题。
四、一个最小可用的验证示例
为便于理解，给出一个教学示例（参数为合理假设，非实测结果）。假设某订单库部署了两副本 Always On 可用性组：主副本 SQLNODE01、同步提交的辅助副本 SQLNODE02，监听器名为 AG-LSN，应用通过监听器连接。承诺 RTO≤300 秒、RPO=0（同步提交）。
验证时先采集基线：查询 sys.dm_hadr_database_replica_states 确认 synchronization_state_desc 为 SYNCHRONIZED、log_send_queue_size 与 redo_queue_size 接近 0；记录当前时间 T0。随后在辅助副本上执行计划内手动故障转移，同时用秒表或脚本记录应用首次成功写入的时间 T1，则实测 RTO≈T1−T0。由于是同步提交且切换前已确认同步完成，理论上 RPO=0；可通过在主副本写入一条带时间戳的标记记录、切换后在新的主副本查询该记录是否存在来验证。若记录存在，说明 RPO 达标；若缺失，则说明切换前存在未同步事务，需要检查同步状态与切换时机。
这个示例虽小，却完整体现了验证工程的四个要素：明确的承诺指标、可观测的基线、真实的故障动作、可判定的结果。后续章节将围绕这四个要素逐层展开，把单点验证扩展为覆盖实例、数据库、连接、数据、流程与监控的完整验证体系。