先說在前面,"史上最長"指的是在我自己的工作史上。  

朋友曾在一家跨國銀行任職Release Manager,經歷過24小時跨國跨區軟體上線的流程。這次經歷的過程沒有他的四分之一久,卻是自己經驗裡,歷時最長、涉及人數最多的軟體上線過程。 

加入新公司即將滿半年之際,第一個全程參與的專案於上週末上線。 

在線上前一個月起,每週兩次的實戰演練會議,已讓我見識到本公司繁雜的流程。  

Outlook會議通知上,洋洋灑灑至少20人以上牽扯其中。
 
光就部門數就至少7個大小部門-3個不同的Development部門,3個系統、網管相關部門,外加一個主導統籌上線的部門。每個部門牽涉的少至1人,多至5~6人,我的部門是這次牽涉人數最多的,包括:本專案的 PM(Project Manager專案經理)、Dev-Client (前端軟體的工程師), Dev-MidTier (Middleware的工程師),BA(Business Analyst-系統分析師), QA(Quality Assurance)。
 
當然真正參與專案的有更多人,出席的就是該項工作的Lead,整體人數算起來令人乍舌。因為人員散佈在不同地方(Toronto, Scarborough與Montreal),只能透過Phone conference每週一一演練上線計劃。計劃包含pre-implementation plan(上線前的前置實作計劃), implementation plan (上線當天的實作計劃), post-implementation plan(上線後的後續作業計劃)與rollback plan(產品上線失敗的回復計劃)。從前端、Middle Tier到後端,一一詳列需要作的事項、負責人員與需完成的時間點。
 
老實講,一開始大家有點像是無頭蒼蠅,有點迷失,尤其是主導會議的新兵愛德華先生,會議節奏沒有抓好,提供的文件落東落西,因為如此有時彼此來往間口氣不好, 火藥味很重。兩週後,在大家陸續提供資訊,愛德華先生也漸入佳境,一個月後,產品發表計畫也終於在幾次來來回回修改中塵埃若定。 

照理說,產品發表後,應該有Smoke Test或是簡單的Regression Test驗證功能無誤,而透過測試結果作Go-No Go Decision。但這次我負責的那個元件,Business那邊大膽的說不需要測試,所以只要新程式擺上去伺服器後,能正常運作就好了。既然這樣,我當時仍不放棄的抱著當天搞不好只需要On-Call的美夢。直到最後一週,PM宣佈我仍得進公司,因為作戰地點(在Scarborough)實在離我太遠,後來在我主管助力下,協調成可以在家裡打電話入場。

整個release流程從禮拜天早上3:00am到7:15am,整整4小時15分。
 
我需要參與的部分從4:30am開始。前一晚因為去參與朋友的生日Party睡時已經凌晨1點多了。沒幾個小時後,勉強睜開沉重的眼皮,起身拿了電話,播了Conference #,向主持當天會議的迪諾小姐,報了自己的名字與部門後,便躺在床上,有如聆聽球賽般,聽著電話那頭傳來的戰況更新。
 
來回喧嘩的聲音,包含著從作戰地點傳來的吵雜討論聲,遠端工作的人回應聲,也有如我需要Stand by的人很微弱的呼吸聲。電話中不時有人回報狀況: " Job 11 is completed.", “I am going to do task xxx” ,我也感染到一絲絲緊張,心理很怕自己負責的元件有什麼狀況,到底該怎辦?! 
 
幸好捷報一一從電話中傳來,終於等到5:00過一刻,宣布我那兩個元件成功更新。 大大的鬆了一口氣,開始閉目養神。六點過後,Middle Tier元件與前端軟體皆更新完畢, 只剩Host(Mainframe)的更新,Mainframe的上線流程最為複雜,從4:45開始,弄到6點都還沒完成,對銀行系統稍微有點概念的就知道,整個重頭戲是在Mainframe的更新,而且如果mainframe 上線失敗, 所有的程式都得rollback(回復),所以雖然其它工作已完成,還是得掛在線上等結果。等了很久,電話中斷斷續續的有人更新狀況, 終於到7:15分,會議主持人狄諾小姐正式宣布release 結束,歷時4小時15分的產品發表才完成。 

3.5小時半夢半醒間腦中的碎碎念:
  1. 目前分行系統使用Client/MidTier/Mainframe3層的Client/Server架構,前端軟體是用C#寫的Standalone Application,中間用Java寫Web Service作Middle-Tier,後端是巨大充滿問號的Host(Mainframe)系統, 開發不用講,養三批完全不同的Developers (C#, Java, Cobol/Assembler),三個部分上線流程又得由不同人在負責. 很多事情本身並不複雜,然而當參與的人增加,複雜程度也呈指數增加。不過也因為如此,這麼多人才能保住飯碗呀。 
  2. Mainframe 到底是甚麼樣的怪物? 為何需要如此長時間更新?
  3. 這個專案從本來只有一個需求,暴增到6~7個,牽扯的人眾多,自己在當中也積歷過幾許不愉快…… 儘管如此,最後,工作還是完成了。
  4. 想到以前產品上線的過程。猶記在台灣工作時,直接FTP檔案到Production Server,完全沒有QA這道程序的經驗。 
  5. 回想到紐約時的工作。當時後期也得負責產品build/deliver,雖然天沒亮就要到公司(記得是早上5點),大部分release過程頂多15~20分鐘,含QA大概半小時。資料庫更新/系統更新在deploy EAR 到Application Server期間可同步完成,涉及的人只有我們自己team的人(通常只有2~3人),最大的一次有整個team都到(大概10人左右),歷時應該不超過1小時。
  6. 紐約時期的系統是J2EE Web-Based Application, live user亦有十幾萬, 4個Application Servers、4個Web Server,並不是很小的系統, 但產品上線的流程有效率很多。
  7. 銀行內部系統雖是在全加拿大分行使用,影響層面包含公司本身的營運,需要小心是可以理解。有時過分的保守不但導致本身固步自封並饌養了一群不願改變的人

上線隔天, 從早上7點到11點開了一個War Room, 監視任何從分行回報的狀況. 我也被指配參與其中一個小時, 幸好整個過程無風也無雨. 至今為止尚未有任何問題回報. 

希望這樣的平靜能一直維持下去到正式結案呀!

創作者介紹

女工程師的美加生活手札

nycEngDiary 發表在 痞客邦 PIXNET 留言(0) 人氣()