"高可用"的谎言：你的 99.99% 是怎么算出来的
💡
原文中文，约8000字，阅读约需19分钟。
📝
内容提要
文章探讨了云服务的可用性（SLA）及其计算方式，指出实际故障往往是关联性的，导致冗余效果被高估。阿里云的案例显示，99.975%的可用性承诺在实际中难以兑现。强调快速恢复（MTTR）比追求更多的“9”更为重要，并提倡通过演练提高系统的真实可用性。
🎯
关键要点
- 99.99%的可用性计算假设故障是独立的，但实际中重大故障往往是关联性的。
- 阿里云的案例显示，99.975%的可用性承诺在实际中难以兑现，12小时的故障超出承诺的109倍。
- SLA合同中的可用性定义与用户体验存在巨大差距，很多情况下降级不算停机。
- 冗余的有效性受到关联故障的严重影响，多个组件共享基础设施时，故障可能同时发生。
- 级联故障会导致系统崩溃，负载转移使得其他组件过载，造成更大范围的停机。
- 快速恢复（MTTR）比追求更多的“9”更为重要，优化MTTR能有效减少故障影响。
- 高可用性应通过演练来实现，而不是仅仅依赖理论计算，演练能提高系统的真实可用性。
❓
延伸问答
云服务的可用性是如何计算的？
云服务的可用性通常通过公式 A = MTTF / (MTTF + MTTR) 计算，假设故障是独立的。
阿里云的可用性承诺在实际中表现如何？
阿里云承诺的99.975%可用性在实际中难以兑现，曾发生超过12小时的故障，超出承诺的109倍。
什么是级联故障，它对系统可用性有什么影响？
级联故障是指一个组件故障导致负载转移到其他组件，可能引发连锁崩溃，显著降低系统可用性。
为什么快速恢复比追求更高的可用性更重要？
快速恢复（MTTR）能有效减少故障影响，而追求更多的“9”并不能保证实际可用性。
SLA合同中的可用性定义与用户体验有什么差距？
SLA中的可用性定义可能不包括降级和计划维护等情况，导致用户体验与合同承诺存在巨大差距。
如何通过演练提高系统的真实可用性？
通过定期进行全链路故障演练，可以发现潜在问题并提高系统的真实可用性，而不仅仅依赖理论计算。
➡️
