隨著雲原生理念與雲原生技術的不斷完善和發展，越來越多的行業開始落地實踐雲原生技術，這對不同崗位的技術從業者產生了不同程度的影響。不管是對 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://item.jd.com/10031230447968.html，可限時享受5折優惠。
