簡介：隨著云原生理念與云原生技術的不斷完善和發展，越來越多的行業開始落地實踐云原生技術，這對不同崗位的技術從業者產生了不同程度的影響。不管是對 IT 主管還是對一線開發人員和運維人員來說，從業務邏輯到技術選型，整個技術棧都發生了天翻地覆的變化。為了更好地迎接云原生時代的到來，大家有必要深入了解云原生落地實踐對不同崗位的影響。

隨著云原生理念與云原生技術的不斷完善和發展，越來越多的行業開始落地實踐云原生技術，這對不同崗位的技術從業者產生了不同程度的影響。不管是對 IT 主管還是對一線開發人員和運維人員來說，從業務邏輯到技術選型，整個技術棧都發生了天翻地覆的變化。為了更好地迎接云原生時代的到來，大家有必要深入了解云原生落地實踐對不同崗位的影響。
?

CXO 和 IT 主管

?

很多企業對技術類 CXO（包括 CTO、CIO、CISO、CDO等，本文均稱為 CXO）和技術主管這些技術領導者的能力要求是全面而嚴苛的，技術領導者不僅要能夠兼顧技術管理的各個方面，還要以維持公司業務為核心職責。因此，CXO 和 IT 技術主管既要擁有寬廣的技術視野、出色的技術判斷力甚至高層架構設計能力，還要具備良好的產品意識，以應對不斷變化的內外部環境。
?

外部環境

?

作為企業的 CXO 和 IT / 研發主管，這些高層角色首先必須意識到：云原生是云計算發展的必然趨勢，云原生重塑了企業數字化轉型的基礎技術平臺，云原生架構是構建現代化企業應用的基礎技術架構。無論是對于互聯網應用、企業交易類應用、大數據應用，還是對于人工智能類型的負載等來說，云原生架構都非常重要。

其次，對于技術管理者特別關注的問題，比如開源開放、國產化等，CXO 和 IT 主管需要看到，大多數云原生相關技術和標準來源于各主流開源基金會的項目，這些技術和標準構成了開源開放的技術體系。各大云供應商推出的云原生服務也都兼容了相應的技術和標準。開源的云原生技術和產品非常符合企業客戶“無廠商鎖定”的訴求，當更換云服務提供商（Cloud Service Provider，CSP）或獨立軟件提供（Independent Software Vendor，ISV）時，企業不用擔心會出現技術上無法切換或者遷移成本太高的問題。國產化日益成為國家和企業的剛需。企業需要選擇符合國產化標準的云原生產品，包括云原生產品的自主可控能力、貢獻的源代碼（通常體現在運維、API、組件擴展等方面）、國產化服務器支持等。同時，像中國信息通信研究院、中國電子技術標準化研究院等單位也為企業提供了相關評測，以幫助企業選擇符合國產化標準的商業化產品。
?

內部環境

?

在企業內部，CXO 和 IT 主管必須結合企業實際情況，利用云原生技術推動企業的技術升級，并實現技術和業務價值。
?

首先，在戰略和組織層面，利用 ACNA（Alibaba Cloud Native Archite-cting）架構設計方法評估和制定企業的云原生戰略和實施路徑，并使之成為企業整體戰略的一部分，以幫助和加速企業的數字化轉型。此外，云原生戰略與企業中臺戰略一樣，不僅是對技術的一次全面升級，也是對企業 IT 組織結構、組織文化的升級。如今越來越多的企業已經意識到了這一點，以阿里巴巴為例，其不僅早在 10 年前就啟動了云原生相關技術和產品的研發，2020 年云棲大會期間關于成立“阿里巴巴云原生技術委員會”的消息，更是讓外界看到集團推動阿里巴巴與螞蟻集團全面云原生化的決心。
?

其次，由于云原生技術是對企業應用開發方式的全方位重構，CXO 和 IT 主管需要思考如何利用容器、微服務、Serverless、Service Mesh 等技術重寫應用，利用 DevOps 重塑企業的研發和運維流程，利用 GitOps、IaC 和聲明式架構重新定義企業的流水線和運維方式，利用可觀測性和 SLA（Service-Level Agreement，服務等級協議）升級原來的監控系統，利用云原生的以身份為中心的安全體系保障企業安全。
?

