3、单机系统瓶颈：单点故障分析、可靠性计算（MTBF/MTTR）、单机架构的局限性
好，咱们接着聊。上一章我们讲了SCADA系统的基本架构，看起来挺完整对吧？但我要泼一盆冷水——单机系统，说白了就是一颗定时炸弹。你想想看，整个工厂的控制、监控、数据采集全压在一台机器上，它要是撂挑子，生产线就得停摆。
我入行第三年就吃过这个亏。当时给一个化工厂做DCS升级，客户为了省钱选了单机架构。结果运行半年后，硬盘坏了。整个车间停了8小时，损失惨重。从那以后，我对单机系统就特别敏感。
3.1 单点故障分析
什么是单点故障？就是系统中某个组件坏了，整个系统就瘫了。单机SCADA系统里，这样的点太多了。
常见的单点故障点：
- 电源模块——断电就是灾难
- 硬盘/存储——数据丢了，历史趋势全完
- CPU/主板——运算能力归零
- 网卡/交换机——通信中断
- 操作系统/软件——蓝屏、死锁、内存泄漏
你可能会说：「这些硬件都有MTBF指标啊，没那么容易坏吧？」嗯，这里要注意——MTBF是统计值，不是保证书。我见过一台号称MTBF 10万小时的工控机，用了3年就挂了。概率再小，落到你头上就是100%。
3.2 可靠性计算：MTBF与MTTR
咱们来点硬核的。可靠性计算有两个核心指标：
| 指标 | 全称 | 含义 | 单位 |
|---|---|---|---|
| MTBF | Mean Time Between Failures | 平均无故障时间 | 小时 |
| MTTR | Mean Time To Repair | 平均修复时间 | 小时 |
这两个指标决定了系统的可用性（Availability）。公式很简单：
可用性 A = MTBF / (MTBF + MTTR) × 100%举个例子。假设一台工控机的MTBF是8760小时（正好一年），MTTR是4小时（从故障到恢复）。那么：
A = 8760 / (8760 + 4) = 0.99954 ≈ 99.954%看起来很高对吧？但你要算一下每年的停机时间：
年停机时间 = 8760 × (1 - 0.99954) ≈ 4小时嗯，一年停4小时。对于非关键系统，也许能接受。但如果是化工、电力、制药这些行业，4小时可能意味着几百万的损失。
我的经验：别只看MTBF，MTTR才是关键。我曾经遇到一个项目，MTBF很高，但备件库在另一个城市，MTTR长达24小时。结果可用性直接掉到99.7%以下。所以，缩短MTTR比提高MTBF更实际。
3.3 单机架构的局限性
单机系统的问题，说白了就三个字：不抗造。
局限性一：无冗余，故障即停机
单机系统没有备用方案。电源坏了？停机。硬盘坏了？停机。网线被老鼠咬了？停机。我见过最离谱的一次，是操作员不小心踢掉了电源线，整个系统直接黑屏。你说冤不冤？
局限性二：维护窗口难安排
单机系统要维护，必须停机。你想打补丁？停机。你想换硬盘？停机。你想清灰？停机。很多工厂为了不停产，系统一跑就是好几年，安全漏洞越积越多。
局限性三：性能瓶颈明显
单台机器的CPU、内存、磁盘IO都是有限的。当接入的PLC数量增加、数据采集频率提高、历史存储量变大时，单机很快就会撑不住。我见过一个项目，单机接了200个PLC，每秒采集5000个点，结果CPU长期100%，操作界面卡得跟幻灯片一样。
局限性四：数据安全风险
所有数据都在一台机器上。硬盘坏了，历史数据全丢。中了勒索病毒，整个系统瘫痪。没有备份，没有容灾，风险极高。
避坑指南：我曾经给一个水处理厂做方案，客户坚持用单机，说「我们厂小，没必要搞冗余」。结果运行一年后，系统崩溃，数据全丢。后来花了两倍的钱重建系统，还赔了环保局的罚款。所以，别省那点冗余的钱。
3.4 什么时候可以用单机？
说了这么多单机的坏话，那它是不是一无是处？也不是。我个人认为，以下场景可以考虑单机：
- 非关键系统——比如实验室、培训系统、演示系统
- 短期项目——临时搭建，用完就拆
- 预算极度有限——但要做好风险预案
- 数据可离线备份——每天手动备份，能接受短时停机
但说实话，在工业现场，我很少推荐单机。你想想看，一套SCADA系统动辄几十万上百万，省那几万块的冗余成本，值得吗？
3.5 小结
单机系统最大的问题，就是把所有鸡蛋放在一个篮子里。MTBF再高，也扛不住一次意外。MTTR再短，停机就是停机。
下一章，我们会讲双机冗余架构。那才是工业SCADA系统的真正起点。到时候我会分享一个我亲手搭建的双机热备项目，保证干货满满。