雲基礎：實現更快、更有利可圖的雲遷移的十誡

除非組織投資建立正確的雲基礎，否則云遷移會很快陷入困境。

對於許多遷移到雲的公司來說，對短期收益的關注會導致長期的痛苦，並阻止他們在雲估計的1 萬億美元潛在價值中佔據更大的份額。當 IT 部門通常在系統集成商的幫助下盡快將一組應用程序遷移到雲中以獲取初始收益時，就會發生這種情況。這種短期關注經常會產生重大影響。

罪魁禍首？缺乏對雲基礎的關注，這是決定公司整個雲戰略成功與否的不重要但關鍵的結構基礎。幾家大型銀行正在為此付出代價，導致需要雇用數百名云工程師，因為他們沒有在一開始就建立正確的基礎架構。

構建堅實的雲基礎作為轉型引擎的一部分並不意味著延遲財務回報或投入大量資源。它只需要知道要採取哪些關鍵步驟並很好地執行它們。我們的經驗表明，建立了堅實的雲基礎的公司能夠以潛在的八倍加速雲遷移和採用速度以及長期降低 50% 的遷移成本的形式獲得收益，而不會延遲他們的雲計劃。

一家頂級消費品 (CPG) 公司的雲遷移計劃遇到了嚴重的延誤——每個應用程序的遷移需要長達兩個月的時間。隨著部分業務的剝離，財務和法律部門向公司施壓，要求他們迅速將其與公司隔離開來。意識到其云基礎的缺陷導致了延遲，它做出了違反直覺的決定，暫停遷移以專注於加強雲基礎。

例如，它自動化了關鍵基礎設施功能，部署了安全軟件以自動化合規性，部署了可重用的應用程序模式，並創建了隔離區以將工作負載彼此隔離並防止一個區域中的潛在問題蔓延。一旦這些改進到位，公司就能夠快速、安全、可靠地遷移應用程序，單個應用程序需要幾天而不是幾週的時間。

讓您的雲基礎正確的十項行動

建立強大的雲基礎並不是“開展業務的成本”。這是一項重要的投資，將在速度和價值方面獲得顯著回報。以下十個行動是建立這個基礎的最重要的。

1. 優化技術以實現最快的“創意到生活”流程

無論他們的工作負載是在雲中還是在傳統數據中心，許多公司都採用過時的官僚工作方法，導致延誤和挫折。您的雲基礎應該被構建成能夠使一個想法從開始到在生產環境中快速發展並運行，而不會犧牲安全性。

在實踐中，這意味著盡可能多地自動化生產過程的步驟，包括沙箱請求、防火牆更改、按需創建大量隔離網絡、身份和訪問管理 (IAM)、應用程序註冊、證書生成、合規性、等等。將這些步驟自動化在傳統數據中心中與在雲中一樣有價值。但是，由於雲提供了使自動化更容易的獨特工具，並且由於遷移到雲導致組織重新考慮其整個戰略，遷移過程的開始通常是改變 IT 運營方式的正確時機。

2. 設計雲架構，使其可以擴展

如果公司做得對，他們可以構建一個基於五個人的雲架構，可以擴展到支持 500 個或更多，而無需進行重大更改。隨著雲足蹟的增長，一個設計良好的架構應該能夠容納更多的組件，包括更多的應用程序模式、隔離區和功能。支持這種縮放需要簡單的、設計良好的組件之間的接口。因為第一次很難做到這一點，所以以前大規模完成的雲架構工程師是一個很大的優勢。

3.建立一個反映架構的組織

根據康威定律，團隊的組織方式將決定他們開發的技術的形態。IT 組織有一套固定的團隊結構，這可能導致他們構建不符合雲架構形狀的東西。

例如，一些公司的每個業務部門都有一個單獨的雲團隊。這可能導致每個團隊為其各自的業務部門構建不同的雲功能，而不是構建它們以供其他業務部門重用。當一個團隊所做的更改影響另一個團隊的使用時，這可能會導致減速甚至延遲。

IT 需要首先設計其云架構，然後基於該架構構建組織。這意味著建立一個擁有基礎團隊、隔離區團隊和應用程序模式團隊的組織，以減少組之間的依賴關係和冗餘，並最終以更低的成本交付架構良好的組件。

4.使用已經存在的雲

許多公司擔心被鎖定在特定的雲服務提供商 (CSP) 中，因此他們尋找降低這種風險的方法。一種常見的模式是過度依賴容器，這可能既昂貴又耗時，並使企業無法從 CSP 中獲得真正的好處。這方面的一個例子是一家公司在雲中創建了一個容器平台，而不是使用云自己的彈性工具。發生中斷時，影響如此之大，以至於系統需要數天才能恢復在線，因為故障嵌入在其非雲工具的核心中。

還有其他方法可以緩解 CSP 鎖定，例如定義有限的鎖定時間框架，並在必要時實施能夠實現快速轉變的實踐和系統。通過嘗試建立非本地彈性能力，公司實質上是在與 CSP 競爭，而沒有他們的經驗、專業知識或資源。這個問題的根源在於，公司仍然傾向於將 CSP 視為硬件供應商而不是軟件合作夥伴。

5. 提供雲產品，而不是雲服務

