雲的時代：
雲時代已經到來，在選擇雲之後，選擇什麼樣的方式遷移上雲？這是企業的首要問題，因爲這會影響企業的遷移花費時間和遷移後的業務服務的性能，所以遷移時一定要按照一定的方法論和流程，而不是盲目的遷移，最基本的也要遵守這五個過程：計劃，設計，遷移，運營，優化，在這套方法論裏面您可以按您們的實際業務情況進行微調。所有云廠裏面，AWS擁有最完善的遷移方法論，例如：CAF（採用雲框架），LandingZone，Well-architected（良好的架構）和三天遷移培訓課程，個人認爲作爲一個AWS初級用戶最應該好好學習一下CAF，這樣可以帶給您對雲更深的認識，讓您知道使用雲會是一種什麼樣的過程，解決您在這過程中的疑問。
如果已經在雲上有一定的使用量，那麼您這時應該好好學習一下Well-architected，借鑑我們過往的經驗，我們建議客戶在AWS上有小量的應用後，再來學習Well-architected，不然您無法理解裏面的精髓，因爲裏面太多術語，最好的方法當然是開始自己先粗略看一下，上了一些應用後，再複習一次，這樣您就能很好的掌握裏面的實踐技能，如果您想縮短學習的時間，當然是有經驗的AWS Partner跟您們做一次詳細的講解以及陪您們一起上雲實踐，讓他們告訴您們什麼是最佳實踐。
實踐分享：
根據我們經歷過大量遷移的實踐，讓我們一起分享在遷移過程中，最爲重要的兩個點，分別是計劃和設計，它們是整個遷移中最爲基礎的部分，就像一棟大樓的地基，怎麼樣仔細的做好這部分工作，我們一起來探討，希望能對您和您的企業有幫助。
1) 計劃：
建議在做計劃前，先做一個遷移優先級列表，裏面必須包含幾個核心的字段，例如：操作系統版本/實際數據量/應用提供商/業務依賴服務/技術複雜度/RTO/RPO等，這些是決定您選擇什麼樣的遷移模式，還有選擇什麼樣的遷移工具，因爲它們會影響你遷移時間和效果（當然也有一些企業也有一些特別的指標，例如：兼容性（遷到其他雲的可能性））。把這個表填完整後，再做整體的遷移計劃，而不是盲目做計劃。
在以上指標看來，其實你們會感覺操作系統版本並不重要，實際上非常重要，首先要清楚AWS支不支持這種OS，如果AWS本身沒有，Marketplace和社區有沒有？（如果您對安全很注重，建議不要使用社區的）當然這裏最好採用AWS本身的OS，這樣不管理是性能，穩定性，功能和故障排查都會比可靠。舉一個我們實踐過的通訊行業的案例：客戶在上AWS前，對OS做簡單測試，原來在On-premises的CentOS是做過一些內核的修改，所以在測試時，只是簡單測試一下功能，沒有性能測試。OS遷移後進行壓力測試時就發現各種故障，AWS的售後技術支持也無法解決。所以建議儘量採用AWS本身的OS，如果對各方面要求非常嚴格的情況，要做好所有的測試。應用提供商，這是對這個應用能不能遷移起決定性作用，例如：License，版本以及軟件提供商是否還存在？業務依賴服務，這主要的是說業務之間數據交互，這業務是不是下一個業務的應用基礎，它與多少服務有交互或是其他業務的數據提供商，請注意“實際上有時其他業務只是依賴這個業務的數據庫的數據，並不依賴於業務本身“，所業務存不存在並無關係。RTO/RPO，這個是會決定遷移成本，想保持業務不中斷，遷移成本就越貴。根據我們實踐過的客戶，RTO/RPO更合適在容災和備份場景，在遷移場景我們更認爲業務可中斷的時間更爲關鍵，因爲這是用來做數據同步和業務切換的時間，最重要的是：“請別認爲自己的業務永遠不可中斷”（這樣造成遷移成本浪費，甚至不可遷移）。決定遷移時間的長短還有三個相關的因素分別是：數據同步技術、網絡帶寬與數據量大小。
把以上指標，還有客戶自己要求的指標，做相關評估與驗證（下一個階段的“設計”是此階段“計劃”最重要的驗證測試）才能決定業務遷移的優先級，業務遷移的模式，業務遷移的工具，業務遷移的時間。
2) 設計：
有以上遷移優先級列表後，我們的工作相對會比較容易進行，但是設計與計劃是承上啓下的作用，並不是各自獨立，因爲通過以上的業務分析與評估，您已經可以進行相應的架構設計，同時進行相關測試驗證（在雲的時代，這個非常重要），以便調整遷移的優先級與遷移模式。在這個階段驗證的業務越多，遷移階段的風險就越小，時間就越短。例如我們的一個高新制造行業客戶，他們在上AWS前與我們詳細的評估與分析他們的業務架構，而他們業務的基礎設施是EC2的K8S和VPC，所以對這兩樣進行充分測試，還有K8S的License生命週期都充分研究，甚至在K8S裏面的業務都做好充分規劃與測試，遷移時他們的時間縮短了兩個星期且非常順利。如果有可能的話，建議採用與生產環境1:1的驗證測試環境，在驗證完成後，可以把資源Stop，這時只收取EBS、EIP等費用，必須刪除的，可先做一個備份爲正式遷移做準備，還有可以使用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 服務業的發展，博思云爲將持續投入資源開展智能混合雲管理平臺、圖數據庫的研發等。