正在全球持續蔓延的冠狀病毒疫情對各行業組織提出了新的挑戰。這對組織的業務發展和運營模式產生了重大影響。很多組織正在思考“如何使業務在疫情期間具有彈性?”，“如何更快地創新并為客戶提供新的業務服務?”，“如何降低總擁有成本?”，以及“如何實現更好的連接性和協作性?”這樣一些問題。這些問題和挑戰在疫情發生之前就已經存在，但現在變得越來越緊密相關和至關重要。

[[378418]]

已經開始進行云計算之旅的組織已經展現出對于應對疫情的更大彈性和響應能力。預計在不久的將來，隨著不同的云服務模型(SaaS、PaaS、IaaS)以及混合云和多云拓撲的結合，預計各行業組織的云計算采用率將顯著提高。云托管將成為企業一項新的必不可少的IT服務。

組織采用的云計算轉型方法有望實現業務目標、節省成本和實現戰略優勢。以下將簡要概述應用程序云遷移、數字化轉型的典型方法的元素。本文結合了可通過減少對非重要價值投資組合的支出來確定潛在節省成本的方法，以及獲得云計算技術好處的云遷移方法。還將解釋成功進行云計算轉型的系統方法。

一個典型的云計算項目分為四個階段。根據組織當前的轉型階段，必須確定其所處在的階段，其中包括：

• 策略與投資組合評估
• 設計與規劃
• 遷移與轉型
• 管理運營和優化

以下重點介紹前兩個階段，即“策略和投資組合評估”和“設計和規劃”。

一、策略與投資組合評估

這一階段的目標是評估組織對云計算的準備情況，定義云計算策略，進行應用程序組合評估，并定義目標部署。

1. 云計算策略

組織在制定云計算策略之前，重要的是了解當前業務目標和優先級、當前的IT環境，正在進行的轉型計劃和技術戰略。組織需要考慮以下幾點：

(1) 定義與組織的愿景、業務和IT戰略一致的云計算目標。定義云計算將如何使組織滿足其業務目標或新功能。

(2) 定義采用云計算的主要目的。例如，數字化轉型、數據中心退役、現代化改造、替換原有技術、推出新的業務服務、提高靈活性、容量激增、降低成本、提高彈性、響應能力、靈活性或運營效率。組織為這些目標定義具有有形利益和無形利益的關鍵績效指標(KPI)。

(3) 定義云遷移和轉型的過程方法。例如，在實施前進行試點以了解各種各樣的工作負載場景，很多組織更傾向于在短時間內進行遷移。

(4) 采用理由、影響和定義云決策。以下是一些決定：

• 選擇云計算服務提供商(AWS、Azure或谷歌云平臺)的決定。定義“私有云”、“混合云”或“多云”等云計算拓撲。如果是多云策略，需要定義選擇不同云平臺的理由以及可以針對不同云平臺放置哪些類型的工作負載(例如AWS上的分析業務和Azure上的原有服務器)。
• 關于容器平臺和容器化策略的決定。
• 選擇應用程序的云計算服務模型——例如，SaaS優先于PaaS，然后是CaaS(容器即服務)，最后是IaaS。
• 定義采用哪個云計算服務提供商提供的哪些云計算服務(IaaS/PaaS)。例如，由于各種安全原因，無服務器計算功能(例如Lambda/Azure功能)可能不被批準為組織策略。在使用新的云計算服務的情況下獲得批準。
• 定義為使用SaaS或商品化的產品或技術(COTS)平臺替代打包軟件或任何應用程序而已經采取或正在考慮的所有決策。
• 定義云采用原則——例如應用DevOps原則，自助服務和云計算代理原則，實施用于遷移的標準技術堆棧。采用可遷移性原則避免了供應商鎖定。例如，實施基于Kubernetes的PaaS容器平臺以支持云平臺之間的可遷移性。“基礎設施即代碼”原則使部署可以在任何一云平臺上進行。選擇與云計算無關的數據庫而不是原生數據庫。云平臺之間的可遷移性選項(例如AWS云平臺遷移到Azure云平臺或從Azure云平臺遷移到AWS云平臺)。

(5) 對于像數據倉庫或大數據和分析平臺這樣的數據遷移，需要使用云原生或新時代的COTS數據平臺制定詳細的數據遷移策略。

(6) 定義用于多云集成的平臺(例如使用iPaaS和API網關平臺)。

