高度可扩展基础设施的里氏可靠性等级


任何运营高度可扩展基础设施的人都会知道,他们必须遵守一条格言:假设一切都失败了

这可能看起来是一种相当病态的基础设施设计和运营方式。当您从100%正常运行时间的目标转向站点可靠性工程师(SRE)方法时,这一点就变得显而易见了。

我所说的方法转变的意思是,我们改变了架构师的经典假设,即我们可以为完全可靠的设计进行设计。SRE方法是依赖于应用程序基础架构的每一层发生故障和持续恢复的能力。

由于设计原因,横向扩展失败

我曾经读过一篇文章Kelly Sommers关于她如何以这样的规模操作数据库基础架构,即由于负载和其他运营影响,任何给定时间都有大约10%的节点发生故障。

任何为大规模应用程序设计系统的人都会明白这一点。更重要的是,他们将接受它作为交易的一部分。传统IT架构师的诀窍是适应这种内置到服务中的失败的新概念。

里氏规模成本挑战

您可能对Richter Scale它是用来测量地震事件的。里氏震级的数学有趣之处在于,震级上的每个点实际上都是前一点的倍增,而不是线性上升1。

例如,6.0TJ等于63太焦耳,7.0等于2拍焦耳,而5.0等于2太焦耳。这一点很重要的原因是,它与构建高度可用的IT基础设施的成本(工作和资本)相对成比例。

运营99.999%可用性解决方案的成本可能是99.99%替代方案的两倍多。随着我们分别达到99.9%和99%,这些成本和运营挑战会降低得更多。那么,我们如何改变我们的方式来降低成本呢?

因设计而失败

我们并不是建议您可以轻松地让10%的基础架构始终出现故障或陷入困境,但是如果您考虑一下设计和部署应用程序以实现99%的子组件可用性所需的条件,您就会开始获得这样的优势,即拥有一个可以在整个结构中承受故障的系统。

这是实践中的一个转变。这就是我们开始更像云本地架构思考的地方,它必须假设松散耦合的组件已经就位,弹性是在横向扩展方法中构建的。

虽然对我们来说,前期成本现在似乎更高,但这是真正的技术性债务削减。我们今天正在以快速的速度获得技术债务,因为我们经常看不到后退一步和攻击作为SRE的一个问题的价值。

最后,与现在跟踪技术债务的成本相比,你为这些额外的9支付了很多倍。这就是里氏震级变得相当可怕的地方,它提醒人们在错误的层上设计弹性的真正成本。