熟能生巧。-Bobby Robson

在過去幾個月裡，我花了很多時間與各種 AWS 客戶和團隊合作來打造幫助企業加快雲遷移工作的全面計劃。此計劃包含許多方面，包括 (但不限於) AWS 服務 (例如，AWS Database Migration Service、AWS Snowball、VM Import/Export)、一個由 AWS 專業服務打造的遷移方法、一個即將推出的“遷移到 AWS”培訓計劃以及與工具提供商和諮詢商店建立的合作伙伴關係 (旨在加快各行各業各種規模的企業的雲遷移速度)。

今天，我很高興介紹由本公司的員工 Sadegh Nadimi 編寫的一篇客座文章，此人詳細說明了我們在執行到 AWS 的大型遷移的企業中觀察到的 21 個最佳實踐。言歸正傳 . . .

-Stephen
[email protected]amazon.com
@stephen

在過去幾年裡，AWS 專業服務已引導企業完成數百個遷移專案並提出相關建議。今年，我們組建了一個專家專屬團隊 (稱為 AWS 專業服務大規模遷移團隊)，專門幫助客戶處理大型 (數百個應用程式) 遷移計劃。

客戶通常想知道哪些最佳實踐可以將應用程式快速可靠地遷移到 AWS。儘管每個企業的組織結構和業務目標各有不同，但大規模遷移團隊已學到的模式和實踐中有一些對各種公司來說往往都是真實可靠的。以下只是其中一些模式和實踐的列表（並未詳盡列出）：

預遷移階段

1. 對於 IT 和業務在將來應該重疊之處有一個清晰的願景。 

考慮這種願景將如何影響您組織的策略；廣泛宣傳這一願景。能夠清晰地說明該策略對於組織的重要性的原因是最主要的。有關更多見解，請參閱“使優秀的領導者成為偉大的領導者的因素”。

2. 概述並分享清晰的雲管理模式。 

確定規模較大的團隊的角色和責任以及符合您組織的“最小訪問特權”和“職責分離”資訊保安原則將非常有助於確保實現業務目標。它還允許您加入合適的控制以改善您的安全狀況。在為內部使用者開放雲服務之前，您需要回答許多問題。您應該有多少個 AWS 賬戶？誰可以訪問哪些內容？您將如何授予該訪問許可權？聯絡 AWS 以瞭解最佳實踐以及針對雲中的管理使用的每個方法的優缺點。

3. 在遷移過程的早期培訓員工。 

您的團隊擁有的 AWS 相關知識越多，過渡就越順暢；您擁有的內部推廣者越多，消除 FUD 和打破障礙就越容易。此過程需要發生在遷移過程的早期，即您就您的 IT 格局在 AWS 中的未來狀況做出組織範圍的決策之前。有關培訓的更多資訊，請參閱“您已經擁有成功實現雲遷移所需的人才。”

4. 花時間和精力來概述如何在 AWS 中形成新的運營方式。 

瞭解可能需要修改或改進的流程、將為您的雲之旅提供幫助的運營工具以及將增強您的團隊能力的任何級別的運營培訓。提前考慮運營問題可讓您著眼於大局並確保您的環境符合總體業務戰略。

5. 瞭解您當前擁有的 IT 資產以及您在每次遷移中包含的內容。

這樣，您就可以完全量化和度量您的雲採用的成功度。投入時間來查詢正確的發現工具 (如 Risc Networks 的 CloudScape、ScienceLogic 的 CloudMapper、AWS Application Discovery Service) 和更新您的應用程式庫存。這將簡化遷移計劃工作並最大程度地降低遷移過程中缺少依賴項的風險。

6. 選擇合適的合作伙伴以在整個遷移過程中為您提供幫助。 

您應該尋找這樣的合作伙伴，他們不僅具有有關遷移到 AWS 的技術專業知識和經驗，還具有正確的敏捷方法和專案管理框架。您的內部可能已經有擁有云能力團隊的合作伙伴。在選擇雲合作伙伴之前，為自己騰出時間來審查他們並要求推薦。此外，考慮您計劃採用的運營模型以及該合作伙伴是否能幫助推廣該模型 (構建 CI/CD 管道和託管服務)。有關更多詳細資訊，請參閱雲中的託管服務的未來。

遷移階段

7. 從小而簡單處著手。 

換言之，在董事會上提出一些速效方案。您的員工對 AWS 服務越滿意，您的利益相關者越快看到收益，在內部“推銷”該願景就越容易。為此，您需要一致性和透明度，而且我們看到了許多組織都在使用一系列速效方案來取得成功。

8. 自動化。 

雲的敏捷性通過自動化來實現。花時間重新審視流程並建立可在您遷移時利用的新流程。如果並非您的所有方面都能實現自動化，請小心確定哪些方面可以實現自動化並幫助您的團隊完成這部分自動化。

9. 將雲用作轉型手段。 

為此，請調整您的內部流程，使它們能夠接納這種技術轉變。利用該轉型性質來增強您的優勢，讓利益相關者與這個新典範相符。此外，始終對那些說“但是我們一直用這種方法. . .”的人抱懷疑態度。