(7) 高級的云遷移和轉換時間表。

(8) 高級變更管理流程，如新角色、新技能、部署流程中的變更、可能需要的其他測試(如安全/滲透測試)，以及云計算新技能的培訓需求

(9) 定義云計算應用限制、風險和對組織的緩解措施，例如數據安全和監管限制以及由于正在進行的戰略計劃而產生的影響。IT服務提供商的退出標準類似于云訂閱/帳戶所有權轉移過程，還有云計算服務提供商退出標準。

(10) 定義云治理準則和護欄，即滿足監管和合規性流程的規則、云遷移項目批準過程、運營準則和成本管理。

(11) 對于數據中心退出策略，定義高級數據中心(DC)退役過程。

(12) 云計算策略是一個不斷發展的文檔。很多時候，在開始實施云計算策略的時候會出現各種歧義。而在設計和規劃過程中，這個策略會變得更加精確。

2. 應用組合評估

進行組織范圍的應用程序組合評估。這是定義組織范圍的轉型策略所必需的步驟。如果已經進行了評估，則可以進行進一步分析。如果組織在整體上還沒有為使用云計算做好準備，則計劃對準備好進行云計算轉型的業務部門的應用程序進行評估。組織采用7R遷移策略：分別是重新托管(Rehost)、重建平臺(Replatform)、重構(Refactor)、重新構建(Rearchitect)、替換(Replace)、保留(Retain)和退役(Retire)。評估階段的結果是提供針對應用程序映射的7R策略之一。

需要通過自上而下和自下而上的方法來評估應用程序。這個階段包括通過舉辦研討會、通過收集一系列調查表的答復來獲得所需的應用程序詳細信息。應用程序和基礎設施屬性也可以從配置管理數據庫(CMDB)或現有的企業架構(EA)存儲庫中收集。對于具有較大IT足跡的企業，建議利用自動化的應用程序和基礎設施發現工具來獲取所需的屬性和應用程序詳細信息。

標識應用程序的生命周期狀態。從評估列表中篩選近期“計劃退役”或已從進一步評估中“退役”的應用程序和基礎設施。

(1) 數據收集

為每個應用程序收集以下類別中的屬性。

• 應用程序屬性：創建包含基本應用程序屬性的清單，如功能、應用程序的生命周期狀態、業務能力、支持業務單元、托管位置/地理位置、應用程序類型(Web /批處理/中間件/事務/分析等)、任何計劃的升級或近期預期的更改。
• 業務價值屬性：這一應用程序對業務的重要程度，包括產生收入、提供分析報告或支持運營。捕獲一些因素，如與業務戰略的一致性、當前收益、業務重要性、存在于其他應用程序中的此應用程序的冗余/重復功能、用戶數量、發布新功能(敏捷性)所用的時間、組織的差異化因素、用戶滿意度，以及這個應用程序的自動化水平。
• 總體擁有成本：例如維護應用程序的成本、基礎設施成本和許可成本。
• 技術價值屬性：應用程序與技術策略的一致性、應用程序的技術債務和性能、易支持性、易集成性、滿足現代技術標準、滿足非功能需求(NFR)的現狀，例如模塊化、可擴展性、可遷移性、可訪問性、可維護性、響應時間、可恢復性、可用性、性能、開發和部署方法，以及生成的數據的質量和準確性。
• 風險和合規性屬性：數據隱私、安全和法規要求，例如數據保密級別、數據加密要求、應用程序安全要求、組織約束、本地/區域法規要求(如HIPPA、GDPR、PCI-DSS等)。
• 云適應性：檢查將應用程序移至云平臺的技術可行性。并了解各種情況：例如應用程序是否具有云中不支持的硬件依賴性(設備)或操作系統(OS);如果是打包的COTS應用程序，需要檢查云平臺的可支持性;應用程序是否使用COBOL、C、C++等傳統技術?還是在使用現代技術?檢查云平臺上的數據庫可支持性，例如是否托管在內部部署數據中心還是第三方數據中心。
• 復雜性：可能影響云遷移的復雜性。應用程序的分布、配置、主機數量、數據庫大小、接口技術、接口數量(入站和出站)、拓撲/集群需求、負載平衡需求、代碼復雜性、構建/測試/部署的易用性，以及使用的傳統技術等因素。

