[公开] MES灾备方案：宕机12次后我们做的改造

【摘要】一年宕机十二次、单次最长四小时十七分，纸单作业救不了产线。本文完整复盘我们的MES高可用与灾备改造：会话无状态化、数据库半同步自动切换、接口机双活、离线降级作业与幂等补传，以及季度演练机制，附组件级RTO与RPO目标表和改造前后实测数据。

分类：MES自动化 | 发布：2026-08-16 | 首发：半导体智能制造博客

一、背景故事：一次真实的产线事件

2023年是我们厂MES运维最难受的一年，全年计划外中断十二次，累计不可用时长十四小时二十六分钟，其中最长的一次是四小时十七分。那次是数据库主库的存储卡固件故障，主库直接宕死，从库虽然在，但没有自动切换机制，DBA凌晨两点被叫醒，远程连上来一步步手工切，光是确认从库数据一致性就花了五十分钟。

产线那边更狼狈。MES不可用期间只能启用纸单作业，操作员手写批次号、机台号、时间和数量。四个小时下来积压了两百多张纸单，恢复后靠三个人加班到第二天中午才补录完，补录过程中还录错了十一条，最后靠比对设备日志才逐条纠正。更严重的是那段时间的批次追溯数据出现断层，一个月后客户来做审核，我们花了整整两天准备解释材料。

这一年下来管理层的耐心也耗尽了，年底立项做灾备改造，预算不算宽裕，明确要求不能靠堆硬件解决。项目做了六个月，2024年全年计划外中断降到两次，平均恢复时间七分钟。这篇文章把我们做的每一件事和踩过的坑写清楚，包括那些看起来正确但实际没用的方案。

二、技术原理：把机制讲清楚

谈灾备必须先把两个指标定义清楚。RTO是恢复时间目标，指从故障发生到业务恢复可用的最长可接受时长；RPO是恢复点目标，指故障时最多可接受丢失多长时间的数据。这两个指标决定了技术选型和成本，不能笼统地说要高可用，必须落到具体数字。我们最终定的是核心交易类功能RTO五分钟、RPO十秒，报表类功能RTO两小时、RPO一小时，差异化定级是控制成本的关键。

MES的高可用要分层来看，每层的手段完全不同。应用层的关键在于无状态化，只要会话和临时状态不存在本地内存里，多实例就可以随意增减，负载均衡摘掉故障节点即可，切换对用户几乎无感。数据库层要在同步方式上做权衡：异步复制性能好但可能丢数据，全同步不丢数据但主库要等从库确认，性能损耗大且从库故障会拖垮主库，半同步是折中方案，要求至少一个从库确认收到日志即可提交。存储与网络层则依赖冗余设计，多路径、双上联、双电源这些属于基础设施标准动作。

自动切换绕不开脑裂问题。当主从之间的网络断开但两边都活着时，如果从库自行提升为主库，就会出现两个主库同时接受写入，数据分叉之后几乎无法自动合并。解决办法是引入第三方仲裁节点，采用多数派原则，只有能与仲裁节点通信的一方才有资格成为主库。仲裁节点必须部署在与主从都不同的故障域，否则失去意义。我们最初把仲裁节点和从库放在同一个机柜，演练时发现机柜断电会导致整体不可用，后来移到了另一栋楼的机房。

还有一个常被低估的概念是降级可用。真正的灾备不只是让系统尽快恢复，更重要的是在系统不可用期间业务还能以某种受限方式继续运转。对MES来说，最有价值的降级能力是让现场能够继续扫码记录，数据先存在本地，系统恢复后自动补传。这套机制的技术难点不在于本地存储，而在于补传时的幂等性和顺序性保证。

三、现状分析：多数工厂现在是怎么做的

我调研过的中小规模Fab，MES灾备的实际水平普遍低于管理层的认知。最常见的状态是有数据库备份但没有切换方案，每天凌晨做一次全备加binlog增量，理论上数据不会丢，但恢复需要几个小时。管理层以为有备份就等于有灾备，直到真出事那天才发现备份只解决数据不丢，不解决业务不停。

