一次事故反思

最近把一个管理后台系统从原来的大单体中整体拆分出来,出了四个问题,我对此进行深刻反思。本文为反思录。

事情的起因是大家决定要把管理后台拆出来,状况是:

  • 原本整套系统都是用 gRPC + gRPC-gateway 写的,不好用,大家想要换到GIN
  • 没有单元测试,但是基本上以前的bug都被修复了
  • 我对整个系统还不够熟悉
  • QA人力不足,不负责测试管理后台

而我花了大约3天的时间,把整个admin从grpc这套搬到GIN这套,又花了2天左右把单元测试覆盖率从0提升到了50%。但是 由于不熟悉,以及回归测试不到位,一共出现了四个问题:

  • 遗漏了某个API,不知道属于管理后台,没有搬过去
  • 给客户用的一个Prometheus metrics API,输出有错误,单位是bytes,但是我少乘了1024,本人、QA、产品均没有看出来
  • 状态码改错了,而dev环境前端代码许久没有更新,导致某个错误没有及时发现
  • 有一个接口,绑定参数错了,导致使用了默认零值。gRPC-gateway会把各种参数放到一个struct里,而GIN需要从各处分别提取参数

出现这几个问题的很大一个原因是我没有完整的覆盖到测试,首先是单元测试,虽然我从零提升到了50%,但是还是漏掉了 一些接口;其次是虽然人肉测了一部分接口,但是仍然遗漏了一部分接口,而恰恰就是这部分接口出了问题。

这就导致一个问题,虽然搬迁整个系统,一共有100多个API,但是由于出现上述四个问题,给人留下一种不稳定的印象, 而我也确实不应该漏测。我认为自己这一次需要承担主要责任,所以从这次事故之后,我进行了深刻的反思,此后的每一个改动, 我都有加上单元测试,以及人肉去回归一遍。

下面是我这一次的经验教训:

  • 对于大的改动,最好是做到熟悉之后,再来开始改动,否则,对于拆分服务这种需要保证兼容性的改动来说,实在是太危险了
  • 对于大的改动,应当是先写好单元测试,然后再开始改动,这样就更容易知道哪里改错了
  • 软件质量应当优先于开发速度,尤其是像我司这种企业
  • 改动之后,一定要自己先完整的测试几遍,对于不熟悉的部分,一定要找老员工问清楚
  • review这个流程非常重要,但是本次由于单个PR太大,review并没有发挥作用(review的也不够细致)
  • 即使有review,也不能依赖review。还是要对自己的产出质量有要求,这是我对自己新的五年的一个要求
  • 单元测试覆盖非常重要,写单元测试的确很花费时间,但是写好之后,单元测试可以每次都跑,节约了人肉测试的时间
  • 一定要把思维训练的更加严谨,我认为这对我个人的长远发展是有好处的,开发之前,一定要想的比较清楚了,再开始,这样可以进一步减少后续的错误
  • 人的确是不可靠的,还是机器可靠,我自己、QA、产品都没有看出来数值有问题,但是如果我写了测试去覆盖,或者拿去Prometheus里比一下,一定能发现

以上就是我的反思,以后要注意这个方面,进一步提升对自己的要求,对代码的要求,提升产出质量,减少问题。


更多文章
  • 我们真的需要这么复杂的技术栈吗?
  • Go设计模式:装饰器模式
  • 程序员的MySQL手册(一): 安装,基本配置
  • ElasticSearch学习笔记
  • Go设计模式:composite模式
  • 拯救删除ZFS之后的分区表
  • Linux使用redshift自动调整屏幕色温
  • Go设计模式:桥接模式和策略模式
  • Go设计模式:单例模式、原型模式和Builder模式
  • 操作系统也是CRUD
  • Go设计模式:简单工厂模式
  • 把USB设备穿透给虚拟机里的系统
  • debug故事之:事务让生活更美好
  • Go设计模式:模板模式
  • Go设计模式:适配器模式