所有的技術升級的目的都是為了給企業帶來實際價值，因此 CXO 和 IT 主管利用云原生進行技術升級時，需要關注以下幾點。
?

運行成本及 ROI（Return On Investment，投資回報率）。

廣泛使用 BaaS（Backend as a Service，后端即服務）和彈性所帶來的直接成本節約。

基于云原生的新技術、新工具、新流程帶來的效率提升。

穩定性、SLA 提升帶來的間接成本優化（風險下降、用戶體驗改善等）。

架構師 / 咨詢人員 / 系統規劃人員

?

對于架構師 / 咨詢人員 / 系統規劃人員等企業的技術中堅力量來說，云原生技術及架構在架構演進及風險控制、技術選型、構建現代化應用、IT 服務流程重塑、新工具應用、安全規劃等工作中產生了深刻的影響。
?

1. 架構演進及風險控制
?

云原生架構演進的根本在于改變軟件運行的基礎設施環境—云平臺，讓上層的軟件架構從“穩態”到“打破原穩態并構建新穩態”。這需要架構師 / 咨詢人員 / 系統規劃人員謹慎評估企業的組織能力、開發和運維人員的技能水平、開發周期、成本預算、遺留系統集成、業務訴求等，并利用 ACNA 架構方法進行風險控制，以保障云原生架構在企業中平穩實施并持續發揮價值。
?

2. 技術選型
?

技術選型涉及兩個方面，一方面是選擇哪些領域的云原生技術和架構，另一方面是如何在同一領域、多個類似的技術或產品中做取舍。對于前者，建議企業根據云原生架構成熟度模型的評估維度，按架構迭代周期逐步選擇與企業訴求和能力相匹配的技術領域（比如，有的企業會選擇“容器 + 微服務 + 互聯網中間件”構建企業中臺）。對于后者，建議企業在開源和開放的基礎上，選擇有商業化支持（至少有同領域成功商業化實施的案例）的產品和服務，比如云平臺提供的微服務、容器等系列服務。
?

3. 構建現代化應用
?

基于云原生構建現代化應用，企業可以實現業務敏捷性，以應對瞬息萬變的市場挑戰，為應用賦予動態擴展和強韌性的能力。企業核心架構師通過重寫和重構企業核心軟件，將云原生技術和架構迭代過程應用到這些核心軟件的新一代研發中，讓新應用具備現代化應用的特點。由于企業云原生化會帶來應用架構的徹底升級，因此建議盡量選擇對系統重寫而非重構，從而最大限度地減少對歷史技術債務的償還，同時可以減少系統的遺留包袱，加速新應用的現代化過程。
?

4. IT 服務流程重塑
?

企業在升級云原生技術后，整個 IT 服務流程也需要進行云原生升級，其中包括事件管理、問題管理、變更管理、發布管理和配置管理，這些流程本身的定義都是完善的。由于云原生技術定義了新的工具、方法和標準，因此整個升級過程變得更加自動化，處理流程也得到了簡化。比如在事件管理流程中，可觀測性工具的使用大大減少了監控的負擔，因為基于 Kubernetes 的云事件管理可以比較好地覆蓋從虛擬主機、容器、PaaS 服務、集成服務到應用層面所有事件的集中采集、存儲、分析、告警、關聯性分析和可視化展示過程，從而提升服務臺以及后續的事件處理效率。
?

5. 新工具應用
?

云原生技術體系中關聯了大量的新工具，這些工具可以極大地提高云交付、云集成、云運維的效率。如果企業缺少這些工具，會面臨自動化程度不足、IT 信息碎片化、運維風險高等問題。因此，架構師 / 咨詢人員 / 系統規劃人員需要為企業的 CI/CD（持續集成 / 持續交付）過程、微服務實施、PaaS/SaaS 服務的云開通與集成、企業 CMDB（Configuration Management Data Base，配置管理數據庫）集成、企業監控集成、賬號 / 權限 / 認證集成等場景選擇甚至開發適用的工具，以提升企業的運維自動化水平，降低運維風險。
?

