左耳听风-故障处理的最佳实践
前言
线上故障是我们技术人员成长中必须要经历的事。从故障中我们可以吸取到很多教训，也能让我们学到很多书本上学不到的知识。坑踩多了，我们会变得越来越有经验，也就成为老司机了。
故障发生时
在故障发生时，最重要的是快速恢复故障。而快速恢复故障的前提是快速定位故障源。因为在很多分布式系统中，一旦发生故障就会出现“多米诺骨牌效应”。也就是说，系统会随着一个故障开始一点一点地波及到其它系统，而且这个过程可能会很快。一旦很多系统都在报警，要想快速定位到故障源就不是一件简单的事了。
故障源团队通常会有以下几种手段来恢复系统。
- 重启和限流。重启和限流主要解决的是可用性的问题，不是功能性的问题。重启还好说，但是限流这个事就需要相关的流控中间件了。
- 回滚操作。回滚操作一般来说是解决新代码的 bug，把代码回滚到之前的版本是快速的方式。
- 降级操作。并不是所有的代码变更都是能够回滚的，如果无法回滚，就需要降级功能了。也就是说，需要挂一个停止服务的故障公告，主要是不要把事态扩大。
- 紧急更新。紧急更新是常用的手段，这个需要强大的自动化系统，尤其是自动化测试和自动化发布系统。假如你要紧急更新 1000 多台服务器，没有一个强大的自动化发布系统是很难做到的。
也就是说，出现故障时，最重要的不是 debug 故障，而是尽可能地减少故障的影响范围，并尽可能快地修复问题。
故障前的准备工作
为了能够在面临故障时做得有条不紊，我们需要做一些前期的准备工作。这些准备工作做得越细，故障处理起来也就越有条理。我们知道，故障来临时，一切都会变得混乱。
以用户功能为索引的服务和资源的全视图。首先，我们需要一个系统来记录前端用户操作界面和后端服务，以及服务使用到的硬件资源之间的关联关系。是以用户端的功能来做索引的。然后，把后端的服务、服务的调用关系，以及服务使用到的资源都关联起来做成一个视图。
这个视图最好是由相应的自动化监控系统生成。有了这个资源图后，我们就可以很容易地找到处理故障的路径了。这就好像一张地图，如果没有地图，我们只能像个无头苍蝇一样乱试了。
为地图中的各个服务制定关键指标，以及一套运维流程和工具，包括应急方案。以用户功能为索引，为每个用户功能的服务都制定一个服务故障的检测、处理和恢复手册，以及相关的检测、查错或是恢复的运维工具。对于基础层和一些通用的中间件，也需要有相应的最佳实践的方法。
这就好像一个导航仪，能够告诉你怎么做。而没有导航仪，就没有章法，会导致混乱。
设定故障的等级。还要设定不同故障等级的处理方式。
制定故障等级，主要是为了确定该故障要牵扯进多大规模的人员来处理。故障级别越高，牵扯进来的人就越多，参与进来的管理层级别也就越高。就像亚马逊的全员上线 oncall 一样。这就好像是我们社会中常用的“红色警报”、“橙色警报”、“黄色警报”之类的，会触发不同的处理流程。
故障演练。故障是需要演练的。因为故障并不会时常发生，但我们又需要不断提升处理故障的能力，所以需要经常演练。要提升故障处理水平，最好的方式就是实践。见得多了，处理得多了，才能驾轻就熟。故障演练是一个非常好的实践。
灰度发布系统。要减少线上故障的影响范围，通过灰度发布系统来发布是一个很不错的方式。毕竟，我们在测试环境中很难模拟出线上环境的所有情况，所以，在生产线上进行灰度发布或是 A/B 测试是一件很好的事。
故障复盘过程
对于故障，复盘是一件非常重要的事情，因为我们的成长基本上就是从故障中总结各种经验教训，从而可以获得最大的提升。
COE(Correction of Errors)文档内容
- 故障处理的整个过程。就像一个 log 一样，需要详细地记录几点几分干了什么事，把故障从发生到解决的所有细节过程都记录下来。
- 故障原因分析。需要说明故障的原因和分析报告。
- Ask 5 Whys。需要反思并反问至少 5 个为什么，并为这些“为什么”找到答案。
- 故障后续整改计划。需要针对上述的“Ask 5 Whys”说明后续如何举一反三地从根本上解决所有的问题。
故障整改方法
- 优化故障获知和故障定位的时间
- 从故障发生到我们知道的时间是否可以优化得更短？
- 定位故障的时间是否可以更短？
- 有哪些地方可以做到自动化？
- 优化故障的处理方式
- 故障处理时的判断和章法是否科学，是否正确？
- 故障处理时的信息是否全透明？
- 故障处理时人员是否安排得当？
- 优化开发过程中的问题。
- Code Review 和测试中的问题和优化点。
- 软件架构和设计是否可以更好？
- 对于技术欠债或是相关的隐患问题是否被记录下来，是否有风险计划？
- 优化团队能力
- 如何提高团队的技术能力？
- 如何让团队有严谨的工程意识？
找到问题的本质
故障处理的原则
- 举一反三解决当下的故障。为自己赢得更多的时间。
- 简化复杂、不合理的技术架构、流程和组织。你不可能在一个复杂的环境下根本地解决问题。
- 全面改善和优化整个系统，包括组织。解决问题的根本方法是改善和调整整体结构。而只有简单优雅的东西才有被改善和优化的可能。