這事該怎麽處理

本文內容已被 [ DCH ] 在 2010-10-25 20:31:17 編輯過。如有問題,請報告版主或論壇管理刪除.

上周我們組出了紕漏,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

請您先登陸,再發跟帖!