早上打开手机，点个外卖，发现App卡在加载页。刷新几次，还是进不去。你皱了皱眉，心想：这平台怎么老出问题？其实，背后可能是系统出了故障，而容灾机制没跟上。
为什么容灾不再是“可选项”
现在的应用大多跑在云上，用户不关心你在用哪家云服务商，他们只在乎能不能下单、能不能看到更新。一旦服务中断，损失的不只是订单，还有信任。比如一家在线教育平台，在上课高峰期宕机十分钟，上千学生进不了课堂，家长投诉电话直接打爆客服中心。
云原生环境动态性强，容器随时起停，微服务之间调用频繁。传统的备份加主备切换那套，在这里有点跟不上节奏。得用更灵活的方式，把“抗打击”能力编进系统基因里。
多区域部署：别把鸡蛋放在一个篮子里
假设你的服务只部署在一个城市的数据中心，结果当地光纤被施工挖断，整个服务就瘫了。云原生容灾的第一步，就是跨可用区甚至跨地域部署。
比如使用 Kubernetes 集群时，可以把节点分散在不同区域。通过 Service Mesh 控制流量，在检测到某个区域响应变慢时，自动把请求切到健康的区域。
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: resilient-service-rule
spec:
host: order-service
trafficPolicy:
outlierDetection:
consecutive5xxErrors: 3
interval: 30s
baseEjectionTime: 5m这段 Istio 配置能让网关自动隔离出问题的实例，避免雪崩。
数据同步不是越快越好
很多人觉得数据要实时同步才安全，但现实是，强一致性会拖慢性能。在电商大促时，每秒几万订单进来，如果每个操作都要等异地数据库确认，延迟高到没法用。
更实用的做法是最终一致性。比如用户下单后，本地库先记一笔，再异步同步到备用区域。哪怕主区全挂了，备用区也能在几分钟内接替，虽然可能丢一两笔单，但整体业务不断。
故障演练要像消防演习一样常态化
有家公司做了全套容灾设计，半年没出事，结果某天真实故障来了，切换脚本一跑，发现权限不对，流程卡住。原本半小时能恢复的事，拖了四个小时。
定期搞点“破坏”很有必要。比如每周随机杀掉一个生产环境的 Pod，看系统能不能自愈；或者模拟整个区域断网，测试流量切换是否顺畅。这些操作现在可以通过 Chaos Engineering 工具自动化完成。
<?xml version="1.0" encoding="UTF-8"?>
<chaosExperiment>
<name>kill-pod-in-region-east</name>
<target>shipping-service-.*</target>
<action>delete</action>
<scheduled>weekly</scheduled>
</chaosExperiment>监控和告警要看得懂人话
告警邮件半夜弹出来：“Pod restart count exceeded threshold”。你睡眼惺忪地爬起来查，结果发现只是某个临时任务失败重试了三次，并无大碍。
好的监控不该堆数字，而要讲清楚“哪里不行了，影响了什么”。比如改成：“订单服务在华东区响应超时，过去5分钟失败率升至18%，影响用户提交支付”——这才叫有用信息。
结合 Prometheus 和 Alertmanager，可以设置分层告警策略。小问题发钉钉群，大故障直接打电话，避免重要消息被淹没。