Introduction

这篇文章系统性地提出并定义了云计算系统中的"灰色故障"(Gray Failure)问题, 认为它是当前云基础设施高可用性的一大障碍

gray failure

component failures whose manifestations are fairly subtle
and thus defy quick and definitive detection

系统某部分发生了轻微但持续的问题, 这些问题不易被传统故障检测机制发现, 但已经影响了应用层的性能和可用性;它不同于"失败即停" (fail-stop) 故障, 后者更易被监测和处理

Gray Failure的特征

Differential Observability (差异性可观测性)

对于 gray failure, 不同的组件对于同一个问题的感知是不同的,
尤其是一个实体受到消极影响但是其他实体感受不到这个影响

检测模块可能认为系统还是健康的, 但是实际上应用已经受损

Cloud Anomalies with Gray Failure

High redundancy hurts

一般的网络数据中心都会采用 high redundancy 设计从而达到很好的 fault tolerance,
例如 clos network 的设计, 如果发生了硬件设备下线,
其自身的 re-route 机制会很好的避免性能下降的问题,
但是相应的常常会受到来自性能下降的影响, 比如出现了丢包的情况, clos
并不会直接的更改 route 来适应这个性能下降, 这就是一个经典的 灰色故障

这个现象会导致 high redundanct -> not higher availability

Under the radar of failure detectors 系统"看不到"的故障

  • 案例: 某些 VM 出现严重网络连接问题, 但系统的远程监控组件无法检测到;
  • 原因: 监控依赖心跳, 由宿主机通过本地 RPC 转发心跳, 绕过了真正的网络路径;
  • 结果: 系统认为 VM 正常, 但用户层面已无法访问, 导致长时间未修复, 直到客户报错;
  • 结论: 心跳机制可能掩盖真实问题, 需要更细粒度的健康检测;

Recovery that kills, rather than heals 恢复机制引发雪崩故障

  • 案例: 某存储节点由于资源压力性能下降, 但报告模块出现 bug, 没上报问题;
  • 后果: 调度器不断向该节点分配写请求 → 节点崩溃重启 → 仍继续接收请求 → 形成死循环;
  • 连锁反应: 节点反复重启被判定为"不可恢复", 被下线, 其他节点压力加剧 → 系统性崩溃;
  • 结论: 灰色故障可能被错误恢复机制"误杀", 最终酿成灾难;

The blame game 多组件系统中的"甩锅"困境

  • 背景: IaaS 服务由计算, 存储, 网络等多个子系统协同提供 VM;
  • 问题: 当 VM 无法访问虚拟磁盘, 系统无法确定是哪个子系统出了问题;
  • 结果: 监控系统错误地将故障归咎于 VM 计算部分 → 排查困难, 各团队互相指责;
  • 结论: 在灰色故障面前, 跨组件协作和透明性极为关键, 否则排障效率极低;