Motivation

目前分布式系统中的故障注入不够高效，主要是由于以下原因：

1. 许多故障是 partial failure。发生故障时，系统仍然在运行，只是系统的某个组件或服务受影响。
2. 故障的触发条件非常罕见。例如，某些故障只在特定时刻的特定网络故障下发生，并且只影响某个组件。
3. 成熟的分布式系统有比较好的容错性。许多混沌工程的实践随机注入故障，成熟的分布式系统可以容忍大部分故障，大量的注入是无效的，无法检测出新 bug。

故障注入的一大难点是“如何在无数中可能的故障注入点中找到最可能暴露 bug 的故障注入点”。论文认为，大多数的 bug 都发生在特殊情况下，因此故障注入框架也应该找到这些“特殊情况”，并在这些容易出错的地方注入故障。论文提出了一个新的故障注入框架 Legolas，Legolas 通过静态分析，找到程序的状态机，并在这些故障迁移时根据 bsrr（budgeted-state-round-robin）策略通过插入 hook 注入故障。

背景

Facebook 存储 2600 亿张照片，数据量超过 20 PB，且处于迅速增长中。Facebook 照片的工作流有以下特征：

• 单次写，多次读，很少删除。
• 长尾：用户会访问旧照片，这些照片不在 CDN 中。

Facebook 一开始直接将照片存储在文件系统中，并通过 NFS 导出，但存在以下问题：

背景

许多部署在 Kubernetes 等现代云平台上的系统使用 operator 替代人工部署，但这些 operator 通常没有完整的 e2e 测试，极大的影响了分布式系统的可靠性。

由于这些原因，人工编写完善的 e2e 测试基本上是不可行的：

1. 开发者很难在庞大的状态空间中构造良好的测试用例。人工编写的 e2e 测试通常从理想的初始状态触发，一步（只修改一次 spec）到达最终状态。这种测试无法覆盖足够多的状态转移。
2. operator 的开发者和被管理的系统的开发者往往不是一拨人，operator 开发者很难有足够的知识完善 e2e 测试。
3. operator 的协调循环（reconcile loop）涉及大量状态迁移，其中一些还涉及被管理系统的细节。

论文开发了一个自动生成 operator e2e 测试的框架 Acto，发现了大量流行的系统的 operator 中的 bug，其中某些 bug 甚至是由 Kubernetes 和 Go 语言运行时的 bug 导致的。

背景

LSM Tree 已经在 write-intensive database 中大量应用，但旧的实现存在以下问题：

1. 严重的读写放大（read/write amplification）
2. 没有充份利用 SSD 的内部并行性。

问题 1 尤为严重，LevelDB 的最坏情况下，写放大（从 L0 下沉至 L1）为 50，读放大（从 L0 读取所有 SST，再读穿到 L6）为 24×14 = 366。严重的读写放大不仅会导致 SSD 磨损，还会导致占用大量带宽。

背景

目前 SSD 的 iops 已经能够达到百万 iops，但 Linux block layer 无法达到 iops。Linux block layer 成为了高速存储设备的性能瓶颈，为了绕开龟速的 block layer，许多开发者使用 bypass 技术在用户态进行 IO。

背景和驱动

The Google file system 等存储系统为了高吞吐和高可用牺牲强一致性，本论文提出一种新复制协议链式复制（Chain Replication，简称 CR），在保持强一致性的前提下实现高吞吐和高可用。