前言

在支持京東集團內部及京東云外部客戶的業(yè)務遷移到京東公有云及京東私有云、京東政務云的過程中，京東科技-京東云事業(yè)群-技術服務組積累了相關業(yè)務系統(tǒng)數據遷移的一些管理和技術經驗，以案例的形式分享給大家，希望對大家的業(yè)務遷移工作有所幫助。

遷移前的準備工作

業(yè)務遷移上云涉及到的業(yè)務數據種類繁多，主要類型包括：

數據庫：

關系型數據庫 MySQL 、PG、Oracle等

對象存儲：

標準S3接口對象存儲遷移中間件數據：ES、mongoDB、redis等

文件存儲：

文檔、圖片等非結構化數據

大數據：

HBASE、HDFS files等

京東云的內外部客戶在上云過程中，大部分業(yè)務均涉及到以上多種數據類型，基于相關遷移的案例所積累的經驗，數據遷移需要在遷移啟動前至少做好如下準備工作。

1、可執(zhí)行的數據遷移技術方案制定完成，包含明確的遷移操作步驟（遷移前準備工作，遷移操作、遷移后校驗工作）、執(zhí)行人、確認人。

2、制定遷移應急預案及回切方案，明確責任矩陣，確認異常情況的決策條件及決策人。

3、確認數據安全等級，確認數據遷移的方案合規(guī)安全，通過相關業(yè)務安全部門審核。

4、遷移時長及割接數據同步窗口的評估（以POC驗證數據信息為基礎制定），確認各個業(yè)務及數據遷移可選的第二方案。

5、 確認網絡帶寬及質量滿足遷移需求。

案例分析

下面是幾個案例，涉及到了不同數據遷移的場景。

一、關系型數據庫

MySQL：

MySQL在遷移中最為常見，也有很成熟的遷移工具和遷移方案，包括官方工具和相關開源工具，如mysqldump等，各個云廠商也都有各自的DTS遷移工具。

DTS工具：

DTS服務在傳輸及同步、數據校驗等步驟都實現(xiàn)了一定的抽象化，具有相對友好的交互界面，同時可以實現(xiàn)多個任務并行進行，對要求平滑遷移的場景，具有自動化優(yōu)勢，節(jié)省大量人力，有部分DTS工具可以實現(xiàn)跨版本遷移。

DTS的限制是：

（1）源端數據庫與目標端數據庫與DTS管理服務IP網絡互通，并具備穩(wěn)定的網絡連接。

（2）數據庫需要滿足一定的前提條件才能實現(xiàn)遷移后的增量同步功能，通常的需求是權限需求，比如REPLICATION SLAVE,REPLICATION等，同時存儲過程及函數在全量+增量的場景下不會被包含，在全量遷移階段，不支持 Alter Table、Drop Table DDL 操作，**不同廠家的工具限制條件可能不同，需要仔細閱讀產品說明，并通過POC驗證功能。

mysqldump工具：

適合的場景，數據庫源端與目的端沒有良好網絡連接或無網絡連接的情況下，允許有一定的業(yè)務中斷時間，則在停機窗口完成數據導出、導入是比較適合的方案（如果具有主機級別的管理和控制能力，直接將數據庫主機整體以鏡像方式遷移也是一個可行的遷移方法）。

Mysqldump導出導入速度相對DTS要快（本地操作，而且與DTS相比，少了一些中間環(huán)節(jié)），但是多了一個數據文件壓縮及通過網絡或移動介質傳送的時間。

其他開源及商業(yè)工具，如streamset等，可以支持mysql到異構數據庫的同步，功能比較強大，同時限制也比較多。

遷移時長的估算：

業(yè)務割接過程中，業(yè)務數據的遷移及同步是切換前的重要步驟，也是割接過程中耗時較長，容易出現(xiàn)錯誤并導致割接延時或失敗的環(huán)節(jié)，因此要對數據遷移及同步耗時做出靠譜的估算。

數據庫同步，是表級別的并發(fā)來遷移全量數據，因此，DTS得結合實際的數據類型、數據行數、網絡帶寬、網絡延遲、同步實例規(guī)格，庫表的數量、單庫表的大小等因素評估時長。

