**主讲 冯忠旗 京东数科高级架构师 **

事故洞察

对自己负责的系统要了如指掌，有多种渠道来源帮助你第一时间发现这些生产事故：

• 实时监控系统：基础设施（硬件/网络/操作系统/容器等）、中间件和服务监控、业务监控

• 对于以下渠道，建立高效的协调沟通方式

  客诉部门

  基础服务支撑部门

  第三方服务依赖

  …

• 特别业务：安排7x24监控室+工程师轮值的on-call机制，on-call要求工程师在一定时间内随叫随到，做好生产环境出现应急情况的应对准备

事故分析

如果确保第一时间能够发现生产问题，接下来最重要的事情不是去定位问题发生的根本原因。

重点强调：研发人员的特点是发现问题之后，都会习惯性地去排查问题的根本原因，因为研发人员一般都觉得自己可以很快地解决掉这些问题，真实情况往往是一个技术难度陷进去之后，需要很长时间，一个难点解决了可能第二个难点又出现了，耽误了时间导致生产事故已经扩大了影响范围

发现问题后，正确的做法是首要分析事故的影响范围和严重程度，例如是否会产生资损风险、影响用户范围等

事故升级

根据公司部门的事故认定规定，上报上级领导

1. 上级可以协调更多资源，加快问题解决
2. 生产事故解决方案是没有完美的，如果有多种方案，领导需要在不同解决方案中做决策
3. 第一时间告知领导，不失告知责任

重点：汇报时提供预案给领导，并解释不同预案的风险优缺点

事故应对

80%的问题是可以提前做好预案的，需要在长期运维中进行积累

事故复盘

最主要的目的不是问责，最主要的目的是回顾解决事故的整个过程，总结经验帮助下一次从容应对；其次是通过分析事故的特点，寻找能够提前避免的预案方案，因为最重要的还是要做到事前预防

完善方案池

通过长期的团队的运营和积累，把经常发生的事故应对方案放到应急的方案池中，作为共享资源作为团队共享。更像生产事故记录表，用来提醒和帮助团队，新问题一定会越来越少。

故障演练

需要不定期进行，才能保证从容应对。包括数据库故障演练、应用故障演练、网络故障演练等一系列极端情况。