許多IT公司和云服務提供商(AWS/Azure/Google)都提供了免費的自動化應用程序發現和評估工具。然而，組織仍然需要人工干預和訪談來獲取某些屬性，以確定正確的處置策略。

(2) 分析

重要的是要了解組織的云計算戰略，這會影響部署。如果組織在短期內擁有數據中心合并或數據中心退役策略，則“重新托管”和“重建平臺”處置檢查可能是現有應用程序的首選。

這也適用于那些需要更快地遷移到部分工作負載并在后期更新應用程序的組織。對于運行關鍵業務應用程序的底層操作系統或軟件，可能存在生命周期終止支持(EOL)。這類應用程序可能是遷移到新軟件版本或云平臺上的操作系統版本的候選程序，在云平臺上可以獲得供應商支持。一些組織利用云計算轉型作為對其現有IT進行合理化和現代化的機會;還有一些組織希望通過重構到受支持的容器技術堆棧(例如Docker)，使采用的應用程序為容器化做好準備;一些組織利用機會將商業應用程序/數據庫轉換為更便宜的開放源代碼以節省成本。有些組織可能將云計算視為額外容量需求的擴展;有些組織可能會將云計算平臺視為構建數據湖、分析和機器學習等新功能的工具。

例如制藥廠商可能希望分析大量數據，以便為應對冠狀病毒疫情更快地找到有效的疫苗。云計算也可以用于實驗(例如試點/概念驗證)。

“重新托管/重建平臺”策略具有較低的風險和較少的遷移工作，但是收益卻較少。修復或使應用程序現代化有更多的遷移工作，但會帶來更多的長期好處。評估每個應用程序的遷移風險與回報比率非常重要。由于技術限制，某些傳統應用程序無法重新托管或重新構建平臺，此類應用程序需要對新平臺進行修正(重新構建)。在低成本硬件上托管低價值應用程序而不是進行昂貴的重構工作是有益的。

如上所述，使用從問卷和其他屬性收集的數據來分析7R處置的應用程序。提供每個類別中屬性的權重和得分。其權重可以根據組織的業務策略來確定，例如上市時間對業務而言可能比提供用戶體驗更重要，技術債務比高可用性更為重要。

業務能力堆映射是定義每個應用程序與業務能力的映射。確定合理化的機會，例如減少COTS許可證的機會，可以合并或替換的冗余應用程序，或者運行成本太高的應用程序/數據存儲。

組織根據業務價值、技術價值和云計算適應性的評分，可以創建各種分析模型，例如“時間”模型、“收益與遷移的便利性”、“技術價值”與“業務價值”之類的圖表。這將有助于確定潛在的“快速成功”，即能夠以低風險更快地遷移還可以提供成本優勢，以及短期業務價值的應用程序。

3. 處置和建議

創建一個決策樹以達到目標云平臺配置，例如具有低業務價值但云就緒分數較高的應用程序可以簡單地“重新托管”，而無需花費大量精力進行“重新架構”。沒有業務價值和低技術價值的應用程序可以考慮在低成本基礎設施上退役或重新托管。可以考慮將業務收益非常高但是技術價值較低(即技術債務較高)的應用替換、重構或重新構建。對于具有長期利益的重新構建/重新托管方案，可以考慮采用具有高業務和技術價值的應用程序。一些IT服務提供商已經開發了分析工具，這些工具可以維護標準化的評分值和規則集以固定分析過程。

在這個階段，為應用程序提供高級別的建議可能是有用的。可以定義針對每個應用程序的短期和長期建議，例如短期策略可以是“重新托管”，長期策略可以是使用無服務器計算示例部署重新構建。

4. 商業案例

完成高級評估后，對應用程序進行高級成本效益分析。基于內部部署基礎設施運行成本、折舊和基礎設施操作成本，確定應用程序的當前總運行成本。組織可以獲得未來3到4年的預期支出。根據應用程序和數據庫的配置，創建具有適當實例大小、實例類型、存儲、網絡組件、PaaS服務的目標基礎設施清單。

組織需要確定未來3到4年內目標云計算應用程序的運行成本，確定云遷移的大概成本。如果轉移到云平臺中，需要確定關閉當前運營基礎設施所節約的成本。使用各種云計算提供商的折扣、長期定價計劃和好處也可以降低成本。

