事故背景

在一次技术 case 的优化中，由于开发人员的低级错误，导致了 L0 级别的功能不可用，客服团队在 1h 内建立看板任务，由于晚上已经下班，QA 团队在第二天早上发现问题并反馈至开发团队，问题过夜，持续时间较久，影响了较多用户。

技术 case 的特点

技术 case 相较于普通的业务 case 往往会更容易引发问题，技术 case 通常有如下特点：

  • 改动代码量较大或者影响文件较多，通常是一些全局性的替换工作：如「H5 上 iView 组件库的移除」、「小程序老版本组库的替换」、「管理后台全部 lint 修复」，替换过程有一定套路，熟练之后偏重复机械劳作，开发者容易犯低级错误
  • 完整的功能测试需要花费大量的精力：改动文件多代码量大，且部分功能较难测试(如提问多次、账号要求是新用户、管理后台进行一系列操作等)，在此类 case 中开发人员通常选用的测试方法是选择性的测试一些业务流程，最终的结果往往就是问题出在那些被忽略测试的功能上
  • code review 不容易发现问题：对于 代码量大，重复性，公式化 的 commit，很快就产生了视觉疲劳，这不是 code review，是“大家来找茬”
  • 影响范围难以评估，或者评估范围也需要花费一定精力：具有一定体量的项目依赖关系往往较为复杂，改动了一个模块中的代码，影响范围或许开发人员自己都弄不清楚
  • QA 没有介入或与开发人员没有形成很好的配合：很多技术 case 没有 QA 介入，导致少了一道质量保障；也存在开发人员没有将具体的改动同步给 QA 的情况，如组件库替换，需要同步 xxx 页面替换了 xxx，xxx 在什么情况下会出现等等，QA 不明确具体的影响范围，测试没有侧重点，往往发现不了问题
  • 对后续团队成员技术优化的积极性有一定影响：技术 case 很多时候不是像业务 case 那样 必须 要做，出了 bug 或者事故，可能会让大家在主动发起技术 case 前有所顾虑，垃圾代码没有被及时优化，会对之后的业务开发留下更大的隐患

问题

  • 如何在速度与质量之间权衡
    • 开发半天完成，完整的手动点点点测试需要一天，这种情况该如何应对🤔？
  • 如何详细的评估影响范围？
  • 对于严重的事故，看板上的反馈力度不够，不能保证通知的及时性

应对手段与预期收益

核心思路：使用技术手段替代重复的机械劳作，加速重大问题客服到技术团队的反馈流程

  • 引入自动化测试
    • 在每次构建之后对定义的 L0、L1 级别功能进行自动化测试，确保不影响主流程
  • 对模块依赖进行静态分析，包括 页面文件夹，组件依赖，js 和 css 的依赖
    • 每次文件改动之后自动生成功能的影响范围(精确到页面)
    • 根据依赖分析的结果进行分包调整，优化包体积大小和分包加载策略，提高加载速度
    • 删除项目中的冗余代码
  • 加强问题反馈的流程，与客服团队沟通，在判断出程序主要功能(L0、L1)有问题的时候，电话联系 QA

思考与想法

一个稳定、健壮、高可用的系统不是设计出来的，而是在无数次 bug 和事故的打击中逐渐成长起来的。

一切 流程、规范、工具 都只能降低错误出现的概率，并不能完全避免错误，工程师需要使用技术手段将人为出错概率降到最低，最大程度的预防 bug。