日盛金控被CONTROL-M套牢了！
CONTROL-M Migration服務版本升級經驗談
專訪：陳幼健日盛金融控股公司資訊處研發支援部協理
吳奇澤日盛國際商業銀行資訊處商業智慧部專案襄理
因鑑於金融商品的整合與跨業經營已是金融業的未來趨勢，為順應全球金融發展潮流，日盛金融控股公司（以下簡稱日盛金控）為提供更多元化的商品與服務，自93年元月1日起，改以功能為導向，將業務調整為個人金融、法人金融、投資理財及財富管理四大事業群。
隨著金控版圖的擴大，在整合各子公司商品的同時，也面臨如何有效整合各子公司資訊系統的挑戰，而這挑戰除來自於技術上整合的困難度外，也包括不同系統間作業平台的差異。目前日盛IT業務的發展多是依據各單位不同的業務目的、需求及作業平台而不同。這種跨平台的作業環境，優點是存放在各系統裡的資料容易交換存取，彼此互通有無，缺點是易產生如檔案到位的確認、資料日期的確認、資料內容的正確性與否、及資料流程控制等問題，所以日盛金控採用CONTROL-M商業批次流程控管軟體做為解決大量批次作業所導致監控不易問題的解決方案。
升級原因：舊版淘汰、新版新增功能強大
為何日盛金控要趕在2007年年底前完成CONTROL-MMigration的版本升級？吳奇澤襄理打趣的說，「主要是因為美國原廠BMC公司已不支援舊版的服務與維護。此外，新版的CONTROL-MMigration有特別加強Security安全控管與監控的功能，也是我們這次急欲完成版本升級的主因。」他指出，新版CONTROL-M有一個很大的改進，因舊版排程的執行歷程在UI介面僅保留一個工作日，這些資訊在批次作業完成的跨日後即無法再透過UI介面來檢視，一旦監控人員還需要這些資訊參考或除錯，維護人員就要花較多時間成本從資料庫或檔案系統調閱相關記錄，進行查詢比對與確認，但新版對於資訊的保留僅需透過監控畫面就能做完全的呈現，滿足日盛金控在這方面的需要。
除上述原因外，陳幼健協理指出，不管是舊版或是新版，日盛金控對CONTROL-M的依賴性只會愈來愈高。他說，日盛未使用CONTROL-M進行批次作業的流程控管前，從批次作業開始執行最快也要當日下午四點鐘才能產生隔日報表，但有了CONTROL-M後，現在報表大概中午時就能取得，在時間上與效益上可說是整整四個鐘頭的前進，對日盛金控的影響與幫助很大。陳幼健協理進一步說，「套句股票上的術語，就是我們被套牢了！我很難想像日盛若沒有CONTROL-M的話，那麼一天這麼多的Job要怎麼Control？」所以，從現實面的考量，監控與預警功能變得非常重要，而這也是日盛金控必須升級版本的另一個原因。
忽略環境問題 待命30小時辛苦歸於零
回想第一次版本升級失敗的原因，陳幼健協理表示，當時日盛金控沒有很重視環境的問題，是利用VirtualServer來模擬正式的Cluster環境，雖說在執行前就已預測到環境可能會有狀況，但因在升級前有一再地與廠商確認，也得到廠商的保證，所以就將這問題忽略；且為了順利升級，日盛還特地選擇中秋節連假的時間，因為這樣在時間的運用上就多了些彈性，只是沒想到傾全力待命超過30幾個小時的辛苦竟換來失敗的結果，而導致失敗的原因正是環境因素，完全出乎我們的意料。也因為第一次的升級作業失敗，所以日盛金控積極部署第二次的升級作業計畫。
記取教訓與經驗 事前做好萬全準備
由於日盛金控每日批次作業的流程有近三千筆，執行單元（Job）約一萬多筆，面對龐大的資料量，讓這次的CONTROL-MMigration升級服務面臨到一些困難與挑戰，也因為先前的升級作業失敗，讓第二次的版本升級承受較大的壓力，相對的，也讓日盛金控對於每個環節與面向的考慮較前次來得謹慎與周全，在導入前的事前準備演練上，更細分為好幾個面向，如資料面、系統面、服務水準與風險控管來為第二次的版本升級作業做最萬全的準備。
資料面：
由於每日執行批次作業的資料量龐大，使得每日所產生的Log自然也占了資料庫一半以上的空間，因考量到後續歷程的分析作業有其必要性，這些Log須全部保留，經審慎評估後，遂決定將資料按部就班地透過原廠提供的機制進行轉換，而從舊版系統將資料移轉至新版系統多了『匯出→驗證→匯入』的程序，除了必須考慮過程中資料轉換一致性的風險，也須評估轉換程序所花費的作業時間。
系統面：
這部份面臨的變數與不確定性較高，特別是在叢集服務上進行軟體的安裝與升級會面臨到的狀況本就較多，加上新版的EnterpriseManager安裝要由原本不支援Cluster改為支援Cluster等，這次除了在架構設計上做了大幅的調整外，資料庫本身也因Collation機制轉換（631版本支援中文）的關係，或多或少也增加軟體版本升級時的不確定性。
服務水準的維持：
因批次作業是每天例行性的工作，系統服務可允許DownTime的時間有限，由此也可看出第二次升級版本作業在客觀上能運用的時間其實相當緊湊，必須在每一次的批次作業之間「搶時間」，意即在下一個批次日期更新前將版本升級完成，再扣除掉可能的緊急復原程序所須花費的時間與例行的批次作業執行所須花費的時間，經評估計算後僅剩約十幾小時可供運用，時間相當有限。
風險管理：
批次作業產出的資料主要是提供銀行裡眾多業管單位進行資料的分析與查閱，因大多數的資料具相依性與增值性，而批次作業有其時效性，因此，在風險考量下，緊急復原程序的擬定與使用時機必須具體可行且有效率，而緊急復原計畫的啟動判斷原則也須事先規劃定義妥當，唯有如此，IT人員才能在突發狀況發生時立刻採取行動與回應，以確保系統服務的水準不會因此受影響。
密集演練模擬實際架構 制定上線教戰守則
這次CONTROL-MMigration升級工作，是由實際執行單位─研發支援部資料倉儲組主導。此外，系統廠商叡揚資訊亦派遣工程人員從上線計劃協助擬定、長期OnSite測試、問題解決，乃至上線當天全程支援，而台灣微軟也於上線當天派遣工程師分時段進行On Site服務，實際上線時定義CheckList，在幾個主要關卡定義檢核點，確實掌握實際進度。陳幼健協理說：「很感激叡揚，因為他們幾乎把我們的升級當成是他們自己的事情一樣。」吳奇澤襄理則表示，「某種程度大家就像是在同一條船上，因為不管是演練階段的人力支援、或是問題的排除，甚至是與原廠的聯繫，叡揚的人員都很全力的Support我們。」
也因為有他們的支援與配合，及透過不斷演練定義出來的標準程序，讓實際上線得以順利進行。吳奇澤襄理說，為了將版本升級時所有可能面臨到的風險降至最低，日盛金控在上線前半年便著手進行規劃，並在前兩個月進行密集的演練，為了模擬Production實際架構，使用微軟VirtualServer建置Cluster，並著手進行以下作業，將每個演練的過程畫面均予以存檔，記錄作業時間，做為實際上線時程的參考，最後並據此制定實際上線的標準程序（SOP）。
安裝演練：
記錄異常→反應異常→尋求解決方案
資料移轉演練：
A.確認移轉程式對於大量資料的執行是否有異
B.確認排程設計屬性是否可由舊版正常移轉至新版
緊急復原計畫演練：
演練Disk Mirror的復原方式，確保上線異常時可在最短時間內回復
觀察演練環境的排程流路與權限執行狀況：
模擬所有Production設計於演練環境在Migration後的執行狀況
運作效能評估：
A.記錄與檢討相關Job Action花費時間
B.記錄與檢討New Day Procedure花費時間
日盛金控在導入CONTROL-MMigration服務後產生不錯的效益，吳奇澤襄理說，CONTROL-M提高了服務水準協議（Service LevelAgreements，SLAs）實踐的可能，透過CONTROL-M本身的特性與日盛金控自行定義的NamingRule與客製化的機制，提升了維護與管理眾多排程的效率，同時可以集中所有排程的歷程資訊，掌握批次排程的相關細節，任何異常均可迅速發現並進行排除，追蹤結果後續並做分析，在提高業管單位對IT服務水平的滿意度上，它提供了一個可以好好實踐與運作的空間。
由圖一的運作模式中可以了解日盛金控的管理運作模式，CONTROL-M讓日盛金控以最精簡的人力完成數量眾多的排程維護，進而再從這些排程運作累積下來的集中資訊，進行進一步的加值分析。
結論：規劃得宜 苦盡甘來
綜觀看來，雖然這次的升級是在第二次建置才成功，但整體而言，日盛金控認為這次的導入可說是相當成功。陳幼健協理表示，從導入建置的角度，三千多個批次排程的運作，滿足各業管單位例行的報表需求，負責人雖分屬不同的開發單位，但當初在規劃整體架構時，研發支援部即已花了不少時間來架構，因客製化的設計得宜，相關的後續維護資源才能降至最低，任何因應演練環境的設計調整都能快速進行，這也是為何在演練階段僅需部署兩位主要人力，便可進行所有階段的演練及須確認的相關事宜；從結果的角度分析，第二次的導入是在不影響例行批次運作的前提下，進行如此龐大的排程流程資料移轉，所有移轉的排程資料也正常運作便是最好的例證。
若真要針對這次的版本升級提出有待改進之處，陳幼健協理表示，從管理者的角度來看，這次投入這麼多的時間籌備與人力只是為了一套系統的版本升級，而非新系統的上線，那麼對於「成功」的定義實在值得重新權商。吳奇澤襄理也指出，若是將第一次升級失敗投入的時間與成本一併納入考量的話，一套系統的版本升級要耗費5個月（不含評估階段半年）才能完成實在有不少改善空間，另外，在建置過程中與美國原廠的溝通若能更順暢，相信定能節省更多的時間，與避免更多人力成本的支出。