0. Introduce

Fail-stop无论在单机系统还是分布式系统中，大家都会有清晰的认识和成熟的解决方案，例如副本offline，在分布式系统中一般都能够很快的发现并且failover出去，对于可用性、可靠性和性能的影响都是可预期和可控的。技术上也相对成熟，无论是传统的热备技术、还是基于一致性复制协议（例如Raft），都能够很好的应对。在分布式系统中，failure是常态。而failure处理难易程度，关键是看其是否容易被确认，Fail-stop就是一类死个全尸的问题，非常容易识别，所以处理起来也更容易对症下药。而相反，系统中还有一种让人头疼的failure，它会让系统处于一个半死不活的状态，难于识别，自然也就不好处理，它就是Fail-slow：

fail-slow, that is still running and functional but in a degraded mode, slower than its expected performance

常见的Fail-slow，大家肯定都遇到过，就我个人而言，有遇到过慢盘，raid卡firmware bug造成disk卡死几十秒，数据中心电源问题造成相应的节点性能急剧下降、软件部分死锁造成性能远远低于预期等等，这些问题多半不好定位。今天给大家分享Fast 2018一篇对Fail-slow的研究[1]，他们收集了 12 institutions的101 reports，进行了详细的分析，总结了造成Fail-slow常见原因，相信可以给今后分析、定位和解决Fail-slow问题提供参考，至少可以开阔思路。

1. Findings & Suggestions

Fail-slow的发现和处理建议如下表格

2. Root Causes

造成Fail-slow的原因很多，总体来说分为如下Internal和External，如下是各类成因的一个统计结果。

文献[1]分门别量的介绍了大量的造成Fail-slow的例子，强烈建议完整的读一遍，为今后解决类似问题开阔思路也非常不错。

3. Fail-Slow Detection

那如何识别Fail-slow，相关团队在2019 ATC的另一篇文章中，提出了一个IASO[2]框架，在生产环境39,000节点规模下，发现了大量的Fail-slow事故，且假阳性的概率表现良好，只有3.7%。相应的方法比较简单，感兴趣的可以参考文献[2]，这里就不在赘述了。

Notes

限于作者水平，难免在理解和描述上有疏漏或者错误的地方，欢迎共同交流；部分参考已经在正文和参考文献列表中注明，但仍有可能有疏漏的地方，有任何侵权或者不明确的地方，欢迎指出，必定及时更正或者删除；文章供于学习交流，转载注明出处

参考文献

[1]. Gunawi H S, Suminto R O, Sears R, et al. Fail-slow at scale: Evidence of hardware performance faults in large production systems[J]. ACM Transactions on Storage (TOS), 2018, 14(3): 23.

[2]. Panda B, Srinivasan D, Ke H, et al. {IASO}: A Fail-Slow Detection and Mitigation Framework for Distributed Storage Services[C]//2019 {USENIX} Annual Technical Conference ({USENIX}{ATC} 19). 2019: 47-62.