除系统最小能状态之外的动态系统的稳定状态是稳定的状态。
- 维基百科
分布式系统通常非常失败，不可预测。他们是一个令人头疼和失眠的夜晚的原因，这是一个太多工程师。尽管要了解故障，但我们必须包含和/或阻止所有工具和“最佳实践”的努力。
今天我想谈谈可能在几乎健康的系统上发生的失败，没有被感知的主要错误或设计缺陷。我们在我们的Hotos'21纸中描述了这种类型的故障。这项工作与Nathan Bronson，Abutalib Aghayev和Timothy Buu合作。它主要基于Nathan的观察和经验。
那么“健康”系统如何失败？当然，需要发生某些东西，以便发生故障。我们称之为触发器。很多东西都可以充当触发器（GC，网络挖掘，软件推动，配置更改，负载尖峰等）。在我们的多租户不可靠的系统中，触发器是不可能的。
触发器导致积压或错误，使系统暂时不太开心。然而，在某些情况下，它们导致系统螺旋入深渊，几乎停止了任何有用的工作或净化。删除触发时（由工程师瞬态，或删除），系统本身不会恢复。所以我们最终在奇怪的情况下造成了造成失败的情况不再存在，所有系统的组件似乎都正常运行，所有服务器/节点都已启动，代码正在工作，但没有什么用实际上已经完成并且净化了仍然可以忽略不计。
我们称之为亚稳态故障，或者我们说系统已输入亚稳态故障状态。稳定性故障背后的罪魁祸首是即使在删除初始触发后，即使在删除初始触发之后，阻止系统留下糟糕/失败状态的持续效果。
Warning: Can only detect less than 5000 characters
在论文中，我们讨论了一些其他假设和轶事情景，这些情况有点复杂。但问题不是任何手段的轶事，因为存在相当多的故障情况，这肯定看起来很像常规失败“在野外”：
谷歌应用引擎事件＃19007。触发：配置更改。维持效果：级联负荷放大。修复：减少流量级别。
亚马逊SimpledB服务中断。触发：电源丢失崩溃多个服务器。维持效果：由于超时引起的负载放大。修复：超时策略＆amp更改;引入额外的容量。
由于提示压力+ MVS，Cassandra超载。触发：滚动重启。持续效果：很少有节点无法赶上暗示的交换，防止它们完全加入，导致系统产生更多提示。修复：策略变更 - 禁用暗示的切换。
由于影响真实系统的亚稳定性失败，我们需要更多地了解开发更好的应对和预防策略所涉及的问题和流程。我们经验中的经常性模式是改变改善系统的常见情况行为往往会增加维持效果的强度。快速路径，高速缓存，重试，故障转移，负载平衡和自动播放都使得失败状态更低的资源效率相对于正常状态，这使得反馈回路更糟。谨防非常高的缓存命中率！
在大型场地中的中断中，亚稳失败是由于持续效应的强度取决于规模。例如，如果反馈循环需要重载网络结构，那么小规模的压力测试将永远不会触发它。持续效果也可能作为传染性的手段，以便问题跨机器或碎片传播。这意味着即使在超刻度分布式系统中，新颖的常规故障的第一次出现也可能是主要的中断。
处理稳定性的目前的方法往往缺乏对问题的充分理解及其原因。例如，工程师经常专注于导致失败的触发器，并且无法实现负责失败量表的复杂正反馈循环。修复触发器是一种临时解决方案，可能只能将系统推入亚稳弱势区域，并使下一个崩溃更严重。
不幸的是，困难的失败和反馈循环复制，因为许多问题只表现为规模。这使得这使得完全了解失败并开发用于处理它们的有效技术。此外，预测失败的可能性也很困难。例如，人们可以寻找意外的性能变化，并尝试将它们与系统中发生的其他事情相关联，以了解潜在的未来触发器，但这仍然没有给出可能发生故障时的完全预测力。我们的预测能力和避免稳定性故障的能力也将直接转化为效率提升，因为它将让我们操作更靠近其自然性能限制的系统。
我认为这是一个令人兴奋的研究领域。由于该行业使得更大更大的系统并将它们推动尽可能便宜，我们需要了解对这些关键系统如何在规模失败的情况下，我们可以继续提高可靠性。