1. 事故洞察

首先，你得对自己负责的系统了如指掌，同时有多种渠道来源，能够帮助你第一时间发现生产事故，比如实时监控预警系统、客诉部门、基础服务支撑部门、第三方服务依赖方等等。

如果核心业务交易量大、交易分布时间相对平均、业务面向 C 端用户多、业务重要程度高，需要特别安排 7*24 小时监控室 + 工程师轮值 on-call 机制，on-call 要求轮值工程师在一定时间内随叫随到，做好生产环境出现紧急情况的应对准备。

2. 事故分析

如果确保了第一时间能够发现生产问题，接下来最重要的事情不是去定位问题发生的根本原因，而是要先去分析事故的影响范围和严重程度，比如是否会产生资损风险、资损的金额可能有多大、影响用户的范围有多大、是否非常严重等等。

因为研发人员的特点是发现问题会习惯性地排查问题的原因，而且一般都会觉得自己可以快速解决掉问题。可往往真实情况是，一个技术难点陷进去之后需要很长时间，就算这个难点解决了，却发现又出现了第二个问题。这就像电视剧里面通过线索排查案情一样，问题一环套一环，结果是时间可能已经过去了 30 分钟，问题也没有解决，这个时候生产事故已经扩大影响范围。

3. 事故升级

如果事故属于严重程度，需要立刻进行事故升级，通知相关业务方和上级领导。

及时向上级汇报有三大好处：

第一，领导会根据严重程度协调高层资源，进而加快解决问题的速度；

第二，没有完美的生产事故解决方案，很多时候需要领导在不同方案中做决策；

第三，就算这次事故没有处理好，第一时间告知领导之后，至少不失告知责任。

需要注意的是，在给领导汇报生产事故的同时，最好提供一些事先应对预案，并将不同预案的风险和优缺点如实告诉他，请他来决策和支持。

4. 事故应对

如果你在长期的应用运维过程中不断积累和沉淀，那么，对于 80% 的常见问题你是可以提前做出应对的。

比如，Java 系统产生 OOM 内存溢出，虽然不知道是什么原因导致的，但是可以通过立即重启来恢复服务；再比如数据库连接池占满，导致其他服务不可用，如果没有最好的方案，可以从数据库层面杀掉耗时最长的慢连接。

5. 事故复盘

事故解决之后，需要做的事情是复盘事故发生和解决的详细过程，包括发生时间、参与人员、详细处理过程、结束时间等环节。如果事故的应对方案是短期临时方案，还需要进一步针对此次事故制定长期解决方案，并且快速上线。

复盘最主要的目的不是问责，而是回顾解决事故的整个过程，总结经验，下一次遇到类似问题能够更加快速从容地应对。此外还能通过复盘分析事故的特点，寻找能够提前避免的预防方案，因为最重要的事情还是需要做到事前预防，而不是事后补救。

6. 故障预案

这里所说的方案池更像是历史生产事故记录表，也就是生产事故预案，你可以把经常发生的事故的应对方案放到应急方案池中，作为团队的共享资源。一旦发生这类问题，就算是新入职的同事也可以参考方案池快速解决问题。

如果再有新的事故发生，就再次把新的方案融入到方案池，这样方案池就越来越丰富，从而不断积累形成宝贵的经验。通过这种方式，生产系统的新问题一定会越来越少。

7. 故障演练

研发团队需要不定期做故障演练，包括数据库故障演练、应用故障演练、网络故障演练等一系列的极端情况下的故障模拟，确保真正出现问题的时候，能够沉着应对。

当你掌握了这些方法，就能从容地应对生产事故，避免或者减少生产事故所带来的影响。