互联网产品线上故障管理规范
备注：一年半以前网上搜索参考了多篇文章，结合实践做了修正和细化之后进行的内部规范，忘记收藏参考文的链接了。
为了让产品人员和开发人员可以更快速解决问题，也为探索更好保证软件质量的方法，针对线上故障，需要规范的处理流程。QA/软件测试人员，在这个过程中需承担非常重要的规范制定和推动落地实施的责任。
线上故障定义:
产品研发完成，验收通过并发布生产环境后，用户反馈的问题都算线上故障。
线上故障级别：
与互联网软件缺陷规范一文中的缺陷严重程度定义保持一致。
故障报告标准
什么情况的线上故障需要报告？
block/critical - p0级
- 需要故障调查报告 & 复盘会议
对收益有很大影响。例如无法打开页面，无法操作
对用户有很大影响。例如无法支付或提现什么情况的不需要报告？
- 无需报告，但需要记录&简短案例分析
简单用户体验或纯UI显示问题
不影响用户使用核心功能的问题
线上故障处理流程
快速处理故障先让系统恢复正常以减少损失，比找到问题原因更重要。
线上故障发现途径
这个环节建议由QA/测试人员负责追踪，确保所有线上问题及其解决方案等系统化管理，并被详细记录。
主动发现——开发或者运维不经意间查看生产环境的error日志，或者例行检查监控项时，看到了一些异常的现象，进而发现了故障；
系统监控告警——通常包括cpu、内存、io、tcp连接数、disk、线程数、GC、连接池等各个服务器指标异常，可能是服务器出现了异常，但业务还未受到大面积影响；
业务监控告警——如用户登录失败率增加，订单堆积量增大，则意味着系统的异常已经很严重，影响了业务处理；
关联系统故障追溯——上游系统或者下游系统的故障处理追溯，可能和本系统有关系，而且情况已经变得很糟糕了，需要快速定位；
客服事件上报——通常业务异常带来的影响传递到用户，再从用户传递到客服人员，再到技术人员手里，存在一定时延，所以一旦有生产事件上报，严重性已经到了最高，技术人员的压力也会增大，会有领导的关注，产品经理询问和催促，客户人员焦虑带来的压力。
线上故障处理常规思路
研发人员需针对具体业务线形成线上故障处理思路，收集当前业务线故障常发的服务/系统及其解决方案并同步给团队。
故障调查报告
模板参考
建议语言简洁明了，快速输出调查报告，解决方案侧重描述当前解决方案，长远改进措施也可后续输出。
线上故障复盘会议
人员：产品/研发发起，产品/开发/测试等相关人员参与
时间：故障发生后一周之内
Actions:
复盘故障原因、解决方案
进一步讨论改进措施，建立任务追踪并分配到人
改进措施的初步排期
故障协调人
1. 按产品线或项目组安排
2. 协调人需有backup，能够第一时间响应并积极主动协
