本帖最后由 h68810115 于 2022-5-19 09:59 编辑
4.1 负责控制器测试
在深圳飘荡了一年多,终于又回到暂居一年的上海,算是重新开始吧。
融入上研所
到上海之后,最初的2天是接箱子,找电脑,把设备放到对应实验室,当然还要在空闲时间租房子,然后才能把个人物品搬回去。当时上研所在证券大厦租了两层楼办公,是属于陆家嘴的核心地带了,旁边就是崂山新村,房子倒也不难租,价格不算贵也不便宜。
过了两天,测试部领导开了一个整个部门的全员会议,算是欢迎我们从深圳的7个人,加我们一起,测试部可能有30多个人吧,当时上研所商用产品还不多,主要就是GSM的两个产品,另外还有就是没商用的3G WCDMA研发产品。控制器产品的测试经理是之前从深圳派到上海支援BSC32开发的,之前也比较熟悉。比较意外的是上海领导给我按了一个测试副经理的名头,在开会之前领导也没说,可能考虑我是当时深圳过来的7个人临时负责的。没过多长时间,大概2,3个月吧,因为工作变动,我的直接领导就调去管基站的测试了,当时上研负责的BTS3.0基站正处于开实验局阶段,作为全新架构的产品,问题自然比较多,急需要补充力量。于是我就开始负责控制器的测试。
那时候一个产品的测试组团队也不大,我对控制器各模块也还算比较熟,做测试计划及任务安排倒也得心应手,大话务量工具已经比较成熟,上海团队里面也有人专职负责维护和改进,主要是跟进产品的版本开发计划,配套做好版本的测试计划,留好问题修改和回归测试的时间,基本上就不太可能影响版本发布的节奏了,因此,业务上到也没什么问题。
人员流动取决于上一层节点
说是融入上研所主要是上研所的管理模式与原来测试部的不一样,当时华为还是按地域管理的,也就是说上研所是作为一个整体,测试部及各开发部都是归上研所所长管的,业务上会受深圳部门指导,但人员,薪酬,考评都是研究所直接管。这就意味着测试部向开发的流动要容易得多,而当时深圳测试部门要向开发流动则要难很多。因为当时华为还没建立起员工职级体系,那么员工看到的都是岗位,对测试员工来说,测试经理不动几乎没什么机会,因此很多测试人员都是想着转到开发部门去。这个问题后来是通过06-07年定岗定薪建立起岗位职级体系及技术发展通道来解决的。
接手控制器测试之后,无线的产品也逐渐开始有了小规模市场突破,版本也是一个接着一个,那个时候华为IPD的试点产品刚刚完成,当时规定新立项的产品按照IPD流程来,但像我们BSC32这样的老产品,版本级没做太多的规定。更有意思的是,当时华为的版本号还没形成统一V,R,C,B四级的规范,只有大的V,R两级,后面好像再跟一个基线版本的时间,比如BSC V3R2 0520版本,之后再出回归版本。这就意味着,产品只有延绵不断的版本,但BSC在BSC32立项开发之后基本没有再立项再审视的过程,而是根据需要再结合人力形成大概的版本基线,这就是版本延绵不断一个接一个的原因。
做测试经理最大的改变就是,不再是仅仅埋头干活,而是有机会了解到市场信息,了解产品“规划”,了解产品网上问题,参与了一些原来作为测试人员基本不会参与的事情,与此同时,也会参与测试部内部人员发展与安排的讨论,相当于接触了部分管理。总之,做了测试经理接触了更多的信息,开拓了眼界,能够学习到更多,开始了成长的自我积累。
第一次出差
到2000年,无线产品在国内已经有了少数几个商用局,内蒙,河北,甘肃,贵州,湖南,其中湖南的娄底应该是华为拿下的最大一个本地网,签的时候大概有500多个载频,产品线也非常重视,开局之前在实验室搭建了一个镜像环境(技术用语,和现网配置尽量相同的实验室环境,便于方案验证及问题定位),投入不少研发力量。
到2000年8,9月份的时候, BTS30还是BTS312在首次规模商用,控制器也需要派个研发人员到现场支持,而当时控制器开局组人员正好比较紧张,于是讨论就让我过去支持一下,于是我就喜提人生的第一次出差机会。
人生第一次出差
BTS30是用在北方某地级市联通,整个本地网替换西门子的设备,虽然说是整个本地网,但那个时候手机用户全国总共也才7000万左右,联通全国总用户数才1500万,对应这个地级市,我们替换的一共是30多个站点,MSC里一共有3万多用户。我到时候BSC已经和MSC对接好正常运行,主要任务已经完成,前期工作是由一个经验比较丰富开局组骨干完成的,他有其他任务,剩下的都是一些配合的工作,就我来值守了。当然,这是产品商用前期,产品稳定性不够,服务能力还跟不上的时候特殊安排,随着产品逐渐稳定,局点开通基本都是由服务人员干了。
到某个邮电宾馆,才知道这次研发支持的规模,虽然控制器只有我一个人,但基站支持的研发人员20个左右,应该是因为这是BTS30的第一个成规模的商用局吧。那个时候华为出差住宿基本是两个人一个标间,一层楼住的基本都是华为的,研发,服务,网规网优各部门都有。晚上小范围的3个人到旁边的小店吃饭,第一次到北方的我算是见识了什么叫北方的菜量,3个人两个菜都吃不完,在上海或深圳,至少人头数或人头数加一。
虽然名义上应该是服务第一责任人,但实际上那时只要有研发人员在,所有的操作都是我们研发人员在做,我也是第一次开局,生怕自己弄出点啥问题影响现网运行。某天因为版本升级还是啥,需要把控制器重启一下,当时还是比较担心的,生怕起不来,需要加载的程序,数据配置检查了一遍又一遍,确保无误之后下电,过了1,2分钟,看到设备正常跑起来,一颗悬着的心才放下来。有了一次成功的经历之后,后面再复位就大胆多了。之所以要经常复位是因为当时控制器有不少数据是不支持动态修改的,只能重启才能生效,当然,之后一年改进非常多,绝大多数的数据都能动态修改了。
某天在白天话务高峰期,因为定位问题需要跟踪某接口的消息,在确定按钮按下去之后就看到跟踪窗口里的消息快速翻屏,不但找不到需要的信息,而且计算机反应也变慢了。赶紧停止消息跟踪,点了几次没反应,继续点,终于将消息跟踪停止。后来想想还是有点怕的,如果不能将消息跟踪停止,光消息跟踪就可能将前后台的正常通信带宽全占了,会严重影响日常维护的前后台通信。
平时在实验室做测试,一般也就1-2个基站,也没啥话务量,需要跟踪设备接口的消息,一般习惯性的就跟踪某个接口的所有消息,而这个习惯放到现网上就可能会导致非常严重的问题。晚上赶紧写了一个邮件,将这个过程说了一下,并建议在消息过滤和筛选上面做出更严格的限制,比如,对于量最大的消息一定要筛选,只能跟踪指定TRX和指定信道的消息等等。
产品设计一个很重要的原则就是要防止一些容易出现且可能出现严重后果的误操作,就像消息跟踪,很容易就会把跟踪所有消息都点上,那么对于消息量最大的一类消息一定做出最严格的限制,就和所有直流电源线的插头都是D型或者其他防插反的设计一样,因为区分正负极的插头插反了就可能会导致设备损坏。这些东西在实验室没想到的,一拿到实际使用就很轻易的能够想到相对完善及改进的方案,这就是实际现网经验的重要性。
|