6. 安全規劃
?

在數字化轉型的背景下，雖然數字資產的價值得到不斷挖掘，但是風險也在不斷加大。云原生倡導的 DevSecOps、零信任模型和大量云安全服務，對權限控制、服務級動態隔離、請求級訪問控制等安全策略進行了細粒度升級，從而實現了從代碼開發到應用運維的端到端流程的安全控制。這個過程要求企業升級安全規劃，以實現從云基礎設施到應用安全的同步規劃。
?

開發人員

?

云原生技術與架構對廣大技術開發人員（設計、開發、測試等技術人員）的影響非常大，具體體現在以下 6 個方面。
?

1. 技術棧
?

從前端到后端的整個技術棧開發人員都將因為采用云原生技術而獲益：開發環境逐步從本地 IDE 變成云端 IDE ，并在 IDE 中預集成云服務（比如，使用 Cloud Toolk it，在 IDE 中實現應用部署），使整個代碼的編寫和調試效率更高；服務于前端的后端（Backend for Frontend） 層因為采用 Serverless 架構和大量的 PaaS 云服務而簡化技術棧， 使開發人員從后端運維中解放出來；后端研發人員需要關注會大量用到的技術，比如容器、微服務、Serverless、Service Mesh、PaaS 云服務等。
?

2. 分布式設計模式
**

云原生技術體系包含了大量已經存在的分布式設計模式，并將這些設計模式融合到開源產品和云服務中，從而極大地降低了架構師和開發人員的工作強度。比如，微服務以及 ServiceMesh 等可以預置灰度模式、熔斷、隔倉、限流、降級、可觀測性、服務網關等架構模式。而諸如事件驅動架構模式（Event-Driven Architecture，EDA）、讀寫分離模式、Serverless 模式、CQRS（Command Query Responsibility Segregation，命令與查詢責任分離）模式、BASE（Basically Available，Softstate，Eventual consistent）模式等則需要從應用架構層面引入，無法對應用做到透明。
?

3. 業務開發
?

云原生技術和云服務采用得越多，開發人員在非功能特性開發方面所花費的精力就越少，從而有更多的時間和精力關注業務本身的功能性設計。基于 Service Mesh 和 Serverless 開發的應用，開發人員甚至不用關心服務器的運維，不用不斷升級依賴軟件，不用處理灰度熱升和自動回退的復雜性，無須采用在線流量壓測來減少集成測試和冒煙測試的工作量。
?

4. 測試方式
?

傳統的基于預測來設計測試案例的方式，效率太低，解決方法是利用主動故障注入和混沌工程進行疲勞測試，真實地模擬現實世界可能發生的故障。而在線流量錄制和回放的 測試方法可以快速形成測試案例并提升回歸的有效性。更關鍵的是，這些測試方法都是直接在生產系統中進行的，沒有事先在測試環境中經過測試，像 NetFlix、亞馬遜、阿里巴巴等互聯網公司都在大量采用這些測試方式，以降低大規模分布式環境帶來的故障風險。
?

5. 軟件研發和運維流程
?

對于從傳統瀑布模型到變為敏捷開發方式的企業而言，DevOps 和 DevSecOps 對研發流程的改變更為明顯，其不僅要求企業做到安全地持續發布，還要求企業重新定義和規范研發人員接觸的研發流程和研發工具，實現開發和運維崗位的一體化，設立專注于提升工程穩定性、效率和質量的崗位，可以說是重新定義了研發和運維的組織、流程和文化。
?

6. 學習場景
?

云平臺是數字社會的基礎設施，是新基建的重要組成部分。很多最先進和最新的 IT 技術、理念都會在云平臺上有所體現。這些新技術背后的開源項目以及圍繞開源項目的大會、聚會、討論區、技術博客等，是廣大技術人員學習和提升技能的絕佳場所。此外，云計算相關的技術媒體往往會提供大量云原生領域的新技術和新解決方案，開發人員通過學習可以拓寬視野，提升技術能力。（這些技術媒體通常會提供在線文檔、直播、視頻錄像、技術文章、博客等資源。）
?