10. 儘可能利用完全託管的服務。 

遷移後階段

11. 監控一切。 

制定全面的監控策略可確保您將有關應用程式的可靠架構的一切細節包含在內。擁有對您的環境的執行狀況的資料驅動型見解將使您能夠在權衡效能和成本時做出明智的業務決策。

12. 使用原生雲監控工具。 

有大量提供了應用程式級見解和 AWS 上的監控的工具 (例如，New Relic、APPDYNAMICS 和 AWS CloudWatch Logs) 可供使用。使用最適合企業的工具。您的運營人員最終會感謝您，您的企業所有者將獲得更清晰的資料點來作為決策依據。

13. 利用 AWS 企業支援。 

AWS 技術客戶經理 (TAM) 和賬單管理員 (均屬於企業支援包) 是極其寶貴的資源。他們開始成為您龐大的虛擬雲團隊的一部分，並且可以提供針對 AWS 的聯絡中心點和呈報途徑以及技術資訊和指南的寶貴來源。

適用於大規模遷移 (即一次遷移數百個應用程式的遷移)

14. 組建一個由圍繞遷移活動的所有團隊、工具和流程組成的強大遷移工廠。 

在您的第一波遷移之前，記錄詳細資訊並與您的組織分享。您希望以敏捷的方式開展運營以提高應用程式遷移到 AWS 的速度。您還希望採取合適的保護措施來保持遷移勢頭，甚至在存在勢頭變緩風險的情況下也是如此，例如，當您的員工休假時或當工具對於特定工作負載沒有達到應有的工作狀態時。

15. 為遷移工廠提供領導力並設定基準。

考慮建立一個專案團隊 (PMO) 來管理整體遷移活動和確保遵循適當的溝通和變更過程。此外，建立一個雲卓越中心 (CoE) 來充當您的遷移工作的支援點。CoE 可扮演提供技術指導的顧問的角色，它還可以更具指向性，即讓成員親自參與遷移工作。CoE 的好處將在“如何在您的企業中建立雲卓越中心”中更詳細地進行討論。最後，PMO 和 CoE 必須在遷移工廠中通力合作以確保遷移專案成功完成。

16. 在全面開展專案的同時為新的團隊成員提供入職培訓流程。 

應該將此流程視為另一種形式的培訓。您還希望有一個專門團隊來評估和稽核將在遷移工廠中使用的工具。為了優化遷移的結果，還要考慮在雲 CoE 之外組建一個小型團隊來尋求效率和對於您的環境來說獨一無二的模式。根據您的衝刺的範圍和節奏，完成遷移可能需要數月甚至是數年。您需要將遷移工廠視為一個不斷演變和改進的生物體。

17. 在您的衝刺團隊中明智地分配人才。 

這將確保您對於 AWS 服務和本地應用程式具有足夠的廣度和深度來應對衝刺過程中的小波折。在衝刺中沒有合適的資源可能產生不知情的決策並導致所有後續遷移衝刺混亂。

18. 在為特定應用程式決定遷移策略時考慮很多不同的條件。 

考慮業務目標、路線圖、風險狀況、成本等。概括來說，您將做出按原樣遷移應用程式或以某種方式修改應用程式的決策。無論您選擇做出哪一種決策，都應嘗試融入最佳實踐以儘可能提高彈性和節省成本，並在有條件時轉移基礎設施。一些常見選項包括自動擴充套件、負載均衡、多可用區方案和 EC2 例項大小調整。支援您的團隊在必要時利用 AWS 最佳實踐並儘可能快地開始優化。

19. 尋找模式併為它們建立藍圖。 

隨著團隊完成計劃活動，基於所選策略，將出現特定的遷移模式。為這些模式建立可重複使用的藍圖將提高遷移工作負載的速度。不要忘記與遷移團隊分享這些內容。這將使移動位元與位元組的人可以真正將注意力放在速度和效率上，而不必圍繞如何遷移具有相似特徵的應用程式做出決策。

20. 測試您的應用程式。 

遷移工廠的關鍵環節是將要在雲中部署的工作負載的整合和驗證。每個應用程式元件都應經歷一系列預先確定且記錄完整的測試。如果您要求應用程式所有者在專案的早期為您提供測試計劃，那麼獲得企業所有者的簽字將順利得多。在理想情況下，將有一個所有應用程式所有者使用其特定測試要求填充的模板。這有助於簡化驗證活動並讓您的企業所有者確信其應用程式在 AWS 中的執行狀況與在本地時相似或者更好。

21. 確保大力宣傳的文化逐漸灌輸到所有相關團隊的頭腦中。 

所有遷移決策都需要被清楚記錄和簽名認可。向組織中的團隊 (甚至是未直接參與遷移的團隊) 傳達“將會出現中斷並可能有新的 IP 地址/URL 指引流動方向”這一事實。此外，不要忘記通知可能有權訪問您的系統的任何第三方。

您是否有想要分享的其他最佳實踐？我們很樂意傾聽！

Sadegh Nadimi
運營整合主管 — 大規模遷移全球實踐
AWS 專業服務
[email protected]
https://www.linkedin.com/in/snadimi