7.3 冗余切换演练、验收与运维移交

7.3 冗余切换演练、验收与运维移交

本节摘要：验收要证明的不是「功能都在」，而是「坏了也扛得住」。本节给出冗余切换演练的完整方案——故障注入矩阵、判定指标、记录表——再讲连续试运行的考核规则，最后是资料与知识移交的清单。2.2 节埋下的「没有演练过的冗余等于没有冗余」，在这里兑现成一场有剧本、有裁判、有记录的实战。

系统交出去之前

把一套 SCADA 交给运行班组，本质是一份信任的转移：班组从此把供水调度托付给它。验收仪式就是这份信任的最后一道关卡——所以验收的重心不在「演示成功路径」，而在按剧本注入故障，看系统与人的表现。本节按演练、试运行、移交三步走完这条收官路。

一、冗余切换演练：剧本、注入与判定

演练方案的四要素：

故障注入矩阵。 把 2.2 节列出的冗余对象逐项变成注入动作：

注入 1  主采集服务器断电       预期 备机接管 操作员站无感  判定 切换时间与数据完整
注入 2  主用光纤通道中断       预期 备用通道接管 中断告警  判定 切换条件与告警一致
注入 3  网关断电再恢复         预期 缓存数据按序补传      判定 曲线连续无空洞
注入 4  核心交换机单台断电     预期 双星另一侧承载        判定 会话保持或秒级恢复
注入 5  主站整体断电恢复       预期 分批重连 错峰补传     判定 恢复过程无二次故障
注入 6  时钟源中断             预期 偏差告警 事件时标降级  判定 告警及时且无时标污染
​

判定指标。 每条注入对应量化判据：切换时间上限（按 2.2 节口径）、数据完整性（注入前注入的变化量与历史库核对）、告警一致性（确认状态与闭锁标志不丢）、恢复行为（回切策略是否按设计执行）。记录表格：每次演练一行，记录注入时刻、发现时刻、恢复时刻、数据核对结果、偏离项——这份表是验收文件的一部分，也是 2.2 节所说「演练记录厚度」的实体。裁判规则：演练由运行班组人员实际操作（不是厂商操作给班组看），甲方验收组掐表核对——演练检验的是「系统加人」的整体能力。

某项目的演练实录片段说明为什么裁判规则重要：注入一条后，厂商工程师条件反射地手工把备机拉起接管，用时三秒、全程无告警——但这检验的是「人有多快」，不是「系统有多稳」。演练组要求清空操作、按设计自动切换重做，暴露出真实的接管时间与两条配置问题。演练的第一纪律：只注入，不施救，看系统自己长什么样。

二、连续试运行：考核规则先讲清

试运行是「带考核的日常运行」，规则前置才不扯皮。三项规则：考核周期——通常以连续运行时长计（行业惯例参考相关规程），中断即重新计时或按约定扣减；中断事件的处理规则——区分「系统原因」与「外部原因」（市电闪络、运营商故障），外部原因按约定折算或不计，判定依据是运维记录而非口头争辩；观察指标——数据完整率（历史库连续性抽查）、报警准确率（误报漏报统计）、遥控成功率（含返核通过率）。水厂项目的实践口径：试运行期间每周出一份指标周报，验收会上一目了然，比「运行稳定」四个字有分量得多。

三、资料与知识移交：把系统交给「人」

移交不只是交钥匙。资料清单的骨干：竣工版四件套——竣工点表（与现场逐一核对过的）、通信契约现势版、画面与程序归档（含版本库与构建说明）、验收文件（含演练与试运行全部记录）。运维手册的必备章节：日常巡检项与周期、常见故障处置卡（把 4.3 节的排错路径清单按本系统实际改写）、备件清单与更换步骤、应急联系与升级路径。培训面向两类人：操作员（画面、报警、遥控流程、应急预案演练）与维护员（组态只读备份、程序结构、点表变更流程）。

知识移交有个常被忽略的软性指标：移交后第一次独立故障处置。验收后一个月内，运行班组第一次独立处理通信或数据异常的过程记录，最能反映移交质量——处置卡按图索骥顺利完成，说明移交到位；全程电话求援，说明知识还留在厂商工程师脑子里。把这个「首战观察」写进服务期约定，是甲方的自我保护。

五、验收会的开法

验收会本身也是门手艺。议程设计：汇报压到三十分钟以内（材料提前发，会上不朗读），主体时间留给现场演示与抽查——演示按验收大纲的功能项走真实操作，抽查由验收组随机点名（随机是关键：提前彩排的演示路径证明不了系统质量）。证据随行：每个演示项旁边挂对应的证据（联调核对单行号、演练记录、试运行周报），验收组可随时下钻——证据链顺畅的验收会，两小时能收场；证据断链的验收会，再多的演示也难收场。遗留项处置：验收不是零遗留，是「遗留项全部有编号、有责任方、有时限、不影响安全与核心功能」——把这条口径写进验收结论模板，避免「非全优不签字」与「带病强过」两个极端。

验收会的心理准备也值得一句提醒：验收组的责任是给出真实结论，而不是证明自己火眼金睛——把验收当侦察战的项目组，通常自己先乱了阵脚。证据链齐备的团队，验收会只是把两个月的工作公开走一遍而已。

六、验收之后：质保期的正确用法

质保期不是「出问题免费修」的宽限期，而是系统成熟的最后一段培育期，甲方的正确用法有四条：缺陷分类统计——质保期缺陷按设计、组态、设备、环境归类，设计与组态类缺陷的修复要同步更新文档与点表，防止「修了系统、坏了档案」；性能基线留档——试运行末期的性能数据（刷新时延、切换时间、通道在线率）作为基线留存，质保期结束验收就是对照基线查衰减；技能验收——运维班组在质保期内独立完成至少一次故障处置与一次组态变更，这是比系统指标更重要的验收项；文档对齐——质保期的所有变更回写竣工文档，质保期满时文档与现势系统一致才算真正移交完成。质保期用得好，系统在第二年就进入「文档可信、人员能干」的稳态；用得不好，质保期只是把问题推迟到付费服务的第一天。

本节要点回顾

• 验收重心在故障注入：按矩阵逐项演练，只注入不施救，看系统自己的表现。

• 判定指标量化：切换时间、数据完整、告警一致、恢复行为，记录表进验收文件。

• 试运行规则前置：周期、中断折算、观察指标写清口径，每周出指标周报。

• 移交交的是能力：竣工四件套加运维手册加分级培训，用「首战观察」验证移交成色。

系统交付，证据链闭合。下一章抬头看路：云化与智能化正在怎样改写这条链路与这套工程节奏。