技术人最怕的是谁？

搞技术的最怕的就是线上事故，以前搞电商的时候，经历过多次618/双十一，遇到过大大小小的线上事故，最令我记忆深刻的是在我结婚的当天，接到了系统报警电话，差点错过了婚礼。

 

墨菲在互联网绝对是神一般的存在，根据墨菲定律，如有事故可能会发生，那么它就一定会发生。墨菲并不可怕，可怕的是出了事故不知道如何处理。所以需要有一套处理事故的应急响应机制，来提高故障定位和故障排查沟通的准确性, 以达到快速高效解决的目的。

1、定义事故的级别

• P0级：核心业务重要功能不可用且大面积影响用户。响应时间：立即

• P1级：核心业务重要功能不可用，但影响用户有限，如仅影响内部员工。响应时间：小于15分钟

• P2级：核心业务周边功能不可用，持续故障将大面积影响用户体验。响应时间：小于15分钟

• P3级：周边业务功能不可用，轻微影响用户体验。响应时间：小于4小时

• P4级：周边业务功能不可用，但基本不影响用户正常使用。响应时间：小于6小时

2、应急响应预案

• 预案准备

  共XXX个预案，执行XX个。

• 预案执行

  发现问题：软件，硬件，人肉监控

  定位问题：监控数据，日志

   

  解决问题 

• 预案演练

  线上演练，压力测试， 平日积累

3、应急响应事故处理小组

小组负责接收监控员报警，客服人员报警、运维工程师发现系统异常、开发人员发现的系统异常、业务部门发现的业务异常，准确分析并快速传达给运维部门。小组也负责快速接收运维部门、产品部门、开发部门的排查反馈，并进行再次定位、故障锁定、故障报告汇总上报等工作。

4、应急响应事故处理流程

• 监控员发现故障报警或者运维人员发现系统异常、开发人员发现系统异常、业务部门发现业务异常后，通知到应急响应事故处理小组的当班成员。

• 应急响应事故处理小组成员收到报警，快速分析故障类型并迅速通知到相关的故障排查部门。

• 故障排查部门（运维、产品部、开发部等）收到应急响应事故处理小组发出的故障排查指示，迅速排查解决问题，并及时向应急响应事故处理小组反馈排查进度。

• 应急响应事故处理小组收到排查反馈，判断重大故障是否解除。针对还没有解除的情况，进行故障的再次定位和问题锁定。重新分配通知、跟踪排查并提供有针对性的修复指示。

• 重大故障修复后，故障排查部门需要追查问题原因、对临时修复的故障进行彻底修复、编写事故报告并发送给应急响应事故处理小组当班成员。

• 应急响应事故处理小组汇总整理事故报告，保管文档并上报CTO。

5、运行机制

• 工作时间

  故障发现后，处理故障优先级最高，全力进行排查、快速定位故障，最快速度给出解决方案并处理解决。并行排查，一个系统出现问题，其他系统检查相关的问题，横向沟通，部门间互相配合，持续跟进，直到故障解决。合理安排人员轮换，做到无论何时何地，保证第一第二联系人都可及时联系到。

• 非工作时间

  利用可群体沟通的软件（例如微信群），相关人员及时获取最新信息和处理进度。保持可联系状态，电话24小时开机。利用电话会议，保持实时跟踪进度和处理结果。严格按照上报机制，相应的时间点上报相应的负责人。

各个公司根据自己的情况酌情处理，大家可以关注公号【IT令狐冲】，加入读者群一起交流，后续会推出一系列互联网企业内部的一些管理机制，制度管理，流程管理，团队建设，预算管理，灾备管理等等。