这事该怎么处理

本帖于 2010-10-25 20:31:17 时间, 由普通用户 DCH 编辑

上周我们组出了纰漏,Production 运转过程中能 down 了两小时。 查了查怀疑和一个Configuration有关。 Error Log 里说一组Config的某个参数 的名字在两个Prod Server 上不Match。 Production 的这个Configuration 都是小老板做的。 后来他们想在UAT 上复制错误,我因为在UAT看见过类似错误,一般我看见就改正了,不改也没发现有大问题。正巧那天UAT的一个Server也有点问题,我就在电话上讲可能UAT 也还有类似的Configuration 的问题。 后来小老板去看果然发现有一个地方也有这个问题。 

结果今天跨组开会时,一个同组的老印就说我其实知道UAT 有问题,但一直不告诉他们。 他用一种半开玩笑的口吻。 我就说没有啊,我是说UAT 可能也有类似问题,何况并不知道这个Config的问题有什么后果,也 没有人天天去看Log。  然后小老板就说,O, 现在你又说是“可能”了。 下来我听他们还在私下嘀咕我说没说“可能”二字,反正对我挺有意见的。

我就接触了UAT,对PRODUCTION的这个COnfig 根本就没Involve。 小老板又不是Copy我在UAT的config,他自己搞错了我觉得没有理由认为我有责任。 因为很多PROD 的东西都是我在Config,我们组一些不知情的人就误以为这个东东 也是我Config 的,交谈中才知道是小老板。 我现在不知道小老板怎么汇报给大老板的,你们觉得我有必要跟大老板解释Production不是我Config 的而是小老板一手操作的吗?我本来不打算去解释的,但看了今天小老板几次谈起UAT 也有类似错误又说我知道UAT有问题没汇报时我总觉得不太放心他背后怎么讲这事。 你总不能说UAT Config有Typo,你自己在Prod 就可以有一堆错吧,你又不是照UAT 搬过去的,起的名字都不一样,和UAT 没关系。我看见UAT 有错自己改了要汇报什么呢,如果还有没改完的我也不知道啊。 我觉得我被搅进去了。大老板对这事看得挺重的,因为PROD down 时很难堪。小老板当时在电话上只说他发现一个Config 的错,也不说谁做错的,什么样的错,大老板几次说他很感兴趣到底是什么错,后来我就问是不是这个东西的Config 的错,还把错讲了出来讨论了一下。  大老板后来问谁来解决这个问题,小老板就说这事他来解决,也没说是他搞错的。

你们说我该忍了算了还是去跟大老板解释一下?怎么解释比较好?

所有跟帖: 

不解释,没用,而且也不是大事儿。 -吃糖?- 给 吃糖? 发送悄悄话 (112 bytes) () 10/25/2010 postreply 20:31:08

回复:不解释,没用,而且也不是大事儿。 -DCH- 给 DCH 发送悄悄话 (179 bytes) () 10/25/2010 postreply 20:34:23

说的就是developer, -吃糖?- 给 吃糖? 发送悄悄话 (428 bytes) () 10/25/2010 postreply 20:51:23

我们那挺乱的,这种小改动根本没人汇报。 因为没有看见Impact -DCH- 给 DCH 发送悄悄话 (179 bytes) () 10/25/2010 postreply 21:04:20

“不需要汇报”这种观念很危险 -布衣之才- 给 布衣之才 发送悄悄话 布衣之才 的博客首页 (138 bytes) () 10/25/2010 postreply 20:56:06

这事该怎么处理关键是看你在公司的地位和你小头是什么东西 -美国老土- 给 美国老土 发送悄悄话 美国老土 的博客首页 (148 bytes) () 10/25/2010 postreply 20:32:12

回复:这事该怎么处理关键是看你在公司的地位和你小头是什么东西 -DCH- 给 DCH 发送悄悄话 (285 bytes) () 10/25/2010 postreply 20:39:54