運維人員

?

包括 SRE（Site Reliability Engineer，網站可靠性工程師）在內的運維人員，作為軟件成功運行的保障者，也會受到云原生技術和架構的深刻影響，特別是在技術棧、運維工具、 監控和錯誤處理、SLA 管理、AIOps 等方面，具體說明如下。
?

1. 技術棧
?

運維人員的技術棧改變，一方面是由于運維的軟件采用了云原生技術棧構建而被動引起的，另一方面則是基于主動利用云原生技術和工具構建新的集成、監控、自動化、自愈、性能管理、高可用管理、安全管理、SLA 管理、IT 資產管理、事件管理、配置管理、變更管理、發布管理、補丁管理等工作和流程而帶來的。這里典型的應用場景是利用 Kubernetes Operator 實施自動化的資源創建、交付和實例遷移操作。
?

2. 運維工具
?

云原生架構特別強調通過 IaC 和聲明式運維來實現運維過程的高度自動化，即使是在擁有幾百上千臺機器的復雜分布式系統中，也可以自動化處理部署、升級、回滾、配置變更、擴 / 縮容等操作。而 GitOps 作為 IaC 的一個核心落地理念，不僅包含了對系統目標態的描述，而且貫穿了整個變更過程，既符合 DevOps 的透明化原則，也具備聲明式運維的優點。
?

3. 監控和錯誤處理
?

從用戶反饋和發現系統指標異常到采取多種運維手段確認、分析并解決問題和故障，是日常錯誤處理的重要工作范疇。可觀測性強調了一次業務的執行能夠從多個分布式服務、容器、虛擬主機、網絡、BaaS 服務中獲得日志、度量和追蹤信息，從而提高監控能力和錯誤處理效率。云原生技術不需要運維人員從多個分布式節點收集和關聯這些信息，而是由 Prometheus 和 Grafana 幫助完成多維度信息的關聯性分析、告警和可視化展示。
?

4. SLA 管理
?

有了度量指標信息后，我們可以結合調用關系中得到的依賴關系，對業務服務和 PaaS 組件進行 SLA 管理，進而對全局的服務和 IT資產進行 SLA 管理。在沒有類似于 Service Mesh 和可觀測性這些基礎設施和能力的情況下，傳統的監控系統只能盡量從不同格式的日志中去獲取這些度量指標信息。如果軟件沒有打印度量指標信息，監控系統就無法獲取；同時，由于缺乏全鏈路的依賴關系，SLA 管理不能做到上下游的關聯分析，從而導致系統不能第一時間感知某個服務或組件是否達成其 SLO（Service Level Objective，服務等級目標）。這些問題在云原生系統中得到了很好的解決，進而可以幫助運維人員提升系統的 SLA 管理水平。
?

5. AIOps
?

AIOps 是指在運維中利用機器學習和人工智能技術主動分析和預防故障，同時加快故障處理速度。當在大量業務服務和技術組件中實施可觀測性操作后，系統將會產生大量的日志、度量和追蹤數據，通過實時的機器學習和人工智能技術對這些數據進行分析，可以輔助變更前后異常檢測、多個事件的關聯性分析和“假陽性”消除、根因分析、自動化異常節點摘除和應急恢復等操作。
?

軟件交付工程師 / 系統集成工程師

?

作為軟件交付鏈條中的重要角色，軟件交付工程師和系統集成工程師也會因為應用了云原生技術相關的軟件，而改變工作方式。
?

1. 標準化交付
?

交付過程中最大的困難之一，就是不同的客戶具有不同的 IaaS 環境，包括不同的服務器或虛擬主機技術、網絡環境、存儲產品、操作系統和基礎軟件庫等。IaaS 環境的不同不僅使得交付軟件產生了不同的版本，而且在不同的交付階段也會發生變化，這又進一步提高了交付管理的復雜度。容器和不可變基礎設施不僅能夠屏蔽 IaaS 組件的不同，而且在容器的運行環境發生變化時，可以通過不同的鏡像形成不同的配置版本，而不是原地修改升級的方式（這種方式會丟失版本的配置信息，或者使不同版本的配置變得難以管理），從而標準化軟件的交付過程，隔離 IaaS 層的頻繁變化對上層應用配置變化的“傳染”，以達到提升軟件交付效率的目的。
?

