最近看了一篇关于线上故障解决的博客很受启发，下面我想根据目前实际工作情况讨论一个解决流程：
发现问题——>定位排除——>回溯
1、发现问题（在此阶段要将线上问题录入JIRA）（从上到下优先级增高）
- 主动发现：研发运维查看生产环境error日志、例行检查（这个我公司运维人员有无在做不清楚）监控项发现异常。
- 总对总告警总群：主要发出系统监控的告警群，通常包括cpu、内存、io、tcp连接数、disk、线程数、GC、连接池等各个服务器指标异常，可能是服务器出现了异常，但是业务还未受到大面积影响。
- 总对总业务告警群：主要发出业务监控的告警群，通常包括各业务模块的告警如流量兑换失败、流量领取、未中奖等影响业务处理。
- 生产事件上报：通常业务异常带来的影响传递到用户，用户再反馈到客服、运营，在我公司最后由产品人员统一收尾反馈给研发、运维（近期出现客服问题比较棘手直接由运营反馈给研发、运维进行分析，是否考虑这类问题由运营收口定期收集？），会存在一定时延，所以一旦有生产事件上报，这个时候严重性已经到了最高，技术人员的压力也会增大，因为会有领导的关注，业务的询问和催促，客户人员的焦虑带来的压力。
上述发现只是问题的苗头，所以要进一步确认这次发现是不是线上问题？尤其是对 “生产事件上报” 的线上问题做甄别——是个例、还是成规模？
2、故障定位与排除
故障定位：收集信息--假设--验证--尝试
排除故障：原则是确保线上服务快速恢复，不能完全恢复的情况下，确保线上服务尽可能少地受到影响。
3、问题回溯
故障回溯的目的是在故障排除后，冷静地回溯整个线上故障的发现/定位/排除过程，找出流程中/架构中/制度中的缺陷，并将该缺陷消灭掉，同时推而广之到其他系统。在‘跳坑’--‘填坑’之后，我们需要通过故障回溯的过程达到‘避坑’的效果，即要保证自己能‘避坑’，也保证团队/公司能够避开类似的坑。
线上故障无小事所以回溯建议以正式的形式进行，每周召开的周例会可以增加线上问题回溯。
回溯问题使用材料：问题列表（问题描述、问题提出方、问题解决办法、经验总结）。
问题列表提供方？运维、研发、产品、运营。一周一次提供？还是使用JIRA录入（大大小小的问题都要录入是否能够保证都录入？）？