写故障预案是运维日常工作的一项，但是如何做好故障预案往往没有那么简单。为什么这么说？因为实践证明，往往都是事故出现束手无策的时候才明白当初很多东西没有做好，以至于服务保证几个9的SLA，就如臆想的一般不真实。
故障就如一个完全控制不了的魔鬼，出现的面貌和预期中的不一样，故障的发生也很灵验，比如你正好没有做这一项，心想出现的概率极低，往往很快就会发生。
那么应该如何做故障预案呢？做故障预案的时候需要的思维模式是以这个故障发生为结果，而不要想，怎么会发生这个故障。
首先，分级的思想，先从最坏的角度考虑，如何这个服务真的挂的，该如何处置？影响面有多广？然后就从这个角度规避，如果服务是影响全局的，那么一定把服务都挂了的情况考虑在内，然后从不同版本灰度，及时回滚，重新部署这些脚本都写好，依赖的机房，是否机房是单点。除了最坏的，那么如果部分故障影响面有多大，如何做好部分故障之后的切换。
其次，考虑依赖，这个服务依赖的所有组件想到处理方式，不要理所当然的认为依赖的服务是百分之百可用的，比如你恢复代码很关键的一点是去代码仓库拉取，那么代码仓库一定百分之百可用吗？当它故障以后要怎么处理呢？
再次，演练并且记录结果，这个看似很简单，但是多少故障就败在了演练不充分。实践中真的有人用心去演练，并且把结果记录的并不是全部，而且很多人只把这个作为上司分给自己的一项日常工作，并没有从服务角度去好好考虑为什么要这么做。
最后，服务监控告警需要定期检查，是否有些点需要更新，而不是服务配好告警以后就不再看了。监控同样有告警，要不连监控都没有正常跑了，那么发生故障就会变得很被动。而且丢失故障时候的关键信息。
故障预案需要极大的耐心，梳理链路中的每一个故障点，并且加以验证，保证这个点出问题的时候，还能正常进行。
同时也需要从另外一个角度看问题，就像从测试的角度看，抱着找出问题的心态。经历一次次故障以后，最大的感触就是，刷新了很多认知，你以为习以为常的东西，真有一天就故障了，仿佛做梦一般。这个时候，就是真正考验我们的时候了。
最后一点，如果不幸故障真的发生了，一般都会有故障报告来记录此次事件，那么该修复的修复以后是否会有相应的演练，是否有专人负责监督，这个往往会被忽视。同时，一般故障暴露出来的都是多种层次的问题，就像冰冻三尺非一日之寒，是否需要根治，需要极大的耐心和毅力。
运维工作就像一场修行，除了付出精力体力，早起熬夜，更要改变自己很多习惯，思维，耐心，意志。
记与 6月2号 aws北京区域故障有感