2. 自動化交付
?

軟件集成和交付的另外一個難點在于，需要提供相應的軟件配置、安裝或部署手冊（相關人員需要學習這些手冊），然后適配標準部署與不同環境部署之間的差異。在這個過程中，安裝腳本只是輔助性工作，因為它并不需要知道手冊中的知識。云原生 OAM（Operation Administration and Maintenance，操作維護管理）通過 YAML 文件從應用的角度對軟件的運行環境、構成以及運維特征進行元數據級別的描述，同時描述軟件部署的終態以及可以適配的配置變化。腳本是可以讀取和理解 YAML 文件的。同時，我們可以看到，同一個軟件在典型場景中的部署是可以被標準化、開源以及共享的（比如，Redis 在阿里云 ECS 上的部署過程）。這不僅可以自動化常用軟件的交付過程，而且可以共享典型環境的交付經驗，從而提升交付水平。
?

3. 云交付和云集成
?

云計算為軟件提供了一個新的運行場所，以及一種新的交付形式。同時，云計算也是一個軟件交付的 POC（Proof of Concept，驗證性測試）場所。軟件與云的集成成為一種新的軟件集成模式，形成了新的 CSI（Cloud System Integration，云集成商）。系統先與部署在公有云中的軟件進行小范圍集成，然后通過云原生交付工具將公有云中的環境一鍵式地復制到私有云環境中。這在簡化集成復雜性的同時，降低了集成和交付的成本。
?

4. 持續交付
?

軟件的持續交付是 DevOps 過程中的必要環節。通過影響范圍小且頻繁的交付，DevOps 可以使軟件的交付過程變得更加自動化、版本化，可以重復且自動地執行升級和回退操作。持續交付可以保證軟件始終有一個最新且可用的版本，即一旦代碼或配置發生了變更，就可以立即生成新的版本并校驗這一新版本的可用性，從而提升軟件的交付效率。
?

5. 廣泛的工具鏈和知識體系
?

云原生技術體系是開源的，擁有廣泛應用的開源組件產品和開放的知識體系。通過這些產品和知識，軟件集成工程師和軟件交付工程師可以快速學到最新的云原生技術，獲得最合適的云原生工具鏈，并在自己的環境中進行快速驗證。不僅如此，企業通過互聯網渠道獲得所用產品的基礎技術知識，也能在一定程度上降低軟件交付過程中的培訓成本。

從數據庫管理員到數據庫架構師

?

數據庫管理員（Data Base Administrator，DBA）在傳統商業數據庫和開源數據庫產品體系中扮演著舉足輕重的角色。他們是保證整個軟件系統穩定性的關鍵一環。云原生技術和產品的發展，也深刻地影響了數據庫管理員。他們的工作方式正在發生巨大的轉變，關注重點從底層系統建設逐步轉向業務系統架構設計、從基礎穩定性逐步轉向業務結構優化、從如何用好數據庫軟件逐步轉向如何用好云原生產品體系等。與此同時，企業對于運維對象、運維平臺、技術能力的要求也發生了巨大的變化。
?

1. 運維對象
?

隨著云原生架構的不斷演進，曾經遙不可及的 DaaS（Database as a Service，數據庫即服務）已成為現實。云數據庫提供了開箱即用的 PaaS 化服務，并通過云原生資源池化技術提供了計算資源池、存儲資源池等豐富的云原生數據庫產品。這使得數據庫管理員的運維 對象從主機、網絡、數據庫轉變為數據庫服務。數據庫管理員不再需要關注從 IDC（Internet Data Center，互聯網數據中心）到主機資源的交付。這些基礎服務都會由云平臺完成。云平臺將發揮供應鏈的規模化效益和虛擬化技術，提供遠低于自建 IDC 成本的優質服務。在云計算時代，數據庫管理員借助云計算的 IaaS 化服務能力，在日常工作中卸下了基礎資源運維的工作負擔，從而可以有更多精力關注數據庫服務對業務的支撐能力，將運維對象的重心轉向數據庫服務。
?