舉例來說，數據庫大小 500G，有5張表，其中一個單表400G，剩下4張表 各25G，因單表400G相對較大，遷移時長會拉長。如果是5個100G的表，遷移時長會縮減。

在正式遷移生產數據前，一般會有對測試環(huán)境的遷移POC，來驗證和評估生產環(huán)境的切換流程及耗時，制定生產業(yè)務割接的計劃時，要以這個時間為數據庫遷移的時長依據。

京東云DTS數據遷移同步架構如下圖：

案例一

從友商公有云遷移到京東公有云云，由于源端binlog問題導致的一次DTS遷移到手動遷移方式的轉換。

項目條件，業(yè)務具有8小時的停服時間，因此在遷移技術方案DTS及手動導數據庫都是可選方案，鑒于DTS的不停服及數據增量功能特性，我們選擇在停服前開始通過京東云DTS服務同步歷史數據，并開啟DTS增量同步功能，基于停機窗口，我們給數據庫在線遷移及增量同步的時間為4小時，DTS服務不影響在線業(yè)務，基于測試環(huán)境的遷移經驗及評估。

在停服前的下午，為了給遷移留出足夠的時間緩沖，我們提前啟動了主數據庫的DTS服務，數據庫遷移進程正常進行，預計遷移時長為4小時，但是在DTS服務最后階段，因源端binlog問題，出現(xiàn)了一個致命錯誤，導致DTS任務失敗。

Migration Task Run Error

ERROR 1236 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.

Region: cn-north-1

ClusterGID: dts-r1rroa

ERROR 1236 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.

因為最終binlog錯誤（部分binglog丟失），DTS任務無法恢復，最終DTS傳輸的4小時時間被浪費，因遷移是系統(tǒng)工程，其他數據遷移進程也都在根據計劃推進，此時大家都沒有時間去分析具體原因。

因到晚上客戶業(yè)務已經推送通知并停服，此時業(yè)務遷移的其他數據遷移及業(yè)務調試已經開始。

所以，當機立斷決定以mysqldump模式導出文件，本地導出速度很快（20M/s），壓縮后的數據庫導出文件體積縮小，減少了網絡傳輸耗時。通過網絡傳輸到京東云側的云主機，然后source方式導入RDS。導出、傳輸、導入整個過程耗時小于2小時。

導入MySQL數據后，根據遷移流程做遷移數據校驗，使用checksum_table工具對源端和目的端數據庫做對比。

源庫信息：—src-host sourceIP —src-user user —src-pass pass

目標庫信息：—dest-host targetURL —dest-user user —dest-pass pass

驗證過程中，發(fā)現(xiàn)部分表不一致，與業(yè)務方確認為源端在遷移開始后，停止服務不徹底導致，仍然有數據寫入操作，因為業(yè)務側并沒有根據遷移規(guī)范檢查mq、kafka的消息產生情況，只是停止了部分服務，后經業(yè)務及研發(fā)檢查新增數據，對部分數據做清理后，完成數據庫的遷移工作。

根據項目經驗，這種DTS服務因binlog問題導致的失敗情況并非個案。

準備工作

（1）為數據庫遷移準備一個備選方案并準備好應急預案。

（2）出現(xiàn)問題時，決策條件及決策人提前確認，在實施過程中能根據需要及時決策做出調整。

廠商改良（非原生）的數據庫的遷移：

在某些云廠商的特定數據庫版本中，會對標準的數據庫產品如mariaDB、PG等數據庫做一些定制化的開發(fā)，以滿足客戶的業(yè)務的某些特殊需求，這種數據庫屬于廠家深度綁定的類型，在做業(yè)務遷移或災備數據同步的時候，根據時間場景做定制化的遷移及同步方案，大部分需要從研發(fā)層面做一些定制化的配置和操作。

案例二

某金融用戶，原系統(tǒng)運行于T的金融云，使用了定制化的RDS服務，因金融行業(yè)的業(yè)務及數據災備規(guī)范，需要做異地容災，目標為實現(xiàn)業(yè)務級別災備，將災備系統(tǒng)運行于京東金融云平臺。

為實現(xiàn)從T云定制化的TDSQL到京東云的遷移，對源端的數據庫做了詳細調研，因為源端是定制化的、具有自動水平拆分、Shared Nothing 架構的分布式數據庫，因此使用京東云的DTS工具不適用于這個場景，同時，在兩個環(huán)境，要求數據基本為實時同步才能滿足業(yè)務容災的需求。

