前言
在日常纷繁复杂的项目开发周期中,故障的发生如同航行中的风浪,虽不可避免,却也是测试工程师磨砺技艺、深化理解的宝贵机遇。作为质量守护者,测试工程师们肩负着探明故障根源、构筑防护壁垒的重任。通过细致入微的故障分析,我们能够洞察系统的脆弱之处,理解错误行为的背后逻辑,进而提炼出预防故障再发的策略与措施。
本文旨在探讨一套系统性的总结与改进方法,助力测试工程师们不仅成为问题的发现者,更成为解决方案的创造者,持续推动项目质量的稳步提升。
什么是故障复盘?
故障复盘是一项至关重要的质量管理与提升活动,它不仅仅是对已发生故障或事故的简单回顾,而是一个系统性的分析、评估与改进过程。在这一过程中,团队成员通过细致的回顾,深入挖掘故障发生的深层次原因,力求触及并识别出问题的根本所在。这不仅涉及对直接触发因素的考察,更涵盖了对系统设计、操作流程、监控机制以及人为因素等多方面的综合审视。
故障复盘的价值?
通过故障复盘,团队能够构建一个全面而深刻的理解框架,揭示故障背后的系统性缺陷和潜在风险点。基于这一认知,团队可以更有针对性地提出一系列改进措施,旨在优化系统设计、强化操作规范、完善监控预警机制以及提升团队成员的技能与意识。这些措施的实施,从根本上消除故障隐患,降低未来类似故障的发生概率,从而提高系统或流程的整体稳定性、可靠性和效率。
如何做好故障复盘?
为了进一步改进和提升系统或流程的稳定性和可靠性,深入的故障复盘显得尤为重要。这一过程不仅通过回顾和总结故障来识别问题的根源,制定并实施有效的改进措施,以显著降低故障频率、缩小故障影响范围,并最终提升系统的可用性和运行效率。
故障复盘模版
类别 | 内容定义 | 说明 |
---|---|---|
故障现象 | 发生故障的场景、概率等引入项目 / 相关实验 等等 | / |
相关信息 | 引入版本引入阶段(需求测试阶段 / 集成阶段 / 灰度) | / |
故障原因 | 需要从研发,测试多个角度给出造成故障原因,故障根因需要给出代码或画出流程图说明 | / |
事前分析 | QA 是否介入项目QA 做了哪些工作能否避免本次事故发生之后有哪些改进点 | / |
时长分析 | 若超时需从 QA 角度给出分析 | 超时原因(流程、个人操作问题)解决方法(问题前置,巡检,预案) |
检测时长 | 故障检测 - 故障发生,故障发生到程序检测(触发报警)所需时长 | 是否超过当前版本 |
响应时长 | 故障响应 - 故障发生,故障发生到产生人为响应所需时长 | 是否超过一天 |
恢复时长 | 故障恢复 - 故障发生,代表整体故障周期 | 若为移动端故障-是否灰度,或小版本紧急修复 |
总结 | xx业务手动监控业务反馈至研发链路止损依赖发版 | / |
- 发生故障的场景、概率等
- 引入项目 / 相关实验 等等
/相关信息
- 引入版本
- 引入阶段(需求测试阶段 / 集成阶段 / 灰度)
/故障原因
- 需要从研发,测试多个角度给出造成故障原因,故障根因需要给出代码或画出流程图说明
/事前分析
- QA 是否介入项目
- QA 做了哪些工作
- 能否避免本次事故发生
- 之后有哪些改进点
/时长分析
- 若超时需从 QA 角度给出分析
- 超时原因(流程、个人操作问题)
- 解决方法(问题前置,巡检,预案)
检测时长
- 故障检测 - 故障发生,故障发生到程序检测(触发报警)所需时长
- 是否超过当前版本
响应时长
- 故障响应 - 故障发生,故障发生到产生人为响应所需时长
- 是否超过一天
恢复时长
- 故障恢复 - 故障发生,代表整体故障周期
- 若为移动端故障-是否灰度,或小版本紧急修复
总结
- xx业务手动监控
- 业务反馈至研发链路
- 止损依赖发版
/
QA视角如何避免故障?
以下是对从「影响范围/同步」、「MR(Merge Request)验收」、「上线规范」、「降级兜底」、「问题发生」、「问题止损」、「之后改进」这七个方面汇总的常见问题改善措施:
类型 | 问题 |
---|---|
影响范围/同步 | MR 的测试范围是否明确? |
CR 变更代码是否需要回测? | |
需求有增删改的情况,是否周知相关人员 并 同步到需求文档里面? | |
其他业务的变更如何评估对上下游的影响? | |
MR验收 | QA 做了哪些工作? |
QA 存在哪些改进空间? | |
部分需求比较难测的场景,是否需要提前评估 和 提供数据? | |
上线规范 | 上线后是否有观察相关监控? |
如果故障是新上线代码导致,是否经过灰度验证? | |
降级兜底 | 能否通过制定合理的降级策略避免直接将问题暴露给用户? |
能否在上层做降级进行容错处理? | |
问题发生 | 为什么会发生这次故障?发生这次故障的根本原因是什么? |
为什么线下没有发现?应该在哪些节点被发现? | |
问题发现通过什么方式?如果发现方式是用户反馈,是否可以通过监控发现? | |
问题止损 | 问题的修复时间是否符合预期?是否可以缩短? |
故障发生到发现时长是否超过 10 min? | |
之后改进 | 是否可以通过改善流程避免同类故障发生? |
故障所有的 action 完成后, 如果发生同样的问题, 能避免故障发生或者让故障降级么? |
结语
故障确实难以完全避免,但关键在于发生故障后能够迅速响应,通过深入的复盘过程,提炼出宝贵的经验教训,从而构建有效的防御机制,防止同类故障再次发生。