第二个普遍问题是单点隐藏得很深。大家都会关注数据库和应用服务器，但往往忽略那些不起眼的组件：许可证服务器、报表服务、文件共享、接口机、甚至某台跑定时任务的老服务器。我们做梳理时找出了九个从未被纳入高可用范围的组件，其中许可证服务器一旦宕机，MES全部客户端在两小时内会陆续失效，这个风险之前完全没人意识到。

第三个问题是有方案但从不演练。文档写得很完整，切换步骤十七步，但从来没人完整执行过。真到出事的时候，文档里的第六步引用的脚本路径早就变了，第十一步需要的账号密码半年前改过没同步，于是变成现场摸索。没有演练过的灾备方案，可靠性接近于零。

第四个问题是过度依赖单一厂商工程师。很多厂的MES是供应商实施的，运维知识集中在对方一两个人身上。半夜出事第一件事是打电话找那个人，找不到就只能干等。这不是技术问题，是组织风险，但后果同样严重。

四、瓶颈问题：卡在哪里

第一个卡点是会话状态存在应用本地内存。我们的MES用的是传统三层架构，用户登录后的会话对象和一批业务临时状态都放在应用服务器的本地内存里。这意味着即使部署了多个实例，某个实例挂掉时连在上面的用户会全部掉线，正在填写的表单内容丢失，操作员要重新登录重新填。产线对此的抱怨很大，因为一次数据录入可能涉及几十个字段。

第二个卡点是数据库切换全手工。从库存在，复制也正常，但没有任何自动化。切换需要人工确认从库延迟、停掉主库写入、提升从库、修改应用连接配置、重启应用、验证。六个步骤全靠人，最快也要三十分钟，深夜叫人到位还要额外算时间。

第三个卡点是接口层重放会造成脏数据。MES与设备、EAP、ERP之间有大量接口，故障恢复后这些系统会重发之前失败的消息。我们早期没有做幂等，一次恢复后同一批次的入站记录被写了三遍，导致WIP数量虚高，追查了两天才定位。这类问题的隐蔽性极强，因为它不会报错，只会悄悄污染数据。

第四个卡点是没有降级方案。系统一挂就只能纸单，而纸单的问题不只是慢，更在于补录质量差、无法保证时序、且极易漏录。前面提到的十一条录错记录就是这么来的。产线在系统不可用期间实际上处于失控状态，这才是最大的风险。

第五个卡点是演练缺位与知识集中。改造前我们从未做过完整演练，运维手册的最后更新日期是系统上线那年。而真正懂数据库切换细节的只有一位DBA，他休假期间团队实际上是裸奔状态。

五、解决方案：可落地的完整做法

第一步是应用无状态化。我们把会话对象迁到Redis集群，业务临时状态改为前端本地暂存加定期草稿保存。这项改造涉及大约四十处代码修改，工作量不算小，但收益最直接：完成后单个应用实例故障时，负载均衡在健康检查失败后三十秒内摘除节点，用户会话不中断，最多感知到一次短暂卡顿。Redis本身用三主三从的集群模式，避免引入新的单点。

第二步是数据库半同步复制加自动故障转移。我们采用一主两从的架构，配置半同步复制并设置超时降级，即从库无响应超过一秒自动退化为异步，避免从库故障拖垮主库。故障转移用开源的高可用编排组件实现，配合部署在第三故障域的仲裁节点，采用多数派选主。实测主库强制断电场景下，自动切换耗时五十八秒，其中检测占三十秒，这个检测时间是可以再压的，但压太短会增加误切换风险，我们权衡后保留了三十秒。

第三步是接口层双活加幂等。原来的单台接口机改成两台双活，前面挂负载均衡，会话信息同样外置。更重要的是给所有写接口加了业务唯一键，服务端在写入前先查重，重复消息直接返回成功但不落库。同时在消息队列层面配置了死信队列，处理失败超过三次的消息进入死信队列并告警，避免无限重试拖垮系统。这三项组合下来，恢复期的数据污染问题彻底消失。

第四步是离线降级作业。我们开发了一个轻量的移动端应用，产线用平板或手持终端运行。正常情况下它是MES的一个前端；MES不可用时自动切到离线模式，扫码记录写入本地数据库，可以支撑至少四小时的作业量。系统恢复后自动检测并按时间顺序补传，补传走的是带幂等键的接口，重复提交不会产生脏数据。补传完成后生成一份差异报告，列出补传条数、失败条数和需要人工确认的项目。

