后端系统上线流程

工作这两年,一直是后端,经历过两家公司。我也从没有经验,到积累了一点经验。后端系统的上线,如果出现bug的话,影响会比较大。上线上出事故的,在程序员的行业中已经屡见不鲜了,甚至有过一些很严重的事故,并且,不止小公司有,一些大公司也会出现这样的事故。当然整体来讲,大公司出现问题的概率要远小于小公司,因为大公司因为业务规模较大,用户量大,所以上线流程控制非常严格,每个环节都尽可能的降低出问题的可能,所以整体来看,是不太容易出问题的。就算出问题,也不太容易将问题带到线上去。当然这样做的代价是,上线效率非常低,上线时间成本和沟通成本也较高,但和上线引起的损失相比,大公司一般会选择较低的事故概率。 而小公司,业务较小,更多的追求业务的发展,对事故的容忍度会更高,所以小公司一般都会采取更加高效的方式,当然这也意味着他们面临更高的风险。


下面简单讲一个比较完善的上线流程

  1. 代码测试,主要是研发自己测试,这个因研发的程度而异。
  2. 让 QA 测试要上线功能,确保上线之后功能符合预期,功能性验证
  3. 跑所有功能的单元测试,也叫回归测试,每个功能或者接口应该由自己的测试用例
  4. 上一个线上的机器,观察核心的监控,看有没有报错,指标验证,观察机器的QPS是否有变化,下降或者提高
  5. 代码的全量上线
  6. 继续观察系统监控

下面我们具体分析一下,为什么一个完整的流程会比较耗费时间。

  1. 代码测试, 研发自己测试代码,这个需要测试环境比较完备,要尽可能保证数据量。
  2. QA进行功能验证,QA需要知道功能点。在一些公司,1、2也可能完全由研发负责,这样可以提高一些开发效率。因为研发最了解自己开发的功能,所以测试起来应该也能更好的抓住测试点。1和2都很依赖测试环境。要保证代码部署方便,测试环境的稳定。在可以保证研发素质的前提下,最好给予研发较多的权限,这样会比较方便,防止每一次测试调试代码都需要权限申请,这个非常麻烦,极其影响开发效率。
  3. 单元测试。这个是最重要,但是往往被忽略的一个环节。我认为在所有的流程中,这个才是减少问题的关键。如果这个环节做的好,那么程序上线可能引起事故的可能就会降低很多。这个是QE可以做的最有价值的工作。就是给尽可能多的业务接口写测试用例,让每一次上线的代码只有在通过这些测试之后才能上线,这样可以拦截下来很大一批低级错误,从而保证线上业务的稳定性。有必要设计一个单独的测试项目,专门负责这样的测试,和功能开发同步,或者尽可能和功能开发保证同步,把一些核心接口都包含进去,这样对不管是业务稳定还是以后项目的维护都很有帮助。举一个例子:新浪在升级php7的时候,仅仅用了几天时间,这就是因为他们的测试非常全,能对整个升级过程有把握,在很短的时间内覆盖系统的绝大部分功能,验证功能的正确性。
  4. 经过了前面几个过程,应该说绝大部分错误都会被拒之门外,但是有一些问题,可能需要监控配合,并且观察一段时间,一般是一个小时左右。如果你对接口性能降低了,那么你通过系统延迟的监控就可以看出明显的变化。所以,这个步骤虽然很少会遇到问题,但是也非常重要,尤其是你的修改可能影响系统性能的时候,这一项的执行就会变得更加重要。
  5. 如果上面的监控没有什么问题,那么上线吧。
  6. 上线后观察。上线之后,请继续观察监控,持续一个小时左右。虽然我们经理了一个完整的流程,已经可以避免很多问题了,但是难免还会有漏网之鱼,保持对线上系统的敬畏之心,是工程师的一种基本态度。

上面这几个核心过程的时间消耗。我们做一个简单的说明

  1. 为开发时间,不方便说明。但是需要尽可能保证质量,这个阶段的质量直接决定后面几个阶段的时间消耗,这个阶段要以质量为重,时间可以多花一点。
  2. 最后也是有开发完成,QA辅助。
  3. 这个阶段也要投入一些时间,绝对有价值的工作。并且将这个自动测试做得比较好用,体验要友好,让失败的case能很容易识别,很容易知道哪里出了问题。虽然这个功能很重要,但是平时对开发而言,这个过程比较机械,所以尽可能做得自动化。
  4. 监控观察大概需要1个小时,功能比较小的话,半个小时也可以。
  5. 全量上线即可。
  6. 观察半个小时到一个小时左右。

我们再来看看稍微敏捷一点的做法,也就是一些小公司小团队的做法,这种简化的类型往往没有单元测试这个东西,所以每一次上线都没有太大的把我,有很大的盲区。并且监控也不全面,对系统的了解掌控不到位。如果系统出问题了,只能从自家产品的反馈来得到信息,其实反馈这种东西是不太可靠的,这种人肉的反馈比较靠运气,看脸。真正稳定的系统,应该由很完善的监控报警系统,核心业务一旦出问题,研发负责人会立刻受到警报,以保证系统的尽快恢复。

一个简化版本的如下:

  1. 开发测试
  2. QA测试
  3. 全量上线

上面的流程有一个问题,就是1 和 2 的关系不太好协调,在大家看来,2通过了,代码就应该没有问题了,但是通过我们前面的分析可以知道,2的测试是存在盲区的,因为你知道1的开发真的只做了新功能,而没有引起系统其他模块的变化吗?而每一次让QA做一个全量的功能回归测试简直不可能,没有自动化测试,你让人肉做一个全量的测试,是不是太不现实了。所以好多时候,团队频繁出工程事故的原因,并不是QA或者研发的过失,其实是团队建设的缺失,缺少了全量的自动化测试,谁也没法保证系统不出问题。所以我觉着对于这样的情况,要找人背锅的话,应该找大领导去,原因就是团队建设不合理,尤其是测试这块。

关于上线,基本的就介绍这么多,也是我这几年的一些经验的总结,如能给你带来些许启发,那将是我莫大的荣幸。

点赞

Leave a Reply

Your email address will not be published. Required fields are marked *