bug管理

事情要从凌晨两点四十三分的一次告警说起。 那条告警至今还躺在我们的通知记录里。线上核心接口超时，用户开始无法支付。运维找到当班开发，开发拉群，一群人揉着眼睛翻日志，最后定位到一个排序函数的空指针异常。五分钟修完，灰度发布，大家互道晚安。两天后，同一个异常再次触发，只不过这次换了一个下游参数，来自另一条调用链路。 单独看，那只是一次普通的线上Bug。但当你把它放进一个季度的统计数据里，它就变成了另一…

一、为什么换了5个Bug管理工具，上线前还是被“临时卡死” 我见过一个非常典型的场景：一家200人的SaaS公司，研发团队先后换过Jira、禅道、TAPD、飞书多维表格、甚至自研了一套Bug流转系统。每次换工具的原因出奇一致，“现在这个工具管不住Bug，上线前总是被卡”。 矛盾点在这里：如果工具是问题根源，换五套早该解决了。真正持续存在的变量不是工具，而是这套团队如何定义、处理、验证Bug的流程，…

上周我在复盘团队Q4的缺陷数据时发现了一个令我坐立不安的事实：线上跑出来的47个Bug里，有19个问题我们在过去一年至少处理过两次以上。其中一个支付回调异常的问题，三拨人轮流改过四遍，每次都像是在重新破案。研发工时不是花在创造新功能上，而是反复填同一个坑。 这个问题几乎每个带过研发团队的人都遇到过。我们常做的第一反应是“要加强测试覆盖”“要搞自动化回归”，但实践下来你会发现，工具只能帮你发现错误，…

上周我在复盘团队Q4的缺陷数据时发现了一个令我坐立不安的事实：线上跑出来的47个Bug里，有19个问题我们在过去一年至少处理过两次以上。其中一个支付回调异常的问题，三拨人轮流改过四遍，每次都像是在重新破案。研发工时不是花在创造新功能上，而是反复填同一个坑。 这个问题几乎每个带过研发团队的人都遇到过。我们常做的第一反应是“要加强测试覆盖”“要搞自动化回归”，但实践下来你会发现，工具只能帮你发现错误，…

一、质量问题的真正转折点 复盘之前，我们团队很多成员认为“日抓200个bug”是测试能力强的表现，甚至带着某种病态的自豪。直到那次大促前夜的线上事故，一个由八个月前匆忙修复、从未被纳入回归测试的旧代码引发，导致核心交易线中断整整47分钟。技术VP在复盘会上说了一句话，让所有人沉默：“我们不缺发现bug的能力，缺的是让bug没有机会诞生的土壤。” “从日抓200个bug到归零”的本质，不是消灭bug…