不是谁谁操作的错,而是操作规程不规范造成的 -布衣之才- 给 布衣之才 发送悄悄话 布衣之才 的博客首页 (307 bytes) () 10/25/2010 postreply 20:50:50

布衣说的有道理.那还是得解释,只是老板会信他么? -俗世痴- 给 俗世痴 发送悄悄话 俗世痴 的博客首页 (0 bytes) () 10/25/2010 postreply 20:53:06

不是为自己解释,也不是推托或是找谁的错,而是建议改进。 -布衣之才- 给 布衣之才 发送悄悄话 布衣之才 的博客首页 (0 bytes) () 10/25/2010 postreply 20:57:10

"我看见就改了"你不应该改.你应该发个email告诉对方什么地方有问题 -俗世痴- 给 俗世痴 发送悄悄话 俗世痴 的博客首页 (0 bytes) () 10/25/2010 postreply 20:43:25

这里不存在对方,我自己改自己的错 -DCH- 给 DCH 发送悄悄话 (55 bytes) () 10/25/2010 postreply 20:47:04

哦,那你就有责任.应该解释一下.毕竟是你做的coding,虽然你改了 -俗世痴- 给 俗世痴 发送悄悄话 俗世痴 的博客首页 (0 bytes) () 10/25/2010 postreply 20:51:40

你没看懂。是Server的某个Config。 我Config 的UAT,他做的PROD,但参数名字是另起的,和UAT没有直接关 -DCH- 给 DCH 发送悄悄话 (0 bytes) () 10/25/2010 postreply 20:57:17

解释的确没用,当时应该争取你解决问题才是 -iCall- 给 iCall 发送悄悄话 (19 bytes) () 10/25/2010 postreply 20:44:27

我怕我争取解决让人误会是我搞错的 -DCH- 给 DCH 发送悄悄话 (0 bytes) () 10/25/2010 postreply 20:48:22

职场上看见别人错误不讲是对的,电话中不该讲 -iCall- 给 iCall 发送悄悄话 (171 bytes) () 10/25/2010 postreply 21:02:57

私下呢?私下需要讲吗?我不想别人的跟头栽到我头上 -DCH- 给 DCH 发送悄悄话 (0 bytes) () 10/25/2010 postreply 21:06:34

不要怕担责任,重要的是怎么解决问题,以后怎么防止类似问题, -吃糖?- 给 吃糖? 发送悄悄话 (152 bytes) () 10/25/2010 postreply 21:19:15

”人家要是想往你头上栽,你也逃不掉题“,我很反感这个说法,没道理。 -DCH- 给 DCH 发送悄悄话 (0 bytes) () 10/25/2010 postreply 21:22:52

你需要当老板,当过了,你就能切身体会老板关心什么,不关心什么。 -吃糖?- 给 吃糖? 发送悄悄话 (0 bytes) () 10/25/2010 postreply 21:41:17

不讲,就等看笑话,俺也谈一件俺的事 -iCall- 给 iCall 发送悄悄话 (752 bytes) () 10/25/2010 postreply 21:41:48

你!你!你的心理上有点奇怪。不要随便越级。 -眼冒金星- 给 眼冒金星 发送悄悄话 眼冒金星 的博客首页 (0 bytes) () 10/26/2010 postreply 00:43:32

综上大家所述,找机会提预防方案是一招。 -驴驴- 给 驴驴 发送悄悄话 驴驴 的博客首页 (654 bytes) () 10/26/2010 postreply 06:46:22

he did not copy it to prod; he named prod stuff his way and had -DCH- 给 DCH 发送悄悄话 (297 bytes) () 10/26/2010 postreply 06:56:09

细节咋描述可以推敲。不一定要真take别人的fault,只是种姿态。你咋不明白呢? -驴驴- 给 驴驴 发送悄悄话 驴驴 的博客首页 (648 bytes) () 10/26/2010 postreply 07:05:47

请您先登陆,再发跟帖!