线上故障是我们技术人员成长中必须要经历的事。从故障中我们可以吸取到很多教训，也能让我们学到很多书本上学不到的知识。坑踩多了，我们会变得越来越有经验，也就成为老司机了。今天听了 左耳朵耗子 --《左耳听风》 中的故障处理最佳实践篇 ，在经历过多次线上故障后，觉得 皓哥这篇确实 干货满满，记录下来共勉。

生产环境故障总共可分为三个阶段，故障发生前，故障发生时，故障发生后。

故障发生前

为了能够在故障发生时，有条不紊的处理线上故障，做到事乱而人不乱的目的。可以提前做以下准备。

• 以用户功能为索引的服务和资源的全视图。

  • 前端
    • 用户操作
  • 后台服务
    • 服务与服务之间的调用关系
  • 中间件
    • 服务涉及到的中间件
  • 硬件
    • 服务以及中间件 所涉及到的硬件资源
  • 网络
    • 整体部署网络拓扑图

• 为地图中的各个服务制定关键指标，以及一套运维流程和工具，包括应急方案。

  • 服务指标
    • 以用户功能为索引，为每个用户功能的服务都制定一个服务故障的检测、处理和恢复手册，以及相关的检测、查错或是恢复的运维工具。
  • 中间件指标
    • 检查其健康运行状态
      • 硬件指标
      • 链接数等
  • 应急方案
    • 常见故障处理
    • 服务不可用处理
    • 服务回滚处理

• 设定故障的等级:制定故障等级，主要是为了确定该故障要牵扯进多大规模的人员来处理。故障级别越高，牵扯进来的人就越多，参与进来的管理层级别也就越高。

  • 亚马逊定级
    • 全站不可用
    • 某功能不可用，且无替代方案
    • 某功能不可用，但有替代方案
    • 非功能性故障，或是用户不关心的故障
  • 其他定级
    • 通用型：包含受影响用户数、受影响商家数、客诉增量、资金损失等通用指标。通用型故障场景在业务线型故障场景未覆盖情况下兜底。
    • 业务型：基于用户视角共同定义。

• 故障演练:故障是需要演练的。因为故障并不会时常发生，但我们又需要不断提升处理故障的能力，所以需要经常演练。

  • 比如:
    • Chaos Monkey
    • 混沌工程

• 灰度发布/ AB Test

故障发生时

在故障发生时，最重要的是快速恢复故障。而快速恢复故障的前提是快速定位故障源。因为在很多分布式系统中，一旦发生故障就会出现“多米诺骨牌效应”。也就是说，系统会随着一个故障开始一点一点地波及到其它系统，而且这个过程可能会很快。一旦很多系统都在报警，要想快速定位到故障源就不是一件简单的事了。

这里 郝哥建议使用亚马逊故障处理方式，每个开发团队至少都会有一位 oncall 的工程师。在 oncall 的时候，工程师要专心处理线上故障，轮换周期为每人一周。自查自己的服务，如果自己的服务没有问题，那么就可以在旁边待命（standby），以备在需要时进行配合。

故障源团队通常会有以下几种手段来恢复系统。

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

在处理故障中，一定要做好服务版本控制，便于回滚，同时也建议与 运维人员一起整理或者更新应急故障手册。

故障发生后

在故障排除后，如何做故障复盘及整改优化则更为重要。

无论是哪个公司 相对的复盘点如下:

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

复盘最终的目的就是要找到以下几点优化方案

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

在以上几点上，优化团队能力是最难的，因为你面对的不仅仅是工程代码，面对的还是自己的团队人员，个人认为 如果是纯技术选手，应该整理优化好一系列的测试，发布流程，在流程中 让团队养成 严谨的工程意识，而团队的技术能力，其实这就像我们以前上学，学生有好有坏，老师把能教的都教给了我们，但是有的同学就学习很好，而有的同学就跟不上。我觉得与其提高团队的技术能力，不如从源头把控好员工是否符合团队要求。