读书笔记（SRE：Google运维解密）：第22章 处理连锁故障

• 连锁故障是由于正反馈循环（positivefeedback）导致的不断扩大规模的故障。

连锁故障可能由于整个系统的一小部分出现故障而引发，进而导致系统其他部分也出现故障。例如，某个服务的一个实例由于过载出现故障，导致其他实例负载升高，从而导致这些实例像多米诺骨牌一样一个一个全部出现故障。

 

• 连锁故障产生的原因

（a）服务器过载：直接由于服务器过载导致，或间接由于服务器过载引发的其他问题导致

例如，某个集群内部的过载可能会导致该服务实例崩溃；这时负载均衡器会将请求发送给其他集群，使那些集群的实例过载，从而造成整个服务过载故障。这些事件连锁发生的速度可能非常快（可能在分钟级范围），因为负载均衡器和任务编排系统的响应速度通常非常快。

（b）资源耗尽：某一种资源的耗尽可以导致高延迟、高错误率，或者低质量回复的发生。这些的确是在资源耗尽时应该出现的情况：在负载不断上升到过载时，服务器不可能一直保持完全正常。

不同种类的资源耗尽会对软件服务器产生不同的影响。

• CPU：如果CPU资源不足以应对请求负载，一般来说所有的请求都会变慢。这个场景会造成一系列的副作用：
  (1) 正在处理的（in-flight）请求数量上升：这会影响其他所有的资源，包括内存、活跃线程数（在每个请求一个线程的编程模型下）、文件描述符，和后端服务器的资源（该资源的耗尽可能会带来其他连锁问题）。
  (2) 队列过长：意味着延迟上升（因为所有请求都要排队一段时间），同时队列会使用更多的内存。
  (3) 线程卡住
  (4) CPU死锁或者请求卡住
  (5) RPC超时：服务器过载时，对客户端RPC的回复会变慢，最终会超过客户端所设置的超时时间。这会导致服务