高可用：企业灾备避坑指南

作者：赵雯雯

高可用不是玄学，是钱、命、面子

昨晚十一点多，我一个老同事打来电话，语气慌得不行：“系统挂了，银行那边对不上账，领导说明早之前必须恢复。”

我一边远程帮他看日志，一边心里叹气。这场景我太熟了。干运维十几年，我见过太多系统在凌晨两点悄悄咽气，然后一群人穿着拖鞋睡衣冲回机房抢修。每次事后复盘，结论都绕不开三个字：高可用。

可问题来了，很多公司嘴上喊着高可用，实际上连高可用到底是什么、要解决什么问题，都没整明白。

高可用，到底在防什么？

说白了，高可用就干一件事：别让单点故障变成业务灾难。

啥叫单点故障？就是你系统里任何一个组件挂了，整个业务就瘫了。比如：

我之前遇到过一个小公司，把核心业务全压在一台服务器上，连个备份都没有。结果硬盘坏了，数据丢了三天，客户资料全没了。老板气得差点把运维开除，可开除有什么用？损失已经造成了。

高可用要解决的核心问题，就两个字：冗余。关键组件不搞单点，数据不搞单份，链路不搞一条。哪个挂了，另一个立刻顶上，用户甚至感知不到。

高可用不是有钱人的游戏

说实话，我见过很多老板一听高可用，第一反应是“那得花多少钱”。然后就不了了之了。

可问题是，一次宕机的代价，往往比搭一套高可用架构贵得多。

Gartner有个数据我一直记着：企业IT系统每小时宕机的平均成本，高达30万美元。这还不算声誉损失和客户流失。你想想，一个电商平台，大促当天挂了半小时，GMV损失多少？一个SaaS服务，早上九点客户全登不上去，客服电话被打爆，运维被骂成孙子。

而且，等保2.0里明确要求，三级以上系统必须具备高可用能力。你不做，过不了等保，过不了等保就接不了政府项目，接不了项目就没饭吃。

所以高可用不是成本，是保险。你买车还知道买交强险呢，系统这么重要的东西，怎么就不舍得买个“保险”？

高可用怎么落地？先记住这三条

我不是卖课的，也不整那些虚头巴脑的框架。就按我踩坑踩出来的经验，给你说几个最实在的。

第一条：数据库一定要做主从或集群。

数据库是绝大多数系统的命根子。单机数据库，就是一颗定时炸弹。你至少要做一主一从，主库挂了，从库立刻顶上。别跟我说“我们数据库很稳定”，这话我听过八百遍，说这话的人，后来都半夜给我打过电话。

这里有个坑：主从复制不是配好就完事了。你得定期演练切换，确认从库的数据是最新的，确认切换脚本真的能跑通。我见过有人配了主从，结果从库同步早就断了，主库一挂，从库数据差了好几天，那叫一个酸爽。

第二条：应用层要无状态化，多节点部署。

别把状态存在应用进程里。登录态放Redis，文件放对象存储，应用节点随便杀随便挂。然后前面挂个负载均衡，流量分发到多个节点。挂掉一个，负载均衡自动把流量切到其他节点，用户完全无感。

我之前有个客户，应用部署了三台，但登录态存在本地内存里。结果负载均衡一转发，用户就掉线，被投诉到崩溃。后来改成Redis存session，问题才解决。这就是典型的“有状态”应用带来的麻烦。

第三条：定期做故障演练，别等到真出事才手忙脚乱。

这个我重点说，因为我踩过坑。之前有个客户，做了主从，做了负载均衡，自认为高枕无忧了。结果真出事的时候——主库磁盘满了，从库没接管。为什么？因为主从切换的脚本从来没跑过，权限配置有问题，切不过去。

后来我帮他们做了个故障演练：每个月挑个周末，人为杀掉主库进程，看系统能不能自动切换。第一次演练，失败了。第二次，又失败了。第三次才成功。从那以后，他们每个月都坚持演练，再也没出过大岔子。

高可用的最高境界：用户无感知

你可能会问，高可用做到什么程度才算合格？

我的答案是：用户无感知。 你系统挂了，用户不知道，还在正常用，这就是高可用。你要是系统挂了，用户全在微博上骂你，那就算你最后恢复了，也是失败。

我之前用过中科热备的方案，帮客户做异地容灾，主中心挂了，备中心分钟级拉起，用户完全没感觉。当然，这不是广告，只是我个人的经验分享——做容灾这件事，一定要提前做，别等火烧眉毛了才想起来。

最后说句掏心窝子的话：高可用不是运维一个人的事，是公司的战略问题。老板不重视，运维再努力也白搭。但反过来，运维要是连高可用是什么都讲不清楚，也怪不得老板不批预算。

希望下次凌晨两点，你不会被电话吵醒。