“變化，無論是突如其來的，還是循序漸進的，有時都會淘汰你認(rèn)為理所當(dāng)然的一切。忽略這一現(xiàn)實，就像近年來許多領(lǐng)導(dǎo)者那樣會帶來毀滅性的后果。”商業(yè)大師拉里·博西迪在他的暢銷書《轉(zhuǎn)型》中曾寫下的這段話，如今看來依然經(jīng)典。唯一不變的就是變化，傳統(tǒng)行業(yè)面對互聯(lián)網(wǎng)、數(shù)字化的沖擊，必須積極需求轉(zhuǎn)型來應(yīng)對變革。

對于電信行業(yè)尤為如此。在國家政策變化、新業(yè)態(tài)沖擊以及用戶飽和等內(nèi)外部眾多因素的影響下，三大運營商的增長放緩甚至下滑已經(jīng)成為常態(tài)。而反映到運營商的IT部門，這就意味著大手大腳花錢的“好日子”已經(jīng)一去不復(fù)返了。如何花更少的錢支撐更多的用戶需求與數(shù)據(jù)量？這是擺在電信人面前的一道難題。

“互聯(lián)網(wǎng)化（以更低的成本以及可線性擴展的云化新架構(gòu)來滿足日益增長的業(yè)務(wù)需求），是公司管理層面提出的新要求?！痹诮邮苡浾卟稍L時，北京電信運維主管隋毅如是說。

狠下一條心，“去I、E”！

過去幾年“IOE”對于電信來說幾乎是標(biāo)配，小型機加高端存儲再配以O(shè)racle數(shù)據(jù)庫的組合能夠帶來足夠的穩(wěn)定性，但后續(xù)擴展與維護的成本不菲，而且這種架構(gòu)在支撐互聯(lián)網(wǎng)業(yè)務(wù)時也已“疲態(tài)盡顯”。隋毅對此頗有感觸。

“我們的計費域和經(jīng)分域核心系統(tǒng)都是基于傳統(tǒng)的IOE架構(gòu)建設(shè)的，最近幾年發(fā)生過幾次現(xiàn)網(wǎng)計費ABM系統(tǒng)在業(yè)務(wù)高峰時期的大交易量導(dǎo)致系統(tǒng)壓力過大、差點導(dǎo)致業(yè)務(wù)無法辦理的情況。這也是我們這次下決心對系統(tǒng)進行改造的主要原因?！彼逡阏f。

隋毅告訴記者，北京電信帳務(wù)、計費和數(shù)據(jù)倉庫（ODS）都是北京電信的核心IT支撐系統(tǒng)。其中，帳務(wù)系統(tǒng)主要實現(xiàn)了帳務(wù)管理、客戶業(yè)務(wù)明細(xì)辦理、業(yè)務(wù)明細(xì)查詢等重要業(yè)務(wù)功能，同時也為其他重要系統(tǒng)，包括計費銷賬、10000號客戶服務(wù)等系統(tǒng)提供重要接口。而ODS系統(tǒng)作為經(jīng)分系統(tǒng)的核心，主要承擔(dān)歷史數(shù)據(jù)存儲、查詢和經(jīng)營分析等功能。這兩個系統(tǒng)對業(yè)務(wù)運行的性能與安全穩(wěn)定有著非常高的要求，同時它們對于整個計費和經(jīng)分系統(tǒng)的正常運行起著不可或缺的作用。

將支撐業(yè)務(wù)運營的核心數(shù)據(jù)庫從IBM小型機遷移至X86架構(gòu)并通過ADG方式實現(xiàn)部分業(yè)務(wù)讀寫分離，同時由閃存替代原有的EMC存儲，對于采用這樣的全新架構(gòu)，并在極短的時間完成跨平臺遷移，北京電信還是第一次嘗試。因此，隋毅也提出了幾點顧慮：

首先，遷移后計費庫、賬務(wù)庫由原來的兩套RAC集群（4臺IBM小型機）變?yōu)橥惶譕racle RAC集群支撐兩套核心庫運行（兩臺PC服務(wù)器），ODS庫則從基于IBM小型機的RAC變?yōu)榛赑C服務(wù)器的RAC，新的平臺與硬件環(huán)境，其整體性能以及穩(wěn)定性能否保證？其次，計費庫、賬務(wù)庫達到5TB，ODS的數(shù)據(jù)量超過10TB，跨平臺的遷移是否能在一夜甚至4個小時之內(nèi)順利完成？

遷移有難度，選型很重要

跨平臺（AIX to Linux）的海量數(shù)據(jù)遷移，對于任何一家企業(yè)來說都不是件容易的事，而選擇合適的方法至關(guān)重要。在經(jīng)過了一系列交流與論證之后，北京電信決定采用“XTTS”（跨平臺表空間傳輸）的方法來實施最終的遷移，并選擇了云和恩墨作為本項目的實施方。

