本故事純屬虛構,請勿對號入座,更別把故事跟作者mapping
================================
公司的會議室裏,VP of Engineering踱來踱去,一臉的震怒:
“這個memory的問題,為什麽產品Ship之前沒有抓到?你們,Hardware Engineering, Software engineering 和 Testing Engineering, 全部失職!你們知道這個bug會給公司帶來多大的損失?這個大客戶,已經連續在一個星期內,由於這個Bug,發生過四次Network Outage。知道這意味著多少$嗎?這個客戶已經要求在全網範圍內swap out 這種型號的line card,所有的RMA, logistics, etc,費用都是公司負擔, cost 大到不可想象!”
Testing Engineering的老印總監馬上說:“Software 出Beta release的時候一直都不能on time delivery,我們要meet FRS的deadline,能夠把所有的feature測完已經很不容易。customer scenario就沒有時間很密集的測了。”
Hardware Engineering的老印總監也隨其後說:”我們的hardware,一共spin過4個version,每一次的proto type,都是一早就準時交到software 和testing手裏了,他們從來沒反饋回來說有發現過memory的error。
VP 轉頭對著Jack,臉色很難看的說,“你們software,那一張Line card的feature,是誰負責寫的?”
Jack還沒開口,綺霜說,“是我們組負責的。”
VP很硬氣地說:“我不管你用什麽辦法,立刻找到bug的root cause,先給客戶交一個root cause analysis,然後趕緊出個fix!”
綺霜說,“我需要testing部門先allocate resource, 搭一個類似客戶環境的test bed, 跑一下客戶用的所有feature和等同於客戶用的網絡traffic 流量,reproduce了這個bug,然後我的staff才能debug找出root cause。而且我覺得hardware部門也得在這件事上allocate 資源,我們現在隻知道有memory的error,並不知道這是一個hardware的bug,還是一個software的bug,如果是software的問題,那我部門當然全力以赴立刻出個fix,可是如果是hardware的bug話,問題就大了。"
Testing的老印總監叫苦連天,說我們現在無法分出資源,要reproduce 你們software自己reproduce, 或者你們去找客戶支持部門reproduce.
Hardware的老印總監也說,就是,我們忙翻天了,你們software先去reproduce/debug,如果真不是software的問題,再hand over給我們。
綺霜說,”我們software也在開發新feature新產品忙翻了天,而且我們也沒有那麽多的設備可以用,我也沒精力去跟TAC(客戶支持部)扯皮,你們testing部門一定得搭環境reproduce"
VP盯著綺霜看了一眼,有些不耐煩的說:“你們各部門之間別相互扯皮了,測試部去找個Engineer搭環境reproduce, software 找個engineer負責debug, hardware待命,三天之內,一定要有root cause analysis 和solution!"
晚上12點,綺霜一臉疲憊的回到家。李毅抱住她,說,怎麽樣,知道是什麽問題了嗎?
綺霜搖搖頭,測試部的工程師還沒把問題複製出來,我剛和下麵的工程師 review了我們所有可能trigger memory error 部分的code,沒發現有什麽可能出錯的地方。
然後她歎了口氣,說,你說老印們,出了問題永遠能理直氣壯的把責任推給別人,我們當初software 不能on time delivery,是因為Sales和你們產品市場為了贏客戶不停的加feature進來,他們測試部當初在代碼 沒有ready的時候有大把時間可以用心寫出很好的t測試計劃,囊括很多customer cases,然後automate 測試計劃,等我們的代碼一ready,立刻run script來測試所有的test case,完全不會耽誤任何測試. 可是他們並沒有這樣做,所以後來測得很匆忙,很多Scenario都沒有測到。這個bug就是個show stopper,如果他們在測試期間抓到,FRS 的dealine 是一定會延遲的。現在問題這麽大,給公司造成這麽大損失,那個Ravi可是輕飄飄一句話就把問題轉移到software來了。