3. 高可用基础概念
在 Ignition 企业部署工程中，高可用（High Availability，HA）不是简单地“多装一台服务器”，而是围绕业务连续性目标，对系统架构、冗余级别、故障域和恢复指标进行系统化设计。理解高可用的基础概念，是后续设计冗余架构、规划容灾方案和制定运维策略的前提。
一、高可用的定义与核心目标
高可用是指系统在计划内维护或计划外故障发生时，仍能以可接受的服务水平持续对外提供服务的能力。其核心目标可以概括为三点：减少服务中断时间、降低数据丢失风险、保证故障后能够快速恢复。对于 Ignition 而言，高可用通常涉及 Gateway 冗余、数据库高可用、历史数据缓存、报警与审计数据不丢失，以及客户端在切换过程中的可感知体验。
高可用并不等于“永不宕机”。任何系统都存在故障概率，高可用的本质是通过冗余、隔离、监控和自动化切换，把单点故障造成的影响降到最低。因此，讨论高可用时必须同时关注两个维度：一是故障发生的频率，二是故障发生后的恢复速度。
二、SLA、MTTR 与 MTBF：衡量高可用的三把尺子
SLA（Service Level Agreement，服务等级协议）是服务提供方与业务方之间对可用性、响应时间、恢复时间等指标的正式约定。常见可用性等级如下：
| 可用性等级 | 年停机时间（约） | 典型场景 |
|---|---|---|
| 99% | 87.6 小时 | 一般内部辅助系统 |
| 99.9% | 8.76 小时 | 普通生产监控系统 |
| 99.95% | 4.38 小时 | 重要生产系统 |
| 99.99% | 52.6 分钟 | 关键控制与调度系统 |
| 99.999% | 5.26 分钟 | 极高要求核心系统 |
MTTR（Mean Time To Repair，平均修复时间）表示从故障发生到系统恢复服务所需的平均时间。MTTR 越短，系统在故障后恢复得越快。MTBF（Mean Time Between Failures，平均故障间隔时间）表示两次相邻故障之间的平均运行时间，反映系统的可靠性水平。三者关系可以简单理解为：可用性 ≈ MTBF / (MTBF + MTTR)。因此，提高可用性有两条路径：提高 MTBF（减少故障）和降低 MTTR（加快恢复）。
关键结论：高可用设计不能只关注“买冗余硬件”，还要关注故障检测速度、切换自动化程度、数据同步方式和运维响应流程。MTTR 往往比 MTBF 更容易通过工程手段显著改善。
三、故障域与冗余级别
故障域（Failure Domain）是指一个故障发生时可能影响到的最大范围。常见的故障域包括：单块硬盘、单台服务器、单个机柜、单个机房、单个网络链路、单个数据库实例、单个电源回路等。高可用设计的第一步，就是识别系统中的单点故障，并判断其故障域边界。
冗余级别通常可以分为以下几类：
- 无冗余：单节点运行，任一组件故障都会导致服务中断。
- 冷备：备用节点存在但不运行或不同步，故障后需要人工启动和恢复。
- 温备：备用节点已安装配置，但数据或状态未实时同步，切换需要一定时间。
- 热备：主备节点同时运行，数据实时或准实时同步，故障后可自动或快速切换。
- 多活：多个节点同时对外提供服务，任一节点故障不影响整体服务能力。
冗余级别越高，系统可用性通常越好，但成本、复杂度和运维难度也越高。企业应根据业务重要性、停机成本和数据丢失容忍度选择合适的冗余级别。
四、常见高可用架构模式
在 Ignition 企业部署中，常见的高可用架构模式包括：
- 主备模式：一台 Gateway 作为主节点，另一台作为备用节点，通过冗余机制同步配置、项目和部分运行状态。主节点故障时，备用节点接管服务。
- 负载均衡模式：多台 Gateway 同时提供服务，前端通过负载均衡器分发客户端请求，适合读多写少或可分区处理的场景。
- 数据库高可用：通过数据库集群、主从复制或 AlwaysOn 等机制，保证历史数据和配置数据不因单台数据库故障而丢失。
- 跨机房容灾：在不同机房部署冗余节点，通过数据复制和 DNS/负载均衡切换，应对机房级故障。
- 边缘缓存与断点续传：在边缘侧缓存历史数据，网络恢复后补传，降低网络故障对数据完整性的影响。
下面用一张结构关系图展示 Ignition 高可用部署中常见的故障域、冗余级别与架构模式之间的关系。
五、案例场景：某水厂 Ignition 高可用改造
某水厂原有 Ignition 系统采用单台 Gateway 加单台数据库服务器，运行两年内发生过两次因服务器硬件故障导致的停机，每次恢复约 2 小时。业务方要求将年可用性提升到 99.9% 以上。改造方案如下：
- 部署两台 Ignition Gateway，配置为主备冗余模式，主节点故障时备用节点自动接管。
- 数据库采用主从复制，主库故障时切换到从库，历史数据保留在边缘缓存中，网络恢复后补传。
- 将 Gateway 和数据库分别部署在不同机柜，避免单机柜电源或网络故障同时影响主备节点。
- 建立监控告警，对 Gateway 心跳、数据库复制延迟、磁盘空间和网络状态进行实时监测。
改造后，系统年停机时间从约 4 小时降至 30 分钟以内，MTTR 从 2 小时缩短到 10 分钟以内，满足了业务方对 99.9% 可用性的要求。
六、常见误区与复盘
误区一：有备用节点就等于高可用。如果备用节点长期不同步、切换脚本未验证、数据库复制延迟过高，故障时仍然无法接管。
误区二：只关注服务器冗余，忽略网络和电源。交换机、防火墙、电源回路同样是单点故障，必须纳入故障域分析。
误区三：把 SLA 当成技术指标，而不是业务约定。SLA 需要明确可用性计算方式、统计周期、排除项和赔偿条款，否则容易产生争议。
误区四：忽视演练。高可用架构必须定期进行切换演练，验证 MTTR 和 MTBF 是否达到设计目标，否则真实故障时可能手忙脚乱。
复盘时建议重点关注：故障是否发生在预期故障域内、切换是否自动完成、数据是否丢失、MTTR 是否达标、监控是否提前发现异常。只有把每次故障和演练都转化为改进项，高可用能力才能持续提升。
实践建议：在设计 Ignition 高可用方案时，先明确业务可接受的停机时间和数据丢失窗口，再选择冗余级别和架构模式。不要盲目追求最高冗余级别，而应让投入与业务价值匹配。