制定方案

在制定數據同步方案時，也對傳統(tǒng)災備廠商的方案做了調研，因傳統(tǒng)廠商災備方案多以主機級別數據及IO分析或日志分析為基礎，需要做一些侵入式agent的安裝，與云上RDS的場景無法適配，相關廠商也表示正在做向云上災備的轉型，但尚未有成熟落地的產品（適配難度較大），因此最終方案采取了基于gtid的主從復制的方案來實現(xiàn)數據庫的異構云同步，屏蔽了架構差異帶來的問題。

注意：涉及業(yè)務信息及底層操作的部分內容已經隱去。

• 首先對源端做權限調整：
  GRANT SELECT, RELOAD, SHOW DATABASES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, SHOW VIEW ON . TO ‘user’@’192.168.%’
• 對源端做全量的邏輯備份：
  mysqldump –h xx –uusername -p –database nx_db -f —single-transaction —master-data=2 —skip-lock-tables > /data1/bs.dmp
  注意導出文件中要有gtid信息。
• 災備端導入：
  mysql –h xx -f –uusername -p < bs.dmp
• 后臺做復制配置：
  set gtid_slave_pos=’0-13381-1xxxx06’;
  CHANGE MASTER TO MASTER_HOST=’sourceIP’,MASTER_USER=’username’,MASTER_PASSWORD=’*‘,MASTER_USE_GTID=’slave_pos’;
• 同步驗證
• 數據驗證
  （1）業(yè)務側停止寫操作，在T云側和京東云側分別通過checksum table tablename對關鍵表做校驗。
  （2）業(yè)務側在T云/京東云兩邊分別執(zhí)行命令，對表/view等做數量校驗：
  select count(1) from information_schema.tables where table_schema=’nx_db’;
  select count(1) from information_schema.views where table_schema=’nx_db’;
  業(yè)務測通過創(chuàng)建測試表/增刪改查等操作驗證ddl/dml是否正常復制。

基礎功能驗證完成后，還需進一步驗證源端數據庫主從切換以及網絡中斷對數據庫同步的影響，對源端數據庫的日志配置，要提出Binlog本地保留時長需求（不少于48小時），避免網絡中斷時間過長導致的日志過期 而影響數據庫的同步業(yè)務。

為保障數據及業(yè)務災備的可靠性，需要對網絡專線做實時的監(jiān)控及告警配置，當出現(xiàn)網絡問題時，需要能及時收到告警，第一時間處理，避免中間專線網絡中斷對災備業(yè)務的可用性的影響。

POC驗證期間曾經對網絡影響進行中斷測試，中斷2小時，后續(xù)觀察數據仍能正常同步追平，能夠容忍實際業(yè)務中可能出現(xiàn)的網絡中斷造成的影響。

對源庫的保護

在這個異構云容災的案例中，因為與源端云是通過專線做了網絡互通，而源端的數據庫是通過IP方式訪問的，因此，在應用主機整體遷移到京東側后，主機仍然可以通過網絡訪問到源端數據庫，這樣有可能對源端庫的寫操作，為阻斷對源端數據庫的訪問，可以采用主機安全組方式，阻斷主機對外部3306端口的訪問，或通過子網級別的ACL，限制對指定網段的特定端口的訪問，在應用配置調整后，數據庫連接指向改變后，再調整安全組條目或ACL策略，放開對應的訪問權限。

因部分數據庫的子網規(guī)劃問題，使用ACL可能對數據庫同步造成影響，因此在此案例，為業(yè)務主機創(chuàng)建一個附加安全組，配置3306端口阻斷策略，實現(xiàn)了對源端數據庫的訪問保護。待業(yè)務調整完成后，解除安全組，即可實現(xiàn)業(yè)務數據的正常寫入。

二、ES遷移

ES應用越來越廣泛，業(yè)務遷移中，ES數據遷移已經成為數據遷移的一個重要部分。

ES遷移技術涉及停服遷移及不停服遷移，不停服遷移對遷移的源端和目的端網絡及服務有很多要求，目前實現(xiàn)起來尚有很多限制，目前一般只在集團內部業(yè)務做ES不停服遷移。

