遷雲的那些事

雲的時代：
雲時代已經到來，在選擇雲以後，企業首要的問題是選擇什麼樣的方式遷移上雲？這會影響企業的遷移週期和遷移後的業務服務品質，因此遷移時必定要按照必定的方法論和流程，而不是盲目的遷移。最基本的也要遵照這五個過程：計劃，設計，遷移，運營及優化，在這套方法論裏面您能夠按您們的實際業務狀況進行微調。
全部雲廠商裏面，AWS擁有最完善的遷移方法論。例如：CAF（採用雲框架），LandingZone，Well-architected（良好的架構）和三天遷移培訓課程，這些能使您意識到使用雲會是一種什麼樣的模式，解決您在使用過程當中的疑問。我的認爲一個AWS初級用戶學習CAF的方法論更爲關鍵，這樣可讓您對雲有更深次的使用體驗。

借鑑咱們過往的經驗，咱們建議客戶在AWS上有小量的應用後，再來研讀Well-architected，Well-architected中的專業術語較多，建議能夠進行初步的瞭解後，進行簡單的應用實踐，後期在實踐過程當中不斷的鞏固知識點，以掌握該部分的精髓。固然也有縮短學習時間的方法，那就是選擇有經驗的AWS Partner作一次詳細的講解以及陪您們一塊兒上雲實踐，他們會根據您企業的業務運行情況告訴您們什麼是最佳實踐。

實踐分享：
根據咱們經歷過大量遷移的實踐總結，讓咱們一塊兒分享在遷移過程當中，最爲關鍵的兩個階段，分別是計劃和設計。它們是整個遷移中最爲基礎的部分，就像一棟大樓的地基，如何詳細地作好這兩個階段的工做，咱們一塊兒來探討，但願能對您及您的企業有幫助。

1) 計劃：
建議在作計劃前，先作一個遷移優先級列表，裏面必須包含幾個核心的字段，例如：操做系統版本/實際數據量/應用提供商/業務依賴服務/技術複雜度/RTO/RPO等，這些是決定您選擇什麼樣的遷移模式（平滑/替換/重構），什麼樣的遷移工具，由於它們會影響您遷移週期長短和效果（固然也有一些企業也有一些特別的指標，例如：兼容性（遷到其餘雲的可能性））。請把這個表填完整後，再作總體的遷移計劃，而不是在沒有任何依據的狀況下作計劃。

按以上指標來看，也許大家會感受操做系統版本並不重要，實際上很是重要，首先要清楚AWS支不支持這種AMI，若是AWS不提供，Marketplace和社區有沒有？（若是您對安全很注重，建議不要使用社區的AMI）您也能夠選擇本身製做AMI（選擇Vmware方法制做），而咱們的建議是採用AWS提供的AMI，這樣無論理是性能，穩定性，功能和故障排查都會較爲可靠。舉一個咱們實踐過的通信行業的案例：客戶在上AWS前，有對AMI進行簡單的功能測試，並無針對他們在On-premises修改內核的CentOS的AMI進行性能測試。在實際遷移後進行性能測試時就發現各類故障，此時AWS的售後技術也沒法解決。根據咱們的經驗建議您儘可能採用AWS提供的AMI，若是對AMI確實有很是嚴格的要求，那麼請作好全部必要的測試。應用提供商，這是對應用能不能遷移起到決定性的做用，例如：License，版本以及軟件提供商是否還存在？業務依賴服務，這個指標描述的是業務之間的數據交互，業務之間的緊耦合關係，它們之間有多少服務數據存在交互或者它們僅是其餘業務的數據提供商，請注意「實際上有時其餘業務只是依賴這個業務的數據庫的數據，並不依賴於業務自己「，因此業務存不存在並沒有關係。RTO/RPO，這個指標會決定遷移成本，要保持業務不中斷，遷移成本就越貴。根據咱們實踐過的經驗，RTO/RPO更合適在容災和備份場景，在遷移場景咱們更認爲業務可中斷的時間更爲關鍵，由於這是用來作數據同步和業務切換的時間，最重要的是：「請別認爲本身的業務永遠不可中斷」（這樣形成遷移成本浪費，甚至不可遷移）。決定遷移時間的長短還有三個相關的因素分別是：數據同步技術、網絡帶寬與數據量大小。
把以上指標，還有客戶本身要求的指標，作相關評估與驗證（下一個階段的「設計」是此階段「計劃」最重要的驗證測試）才能決定業務遷移的優先級、業務遷移的模式、業務遷移的工具、業務遷移的時間。