第五步是分级与演练制度化。我们把MES的功能模块分成三级：一级是批次流转、设备交互、数据采集这些直接影响生产连续性的功能，RTO五分钟；二级是质量判定、库存管理，RTO三十分钟；三级是报表、看板、历史查询，RTO两小时。不同级别对应不同的资源投入。演练方面规定每季度一次，轮流演练数据库切换、应用节点故障、接口机故障、以及完整的离线降级流程，每次演练必须有真实的故障注入，不接受桌面推演。演练结果记入运维团队考核。

第六步是知识去中心化。所有切换操作脚本化，参数外置到配置文件，脚本纳入版本管理。运维手册改为可执行的检查清单形式，每一步都有明确的验证命令和预期输出。同时要求团队内至少三人能独立完成每一类切换，通过演练轮岗来保证。这一条看起来是管理措施，实际上是灾备可靠性的重要组成部分。

六、实战案例：一个完整的改造过程

改造完成后的第四个月，我们遇到了一次真实的主库故障。凌晨一点十七分，主库所在物理机的内存条报错触发系统崩溃。监控在二十八秒后检测到主库不可达，仲裁节点确认后触发选主，一号从库提升为主库，应用连接池自动重连，全过程五十八秒。产线侧的感知是MES界面卡顿了大约一分钟，有七个正在提交的操作报错需要重试，没有数据丢失，没有人被叫醒。

第二天早上我们做了完整的事后核对。比对主从切换前后的关键表记录数，一致；比对设备日志与MES记录的批次流转时间戳，最大偏差三秒，在可接受范围；检查接口队列，有十四条消息在切换窗口内投递失败，全部由重试机制成功补投，无重复写入。这次故障验证了整套机制确实能工作，而不只是文档上写得好看。

同一年的第三季度演练中我们暴露了一个新问题。演练场景是完整断开MES与产线网络三十分钟，测试离线降级。结果发现手持终端的离线数据库在写入约一千两百条记录后出现性能急剧下降，原因是本地表没有建索引，查重逻辑做了全表扫描。这个问题在日常测试中从未出现，因为测试数据量太小。修复后重新演练，五千条记录写入无压力。演练的价值就在这里，它能发现设计时想不到的边界问题。

还有一次演练暴露的问题更有意思。我们模拟接口机故障，把主接口机断电，流量应当自动切到备机。切换本身很顺利，但十分钟后发现某个与ERP对接的定时任务没有跑，因为那个任务被写死在主接口机的系统计划任务里，不在双活范围内。这类残留的单点只有通过真实演练才能揪出来，纸面评审是查不到的。我们后来把所有定时任务统一迁到了带分布式锁的调度平台。

七、实施效果：数据说话

最核心的指标，计划外中断次数从2023年的十二次降到2024年的两次，累计不可用时长从十四小时二十六分降到十四分钟，系统可用率从百分之九十九点八三提升到百分之九十九点九九七。平均恢复时间从四小时十七分（最长值）和约七十二分钟（平均值）降到七分钟。RPO方面，半同步复制配合幂等接口，两次故障均实现零数据丢失。

第二个效果是纸单作业基本退出历史。改造后的两次中断中，产线全程使用离线降级模式作业，共记录一千八百余条操作，恢复后全部自动补传成功，人工确认项只有六条，且都是因为操作员重复扫码导致的正常提示。相比之前四小时积压两百张纸单、三人补录一天半，效率差异是数量级的。

第三个效果体现在审计与客户信任上。2024年底客户来做体系审核，专门问到了系统连续性保障。我们提供了四次演练记录、两次真实故障的完整时间线、以及分级RTO与RPO的定义文档，审核员当场认可，没有开任何观察项。而2023年那次审核，我们在这一项上被开了一个整改要求。

最后想说一个不太容易量化的变化：团队心态。改造之前，运维同事晚上睡觉手机不敢静音，出差都要带电脑。现在虽然依然有值班，但大家清楚系统能自愈到什么程度、哪些场景需要人介入、介入时该执行哪份清单。这种确定性本身就是灾备体系最重要的产出之一。

