拒絕服務

已經第四天了，系統還是在『上線中』。

一路上不停的踢到鐵版。

資料轉移在延誤兩天之後順利結束，大家興奮極了，急忙把系統放上去打開來玩。其實第一天的資料轉移是個警訊，是系統強度的縮影。會延誤兩天不是沒有原因的，上線後幾分鐘，就看到CPU利用率暴增，IO暴增，連線逾時被踢出去的問題。這是我這輩子第一次親眼看到Denial of Service拒絕服務。原本大家興奮的心情一瞬間盪到谷底，開始悶著頭找問題。基本上這就像是你開了一家超市，員工就位，收銀機起動，但卻因為顧客太踴躍，大家還沒有到門口就互相踐踏掛掉了。任憑你店裡再美，員工再好，進不來就是進不來。

老實講我以為大家會像我以前的單位那樣，靜靜地看這我們計畫死掉。然而這七天，全公司相關的主管都動員起來，輪流照顧我們的伙食，一天一夜後，我們重寫了三分之一的stored procedures，系統開始有了起色。OS/400對我來講完全是個神秘的系統，還好公司裡的專家們不停的進來我們戰情報告室幫忙，十二個小時不停的輪班分析是IO太重還是CPU太重，甚至還請出了幾個原廠資料庫的設計大師出來解題，所以幾乎每天都看得到成長。兩個DBA輪流上陣抓瓶頸，兩個系統管理員輪流坐鎮，還有兩個作業系統專家輪流調整設定，更不用說我們程式開發小組全天候待命了。

在最艱困的那幾天，一頭白髮的副總裁在半夜驅車來IT部門為我們加油。每一次重新起動就是一次新記錄。七天後，我們的系統終於百分之百運轉上線。我從來不知道一個計畫的成功背後會有這麼多的力量，除了感謝，還是感謝。真的很幸運，能與這樣的同事一起工作。

我要勇敢

系統上線日。

籌備長達五年的系統終於到了上線的時候，前幾年一直系統難產的低氣壓也因此漸漸有了變化。最初計畫剛成立時，閃亮到登上雜誌裡面。一年一年過去，計畫承諾越來越大，完工卻遙遙無期，最大的計畫成了最大的笑話。環繞在中大型主機系統與微軟平台的我們，就成為樓裡最低調的一群人。

後來公司調來一位專案經理，這位經理上來之後，把計畫的範圍明確的畫出來，沒在範圍內的一律幫我們推掉。幾個月的時間，計畫開始有了轉機，甚至出乎意料地在今年上半年就能上線。

我們系統今天上線，目的是要取代原本的舊系統。既然要取代，就要把舊系統的資料轉移到新平台上。因為設計觀念與商業需求的增加，新舊系統的資料模型有很大的不同，因此不是說把表格轉一轉就能解決的。也就是因為這樣，我們必需要先把舊資料匯入新系統，再轉存成新資料。我知道這聽起來很遜，但資料轉移真的是很大的工程，只要漏報一筆，就會讓大家擔心是否轉換有瑕疵。這還不是最慘的。最慘的是，別人的計畫資料是死的，例如上個月的帳目這個月還是不變，所以可以在上線之前提早處裡。而我們的資料不能作這種假設。因為這樣，我們必須要在系統維護期四十八小時內把用戶導出去，然後把熱資料完整轉移上線，否則就要退回原點。

這就是一切問題的來源。在這四十八小時裡，我們遇到了想像中與想像外的各種狀況。系統比預期的轉移速度要慢了好幾倍，而且，就在接近一半的時候，報出了核對結果有誤的惡耗，原資料品質有問題，而且不只一處。一路上找出了好幾種修正程式，想辦法補救轉移後的資料。這時有了兩種不同的聲音。

一派人主張先完成，再回來修整。我的師父認為要往回退，從第一次出錯的那點起，重頭開始。既然前三十六小時累積了資料品質的經驗，後面要重新開始應該不是難事。兩派人爭議不斷，我卻沒有勇氣挺身而出。我是贊成重新開始的，但卻不敢承擔丟掉三十六小時的風險。對於自己的不夠勇敢，我覺得很遺憾。

我丟掉七年的時光找到自己最喜歡的工作，卻因為擔心喜歡的工作而捨不得三十六個小時。妥協的人永遠只是笑話。希望我能夠勇敢一點，不要再作一個妥協的人。

大船入港

上星期全世界最大的遊輪開到邁阿密來了
趁著公司之便參加了一個小時的快速導遊
這船還真是大到有點扯
裡面還有一條商店街 好像捷運地下街那樣

VB6回來了

今年的Java One研討會跑出來一個怪東西：Project Semplice。

這個計畫使用Visual Basic 6來寫Java，想必是要吸引還沒有轉換到的系統改用Java。

想來有點好笑，先是Java帶走了VC++的程式員
然後是C#帶走了Java程式員。現在Java再想要帶走另外一批VB6。然而根據目前的計畫進度，我想，要能吸引VB6程式員還很早。VB會受歡迎，不是因為他語言本身有多優雅，而是廣大的OCX/VBX元件。如果不能面對現實讓它運行Windows的元件。那麼就不可能有人願意轉換。這是最難的一部份。

不管怎麼樣，還是覺得有這些點子也蠻好的。