<>概述
在平时开发系统功能模块的时候,有些开发人员可能认为功能模块按时提测、按时上线就算"认真负责
"了,可以不用管了。其实做到这些还是远远不够的,因为真正考验你对自己做的模块是否认真负责,是在上线后。假设你开发的模块在今天上线,隔天就出了问题,老大来个连环问
:
老大:问题影响面有多广?
我:?
老大:能回滚吗?
我:?
老大:是接口性能问题还是功能性问题?怎么监控没有报警?好吧,只能硬着头皮解决问题,然后上线,请求参数和报错的上下文日志发一下
我:。。。。。。忘记打了
老大:。。。。
上面还只是一个小小的场景,线上功能模块要运行良好,开发人员是要花非常多心思的,下面笔者简单列一下。
<>想好回滚/降级/灰度方案
功能上线之前,就算做了非常严格的功能测试和回归测试,也是不能百分之百保证上线后没问题的。因此研发第一个要做的事情是,上线前先列好线上问题处理方案,大概有如下几种场景:
* 如果技术重构项目,必须有灰度开关,能随时切回去;
* 如果是对接其他微服务接口的,必须保留原有的逻辑,万一新服务接口有问题,能降级到使用旧接口;
* 如果是改动原有接口的,且是非常重要的核心功能,而且涉及到小程序端或者APP端联动一起修改的,那么就需要评估一下,前端和后端同时回滚的方案;;
*
如果是数据库做了变更的,那么一定要做的事情是:旧代码访问变更后的数据库,是否正常,如果事先没做好这个兼容性,到时候上线后出问题,是退无可退的,因为数据库变更是不允许回退的;
<>重视测试人员的测试用例
测试人员一般都会给出功能模块的测试用例,开发人员必须认真对待它,协助测试人员一起完善它。因为测试人员就是依据这份用例来执行的。如果你不放心,则拉上产品经理,一起评估测试用例。一般来说,评估的维度如下:
* 新功能完整性;
* 旧功能回归场景是否全;
* 有无漏掉的场景;
开发人员也尽量提供一份功能改动点的文档出来,说清楚改动了哪些点,哪些重要的点被改动了,让测试做好评估。
<>做好日志监控
功能模块要做好监控,一旦有任何一个报错,你都能第一时间知道,提前介入解决。比如说:
* 接口打印响应时间,如果响应时间超过200毫秒的,打warn日志;
* 将接口关键字上报到elk,借助elk做告警,并同步到企业微信或者钉钉告警群;
* 打印入参和出参,方便定位问题,尤其是接口报错时,上下文入参一定要打;
* 如果接口调用了第三方服务的,也必须打印调用一次接口的时间以及入参和出参;
<>做好数据监控
如果你负责的订单/支付模块,最好能做个数据监控,例如:
* 未支付订单数监控
* 退款订单数监控
* 使用优惠卷订单数监控
如果做的是短信模块,就监控短信发送数量,如果是做的是发票业务,那就监控开发票失败的数据。
把监控结果,放到监控大盘里,方便大家看。
<>C端接口的,做好压测
C端接口是用户级别的,每个接口都得压测,通过压测发现瓶颈所在,提早优化。一般要经过如下几个阶段:
* 开发压测,给出预期qps;
* 测试人员压测;
* 线上压测;
关于线上压测,如果服务设施没搞好,那就必须晚上压测。现在用阿里的PTS做压测方便,建个压测任务就行。
<>一个星期的线上观察期
如上文提到的,功能按时上线了,还是做的不够的,因为还需要加一个线上观察期。模块上线后的一个星期内,每天都要仔细观察该功能是否运行正常,例如如下这些维度:
1、接口有无ERROR日志;
2、接口响应时间是否正常,尤其是高峰期;
3、BUG群里是否有关于该功能的报障;
4、有无异常数据;
5、写入的数据是否符合预期,是否影响到下游系统;
6、之前的出现的问题,是否如预期的完整解决了;
好多开发人员经常漏掉这一步,认为上线后就完事了。
<>小结
功能模块从需求-->开发-->测试-->上线-->线上观察期
这几个过程,都照顾周到了,才算对该模块负责了。同时这也是一个开发人员应该要有的习惯和素质,如果你每做一个项目,上线后都没有手尾,非常稳定,那么你与老板的信任
关系就会慢慢的建立起来,老板才会不断的分配任务给到你,你也才能发展和成长。