遷移這個活對公司內部成員來說不是功勞苦勞，是應該幹好的，不出現問題是應該的，出現問題就要追責。一入運維深似海，萬年填坑填不平。
一、目標
機房搬遷整體方案是為了平穩遷移所有業務，在有限的資源和有限的切換時間（甚至秒鐘級別時間內）完成搬遷（銀行、ATM之類的公司不能比，在不提供新資源或者提供基礎幾台資源的情況下搬遷）， 保證機房業務和數據能夠安全、可靠、快速的搬遷。
二、 背景
現今IDC跟10多年前IDC不同，第一是數量開始增多，第二是價格下降，第三是很多公司使用公有雲替換了IDC，當然也有使用公有雲+IDC的公司。總之現在因為需求的不同，各種方案都有。(使用公有雲替換自己租IDC的公司，主要考慮自己維護管理機房、采購伺服器、後期維保伺服器等不是專業的，專業的事交給專業的公司幹，將公司的精力集中到公司業務，當然關鍵的還能提升運維效率，如，一個計畫立馬上線，如果普通中小企業無備用伺服器的情況下，就需要立即購買，可能會有選型、招標過程，這樣整個采購周期就很長，計畫上線可能延遲。如果使用雲幾分鐘就完成任務）。
三、 遷移前的考慮
（其實這裏搬遷到雲上已經包含其中，當然有一些沒法搬遷的後面補充）
1、 機房標準：環境了解，機櫃位置了解，機房 動環系統 ，pdu插口是否滿足需求。
2、 一般租用的機房公司，他們是否給巡檢，是否有基本的上架，梳理線纜服務（實際工作中，上架、拉線、綁線很浪費時間，最後還不是很美觀。）
3、 機房專線進入是否方便，進園區是否收費，機房所在公司是否在收埠費用，埠費用有多貴？
4、 網路如何規劃，需要多少個接入交換機，路由器、防火墻，是否滿足高可用，是使用大二層還是3層網路？是使用基於單個主機冗余（交換機浪費，但是適用於中小企業），還是基於整個機櫃甚至整排機櫃的冗余？我們曾經的機房是基於主機冗余（單台主機雙網卡繫結），現在新機房是使用基於機櫃冗余（允許宕機一個機櫃）
如果是公有雲：考慮網路規劃、網段、安全組等基礎環境配置，然後考慮專線跟IDC打通。
四、 搬遷團隊（運維人員+開發+業務）
1、 是否僱用專業搬遷公司，還是自己搬遷+僱用車。原則上是重要裝置、高端儲存之類的裝置僱用專業公司進行搬遷，普通x86伺服器，多節點的業務，自己搬遷即可。（可以節省很大的成本）
2、 一般情況下搬遷團隊是由公司運維部門擔任，當然一般搬遷都是公司大事，必須知會各個開發部門領導和產品，甚至開專門的動員會，這樣開發才會配合支持。
五、 原機房註意事項
1、 統計搬遷的數據：機器數量、分別每個機器的u數，分類搬遷。
2、 準備打包箱子、標簽紙、紮帶等
3、 小型機連結線務必輕拔輕放，包裝好。
4、 根據業務型別劃分搬遷次序，分配到責任人，責任人務必包含運維、開發、產品。比如：支付系統、行銷等
5、 辨識特殊系統，比如：有停機先後順序的，帶儲存的，掛載有nfs的系統，帶狗的系統，有物理機授權等。
六、 針對每套系統具體方案編寫
1、 按照具體業務列出具體系統中的每個模組，如行銷系統中的優惠券、活動，采銷系統中的訂單、主數據等，越細越好。
2、 按照每套系統的每個模組編寫文件，內容包含原主機ip、部署內容、部署路徑或者目錄、緩存ip、資料庫連線ip，zk地址等等，所有詳細資訊均要列出。
3、 與開發溝通編寫api部份模組，具體到呼叫介面和http介面，所有介面都要列出（後期用於驗證）
4、 網路層面許可權檢視，是否有特殊限制，比如分支機構或者分公司是否有許可權存取。
5、 網域名稱檢視，是否有公網。
6、 註意點：如tomcat是否有使用者限制，最好方式是將tomcat直接打包原路徑解壓。即使是平台管理也可以這樣操作。
7、 資料庫連線檢視，是否有共用庫的情況，是否有大數據抽數，是否有其他特殊許可權。
七、 具體切換方案
1、 閘道器或者負載均衡按照原配置配置即可，後面切換dns即可。
2、 Web層大部份系統為基於互聯網的多web或者多模組系統，1：1部署即可，按照第六步統計結果進行部署即可。
3、 Redis、mysql、mongodb采用數據同步
4、 Es采用加入集群同步數據方式，完成後把老機器踢出集群。
5、 如果有Oracle，采用OGG或者DG同步到新機房，提前配置套用JDBC連結，當數據追平時，重新開機套用即可生效。這步說來簡單，實際辦起來可能因為數據大小，或者每天產生的數據過多，會導致效能問題。當然還有一些其他的問題，細節上要註意，多想問題。
6、 最難的就是一些老系統，比如一些win系統，開發走了無人維護，甚至一些系統是購買的商業軟體，但是這個商業軟體公司已經倒閉。這種系統最麻煩，一般采用硬搬，當然要備份相應的數據。
7、 小型機和儲存搬遷也是麻煩事，註意上面拆除小型機，一些連線線要保存好，儲存這個該買保險買保險。
八、 具體切換
1、 按照上面7個步驟該準備的準備，越細越好。
2、 提前將新環境部署好，只等待dba同步數據，等到數據同步完畢，每套系統按照具體的修改程式碼送出，釋出，連結到新機房的庫。
3、 資料庫檢查連結正常，即可驗證業務。
4、 產品通知業務一起驗證業務。
5、 回顧切換過程中的問題，形成總結文件。
九、 總結
以上幾點均是我在搬遷工作中形成的一些經驗，越細越不容易出問題，一般遷移切換選擇閑時進行，比如晚上或者半夜遷移切換，往往第二天早上因為一個配置疏忽造成業務受影響，所以重要系統，重要配置最好雙人檢核，避免出現事故。
遷移這個活對公司內部成員來說不是功勞苦勞，是應該幹好的，不出現問題是應該的，出現問題就要追責。一入運維深似海，萬年填坑填不平。
