【故障处理】最佳实践流程

总结陈皓老师的故障处理的文章，侵删。

应对故障

准备工作

为了能够在面临故障时做得有条不紊，我们需要做一些前期的准备工作。这些准备工作做得越细，那么故障处理起来也就越有条理。

• （地图）以用户功能为索引的服务和资源的全视图
• （导航仪）为地图中的各个服务制订关键指标，以及一套运维流程和工具，包括应急方案
• 设定故障的等级
• 故障演练
• 灰度发布系统

故障发生时

在故障发生时，最重要的是快速恢复故障。而快速恢复故障的前提是快速定位故障源。

尽可能地减少故障的影响范围

• 重启和限流。
  重启和限流主要解决的是可用性的问题，不是功能性的问题。重启还好说，但是限流这个事就需要相关的流控中间件了。
• 回滚操作。
  回滚操作一般来说是解决新代码的 bug，把代码回滚到之前的版本是快速的方式。
• 降级操作。
  并不是所有的代码变更都是能够被回滚的，如果无法回滚，就需要降级功能了。也就是说，需要挂一个停止服务的故障公告，主要是不要把事态扩大。
• 紧急更新
  紧急更新是常用的手段，这个需要强大的自动化系统，尤其是自动化测试和自动化发布系统。假如你要紧急更新 1000 多台服务器，没有一个强大的自动化发布系统是很难做到的。

尽可能快地修复问题

故障改进

故障复盘过程

• 故障处理的整个过程。
  就像一个 log 一样，需要详细地记录几点几分干了什么事，把故障从发生到解决的所有细节过程都记录下来。
• 故障原因分析。
  需要说明故障的原因和分析报告。
• Ask 5 Whys。
  需要反思并反问至少 5 个为什么，并为这些“为什么”找到答案。
• 故障后续整改计划。
  需要针对上述的“Ask 5 Whys”说明后续如何举一反三地从根本上解决所有的问题。

故障整改方法

• 第一，优化故障获知和故障定位的时间。
  从故障发生到我们知道的时间是否可以优化得更短？
  定位故障的时间是否可以更短？
  有哪些地方可以做到自动化？
• 第二，优化故障的处理方式。
  故障处理时的判断和章法是否科学，是否正确？
  故障处理时的信息是否全透明？
  故障处理时人员是否安排得当？
• 第三，优化开发过程中的问题。
  Code Review 和测试中的问题和优化点。
  软件架构和设计是否可以更好？
  对于技术欠债或是相关的隐患问题是否被记录下来，是否有风险计划？
• 第四，优化团队能力。
  如何提高团队的技术能力？
  如何让团队有严谨的工程意识？

根除问题的本质

• 举一反三解决当下的故障。为自己赢得更多的时间。
• 简化复杂、不合理的技术架构、流程和组织。你不可能在一个复杂的环境下根本地解决问题。
• 全面改善和优化整个系统，包括组织。解决问题的根本方法是改善和调整整体结构。而只有简单优雅的东西才有被改善和优化的可能。