2026-08-22
先给结论：高可用和容灾设计应先由业务确定RTO与RPO，再选择单机可恢复、主备、暖备或多节点架构。零停机、零数据丢失通常成本很高且未必可实现。对大多数企业网站，更实用的起点是消除单点、自动备份、异地副本、可重复部署、健康检查和定期演练。
本文更新时间：2026年8月22日。可用性目标越高，架构、测试、自动化和运维成本通常越高，应按业务影响分级，而不是所有系统都按最高标准建设。
| 指标 | 定义 | 示例问题 |
|---|---|---|
| RTO | 从中断到恢复服务可接受的最长时间 | 官网中断后，30分钟还是4小时内必须恢复？ |
| RPO | 故障时可接受的最大数据丢失时间窗口 | 最多能丢失5分钟订单，还是一天内容？ |
| 可用性目标 | 一段时间内服务成功提供功能的比例 | 哪些计划内维护和依赖故障也计入？ |
适合可接受较长恢复时间的展示站。重点是自动化重建脚本、异地备份和真实恢复演练。只有快照、没有文档和恢复测试，仍然存在很大风险。
异地保存数据和配置，灾难发生后创建资源并恢复。成本低，但RTO较长，DNS、证书、密钥和依赖准备会直接影响恢复速度。
备用环境持续运行较小容量，数据定期或持续同步，故障时扩容并切流。要防止错误数据同步到备用端，并定期验证切换流程。
负载均衡后运行多个无状态应用节点，数据库、缓存和文件也要有相应高可用策略。仅增加两台Web服务器并不能消除数据库、共享存储、DNS或证书单点。
任何一个硬依赖不可用，都可能让整体不可用。应标注依赖的恢复目标、负责人和替代方案，并避免把生产、备份和监控全部放在同一故障域或同一权限账户下。
基础计算可根据业务选择云服务器或物理裸机；数据保护参见3-2-1备份与恢复演练，迁移切换参见DNS、HTTPS与回滚清单。
不算。复制、备份、故障切换和业务验证是不同环节。误删除可能被复制，主从也可能位于同一故障域。
业务上越小通常越好，但成本和复杂度会显著上升。目标应由停机与数据丢失的实际影响决定，并通过演练证明能达到。
