项目过程管理（十五）线上故障

Posted 2022-12-12 hursing

故障定义

发布生产环境并验收通过，确认放量后，还发现的bug都算线上故障

响应机制

分为3个等级：

1. 严重，发现后需立刻找到人马上解决。例如系统宕机，前端崩溃等。
2. 中等，需在一两个工作日内解决。例如主路径的问题。
3. 一般，在项目排期中安排解决。例如UI问题。

报告标准

什么情况的线上故障 需要 写邮件报告？

• 对营业额有大影响。例如无法打开页面，无法操作
• 对用户口碑有大影响。例如无法支付或提现

什么情况的 不需要 报告？

• 简单的用户体验或纯UI的问题
• 不影响用户使用核心功能的问题

处理流程

1. 无论谁发现的，首先应该 反馈给测试同学
2. 测试确认重现步骤后，报bug给开发解决，并由 产品经理决定 是否紧急发布修复
3. 修复后，由 测试负责人 汇总各职能的报告并发出邮件。

邮件内容包括：

• 产品报告对运营数据的影响
• 开发报告出错的原因、（代码层面的）影响范围
• 测试报告没测出来的原因
• 由测试组织讨论如何防范这样的情况再出现

报告邮件

原则：

1. 要找出责任人（或指出是哪个职能即可）和出错类型（代码、需求、沟通之类的），并明确写到报告中
2. 对事不对人，注意措辞
3. 要有解决方案，且有明确的跟进人

收件人：项目组群
抄送：测试组群
标题：【线上故障】xxx项目a月b日yyy问题

正文示例：

Dear All，
本次故障的
现象：支付页出现白屏，并一直弹框“数据异常”
持续时间：10月3日14:30上线就存在，在10月3日18:00由后端修复，故障持续3.5小时
发现时间：由客服在10月3日16:00收到用户反馈而发现
影响：用户无法购买商品
原因：后端……
解决方案：解决代码错误即可
未能更早发现故障的

原因：后端上线前改代码未通知测试
防范方案：需要开发自觉，开发主管要加强宣导。最佳解决方案是git提交都有监控，但目前可执行性太弱

问题跟踪：【url】

本系列文章的目录：https://hursing.blog.csdn.net/article/details/88025790