2. 運維平臺
?

在商業數據庫時代，數據庫管理員的基礎能力是用好單一的數據庫產品，建設基礎運維平臺，實現數據安全、服務高可用、備份恢復、性能監控、問題診斷等基礎功能。即使是在開源數據庫時代，大多數公司的數據庫管理員也是圍繞著上面所列舉的幾個方面，或從零自研或基于開源運維組件進行定制化修改，這耗費了大量的人力、物力資源，而且很難獲得持續的運維能力。一旦有核心運維人員流失，企業很有可能會出現平臺難以為繼的局面。而在云原生架構下，數據庫 PaaS 平臺提供了豐富的運維能力支持，因此數據庫管理員不再需要從零開始建設運維平臺，從面向基礎組件的運維轉向面向數據庫服務的運維，得以基于云平臺提供的豐富 OpenAPI 實現業務支持能力的定制化開發，將如何為業務提供穩定的數據庫服務支持作為運維平臺的首要目標。同時，伴隨云平臺基礎能力的逐步提升， 新技術借助 OpenAPI 體系的優勢，使得面向數據庫服務的運維平臺能力能夠得到持續提升。因此，我們需要意識到，只有轉變運維平臺建設的目標，才能夠充分發揮云原生架構平臺化的優勢。
?

3. 技術能力
?

云原生時代豐富的云服務帶來的技術和架構優勢，將傳統數據庫管理員從基礎問題中解放了出來。企業更需要具備基于云服務進行業務數據架構設計能力的架構師，而非傳統意義上的運維數據庫管理員。因此，數據庫管理員需要盡快完成轉型。在云原生架構下，過去很多需要數據庫管理員花費很大精力去解決的問題都迎刃而解。典型的例子是數據安全問題，數據安全向來是數據庫管理員工作的重中之重，他們將巨大的精力都投入磁盤容災、機房容災、數據備份等數據安全保障工作中。云原生時代的多 AZ（Availability Zone，可用區域）以及分布式存儲架構，在解決數據安全問題方面具有天然優勢。再比如容量規劃問題，數據庫容量規劃一直是一個很難把握的難點。在業務模型發生變化的時期，如在大促等場景中，很容易出現系統容量不足的問題。云原生系統借助資源池化技術，發揮云原生存儲計算分離架構的彈性能力優勢，可以將擴展周期從原來的“天”級別大幅縮短為“秒”級別；共享存儲技術更是可以在秒級別實現讀節點拉起，實現系統讀容量的擴展。相信在不久的將來，伴隨 CPU 池化、內存池化、多點可寫技術的突破，數據庫容量彈性能力將更加強大。
?

另外，SQL 優化一直是數據庫管理員日常工作中很重要的一部分。指導業務開發人員編寫符合數據庫特性的 SQL 一直占據著數據庫管理員很大的工作比例。在云原生時代，云原生的自動優化系統基于機器學習和專家經驗實現數據庫自感知、自修復、自優化、自運維及自安全的云服務，可以幫助數據庫管理員降低數據庫管理的復雜度、消除人工操作引發的服務故障，從而有效保障數據庫服務的穩定性、安全性及高效性。
?

在云原生時代，云服務在很大程度上解放了數據庫管理員，同時也要求數據庫管理員盡快完成個人能力的轉型，加速從數據庫管理員向數據庫架構師的轉變，從而更加深入地參與到業務系統的架構設計中，幫助開發人員用好云數據庫的特性。
?

結語

?

云原生技術從業務流程、技術選型、技術棧等諸多方面影響著相關技術角色的日常工作，而云原生技術所帶來的影響還遠不止上述這些。在云原生已成為未來必然趨勢的大環境下，不同崗位的技術從業者也要遵循云原生所強調的專注業務并不斷演進，學習和接納云原生的理念與技術，從而通過云原生技術和產品更好地釋放云計算的價值，更好地支持相關業務的發展。

原文鏈接：https://developer.aliyun.com/article/785142?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的云原生不仅颠覆了技术栈，背后的每个岗位也在悄然发生改变的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。