2) 設計：
擁有以上已完善的遷移優先級列表後，此階段將進行架構設計與驗證測試，以致確保遷移模式，遷移工具與遷移優先選擇正確，這也說明設計與計劃是承上啓下的做用，並非各自獨立。經過計劃階段的業務分析與評估，您已經能夠進行相應的架構設計，同時進行相關驗證測試（在雲的時代，這個很是重要），以便調整遷移的優先級與遷移模式。在這此階段驗證的業務越多，遷移階段的風險就越小，時間就越短。例如咱們的一個高新制造行業客戶，他們在上AWS前跟咱們一塊兒對現有在某雲廠商的業務架構進行詳細地評估與分析後，在採用替換遷移的模式下得出他們最關鍵的驗證測試是以EC2爲基礎的K8S和網絡VPC，因此對這兩樣進行充分測試，例如： K8S的License有效期，K8S的Autoscaling，K8S分紅不一樣業務組以及K8S的網絡測試，還有作一些關鍵業務遷移測試。因爲設計階段充分測試使得正式遷移時節省兩週時間。若是有可能的話，建議採用與生產環境1:1的驗證測試環境，在驗證完成後，能夠把資源Stop，這時只收取部分資源的費用例如：EBS、EIP、S3等。對於那些必須刪除的資源，可選擇先作備份爲正式遷移作準備，還有可使用Cloudformation作好模板，這樣能夠減小正式遷移的準備工做。

實踐總結：
不少企業都喜歡經過少許驗證或不驗證，就開始執行遷移，在執行過程當中遇到各類各樣的問題，有些問題以至他們沒法繼續，必須從頭開始。從咱們過往的經驗來說，建議最好先把簡單的業務遷移上雲，最好都是平滑遷移，最好在前兩個階段作好充分驗證測試準備。對一些確實沒法中斷的業務（實際上DNS域名切換仍是須要中斷幾分鐘的）設計好數據同步的方式（主要仍是數據庫數據的同步，能夠利用AWS DMS或專門針對數據庫實時同步的第三方軟件），這裏的數據同步會存在必定延遲，要考慮業務可承受的時延範圍。必定記住和理解每一個階段之間是存在嚴格的關聯關係。

遷移，運營，優化這三個階段也很是關鍵，而在遷移的前兩個階段作好了充分準備，到遷移階段會相對輕鬆，只需注意風險評估和人員工做分配，運營和優化屬於高級階段，對遷移後的業務在穩定性，性能，安全，可用性和成本等方面進行逐步優化。（此文章如有錯誤，請指正，謝謝！）

參考學習地址：
https://d0.awsstatic.com/whitepapers/AWS_CAF_Security_Perspective.pdf
https://aws.amazon.com/cn/architecture/well-architected/

【關於博思云爲】

做爲一家專業的雲計算服務型企業，博思云爲專爲客戶提供 AWS 上的運營服務：包括架構諮詢服務、遷移服務、雲安全集成服務、混合雲管理服務、大數據服務以及 DevOps 服務。目前，博思云爲在大數據、DevOps、架構、數據庫以及操做系統等都已取得廠商認證，在上海、南京、杭州、武漢等地設有分公司。爲創新服務模式、引領 IT 服務業的發展，博思云爲將持續投入資源開展智能混合雲管理平臺、圖數據庫的研發等。