高可用：企业数据保护绕不开的话题

作者：李常青

# 高可用不是玄学：企业数据保护中的“不死”术

上周跟一个做金融IT的朋友吃饭，他一脸疲惫地吐槽：去年花了三百万买了两套高端存储，做了双活，结果前两天机房空调故障，一套存储直接宕机，备用那套切换花了11分钟。业务中断，领导质问他“不是做了高可用吗，怎么还断？”

说实话，这种事我见过太多次了。

很多人以为“高可用”就是买两份设备、做个主备，出事自动切。但现实往往比理论复杂得多——高可用不是买来的，是设计出来的。

到底什么是高可用

先把这个概念说明白。

高可用（HA）的本质，是让系统在硬件、软件、网络等组件发生故障时，依然能对外提供服务。它不是“永不故障”，而是“故障了也感觉不到”。

行业内有个经典目标叫“五个九”——99.999%的可用性，一年停机不超过5.26分钟。说实话，能达到这个级别的企业凤毛麟角，大部分能做到“三个九”（99.9%，年停机8.76小时）已经很不容易了。

我自己的理解更直白：高可用就是给系统装了个“备胎”，但这个备胎不能是“备而不用”，得真正做到“无缝切换”。

关键指标有两个：

简单说，RTO是你“死”多久，RPO是你“丢”多少。

高可用到底解决什么问题

之前有个客户找到我，说他们业务系统用的是单机Oracle，跑着核心交易。我问：硬盘坏了怎么办？他说有RAID。电源坏了呢？有冗余电源。那服务器主板短路呢？他愣住了。

这就是问题：单点故障无处不在。

高可用在数据保护领域主要解决三个核心问题：

第一，消除单点故障。 不光是硬件，还包括网络链路、电力供应、甚至机房位置。我见过最离谱的案例：某公司两套存储做双活，但连在同一台交换机的两个端口上——交换机一坏，全挂。

第二，缩短故障恢复时间。 传统备份恢复可能要几小时甚至一天，高可用方案能做到秒级甚至亚秒级切换，让业务中断对用户无感。

第三，保证数据一致性。 这个最容易被忽视。很多人以为数据复制过去就行了，但如果是异步复制，主库挂了，备库可能少了几秒钟的数据，这对金融、电商等场景是致命的。

实际场景：三种典型高可用架构

场景一：数据库主从复制

最常见也最成熟。MySQL主库写、从库读，主库挂了手动或自动切到从库。

优点：技术成熟、成本可控

缺点：切换有延迟，数据可能丢几秒到几分钟

适合：电商后台、内容管理系统，对RPO要求不那么严苛的场景

场景二：存储双活

两套存储同时在线，数据实时同步，任何一个存储故障都不影响业务。

优点：真正的无缝切换

缺点：贵，而且对网络延迟极其敏感（通常要求光纤链路延迟小于1毫秒）

适合：银行核心交易、证券交易系统等对可用性要求极高的场景

场景三：应用层集群

比如Web服务器做负载均衡，一台挂了流量自动分发到另一台。这是最“上层”的高可用，往往结合前面两种一起用。

我有个客户做了三层高可用：Web层负载均衡+应用层集群+数据库主从，三层互相兜底。说实话，这套架构确实稳，但运维复杂度也上去了——每次版本升级都得考虑三层之间的兼容性，稍有不慎就出问题。

一个真实案例（脱敏）

某制造企业，核心ERP系统运行在单台服务器上，用的是Windows+SQL Server。某天凌晨，系统盘故障导致服务器无法启动。IT紧急联系硬件厂商，花了4小时更换硬盘，又花了2小时从备份恢复数据——总共中断6小时，生产线停摆，损失超过200万。

后来他们做了两件事：

1. 在同一个机房部署了两台服务器，用SQL Server AlwaysOn做数据库高可用，实现秒级切换

2. 在异地机房（距离50公里）部署了第三台服务器，做异步复制，防止本地灾难

这套方案RTO控制在1分钟以内，RPO控制在30秒以内，成本大约是原服务器的1.5倍。

踩了个坑：当时他们以为AlwaysOn能自动切换，结果第一次测试发现，SQL Server的自动切换需要配置监听器，且对网络有特殊要求。后来找了专业团队调优，才真正跑通。这件事给我的教训是：高可用方案买回来只是第一步，真正跑起来才见真章。

选型和使用建议

基于这些年踩过的坑，我总结了几条实在的建议：

1. 别一上来就追“五个九”

先搞清楚自己的业务到底需要什么级别的可用性。一个内部OA系统，做到99.9%已经够用；一个支付核心，才需要99.999%。高可用是有代价的，每增加一个九，成本通常翻倍。

2. 网络环境是最大变量

很多高可用方案对网络延迟、丢包率极其敏感。我见过太多案例，方案选好了，设备买回来了，结果机房之间的专线延迟超标，导致数据同步一直报错。建议先做网络评估，再定方案。

3. 定期做切换演练

这个最重要也最容易忽视。很多企业高可用方案部署完就“躺平”了，真正出问题时才发现根本切不动。建议至少每季度做一次主备切换测试，最好在业务低谷期做，让运维团队真正动手操作。

4. 别忽视“人”的因素

高可用方案再牛，如果团队不会用、不敢用，就是摆设。我建议企业培养至少2个人能独立完成切换操作，并且把切换流程文档化、脚本化，减少人工出错的可能。

写在最后

回到开头那个金融IT朋友的问题：为什么做了双活，切换还是花了11分钟？

后来我帮他复盘发现，问题出在“脑裂”处理上——两台存储之间的心跳链路断了，两边都认为对方挂了，争抢资源，导致切换逻辑卡住。这种问题在双活架构中非常典型，解决思路通常是在心跳链路之外再加一条仲裁链路，或者引入第三方仲裁节点。

高可用这件事，说到底是“设计出来的冗余+演练出来的可靠”。没有一劳永逸的方案，只有不断迭代优化的过程。

如果你想深入了解具体的高可用架构设计或数据保护方案，热备云在数据库实时复制和CDP持续数据保护方面有不少实践经验，可以持续关注后续的技术分享。

一个提醒： 下次老板问你“系统是不是高可用了”，别只回答“是”，把RTO和RPO数值报给他，这才是真正的高可用度量。