通常停服遷移技術路徑可選擇reindex或snapshot方式及l(fā)ogstash方式，幾種方式均要參考官方對版本的要求，選擇滿足版本要求的遷移方式。

Snapshot方式：

Snapshot方式，從源ES集群創(chuàng)建數據快照，然后在目標ES集群中進行恢復。創(chuàng)建快照前必須先創(chuàng)建repository倉庫，一個repository倉庫可以包含多份快照文件。repository支持S3及共享文件存儲系統(tǒng)等，自建的ES可以使用共享文件存儲（從速度、成本等因素考慮，是最佳選擇），使用公有云ES服務的建議采用支持S3協(xié)議的對象存儲。

從速度和效率上來講，快照方式優(yōu)于reindex，當不需要對源端做任何變更，且網絡存儲條件具備時，優(yōu)先選擇快照方式遷移ES。

reindex是Elasticsearch提供的一個api接口，可以把數據從源ES集群導入到當前的ES集群，實現(xiàn)數據的遷移，reindex適用于數據量較大，有索引調整需求或無法連接共享存儲的遷移場景，以及只需要遷移部分數據的場景。

reindex方式需要目標端能夠訪問到源端ES的服務端口。

案例三

客戶業(yè)務從友商云遷移到京東云，源端ES為K8S集群自建服務，服務訪問方式為nodeport方式，因為安全原因，限制訪問方式為內部業(yè)務主機訪問，服務未通過互聯(lián)網對外開放。

選擇遷移技術方案，源端自建的ES未安裝S3插件，考慮到快照方式遷移需要源端安裝S3插件，而通過POD方式部署的業(yè)務需要重新制作鏡像并更新應用，從時間及工作量上考慮不是最佳選擇，因此采取reindex方式來做業(yè)務數據的遷移。

為實現(xiàn)從京東云側對ES的數據拉取，在源端配置一個nginx反向代理，實現(xiàn)了通過公網對內部ES接口的訪問，同時配置白名單，限制訪問IP為京東側NAT網關出口的公網IP，確保數據的訪問安全。

在京東云側，因生產環(huán)境子網未配置公網出口，為臨時拉取數據，滿足遷移需求，調整路由表，配置明細路由，將源端公網IP配置到對應子網的路由表中，指向NAT網關，臨時打通公網連接，通過NAT網關可以拉取到源側的ES數據，并在ES服務中對源端的公網IP做加白操作，注意加白操作會重啟ES服務。

為滿足網絡通信需求，臨時配置ES子網的明細路由，完成數據遷移后需刪除明細路由。

遷移前，確認相關遷移條件已經具備：

• 源端及京東云ES服務均創(chuàng)建對應索引，需要確認云上索引是新建的，源端與目的端的mapping可以一樣，也可以不同，通過reindex，可以實現(xiàn)修改mapping后的字段類型。
• 可以從京東云側ES訪問到源端云側服務的ES的服務端口，驗證方式，telnet或curl -XGET??http://:9200??方式驗證均可。

在源端創(chuàng)建索引：

源ES集群

1.創(chuàng)建索引（示例）

2.寫入數據(示例)

目標端ES配置

三、對象存儲的遷移

對兼容S3協(xié)議的對象存儲數據遷移，各個公有云廠商（包括部分傳統(tǒng)災備廠商）均有遷移工具或腳本，遷移技術難度不高。但是，因為不同廠家的對象存儲在不同region可能存在底層版本及配置差異。

因此，同一個工具或腳本，在處理不同區(qū)域的對象存儲數據時，可能會出現(xiàn)文件訪問問題，在做遷移前后，需要對遷移的數據做完整性和可用性校驗。

對象存儲遷移的一般順序：

1、目標端配置鏡像回源，保證讀404可以回源拿到數據

2、使用遷移工具遷移源端的歷史數據

3、同步后的數據校驗

實際遷移中，因為涉及到增量數據的同步（遷移工具支持對transfer.coverFile的參數設置，是否覆蓋文件，因此也可以做到增量復制），因此，應根據項目實際的數據存儲量、業(yè)務訪問特性、業(yè)務停機窗口等信息，綜合考慮遷移流程和選擇技術方案。

案例四