組織的云計算投資通常將在2至3年內實現。比較在不同云平臺上托管的成本。可以使用云計算提供商的在線TCO計算器/月度支出計算器來計算費用。將附加的無形好處(如敏捷性、彈性、靈活性和可擴展性)作為其業務案例的一部分。

這一業務案例將為業務所有者和組織高管提供啟動云計算項目的決策點。在應用程序和數據在云平臺上遷移之后，包括云優化的練習也很重要。

5. 云計算業務辦公室

對于成功的云采用和價值實現，在組織中進行有效的戰略監督和治理非常重要。組織需要建立云計算業務辦公室(CBO)，其中擁有組織高管、關鍵業務利益相關者、應用所有者、基礎設施負責人、安全主管、工程主管、運營主管、采購團隊、風險與合規性以及推動并實現云轉型。云計算業務辦公室(CBO)的目標是定義轉型目標和目的，在整個組織內推動云戰略，提供預算、架構標準、變更管理，啟動和管理云遷移項目，通過度量指標和效益跟蹤價值實現。

每個角色都有長期或短期的責任來支持云計算業務辦公室(CBO)的目標和云計算應用決策。這種職能或部門也可以稱為云計算策略辦公室(CSO)或云計算卓越中心(COE)。

二、設計與規劃

在這一階段，將對應用程序進行詳細評估，并定義最小可行的架構以實施云遷移策略。在這一階段還可以改進云計算策略。

(1) 詳細評估：分析計劃使用代碼掃描程序進行重構的應用程序代碼/軟件。有許多商業工具可用于掃描代碼以進行重構。Azure云平臺和AWS云平臺還提供了代碼掃描工具，例如.NET的.NET可遷移性分析器/遷移助手等。還有諸如AWS App2Contaner之類的工具，它們甚至可以將應用程序容器化，并將其部署在容器平臺上。組織還要分析用于重新托管、重建平臺和重新配置應用程序的功能和代碼，并確定任何風險和阻止因素。

(2) 轉型路線圖：根據所做的努力和評估來定義云遷移計劃。將應用程序與公共依賴項和數據庫分組。為每個這樣的組定義遷移。分組也可以通過組織功能/域或技術功能(例如Webapp、中間件、核心交易系統、大數據等)完成。通過復雜性確定應用程序的優先級。計劃具有低風險并且不太復雜的應用程序的遷移。

例如，簡單的Web應用程序或報表應用程序可以被視為早期行動者。組織可以確定敏捷過程方法和團隊結構，識別遷移用戶案例和sprint的數量，定義遷移團隊的結構，并通過將其分為部落和小隊來確定合適的團隊規模。一些組織可能將其稱為POD結構。

組織還要定義應用程序的遷移、測試和切換計劃的生命周期階段。成功的遷移將創建用于移動其余應用程序的模板，使應用程序現代化(重新構建或重構)可能需要更多的時間和長期策略，為遷移應用DevOps和敏捷方法(例如Scrum、SAFe)。

(3) 目標架構：定義應用程序、數據和網絡組件的目標部署架構。由于云遷移是以敏捷的方式規劃的，因此定義一個簡單但足以實現遷移的架構(最小可行架構)是很重要的。定義現有應用程序和數據庫在遷移期間將轉換的目標技術、軟件/操作系統版本和數據庫版本。

組織需要考慮應用程序的數據庫依賴關系、接口、外部集成和數據遷移需求。對于數據和相關應用程序將駐留在內部部署設施的情況，需要考慮混合云架構。這種架構將在云遷移期間不斷發展。

組織要做出架構決策，并獲得利益相關者的支持。設計具有高可用性、負載平衡和性能的架構，并遵循“適合用途”的原則。畢竟，云計算是為可擴展性和可用性而構建的，因此避免過度工程化。

(4) DevOps：DevOps如今已經成為各行業組織實現轉型和現代化項目的事實上的標準。每個遷移POD團隊都應遵循DevOps流程。對于某些應用程序(例如COTS)，DevOps可能不相關或無法應用。在架構決策中調用此類應用程序。這樣的應用程序可以遵循目標云平臺現有的構建和部署方法。

