2023年Gartner云終端用戶行為調研發現，88%的受訪者選擇將工作負載現代化作為云遷移的首選。同樣地，在中國市場，云原生架構是工作負載遷移地熱門選擇。

　　中國的許多企業都是用云原生工作負載比例即容器化比例來衡量數字化轉型的進展，導致現象是容器化遷移比例越高，云原生工作越成功。但是，這種鼓勵把盡可能多的工作負載轉變為云原生工作負載的工作方式，將更多的注意力放在技術實施路線的落地層面而不是業務結果層面，從而產生了需要耗費大量資源的基于分布式架構的系統孤島，反而限制了業務的敏捷性、推向市場的速度和可擴展性。

　　中國基礎設施與運營(I&O)領導者可以通過以下三大策略確定合適的云原生工作負載，從而以業務成果驅動的方式推動數字化轉型。

　　使用工作負載論證框架，為應用部署設定明確原則

　　敏捷團隊通過云原生實踐方法快速完成交付，但敏捷交付保留了傳統交付的大部分特性，包括線性、循序漸進和緊密耦合的一體化方法。因此，僅僅將盡可能多的工作負載轉變為云原生，并不能緩解由于各自為政的技術環境所造成的問題。事實上，敏捷交付的快節奏導致系統面臨可用性變差，這主要是由于容器化交付模糊了I&O和應用團隊對于可用性的責任界限。

　　因此，僅僅以容器使用比例為標準跟蹤轉變為云原生的工作負載，并不能體現技術轉型對業務的直接價值結果(而只是展現了IT的工作量)，更無法據此衡量有說服力的數字化轉型的成效。I&O領導者不應專注于跟蹤轉變為云原生的工作負載數量，而應明確云原生工作負載可量化的業務價值，從而專注于改善業務成果。

　　I&O領導者可以根據交付要求，確定工作負載與云原生的適配性。傳統架構適用于穩定且可控的工作負載，通常不需要云原生。云原生架構適用于敏捷工作負載，快速迭代的業務場景，尤其是創新系統層。

　　圖1：確定最適合使用云原生和容器化的工作負載論證框架

　　鼓勵改變文化，從新的角度考慮工作負載

　　大多數企業多年來一直使用雙模式IT。傳統的項目管理交付方法依賴瀑布式架構，將信息技術基礎設施庫(ITIL)管理作為模式1;敏捷產品管理交付則依賴敏捷實踐，如Scrum或看板，將DevOps作為模式2.

　　對于傳統交付方式，應用團隊和I&O團隊都依賴于面向項目的管理方法。I&O團隊與應用團隊合作，構建一個大型單體架構，并每隔幾個月對該系統進行測試與升級。

　　傳統架構系統(通過硬件容錯)可規避應用出錯風險，但檢查點較多，有著嚴格的層級結構。對各個特定領域(包括安全、服務器、網絡和數據庫)，采用傳統交付方法的I&O領導者傾向于使用專門團隊分別對這些領域進行專業的系統管理。架構師需要了解整個解決方案，包括其所有組件的互連情況和復雜設計，而I&O團隊相關領域負責?只需要了解其具體負責的部分。

　　敏捷和傳統交付都需要跨團隊協調，以便集成各個獨立組件并交付。二者的主要區別在于部署的頻率——敏捷交付的頻率要高得多。這意味著，與傳統交付相比，敏捷團隊需要應對的復雜性可能要放大5到10倍，但在此過程中，敏捷團隊因自身能力不足，為了快速部署達到結果，會妥協構建“分布式單體架構”以提供服務。

　　由于交付效率的提高帶來了更多的韌性和可用性挑戰，在使用圖2所述的交付模式時，I&O團隊和應用團隊之間的界限并不清晰。此模式的運營極富挑戰性，需要高可用性甚至危機管理。

　　圖2：未用到云原生的敏捷交付流程示例

　　避免一味追求高容器化率，重點關注工作負載的敏捷性和快速推

　　虛擬化是云計算的基礎。借助虛擬化，物理平臺的功能細節可以與平臺托管的應用和數據解耦。容器通過將應用和服務使用資源的抽象層級進一步上移，提升計算功能的效率和敏捷性。

　　圖3：虛擬化方法及其基礎設施抽象層的演進

　　不同的抽象層帶來不同的基礎設施控制效果。基于物理服務器的單體架構推動提高了穩定性和控制能力，而基于容器的云原生架構則促進了敏捷性和靈活性的提升。

　　然而，如果I&O領導者將高比例的云原生部署覆蓋率作為判斷成功的要素，就很容易在容器采用方面遇到挑戰。容器部署覆蓋率并非良好指標，無法反映不同類型工作負載的業務需求。I&O領導者應重點