故障预案

故障处理trouble shooting 是每个SRE要做的日常，特别是处在快速成长期的大型互联网系统、模块多、变更多、访问量大、用户环境复杂，不是这里出问题，就是在那里出问题，SRE就像是一个医生，需要在故障是协同研发发动各种手术区修复系统，常用的修复方法一遍提前梳理准备好，我们称之为预案

没有什么是“重启大法”解决不了的，如果重启依次不行，那就两次

“重启大法”，电脑修理秘术，同样对互联网服务也适用，经过实践许多问题确实可以通过重启暂时解决

重启也是有套路的，例如你是要一台一台重启还是瞬时批量？还有并不是所有服务都可以重启，重启可能会导致数据丢失（有状态，又有状态存储），比如若Redis集群重启导致数据丢失，可能会进一步造成MySQL雪崩，所以在重启之前应当也研发协调好，达成一致建议

重启是成本最低的预案

即回滚上一个版本
故障发生的原因很多都是变化，其中最常见的变化就是变更，从开发过程中来看，有大量的变更类故障，回滚就是应对变更类的故障

如果排查后，故障开始时间和变更时间基本一致，那就把理性分析放一边，先回滚吧

回滚相对于重启就重一些了，需要重新上线，也是最常用的故障预案，作为SRE一定要引导大家，不要上图想把原因在故障期间分析清楚了再操作。

回滚的目的是使系统恢复到上线前的状态。一般来说，上线引起的问题都可以通过回滚解决，出了问题先回滚，回滚之后再查原因。这就要求开发人员写代码的时候时刻谨记一点，所有的变更，都应该能回滚。

**数据污染。当代码因为bug把数据库或者缓存上的数据也污染了，只回滚代码是没有用的
缓存如果能从数据库当中重建，且花费时间不是很长，可以考虑把有问题的缓存清掉

大型系统，但凡故障一定会带来用户请求的拥堵，进而流量堆积、抖动，所以从这个角度看，扩容也要先做起来，很多时候堆机器是解决问题最直接的手段，不要讲这么多武德，每分每秒都很宝贵，理性分析等业务恢复了再说。

切流也是故障处理中最重要的一个招式、如果容灾、容量做的好，不用犹豫，切流是解决故障最快的方式。

切流最常见的是机器和运营商的切换，这个操作最大的挑战是容量，最大的风险是流量切换后的雪崩，切换前我们要经常考虑的是，B机房的流量是否能承载线上所有的流量，本来还有一半用户都能够正常使用，结果流量切了后，整个系统都雪崩了！！

所以说，要不要切、切哪些、切多少、怎么切是需要根据当时的客观情况，理性决策后再去执行，我们故障处理的目标是止损，是两害相权取其轻，不能因为想完美的想照顾每一个用户，反而把故障蔓延的更大。

切流是一种相对来说风险比较小且行之有效的应急预案
某个机房的网络出现问题了，那么这时候，就可以把原本调度到该机房的流量，切换到其他机房。切流可能会有两点影响：

看起来切流这种手段稳妥，但是有两点需要注意：
3. 为了应对随时可能到来的切流动作，日常期间，每个机房的负载都要控制在40%以下，这可能有一点浪费资源
4. 有一种情况是不可以切流
比如，某些用户请求如（短时间内查不出来）

断臂求生，弃车保帅

降级就是降低标准来服务，某些短时间修复不了的非核心功能，通过配置将其暂时，保障主干功能可以继续服务。

降级是一个十分有效且快速的问题处理方式，但是使用不当的话，可能会引发新的问题
如网关的调用次数统计功能出现问题了，导致用户调用次数还没有达到阈值就被拦截了。
这时，直接把拦截功能降级，就可以恢复用户的调用。影响就是，降级期间，用户可以获得比阈值更多的调用次数。这种影响相对于用户拒流是可以接受的。

但是这样也是存在风险的，如网关的限流功能出问题了，如果进行降级，极有可能大量流量进入后端服务，把后端服务干崩溃，那么用户请求都会失败。
所以，降级只有在确定不会引起不可承担的后果时，才可以使用

限流是一个辅助招式，可以和其他任何招式做排列组合
如果没有限流，可能会出现流量突增类故障很难处理，特别是数据库被打挂了，基本上服务一恢复，瞬间就再被打垮，只有通过限流，让流量慢慢进来，才能让系统逐渐恢复。

是否我一个人走，想听见你的挽留