組織需要確定用于在目標云平臺上構建、測試、部署和監視應用程序的工具，有許多云原生選項可用。設計DevOps管道(例如使用Jenkins/AWS代碼管道/Azure DevOps等)。在部署之前考慮代碼漏洞掃描和安全測試。在可行的情況下，計劃自動化這些步驟(例如測試)。定義源代碼的管理和版本控制方式(例如，使用Github存儲庫和分支)。定義如何捕獲和跟蹤用戶故事(例如，使用Jira之類的工具)。定義現有應用程序在投入生產之前將要部署和測試的各種環境。

對于每個應用程序來說，遷移過程必須是持續的(持續集成/持續交付)和迭代過程，直到滿足所需的測試KPI。定義應用程序支持過程以及如何在后期制作中監視問題。從代碼更改、部署到運營，DevOps團隊應擁有該應用程序。

(5) 概念驗證(POC)：在云平臺中進行概念驗證。無論是應用程序遷移還是數據倉庫遷移，在云計算環境中進行嘗試遷移都將給組織帶來信心。概念驗證(POC)將幫助組織根據當前的組織流程、連接性和環境依賴性來確定問題和差距。在遷移時應用DevOps流程和工具，并選擇中等復雜的重新托管和重構應用程序(例如POC)，通過它可以解決大多數遷移用例。概念驗證(POC)將幫助組織完善目標應用程序和基礎設施。

(6) 云計算基礎設施和安全性設計：這是設計階段一個非常重要的部分。這是關于定義目標架構的技術著陸區。AWS著陸區域的示例將包括網絡組件，如專有網絡數量、數據中心連接、專有網絡間通信、子網、API網關等。

組織還要關注計算和存儲(如EC2、EKS、ECS、RDS、SQS、S3等)、安全組件(如IAM組、用戶組、IAM策略、現有企業用戶的AD SSO)、網絡級別的安全組和端口控制。定義組件的標記(標簽)規則。環境的訪問控制機制，并使用基礎設施即編碼原則來定義基礎設施。組織還要利用新工具，如云原生基礎設施創建服務或獨立于云計算的開放源代碼，例如terraform。設計與DevOps工具的集成，以輕松創建基礎設施。該設計應涉及以下方面：

• 云計算基礎設施組件和服務;
• 集成層;
• 大數據和分析組件(如果適用);
• 網絡連接;
• 混合云網絡連接拓撲(定義到數據中心和外部云的位置/區域連接);
• 高可用性設計;
• 以及災難恢復方法。

(7) 安全架構應解決的問題：訪問和身份管理(如AD集成、AWS帳戶和組織);訪問環境/應用程序和數據庫的安全控制和過程;安全審計和監控(如SIEM集成);數據安全和加密;以及漏洞/補丁管理過程的評估。

(8) 云計算運營模型：云計算運營模型是關于組織將如何實施其云計算轉型的全部內容。它由人員、流程和工具組成。人員是推動云計算項目成功的關鍵。

組織需要確定與云計算業務辦公室、業務/域、運營、安全和DevOps相一致的利益相關者、團隊結構和角色;確定應用程序和數據治理流程和策略;確定合規性要求和解決方法。

還可能存在創建集中式、分散式或共享操作模型的策略。分散運營是首選模式，因為它提供了更多的靈活性和成本管理。然而，這種模式可能還有一些局限性。

(9) 變更管理：云計算轉型需要適應流程技術和工具的變化。治理和基礎設施控制將發生變化。解決現有團隊可能必須承擔的不同角色所需的新變化。為員工制定技能培訓和云計算培訓計劃。組織制定一個計劃來彌補新技能的差距。

云遷移主要是一種技術變革。許多組織都涉及顧問委員會(CAB)的變更，該委員會負責審查和批準此類轉換變更。除非事先與利益相關者進行良好的溝通，否則傳統的顧問委員會(CAB)批準可能會阻礙云遷移。組織需要考慮使用企業變更管理工具(例如ServiceNow、BMC、Jira服務臺、Freshservice等)來管理和控制整個云遷移過程。

有一些工具可用于完成環境訪問控制、資源調配、計費/成本控制、安全監控、事件管理、版本管理以及更改管理和批準流程。或者，使用云原生服務(例如AWS Config、CloudTrail、服務目錄、AWS控制臺、AWS組織、trusted advisor等)以及實現這些任務的企業工具。

三、下一步發展

下一步是“遷移和轉換”。組織需要部署POD團隊，按照設計遷移應用程序和數據，并在前面的階段進行規劃。而“管理和優化”階段是關于管理云平臺上的基礎設施、應用程序和數據遷移。