某業(yè)務從友商云遷移到京東云，涉及到對象存儲遷移，源端文件數量約為1000萬級別，遷移前，先對源端對象存儲做文件list，檢查遷移工具list數據與對象存儲實際數據能夠匹配，然后通過遷移工具做遷移操作，因文件量較大，而且業(yè)務每天都有新數據上傳，要保證所有文件都正確同步。因此采用的的歷史和增量數據同步方案為提前一周做全量遷移，然后通過鏡像回源同步新增文件。割接前一周做全量遷移

1、 在割接一周前，利用京東云的osstransfer遷移工具進行全量遷移。

2、 遷移后會生成一個以源oss的bucket命名的.list.txt的文件，此文件里含用源oss bucket的所有文件的清單。

3、 遷移日志會生成在遷移的工具包log目錄下，相關log說明（log文件很重要，遷移完成后做了一個異地備份）：遷移的所有文件將記錄在audit-0.log中

遷移成功的文件記錄在audit.success中

可以用命令grep “1$” audit-0.log查看遷移失敗的文件

用生成的源oss的清單文件列表的txt文件中的文件數量和audit.success文件中的文件數量進行對比，如果數量一致說明全部遷移成功。

文件list獲取配置示例：

割接當天進行全量遷移后的增量遷移

1、 利用osstransfer工具生成源oss的清單文件列表。

2、 從文件列表清單中找出全量遷移至增量遷移這段時間內新增加的文件。

3、 開啟oss的鏡像回源。

4、 使用curl訪問新增加的文件(要訪問目標端oss)，進行新增文件的鏡像回源。

實際遷移中遇到了問題：

在POC階段，做測試環(huán)境數據遷移時，采用這個方案驗證一切順利，但是在生產環(huán)境割接時，遇到了問題，判斷增量文件所需的list清單出現(xiàn)循環(huán)錯誤，導致list任務一直運行中，而list的清單有大量重復內容。

遷移軟件版本與測試環(huán)境遷移使用的版本一致，而生產環(huán)境中，遷移軟件在一周前的全量同步的使用也是一切正常。數據也正常同步到了京東云的對象存儲中，割接時需要的是通過回源方式獲取一周內新增的文件，如果list文件不正確，會導致增量的數據同步無法進行。

問題處理

業(yè)務割接時間有限，迅速升級問題，將問題反饋到工具軟件的研發(fā)同事，研發(fā)同事迅速投入排查（已是凌晨，為京東研發(fā)同學的敬業(yè)精神點個贊）。經過研發(fā)同事排查，發(fā)現(xiàn)源端的友商云上，測試環(huán)境使用的對象存儲與生產環(huán)境的對象存儲位于不同區(qū)域（zone），而友商云的生產環(huán)境對象存儲所在區(qū)域的OSS接口在本周做了調整，導致原有工具list出現(xiàn)錯誤。

研發(fā)同事緊急更新一個工具包提供給遷移現(xiàn)場同事，解決了對象存儲文件list循環(huán)錯誤問題，順利完成了文件list檢查，通過對比前后生成的list文件，獲取到新增的文件列表。配置鏡像回源，通過腳本同步了一周的新增文件，校驗無誤后，配置業(yè)務應用啟用對象存儲，業(yè)務啟動及驗證工作繼續(xù)正常進行。

四、redis遷移

業(yè)務中Redis使用有兩種場景，一種是僅作為緩存，不做數據持久化，這種業(yè)務場景，遷移后在新環(huán)境部署業(yè)務后直接調整業(yè)務指向新的redis實例即可，一種是有數據持久化，這種業(yè)務在遷移到云上時，需要根據業(yè)務需求，做redis數據的遷移操作。

Redis有rdb（point-in-time snapshot）和aof兩種持久化方案，其中rdb模式是二進制格式，類似于快照，恢復直接覆蓋，aof保存的是命令（文本格式），類似于追加模式，如果需要保留目標端的redis的數據，可以使用aof方式，aof方式需要把源端redis做停寫操作。Redis加載RDB恢復數據速度快于AOF的方式，但要注意老版本Redis服務不兼容新版RDB格式，因此RDB模式不適用降級的遷移或恢復。

在業(yè)務遷移時，需要根據redis的使用場景、源端與目的端版本要求，數據存儲、網絡條件等選擇適用的redis遷移工具。

Rdb及aof的遷移，官方有詳細的說明（bgrewriteaof/bgsave/redisdump等），使用也相對簡單，因此本文不多做介紹。

