线上事故处理方案
故障前准备工作
为了能够在面临故障时做得有条不紊，我们需要做一些前期的准备工作。这些准备工作做得越细，故障处理起来也就越有条理。故障来临时，一切都会变得混乱。此时，对于需要处理故障的我们来说，事可以乱，但人不能乱。如果人跟着事一起乱，那就是真正的混乱了
以用户功能为索引的服务和资源的全视图
这就好像一张地图，如果没有地图，我们只能像个无头苍蝇一样乱试了
为地图中的各个服务制定关键指标，以及一套运维流程和工具，包括应急方案
以用户功能为索引，为每个用户功能的服务都制定一个服务故障的检测、处理和恢复手册，以及相关的检测、查错或是恢复的运维工具
这就好像一个导航仪，能够告诉你怎么做。而没有导航仪，就没有章法，会导致混乱
设定故障等级
亚马逊一般将故障分为 4 级：1 级是全站不可用；2 级是某功能不可用，且无替代方案；3 级是某功能不可用，但有替代方案；4 级是非功能性故障，或是用户不关心的故障
故障演练
故障是需要演练的。因为故障并不会时常发生，但我们又需要不断提升处理故障的能力，所以需要经常演练
灰度发布系统
要减少线上故障的影响范围，通过灰度发布系统来发布是一个很不错的方式。毕竟，我们在测试环境中很难模拟出线上环境的所有情况
故障发生时处理流程
在故障发生时，最重要的是快速恢复故障。而快速恢复故障的前提是快速定位故障源
故障源团队通常会有以下几种手段来恢复系统
- 重启和限流
- 回滚操作
- 降级操作
出现故障时，最重要的不是 debug 故障，而是尽可能地减少故障的影响范围，并尽可能快地修复问题
故障发生后复盘与整改优化
故障复盘文档 COE (Correction of Errors)
- 故障处理的整个过程。就像一个 log 一样，需要详细地记录几点几分干了什么事，把故障从发生到解决的所有细节过程都记录下来
- 故障原因分析。需要说明故障的原因和分析报告。 Root Cause
- Ask 5 Whys。需要反思并反问至少 5 个为什么，并为这些“为什么”找到答案
- 故障后续整改计划。需要针对上述的“Ask 5 Whys”说明后续如何举一反三地从根本上解决所有的问题
故障整改
第一，优化故障获知和故障定位的时间。
- 从故障发生到我们知道的时间是否可以优化得更短？
- 定位故障的时间是否可以更短？
- 有哪些地方可以做到自动化？
第二，优化故障的处理方式。
- 故障处理时的判断和章法是否科学，是否正确？
- 故障处理时的信息是否全透明？
- 故障处理时人员是否安排得当？
第三，优化开发过程中的问题。
- Code Review 和测试中的问题和优化点
- 软件架构和设计是否可以更好？
- 对于技术欠债或是相关的隐患问题是否被记录下来，是否有风险计划？
第四，优化团队能力。
- 如何提高团队的技术能力？
- 如何让团队有严谨的工程意识？
找到问题的本质
一个技术问题，后面隐藏的是工程能力问题，工程能力问题后面隐藏的是管理问题，管理问题后面隐藏的是一个公司文化的问题，公司文化的问题则隐藏着创始人的问题
整改优化三个原则
- 举一反三解决当下的故障。为自己赢得更多的时间
- 简化复杂、不合理的技术架构、流程和组织。你不可能在一个复杂的环境下根本地解决问题
- 全面改善和优化整个系统，包括组织。解决问题的根本方法是改善和调整整体结构。而只有简单优雅的东西才有被改善和优化的可能