有一次团队以为自己有备份，直到真的需要恢复。
备份文件确实存在，但恢复脚本很久没跑过；恢复出来的数据还要校验；应用连接怎么切，缓存怎么处理，消息积压怎么补，都没有完整演练。
那一刻才会明白：高可用不是文档里写了“有备份”“有主从”“有回滚”，而是故障发生时，这些东西真的能跑起来。
故障一定会发生。关键是影响范围有多大，持续多久，能不能收住。
可用性这个词听起来很大，真正出事时却很具体。
可能是一个第三方接口超时，可能是一台机器磁盘满了，可能是 Redis 抖了一下，也可能是某个发布把配置带错了。
用户不会区分你是数据库问题、缓存问题还是外部服务问题。他只会觉得系统刚才不能用了。
所以做可用性设计时，我更关心一件事：当某一块真的坏掉时，系统还能不能给用户一个可接受的结果，而不是把技术细节原样甩到页面上。
备份、主从、灰度、回滚，只有演练过、能执行，才算真的属于系统能力。
一、先消除明显单点
单点故障是高可用里最基础的问题。
一个服务只有一个实例，一台机器挂了服务就没了。数据库没有复制和备份，磁盘损坏可能就是灾难。网关、缓存、MQ 只有单节点，也都可能成为系统瓶颈。
消除单点的常见方式是多实例、主从、集群、负载均衡、自动故障转移。
但多实例不是简单多启动几个进程。服务要能被健康检查，要能自动摘除异常节点，要能处理重复请求，还要确保配置和版本一致。
高可用的第一步，是让系统不要因为一个点坏掉就整体停摆。
二、主从切换和容灾要演练
很多系统文档里都有主从切换，但真正出事时却切不过去。
原因很简单：平时没演练。
主从切换要考虑数据延迟、连接重连、写入口切换、应用配置刷新、缓存一致性、业务补偿。数据库切换成功，不等于业务完全恢复。
容灾备份也是一样。备份文件存在，不代表真的能恢复。要定期做恢复演练，确认备份可用、恢复时间可接受、恢复后数据完整。
未经演练的方案，只能算愿望。
很多高可用方案写在文档里很完整，真正出事时卡在这些细节上。
主从、实例、流量入口都要真的切得过去。
备份要能还原，恢复后数据还要能校验。
发布、配置、数据库变更，都要提前想好退路。
三、多活很强，但也很贵
多活听起来很美：多个机房同时提供服务，一个地方挂了，另一个地方继续扛。
但多活的复杂度很高。流量调度、数据同步、跨地域延迟、冲突处理、全局 ID、缓存一致性、故障切换，每一个都不简单。
不是所有系统都需要多活。
很多业务先做好同城高可用、异地灾备、核心链路容灾，已经能覆盖大部分风险。只有当业务规模、可用性要求和团队能力都到位时，再考虑更复杂的多活。
架构不是越高级越好，能稳定落地才重要。
四、灰度发布是在降低人为故障
很多线上故障不是机器坏了，而是新版本发布出了问题。
灰度发布的价值，是让新版本先影响一小部分流量。观察没问题后，再逐步扩大范围。如果发现异常，可以及时停止或回滚。
灰度一定要配合监控。只发 5% 流量但没有指标观察，也很难判断好坏。
常见观察指标包括错误率、接口耗时、核心业务转化、消息积压、数据库压力、日志异常。
灰度不是慢慢发版这么简单，它是带观察的发布。
五、回滚机制要比发布更熟
发布前最应该问的问题之一是：如果出问题，怎么回去？
代码能不能回滚，数据库变更能不能兼容，配置能不能恢复，缓存和消息会不会受影响，这些都要提前想。
特别是数据库变更，不能只写升级脚本，也要考虑兼容和回退。很多时候更稳的方式是先兼容旧字段和新字段，分阶段发布，而不是一次性切换。
真正成熟的发布体系，不是发布按钮多漂亮，而是回滚足够快。
六、可以带走的判断清单
- 单点要消除，但多实例也要配健康检查和摘除机制。
- 主从切换、备份恢复必须定期演练。
- 多活很贵，不要为了高级而高级。
- 灰度发布必须有观察指标。
- 数据库变更要考虑兼容和回退。
- 回滚流程要比发布流程更熟。
高可用不是让系统永远不失败，而是让失败可控。
本系列：
暂无评论