写在前面
对于每一个测试人员来说，软件测试过程中有一个四字成语，真的是如噩梦一般的存在，会在你不注意的时候，就突然蹦出来，劳你筋骨、空乏你身、乱你心神、行拂乱你所为，那就是——线上故障。
线上故障顾名思义，就是项目上线后出现的故障。诱发线上故障的因素有很多，每一个团队，大大小小，都会受到各种各样的线上故障，我们有时候会局限于故障的本身，但是如何应对、避免线上故障的发生，是每个技术研发团队都要面对的事情。并且，由于线上故障的解决跟踪过程，能直接体现一个团队的应急反应能力，所以，线上故障的解决并不是测试一个人的问题，而是整个团队协同一致，共同面对的一个问题。因此在这个基础上，我们的测试团队在部门长的指导下，制定出了我们团队的线上故障等级和处理规范，供大家参考学习
线上故障规范及模板
文档背景
为保障线上功能正常使用，并在遇到问题时及时反馈并快速解决，现编写规范如下
问题分类
线上BUG:
① 运营同事的错误操作导致的体验类型问题，如：文案错误；
② 运营后台使用异常，如：无法修改商品状态，不能正常打开使用后台管理；
③ 产品设计缺陷，不合理需求，等
线上故障：
① 由技术原因导致的线上使用异常，如：无法正常支付、无法正常跳转配置的链接地址、订单异常等；
② 运营同事的错误操作导致的问题，如：错配优惠券为无限量无门槛；
非故障类型
产品设计未实现的需求问题，如：需要新增某种功能，或者产品未覆盖的功能点等
问题录入
录入问题必须写明：项目（线上故障NOF）、模块（android、ios、公众号、小程序、后台）、环境（手机配置、浏览器及版本）、描述（故障产生场景及操作）、影响版本（故障对应版本号）、严重性、优先级（紧急故障会立即启动故障流机制）、经办人、附件（非必填）；问题发生（收到反馈）的时间等，尽可能的详细
等级评判
评级标准可参考《故障等级参考》
问题修复
1、 定位问题原因，和影响范围
2、 修改问题耗时，和修改方案
3、 确认后续跟踪方案
故障Review
故障责任人：故障问题的负责人
问题修复：开发and 开发组长，测试and测试组长
定责内容：确认故障级别、故障原因、故障导致的影响以及最终的解决方案，后续跟踪
为方便理解以上规范内容，现取一条线上问题作为模板供阅读此规范的同事参考：
[NOF-32] 全平台所有业务下单后支付异常，无法调起支付创建: XX年/XX月/XX日 更新: XX年/XX月/XX日 解决: XX年/XX月/XX日 |
|
|
项目: |
线上故障 |
|
模块: |
无 |
|
影响版本: |
4.X |
|
解决版本: |
无 |
|
类型: |
技术方故障 |
优先级: |
高 |
|
报告人: |
雪姨 |
经办人: |
陈独秀 |
|
解决结果: |
完成 |
责任人: |
陈独秀 |
|
标签: |
无 |
||
|
剩余时间: |
XX天XX时XX分 |
||
|
耗费时间: |
XX天XX时XX分钟 |
||
|
原预估时间: |
尚未登记 |
|
严重程度: |
严重 |
|
描述 |
|
|
全平台所有业务下单后支付异常，无法调起支付。 持续时间：XX小时XX分钟，重启服务后恢复正常 |
|
|
|
|
|
|
测试-克莱瑞斯复盘 [ XX/XX月/XX ] |
|
问题解决： 1．临时通过重启服务器解决无法支付的问题 2．最终通过代码修复，发布版本解决问题， 原因分析： 1. 因为没有.......（问题原因），导致........（问题） 2. 问题出现时，没有能够及时联系到相关值班人，导致时间延误 解决方案： 1、陈独秀通过修正........，添加...........，并在XX时，经小组长抖音帝验证后发布到线上环境， 2、万能钢新增...........机制，通过.........实现.......，与经小组长抖音帝验证后发布到线上环境 3、互留手机号，避免由于沟通不畅影响故障修复速度，部门长已验证通过 影响范围： 通过日志确定XX日XX时XX分出现问题，XX日XX时XX分开始解决， XX日XX时XX分问题解决并发布上线，影响时长 XX天XX小时XX分 全平台不能调起支付，经核算，问题时间段内影响客户影响交易量为XXXX元 参与修复人：陈独秀、万能钢 问题责任人：陈独秀 故障评级： 经过以上影响范围评估，此判定等级为P-1级故障 |
后续Action：
此次支付故障后，由于该问题具有普遍性，所以阿尔法小组伙伴排查了线上所有的任务并做了危险等级评估
1、业务一......危险评估高，计划某月某号某人优化修改
2、业务二......危险评估中，计划某月某号某人优化修改
3、业务三......危险评估低，计划某月某号某人优化修改
贝塔小组也做出了同样的预防措施如下：
1、 实现A功能优化，执行人Eason，计划完成日期XX
2、 通过B方法检查来review代码，
3、 通过C方案避免.......问题。
由于此次问题具有代表性，需要引起各位同事的重视和品质意识，所以有了此规范文档。又因为是首次复盘线上故障，过程和步骤生疏，导致耗时比较长。所以为了更高效的解决线上故障，以后每周由每条业务线的测试人员驱动，进行故障Review，若本周内未录入线上故障，则不走此流程。
所有的流程和步骤，都是为了高效、优质、有意义的工作，祝大家工作顺利
写在最后
因为是第一次执笔写故障定级和规范，所以有很多不足之处，也请大家多多指正出来，我们共同讨论，更高效，高质量的管控故障，共同保证我们的项目，安全平稳的运行
