可靠性架构 · 栏目说明

可靠性不是监控出来的，是设计出来的。监控只能让你更早发现问题，架构才决定系统在出问题时能不能扛住。

这个栏目讨论的是架构层面的可靠性决策。

覆盖主题

• 冗余与隔离：多副本、多可用区、故障域划分，以及隔离到什么粒度才够。
• 容量与排队：容量模型、排队论的实际用法、弹性伸缩的边界。
• 降级与熔断：降级预案怎么设计，熔断阈值怎么定，避免降级本身成为故障。
• 多活与数据一致性：多活的真实成本，数据同步延迟下的取舍。
• 发布与变更：灰度、蓝绿、金丝雀、特性开关，以及变更管控的组织前提。
• 混沌工程：从故障注入到持续验证，怎么做到不制造新风险。

文章的写法

每篇尽量包含四部分：适用场景、备选方案、关键取舍、落地清单。

不写「最佳实践」这种没有前提的结论。可靠性方案强依赖业务目标、成本约束和团队能力，脱离约束谈架构没有意义。

判断标准

评估一个可靠性设计，主要看四件事：

1. 可用性目标是否清晰，并且能被度量。
2. 故障域是否划清楚，单点是否真的被消除。
3. 恢复时间是否经过演练验证，而不是纸面承诺。
4. 成本是否可接受，包括机器成本、人力和复杂度成本。

适合谁看

架构师、技术负责人、平台团队，以及正在做多活、容灾和容量规划的技术管理者。