"高可用"的谎言：你的 99.99% 是怎么算出来的
原文中文，约8000字，阅读约需19分钟。
📝
内容提要
文章探讨了云服务的可用性（SLA）及其计算方式，指出实际故障往往是关联性的，导致冗余效果被高估。阿里云的案例显示，99.975%的可用性承诺在实际中难以兑现。强调快速恢复（MTTR）比追求更多的“9”更为重要，并提倡通过演练提高系统的真实可用性。
🔎
延伸解读
可用性计算的误区
文章指出，云服务的可用性计算往往假设故障是独立的，但实际情况中，重大故障通常是关联性的。这意味着，多个组件同时故障的风险被严重低估，用户在选择云服务时应关注这一点，以避免对可用性承诺的误解。
SLA条款的复杂性
SLA合同中的可用性定义与用户实际体验存在显著差距。许多情况下，服务降级并不算停机，这可能导致用户在遭遇服务问题时无法获得合理的赔偿。因此，用户在签署合同时需仔细审查条款，确保理解其中的细节。
快速恢复的重要性
文章强调，快速恢复（MTTR）比追求更高的可用性数字更为重要。优化MTTR可以有效减少故障对业务的影响，企业应将更多资源投入到故障恢复演练和应急响应机制的建设中，以提升整体系统的韧性。
❓
Q&A
云服务的可用性是如何计算的？
云服务的可用性通常通过公式 A = MTTF / (MTTF + MTTR) 计算，假设故障是独立的。
阿里云的可用性承诺在实际中表现如何？
阿里云承诺的99.975%可用性在实际中难以兑现，曾发生超过12小时的故障，超出承诺的109倍。
什么是级联故障，它对系统可用性有什么影响？
级联故障是指一个组件故障导致负载转移到其他组件，可能引发连锁崩溃，显著降低系统可用性。
为什么快速恢复比追求更高的可用性更重要？
快速恢复（MTTR）能有效减少故障影响，而追求更多的“9”并不能保证实际可用性。
SLA合同中的可用性定义与用户体验有什么差距？
SLA中的可用性定义可能不包括降级和计划维护等情况，导致用户体验与合同承诺存在巨大差距。
如何通过演练提高系统的真实可用性？
通过定期进行全链路故障演练，可以发现潜在问题并提高系统的真实可用性，而不仅仅依赖理论计算。
🏷️
