互联网产品线上故障管理规范

备注：一年半以前网上搜索参考了多篇文章，结合实践做了修正和细化之后进行的内部规范，忘记收藏参考文的链接了。

为了让产品人员和开发人员可以更快速解决问题，也为探索更好保证软件质量的方法，针对线上故障，需要规范的处理流程。QA/软件测试人员，在这个过程中需承担非常重要的规范制定和推动落地实施的责任。

---

线上故障定义:

• 产品研发完成，验收通过并发布生产环境后，用户反馈的问题都算线上故障。

线上故障级别：

与互联网软件缺陷规范一文中的缺陷严重程度定义保持一致。

故障报告标准

• 什么情况的线上故障需要报告？
  block/critical - p0级
  - 需要故障调查报告 & 复盘会议
  对收益有很大影响。例如无法打开页面，无法操作
  对用户有很大影响。例如无法支付或提现

• 什么情况的不需要报告？
  - 无需报告，但需要记录&简短案例分析
  简单用户体验或纯UI显示问题
  不影响用户使用核心功能的问题

线上故障处理流程

快速处理故障先让系统恢复正常以减少损失，比找到问题原因更重要。

线上故障发现途径

这个环节建议由QA/测试人员负责追踪，确保所有线上问题及其解决方案等系统化管理，并被详细记录。

1. 主动发现——开发或者运维不经意间查看生产环境的error日志，或者例行检查监控项时，看到了一些异常的现象，进而发现了故障；

2. 系统监控告警——通常包括cpu、内存、io、tcp连接数、disk、线程数、GC、连接池等各个服务器指标异常，可能是服务器出现了异常，但业务还未受到大面积影响；

3. 业务监控告警——如用户登录失败率增加，订单堆积量增大，则意味着系统的异常已经很严重，影响了业务处理；

4. 关联系统故障追溯——上游系统或者下游系统的故障处理追溯，可能和本系统有关系，而且情况已经变得很糟糕了，需要快速定位；

5. 客服事件上报——通常业务异常带来的影响传递到用户，再从用户传递到客服人员，再到技术人员手里，存在一定时延，所以一旦有生产事件上报，严重性已经到了最高，技术人员的压力也会增大，会有领导的关注，产品经理询问和催促，客户人员焦虑带来的压力。

线上故障处理常规思路

研发人员需针对具体业务线形成线上故障处理思路，收集当前业务线故障常发的服务/系统及其解决方案并同步给团队。

故障调查报告

1. 模板参考

2. 建议语言简洁明了，快速输出调查报告，解决方案侧重描述当前解决方案，长远改进措施也可后续输出。

线上故障复盘会议

人员：产品/研发发起，产品/开发/测试等相关人员参与
时间：故障发生后一周之内
Actions:

1. 复盘故障原因、解决方案

2. 进一步讨论改进措施，建立任务追踪并分配到人

3. 改进措施的初步排期

---

故障协调人

1. 按产品线或项目组安排

2. 协调人需有backup，能够第一时间响应并积极主动协