gopher成长之路(五): 2年前和2年后同一个项目

别人的尊重，取决于自己的专业。

这次的记录是对同一个项目，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号下午统计完一些异常数据，给算法看的时候，发现了问题，竟然是语音数据的问题。这个问题很严重，如果是我们的问题，那我想要周六就离场的方案就泡汤了。出现问题之后，首先先排查是否还是我们自己的问题，还好我们有测试用例，可以把场景测试的结果都复现一下，然后看下保存的数据是否是对的。排除掉了代码的问题，再去排查是否不是我们和音视频平台保存的数据不一致的问题。在等待拷数据，及校验的过程十分煎熬，一直担心是自己的问题的，这个紧张的程度比上线还要紧张，说实话心脏就快跳出来了。不过还好，最后校验后，音视频平台和我们存储的是一样的，就表示不是我们这边处理的问题，悬着的心就放下了，真的是吓死人。

最后，整理完数据，就离场了。原本客户还要请客吃饭，后面他们要团建，就算了。不过，原本也不打算参加，这个上线是我们应该做的。只不过这次的上线比较顺利，比之前两次上线来得舒服多了。虽然都在忙，不过是有目标地去完成，而且这次我们说话的分量明显比较有用。