爱吱声 › 标签 › 工作 › 相关日志

标签: 工作

相关日志

分享惹祸之后: 热度 68 landlord 2015-9-19 06:58; 出国出差的前一天发现自己犯了个大错误。周二一大早就要出差，周一来公司，觉着没啥事儿了，准备一下要明天带到厂家去的设备把，结果事儿发了。有个产品测试没过，这很正常，但不正常的是发现它已经在服务器上了。嗯，我们公司的产品是IoT--Internet of Things，中文叫物联网。所有的产品都自动上网，登录到特定的服务器上。检查原因，发现这个产品和以前的一个产品有着相同的MacAddress。小科普，这个MacAddress对于上网的东西，就如同它们的居民身份证。每个能上网的东西，比如智能手机、有线或无线的网络卡都有，而这个东东在全世界都不带重样的。每个生产网络产品的公司都去特定的机构买一批来用。一个身份证发给俩人用，这是大事件！我很快就想到并核实了原因，这个祸是我惹的！得赶紧改！当务之急得到公司相关部门的全力支持。刚好10点有个会，生产部门的头儿和公司管工程生产的副总裁都在，我一般是去例行汇报。这次我可要露脸了（不是好脸，泪）。我一开会就报告有些MacAddress被重复使用了！满屋皆惊！副总第一个问题就是怎么造成的？这个产品的MacAddress是由测试程序自动分配的。半年多前这个产品投入生产的时候，公司决定生产线外包，所以我给公司内部的生产线留了几百个名额，偶尔做一两个给设计部门玩。那以后的MacAddress都分配给代工厂了。最近突然有批急活公司让内部的生产线来做，结果加一加一的加过保留值了。多少个产品受影响？大概100多对。那些产品都在哪儿？老的那一批有的发货了，有的在公司各部门；新的一批。。。我转头问生产部门的头儿最近N天（第一次出现重复产品的日期，我从测试数据库查到的）有向外发货吗？回答是“没有，今天马上会发一批。”好，我会后立刻去找去截！我再回头和副总要求把设计部门的负责人找来，因为改那个MacAddress没那么容易，需要设计工程师的帮助。立马就找来了，然后设计部门负责人答应会后带我去找相关的工程师，让他全力帮助我研究解决方案。副总又问，以后怎么防止类似情况？我回答：1、在测试中检查新分配的 MacAddress 是否已经存在和是否在保留值区间之内；2、把保留值在各个公司厂子之间怎么分配及相关措施写文档放入Agile系统管理。最后副总说去干吧，实在不行明天可以不去出差。后来怎么干的就不细说了。反正是忙了一整天，比平时晚下班一个多小时。终于找到所有（新）重复的那一批货，专门给这批货写了个小程序修正它们的MacAddress。自己测了几个没问题又训练了俩工人。让他们转天一大早就处理剩下的。有问题给我打电话。第二天一大早去机场的路上和上飞机之前一直远程监控，果然啥事儿没有都修正了。教训啊！以后手不能懒，有可能出事儿的地方一定得把防护措施做好，不能迷信什么预测路线图啥的。把自己的工作做好，甭管其他人怎么折腾。对自己惹祸之后的表现，我还是满意的。情况发现的及时，处理的果断，最后的修正一个上午就完成了，也没耽误出货。虽然不能说是虚惊一场，但毕竟大事化小，小事化无了。。。; 个人分类: 工作纪事|242 次阅读|16 个评论

1 2 34 / 4 页

		自动登录	找回密码
密码			注册