一次事故反思

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

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

  • 原本整套系统都是用 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里比一下，一定能发现

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

更多文章
  • 再读vim help：vim小技巧
  • 再读 Python Language Reference
  • 设计模式（2）- 深入浅出设计模式 阅读笔记
  • 设计模式（1）- 深入浅出设计模式 阅读笔记
  • Cython! Python和C两个世界的交叉点
  • socketserver 源码阅读与分析
  • functools 源码阅读与分析
  • contextlib代码阅读
  • Collections 源码阅读与分析
  • Redis通信协议阅读
  • 2016年就要结束了，2017年就要开始啦！
  • unittest 源代码阅读
  • APUEv3 - 重读笔记
  • Mock源码阅读与分析
  • Thinking in Python

    • 本站热门