公司創建內部雲服務團隊來幫助 IT 和業務使用雲是很常見的。通常，這些服務團隊像履行中心一樣運作，響應訪問批准的雲服務的請求。該業務最終會獨立使用數十個雲服務，並且沒有連貫的架構，從而導致複雜性、缺陷和使用透明度差。

相反，公司需要配備經驗豐富的雲架構師和工程師的專門產品團隊，為應用程序團隊創建和管理簡單、可擴展和可重用的雲產品。圍繞雲產品調整所施加的限制有助於確保業務以正確的方式使用正確的功能。

一旦產品團隊擁有云產品清單，它就可以鼓勵應用程序團隊使用它們來快速跟踪他們的雲遷移。然而，每個應用程序團隊的能力和興趣將影響其採用新雲產品的速度和容易程度。幾乎沒有云經驗、技能或興趣的團隊將需要逐步幫助，而其他人將能夠在很少的指導下快速行動。因此，產品團隊需要有一個運營模式，可以支持不同級別的應用程序團隊參與雲遷移之旅。

一種有效的途徑提供三個級別的參與（展覽）：

• 禮賓級別：參與團隊構建應用程序團隊所需的一切。
• 嵌入式級別：來自中央雲團隊的架構師嵌入到應用程序團隊中，以幫助他們構建正確的應用程序模式。
• 合作夥伴級別：合作夥伴團隊使用基礎基礎的核心功能（例如網絡、日誌記錄和身份）來構建和運行自己的隔離區。

通過建立雲產品、支持它們的團隊以及應用程序團隊與產品團隊互動的模型，企業擁有適當的機制來深思熟慮地擴展其云戰略。

6. 應用程序團隊不應重新發明如何在雲中設計和部署應用程序

當組織放任應用程序團隊將應用程序遷移到雲提供商時，結果是各種不同的雲功能和配置使得整個庫存的持續維護變得困難。

相反，組織應該將應用程序的部署功能視為一個獨立的產品，一旦使用應用程序模式就可以解決常見問題。應用程序模式可以負責配置共享資源、標準化部署管道以及確保質量和安全合規性。支持應用程序清單所需的模式數量可能很少，因此可以最大限度地提高投資回報率。例如，一家大型銀行僅使用 10 種應用程序模式就成功地滿足了 95% 的必要用例。

7. 使用隔離區提供有針對性的變更管理

隔離區是應用程序所在的雲環境。為了加速雲遷移，CSP 和系統集成商通常從單個隔離區開始，以託管所有應用程序。這是一種高風險的方法，因為支持一個應用程序的配置更改可能會無意中影響其他應用程序。走向另一個極端——每個應用程序一個隔離區——會阻礙配置更改的有效部署，需要跨多個隔離區執行相同的工作。

根據經驗，一家公司應該有 5 到 100 個隔離區，具體取決於業務規模及其回答以下問題的方式：

• 應用程序是否面向互聯網？
• 需要什麼級別的彈性？
• 在區域中運行的應用程序所需的風險保證級別或安全狀態是什麼？
• 哪個業務部門有權決定如何出於法律目的更改區域？

8. 構建一次基礎功能，以便在每個 CSP 中使用

大多數公司將在多個雲上。這種混合通常分解為大約 60% 的工作負載在一個中，30% 在另一個中，其餘的在三分之一中。與其在所有 CSP 中構建相同的基本功能（例如，網絡連接和路由、身份服務、日誌記錄和監控），公司應該構建它們一次並在所有隔離區域重用這些功能，即使是位於不同區域的隔離區域來自基地的 CSP。

9. 通過建立另一個基礎實例來加速收購整合

在收購過程中，合併 IT 資產既困難又耗時。如果收購公司創建一個可以運行被收購公司資產的“集成基礎”，雲可以加速合併過程並降低其複雜性。這使得被收購公司已經實施的 IAM、安全、網絡和合規策略能夠繼續執行，從而使其現有工作負載能夠繼續按設計運行。隨著時間的推移，這些工作負載可以以可衡量和可預測的速度從集成基礎遷移到主基礎。

使用這種方法，公司可以使用具有不同配置的相同軟件有效地運營其核心雲資產以及收購的資產。這通常可以將集成時間從兩到三年縮短到接近三到九個月。

10. 將預防性和自動化的雲安全與合規性作為基石

所有軟件組件和系統都必須經過安全層。傳統的網絡安全機制依賴於人工監督和審查，這無法與捕捉雲的敏捷性和速度的全部優勢所需的節奏相匹配。出於這個原因，公司必須採用新的安全架構和流程來保護他們的雲工作負載。

安全即代碼(SaC) 一直是以速度和敏捷性保護雲工作負載的最有效方法。SaC 方法以編程方式定義網絡安全策略和標準，因此可以在用於配置雲系統的配置腳本中自動引用它們。可以根據安全策略評估在雲中運行的系統，以防止更改導致系統不合規。

只有從一開始就創建了基本構建塊，“從小處著手並不斷發展”才是可行的雲戰略。公司需要設計和構建他們的雲基礎，以提供一個可重用、可擴展的平台，支持所有以雲為目標的 IT 工作負載。這種方法釋放了雲提供的好處，並最終獲得了它的全部價值。

關於作者
Aaron Bawcom is a distinguished cloud architect in McKinsey’s Atlanta office, where Sebastian Becerra, Beau Bennett, and Bill Gregg are principal cloud architects.

   訪問麥肯錫網站了解更多詳情