close
先說在前面，"史上最長"指的是在我自己的工作史上。
朋友曾在一家跨國銀行任職Release Manager，經歷過24小時跨國跨區軟體上線的流程。這次經歷的過程沒有他的四分之一久，卻是自己經驗裡，歷時最長、涉及人數最多的軟體上線過程。
加入新公司即將滿半年之際，第一個全程參與的專案於上週末上線。
在線上前一個月起，每週兩次的實戰演練會議，已讓我見識到本公司繁雜的流程。
Outlook會議通知上，洋洋灑灑至少20人以上牽扯其中。
朋友曾在一家跨國銀行任職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分。
照理說，產品發表後，應該有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小時半夢半醒間腦中的碎碎念：
3.5小時半夢半醒間腦中的碎碎念：
- 目前分行系統使用Client/MidTier/Mainframe3層的Client/Server架構,前端軟體是用C#寫的Standalone Application，中間用Java寫Web Service作Middle-Tier，後端是巨大充滿問號的Host(Mainframe)系統， 開發不用講，養三批完全不同的Developers (C#, Java, Cobol/Assembler)，三個部分上線流程又得由不同人在負責. 很多事情本身並不複雜，然而當參與的人增加，複雜程度也呈指數增加。不過也因為如此，這麼多人才能保住飯碗呀。
- Mainframe 到底是甚麼樣的怪物? 為何需要如此長時間更新？
- 這個專案從本來只有一個需求，暴增到6~7個，牽扯的人眾多，自己在當中也積歷過幾許不愉快…… 儘管如此，最後，工作還是完成了。
- 想到以前產品上線的過程。猶記在台灣工作時，直接FTP檔案到Production Server，完全沒有QA這道程序的經驗。
- 回想到紐約時的工作。當時後期也得負責產品build/deliver，雖然天沒亮就要到公司(記得是早上5點)，大部分release過程頂多15~20分鐘，含QA大概半小時。資料庫更新/系統更新在deploy EAR 到Application Server期間可同步完成，涉及的人只有我們自己team的人(通常只有2~3人)，最大的一次有整個team都到(大概10人左右)，歷時應該不超過1小時。
- 紐約時期的系統是J2EE Web-Based Application， live user亦有十幾萬， 4個Application Servers、4個Web Server，並不是很小的系統, 但產品上線的流程有效率很多。
- 銀行內部系統雖是在全加拿大分行使用，影響層面包含公司本身的營運，需要小心是可以理解。有時過分的保守不但導致本身固步自封並饌養了一群不願改變的人。
上線隔天, 從早上7點到11點開了一個War Room, 監視任何從分行回報的狀況. 我也被指配參與其中一個小時, 幸好整個過程無風也無雨. 至今為止尚未有任何問題回報.
希望這樣的平靜能一直維持下去到正式結案呀!
全站熱搜
留言列表
多倫多 (1)