京東云研發(fā)了redis的遷移工具redissycner（目前支持自建redis業(yè)務遷移），通過模擬redis的replication協(xié)議，提供redis遷移及同步。

Redissycner通過docker部署方式：

git clone https://github.com/TraceNatur...

進入目錄docker-compose up –d

下載客戶端軟件：wgethttps://github.com/TraceNatur... md?64.tar.gz

調整配置文件：.config.yaml syncserver: http://x.x.x.x:8080 （docker服務地址） token: xxx

注意token文件內容需要在容器中確認。

編輯配置文件后即可啟動服務，通過編寫要執(zhí)?的任務json來配置操作環(huán)境。

{
“sourcePassword”: “xxxx”,
“sourceRedisAddress”: “10.0.1.101:6379”,
“targetRedisAddress”: “10.0.1.102:6379”,
“targetPassword”: “xxxx”,
“taskName”: “testtask”,
“targetRedisVersion”: 4.0,
“autostart”: true,
“afresh”: true,
“batchSize”: 100
} redissyncer-cli -i
redissyncer-cli > task create source ./task.json

五、數據備份的重要性

數據備份是在業(yè)務遷移的全生命周期怎么強調都不過分的環(huán)節(jié)（也包括遷移后的一段時期），因數據備份不充分導致數據丟失、業(yè)務受損的教訓很多，但是，在遷移實施過程中，因忽視數據備份而導致出現(xiàn)問題的事件仍然很常見。

問題可能來自客戶，可能來自我們實施團隊，也可能來自ISV或者其他可能操作數據的團隊或個人。有些問題是因為遷移各個責任方的溝通不充分、宣貫不到位或技術不過關導致，有些是誤操作導致。

實際場景中數據備份實施的壓力或阻力，主要來自存儲空間不足以及備份過程可能造成的對性能的影響。

除了備份的數據文件需要占用存儲空間，數據庫文件的可用性、一致性驗證，同樣會占用大量的存儲空間（臨時），因此在實際遷移過程中，對存儲空間的需求，可能會大于現(xiàn)有數據庫的數據量的2倍（源端及目標端都是如此）。因此，在重要業(yè)務場景中，遷移前，需要對數據備份所需的存儲空間做好評估并考慮備份空間的成本。

案例五

某局委辦業(yè)務由vmware環(huán)境遷移到政務云，在遷移前，筆者為客戶做了所有遷移主機的整機備份（導出到vmware外部的外部存儲中），事實證明這些環(huán)節(jié)（準備存儲環(huán)境、溝通vmware運維方、數據導出耗時等）導致的成本增加是值得的。

遷移過程很順利，在業(yè)務遷移到政務云正常服務完成業(yè)務交接大約1個月后，接到客戶電話，希望能夠通過遷移前備份的主機恢復數據。

問題原因

原因是一個ISV在新環(huán)境做業(yè)務升級時，安排了一個沒有經驗的新人，把數據庫軟件做了重新安裝，并刪除了原有數據。在協(xié)助客戶通過備份的鏡像恢復數據后（歷史數據，新增數據部分由ISV做了增補操作），客戶購買了政務云提供的災備服務，開始定期對重要主機和數據做全量及增量備份，通過云上的容災服務來避免或減少業(yè)務錯誤或誤操作造成的損失。

六、業(yè)務數據遷移總結

1、提前做好備份，有了備份數據，遷移過程的壓力會減小，相對寬松的遷移氛圍對遷移實施很有利。

2、遷移技術及工具的選擇，現(xiàn)在數據遷移工具越來越多，各個大廠也都有自己的工具，但是產品的限制及兼容程度各有不同，需要根據業(yè)務性質選擇并驗證。

3、準備回退預案，做好POC驗證，POC能發(fā)現(xiàn)部分問題，提前準備解決方案。

4、做好流程手冊，明確操作責任人，聯(lián)系相關部門做好遷移的切換階段的護航準備。產品和服務類的問題一定要能找到人支持。

5、明確責任矩陣、進行全面溝通，溝通能夠發(fā)現(xiàn)技術層面很難發(fā)現(xiàn)的問題，越早建立遷移組織并形成有限的溝通機制，對遷移的順利實施越有利。