八、常见问题答疑

Q：预算有限，最优先做哪一项？

A：先做会话无状态化和接口幂等，这两项几乎不增加硬件成本，收益却最直接。数据库自动切换排第二，离线降级排第三，因为它需要额外的应用开发投入。

Q：自动故障转移会不会误切换？

A：会，所以检测窗口不能太短。我们保留了30秒检测期并要求仲裁节点确认，运行一年出现过一次因网络抖动触发的准误判，仲裁机制成功阻止了切换。宁可慢30秒，不可脑裂。

Q：演练会不会影响生产？

A：选在周末或计划停机窗口做，并提前通知产线。第一次演练建议在测试环境完整跑一遍再上生产。我们的经验是不敢在生产做演练的方案，本质上就是不敢用的方案。

九、工程落地经验：路线图、分工与验证

验证方法上，建议采用离线回溯加在线影子运行的两段式。先用历史数据回溯，看新方案能否在事后正确识别已知事件，统计召回率与误报率；再在产线上做影子运行，即方案照常输出结果但不触发实际处置，与现有做法并行跑两到四周，对比差异。两段验证都通过后再切换为正式生效，这套流程能把上线风险降到可接受范围。

文档与知识沉淀常被忽略，但它决定了方案能否活过人员变动。建议为MES灾备体系建立三份文档：一份是给管理层看的一页纸方案说明，一份是给工程师看的参数与规则手册，一份是给现场操作看的处置卡片。三份文档面向不同读者，语言和详略程度完全不同，不要试图用一份文档覆盖所有人，那通常意味着谁都不看。

与其他系统的接口要提前约定失败语义。MES高可用集群与MES、SPC、EAP之间的调用，必须明确超时时长、重试次数、幂等键和补偿机制。我们踩过的坑是重试没有幂等保护，网络抖动时同一条系统单点故障记录被写入三次，导致系统可用率统计虚高，追了两天才定位到是接口层重复提交。现在所有写接口都强制带业务唯一键，服务端做去重。

关于阈值的动态化，固定阈值在产品结构单一时够用，但一旦产品组合频繁切换就会失效。做法是按产品族、机台族、班次分层设定，并用滚动窗口定期重算。重算周期建议不短于两周不长于三个月，太短会跟随噪声漂移，太长则跟不上工艺演进。每次重算必须留档，记录重算前后的阈值、依据样本量和批准人，方便后续追溯系统可用率判定口径的变化。

最后是人的因素。MES灾备体系的推行本质上是在改变现场的工作习惯，技术方案再完美，如果操作员觉得多了负担就会被绕过。有效的做法是让现场先尝到甜头：优先自动化那些他们最讨厌的重复劳动，比如手工抄表、跨系统复制粘贴、每日报表整理，等信任建立起来，再推进那些需要他们额外配合的环节，阻力会小很多。

十、配图：数据可视化

图1：MES高可用与灾备总体架构

图2：故障切换与离线数据补传流程

十一、MES各组件RTO/RPO目标与高可用手段对照表

十二、灾备改造前后关键指标对比表

十三、配套资料与实战工具

本文配套完整实战工具包，包含文中涉及的测算模板、参数配置表、排查清单与Python脚本，可直接用于工厂落地实施。

点击上方「VIP资源」下载区，免费获取以下五项配套资料（持续更新中）：

产能负荷与瓶颈识别测算表（含机台产能、稼动率、排队时间与节拍分解模板）

洁净室颗粒监控与良率关联分析脚本包（含示例数据与归因模板）

时序异常检测与Transformer调参配置模板（含窗口、阈值、评估口径清单）

SPC自动告警链路配置表与OCAP标准表单（含分级与抑制规则）

MES灾备演练Checklist与工艺窗口margin测算表（含RTO/RPO定级模板）

────────────────────────────────────────

本文首发于博客：半导体智能制造 | MES工程师实战笔记

你遇到过类似的问题吗？是怎么解决的？欢迎在评论区分享你的实战经验，一起交流进步。

标签：MES自动化 | 高可用 | 灾备演练 | RTO RPO | 系统架构 | 半导体Fab