别人的尊重,取决于自己的专业。
这次的记录是对同一个项目,2年前和2年后对比的一个感受。
来了这个客户这里已经是三次了,第一次是20年9月上线,第二次是21年8月上线,这次是第三次。三次,感觉自己完成了蜕变。
相较于前面两次,尤其是第一次,简直是天朗之别。还记得第一次,上线一次就出现一堆bug,对一些上线经验也不足,什么都是靠自己过来。被客户怼得都不敢看手机了,当微信亮起来的时候,都是一声叹气。而且每次上线都是担惊受怕的,生怕隔天到现场线上又出什么bug。上线完之后,客户还要求必须再待个一两周,谁让当时的我菜呢,bug多。
到了第二次,想当于也是出于稳定阶段了。对需求了解的更多了,虽然是上线了,但也有低知道这次上线大概会是怎么样了。对代码的质量也比较重视,上线之后也就是观察了一周就撤了。
这次第三次,已一个绝对主导地位去上线的一次。怎么说是主导呢,需求是以我们为主,就是我们是专家,得听我们的。上线之后,没有再无时无刻的监测,相信我们的代码质量,虽然还有一点问题,但是我们也绝对有底,也知道怎么去复线或者排查。
8/24到了北京之后,以为要隔离,这次还带了显示器过去,也是担心7天真的都在看笔记本的话,眼睛受不了。或许会有人不理解,甚至觉得奇怪,出个差还带个显示器这么麻烦。有些时候麻烦一点,换来的便利可能都被人忽视了。当然也有可能是我看大的显示器习惯了。不过还好的是,到了北京之后不需要隔离,因为没有弹窗。不过还是基于三天两检的策略去隔离一下,也安全一点。在酒店待了3天,算上24号,27号还是出去走了下,逛了逛天坛,北京的公园绝对是极好的。
此次能这么顺利测试下去,也是因为我们在前期做了全的测试用例,虽然是有些类型不同,但是基本上都覆盖到了。对每个测试用例的实现,如何测试都已经了然于心,所以客户的测试有问题的时候,基本上都可以很快地反应过来。我们也把这些用例写成了自动化测试脚本,每次上线的时候也都会跑一下脚本来保证代码的正确性。能搞保证上线的数据是正确的,唯一途径就是大量的测试用例,大量的自动化测试脚本,减少人工校对的时间。
30号当天上线,当天还在跑剩下的2个案例,还是测出了点问题,到晚上9点才上线完成。上线完之后,还在测试,差不多测到了11点半,是客户公司最后一个走的。当天本来是想放弃的,不过如果没有在周二上线,我也不能提周六就回来,因此我势必要在周二上线完成。
30号当天把要测试的用例都再测了一遍,确保版本的正确性,别因为版本问题导致上线失败。客户测试必须要测试过最后一个案例,才允许上线。但是此时电话又不能打,用例还得建,就变成要等,即使我这边测试好了之后也不行,这一点其实有一点木讷。当天都一直在测试,都忘了要准备上线的模型及一些脚本上传啥的,后面才想起来,测完才在准备。上传时间又花了一些,因为这次是大版本的改造,传上去又不能直接用run.sh做部署,就很尴尬。上传完脚本镜像啥的都9点了,部署完之后,还在测试,测到差不多11点半,测试的目的就是为了隔天起床的时候是闹铃而不是电话铃声。
上线之后确实发现了不少问题,自己在做测试的时候遗漏了一些测试用例。不过好在,客户对我们放心,可以快速解决问题,这次跨信道的主要开发不是我,是我同事,还是同事够给力能够快速定位问题,分析。基本上问题都在31号晚上就处理好了,当然隔天还是有遗留问题。所以最终其实花了2天的时间吧,去把所有的问题去做分析。31号,没有入场,但是跟客户在楼下讨论了一下后续的安排。这个是一个很重要的动作,在上线完之后,没有出现大问题的前提下,把后续的计划跟客户沟通好。中间谈了离场的事情,开发新需求的问题,对我们团队同事的看法等。我觉得不是以一个甲乙方在沟通,而是跟同事在沟通。本来客户提的是下周三再离场,不过在我的沟通下,客户说周五没有问题的话,就可以离场,对我们也是比较放心。在听到这个离场的答复后,那当然要安排后面几天的工作了。
想要离场,不是说我做完我自己的就可以走了,不是说上线完了就完了。想要能够顺利地走,不仅仅是要做好自己的,也要把客户的事情做好。什么叫客户的事情做好,比如说在31开发的新需求,帮客户把测试用例写清楚,这样子在隔天客户要测试的时候不用再准备测试用例,直接按照你的来就可以。客户要配置的一些参数,可以通过代码里面配置的方式来实现,这样客户不用麻烦地去创建测试用例对应的参数。在客户测试的时候,不要干等着,而是要去主动帮忙分析,因为客户测试不一定懂里面的逻辑,要去讲解。开发跟实施来说,一般在现场实施的人解决问题更多依靠对应的开发,有时候在现场会着急,其实开发能够在入场前或者测试前把问题都尽量测试完,保证实施能够顺利进行就是一个很好的事情。
9月2号,为了能够顺利离场,也是早早8点半就到现场,监控数据,以免上线出问题不能走。当然是没问题的,就在那边看数据。此时有一个很重要的动作,就是统计数据,把之前的数据都做一个统计,看一下我们的系统在客户这边的运行情况。不是说在那边监控数据就是傻坐的,一直点页面,看页面数据有没有出问题。当然,这么做也没错,但是除此之外我们还能做什么呢?我把生产和测试的配置,部署文档,参数,拓扑图都做了一个记录,来保证以后要复盘或者查问题的时候,有东西可以查。这个动作很多开发会忘记,或者就在现场等时间结束,这个动作可以保证在后续要查看问题的时候有个依据。之后要拿一些文件的时候,也知道让运维去哪个地方拿文件。
2号下午统计完一些异常数据,给算法看的时候,发现了问题,竟然是语音数据的问题。这个问题很严重,如果是我们的问题,那我想要周六就离场的方案就泡汤了。出现问题之后,首先先排查是否还是我们自己的问题,还好我们有测试用例,可以把场景测试的结果都复现一下,然后看下保存的数据是否是对的。排除掉了代码的问题,再去排查是否不是我们和音视频平台保存的数据不一致的问题。在等待拷数据,及校验的过程十分煎熬,一直担心是自己的问题的,这个紧张的程度比上线还要紧张,说实话心脏就快跳出来了。不过还好,最后校验后,音视频平台和我们存储的是一样的,就表示不是我们这边处理的问题,悬着的心就放下了,真的是吓死人。
最后,整理完数据,就离场了。原本客户还要请客吃饭,后面他们要团建,就算了。不过,原本也不打算参加,这个上线是我们应该做的。只不过这次的上线比较顺利,比之前两次上线来得舒服多了。虽然都在忙,不过是有目标地去完成,而且这次我们说话的分量明显比较有用。