大型API网关（七）—— 紧急预案

上一篇，《大型API网关（六）——监控和预警》中，我们讲了如何发现问题，这一篇讲发现问题之后如何进行处理。

紧急预案

线上出现问题之后，第一时间进行处理的原则都应该是：如何将影响降到最低。
线上都鬼哭狼嚎。山崩地裂了，这边研发还在查日志，研究代码。这肯定不行。
这一篇讲的是紧急预案，而不是bug修复，关键时刻能力挽狂澜的那种。
通常来说，行之有效的紧急措施有三种：回滚、切流、降级。

回滚

当我们发现问题时，先看最近有没有上线，上线时间和故障时间是否能对的上。如果能对上，大概率是上线引起的。那么，第一要务就是回滚。
回滚的目的是使系统恢复到上线前的状态。一般来说，上线引起的问题都可以通过回滚解决。出了问题先回滚，回滚之后再查原因。
这就要求开发人员写代码时时刻谨记一点，所有的变更，都应该能回滚。
有一种情况是没办法回滚的，需要特别注意。
那就是数据污染。
当代码因为bug把数据库或者缓存上的数据也污染了，只回滚代码是没有用的。
缓存如果能从数据库中重建，且时间花费不是很长的话，可以考虑把有问题的缓存清掉，从数据库新建。
如果数据库中的数据也被污染了，可以考虑提取出问题时间段内的日志，然后执行反向操作。
不行的话，可以将数据库恢复到某个出问题之前的备份，但是这样就会存在数据丢失的问题了，也许后果更严重。。。
对于回滚搞不定或者花费很长时间的场景，需要通过降级来为问题修复争取时间。

降级

降级，本质上是一种绕过问题的手段，降级一定是有代价的，这种代价换来的是系统可以暂时绕过问题运行。
降级通常是十分有效且快速的问题处理方式，但是使用不当的话，可能会引发新的问题。
举个例子，比如网关的调用次数统计功能出现问题了，导致用户调用次数还没达到阈值就被拦截了。
这时，直接把拦截功能降级，就可以恢复用户的调用了。影响就是，降级期间，用户可以获得比阈值更多的调用次数。这种影响相比对用户拒流是可以接受的。
有时候，降级会引发其他问题，比如，网关的限流功能出问题了，此时如果进行降级，极有可能大量的流量进入后端服务，把后端服务干崩溃。如果不降级，那么用户的请求都会失败。
所以，降级只有在确定不会引起不可承受的后果时，才可以使用。

切流

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

1. 因为地域原因，新机房可能离用户比较远，导致用户RT稍有增长。
2. 新机房需要承载当前机房+故障机房的流量，整体负载会增大。

看起来切流这种手段比较稳妥，但是有两点需要注意：

1. 为了应对随时可能到来的切流动作，日常期间，每个机房的负载需要控制在40%以下，这可能有一点浪费资源。
2. 有一种情况是不可以切流的。
   比如，因为用户的某些特殊请求（该请求短时间查不出来）造成了服务崩溃。这种情况是不能切流的，否则切到哪个机房，哪个机房就完蛋。

泰山崩于前而色不变

最后需要说一下具体操作时可能会遇到的问题

紧急预案的执行不该有过多的阻拦

日常一些系统变更可能都会有审批流程，有的审批流程还挺长。
但是紧急预案的执行，务必保证审批流足够短，且审批流各个节点都不止一个人可以审批。否则流程上的某个人找不到（比如上飞机了）,一堆人只能干瞪眼。

紧急决策

紧急情况发生时，多找几个有经验的人一起处理。一个人在紧急情况下容易做出错误的判断和决定，这是不靠谱的，后果可能很严重。
所以，面对问题时，一定要淡定。综合考虑各种因素，尤其是预案执行后可能造成的后果。
也不能畏手畏脚，怕承担责任，啥都不敢干。
力挽狂澜的操作，都来自于平时的修炼。
为了能应对随时可能到来的紧急情况，平时一定要注意做两件事：

1. 尝试了解系统及上下游的各个细节，给紧急决策提供更多有用的信息。
2. 降级、切流需要演练，以防真的需要执行紧急预案时，预案本身是不可用的，这就尴尬大了。