云和恩墨CTO，Oracle ACE總監(jiān)楊廷琨向記者介紹，傳統(tǒng)的OGG同步方式并不適用于超大數(shù)據(jù)規(guī)模的數(shù)據(jù)庫遷移工作。因為跨平臺的數(shù)據(jù)遷移涉及到字節(jié)序的轉(zhuǎn)換，無法采用物理同步的方式進行數(shù)據(jù)初始化，只能采用邏輯同步（導(dǎo)出導(dǎo)入）的方式完成初始化，然而這種處理方式，又會帶來長時間的停機、復(fù)雜的操作和大量測試、數(shù)據(jù)比對的工作，耗費大量的人力、物力，出錯率極高。因此，只有借助XTTS這種兼有物理和邏輯同步優(yōu)勢的技術(shù)，才能完美的實現(xiàn)目標(biāo)數(shù)據(jù)庫的遷移目標(biāo)和要求，這種技術(shù)能夠最大程度的降低業(yè)務(wù)停機時間，同時由于具備物理同步的特性，在同步完成之后也不再需要繁瑣的數(shù)據(jù)比對校驗，能夠確保數(shù)據(jù)的一致性。

而在談到為何選擇云和恩墨時，隋毅表示：“在幫助運營商進行系統(tǒng)升級改造方面，云和恩墨擁有非常豐富的經(jīng)驗。他們曾協(xié)助四川電信等多家客戶成功實施了核心數(shù)據(jù)庫的XTTS跨平臺遷移工作，并且取得了很好的效果。同時，云和恩墨擁有業(yè)內(nèi)最頂尖的數(shù)據(jù)庫專業(yè)服務(wù)技術(shù)團隊，幾乎囊括了國內(nèi)IT服務(wù)商中所有的OracleACE總監(jiān)和大部分Oracle ACE專家，這讓我們對項目成功實施充滿信心、也是我們最終選擇云和恩墨的根本原因?！?/p>

系統(tǒng)遷移的一小步 互聯(lián)網(wǎng)化的一大步

在整個項目中，云和恩墨技術(shù)團隊從前期可行性研究、整體架構(gòu)規(guī)劃、遷移方案設(shè)計與測試、正式實施及后期系統(tǒng)穩(wěn)定性保障，提供了一站式全流程的去IE、升級遷移服務(wù)，同時配備頂級的專家服務(wù)嚴(yán)控技術(shù)專業(yè)度與項目質(zhì)量，確保這些核心系統(tǒng)數(shù)據(jù)庫跨平臺遷移的萬無一失。

楊廷琨介紹，云和恩墨團隊在項目實施過程中從x86服務(wù)器性能與穩(wěn)定性、存儲IO性能、真實應(yīng)用壓力測試、XTTS遷移方案等多方面進行了全方位的可行性驗證，最終通過Oracle XTTS結(jié)合增量備份的方案完成了所有核心庫升級遷移。

事實證明，北京電信的選擇是正確的。在云和恩墨技術(shù)團隊和北京電信的共同努力下，單套5TB級數(shù)據(jù)庫在不到3小時的停機時間就完成了從小型機到x86環(huán)境的遷移。同時，為確保數(shù)據(jù)庫的高可用性、數(shù)據(jù)保護及災(zāi)難時可恢復(fù)，云和恩墨還通過ActiveDataguard（ADG）構(gòu)建了生產(chǎn)數(shù)據(jù)庫的數(shù)據(jù)級容災(zāi)環(huán)境，并借助ADG提供了客戶應(yīng)用的讀寫分離，更為高效的支撐業(yè)務(wù)整體運行。

遷移實施已經(jīng)過去了數(shù)月，在新的環(huán)境下，北京電信計費庫及賬務(wù)庫的整體運行穩(wěn)定，通過高配置PC服務(wù)器+部分應(yīng)用讀寫分離，業(yè)務(wù)高峰時段承載兩套核心庫的主生產(chǎn)系統(tǒng)整體運行穩(wěn)定，平均CPU使用率10%左右，系統(tǒng)整體吞吐量得到了明顯的提升。

對這一結(jié)果，隋毅表示非常滿意：“感謝云和恩墨團隊在本次數(shù)據(jù)庫遷移項目中的辛勤付出。通過本次項目，我們成功實踐了互聯(lián)網(wǎng)化去‘I、E’的要求。在支撐新業(yè)務(wù)方面，系統(tǒng)的性能提升效果非常令人滿意，同時進一步節(jié)約了運維成本，為我們今后互聯(lián)網(wǎng)化工程項目陸續(xù)落地打下了堅實的基礎(chǔ)。”

楊廷琨表示：“當(dāng)北京電信面臨架構(gòu)擴展性問題和大數(shù)據(jù)量跨平臺遷移等難題時，云和恩墨團隊充分發(fā)揮技術(shù)優(yōu)勢，經(jīng)過充分的論證和測試，選擇了技術(shù)實現(xiàn)難度最大，但停機時間最短、對客戶業(yè)務(wù)影響最小的技術(shù)方案。在正式遷移過程中，僅停機3個小時就幫助客戶完成超過5T數(shù)據(jù)量的U2L遷移。單純討論技術(shù)的專業(yè)性和領(lǐng)先性意義不大，只有能夠幫助客戶取得成功的技術(shù)才是有意義的?！?dāng)?shù)據(jù)驅(qū)動，成就未來’是云和恩墨的服務(wù)理念，而通過這次遷移項目，也非常好地詮釋了我們的這一理念?！?/p>

關(guān)于云和恩墨：

數(shù)據(jù)驅(qū)動，成就未來。

整合業(yè)界頂尖的技術(shù)與合作伙伴資源，圍繞數(shù)據(jù)及相關(guān)領(lǐng)域，提供解決方案和專業(yè)服務(wù)。