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

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

线上故障定义:

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

线上故障级别：

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

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

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

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

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

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

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

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

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

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

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

模板参考

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

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

复盘故障原因、解决方案

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

改进措施的初步排期

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

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