一、寫在上面

最近被多次問到：“隨著云原生的逐步建立和深入應用，NoOps（零運維）時代真的要來了嗎？作為運維人員，我們應該如何應對這些趨勢？ ？”。云原生架構不斷融入數字化轉型應用后，IT運維真的沒了嗎？仁者見仁，智者見智。但我個人認為，如果我們能先充分理解“云原生”，再思考“在云原生下，是不是真的不需要運維”，會更準確一些。

二、什么是云原生？

Cloud () 是一個復合詞，Cloud+。云意味著應用程序位于云端，而不是傳統的數據中心；這意味著應用程序的設計從一開始就考慮到了云環境。彈性+分布式優勢。

三、云原生的主要特點？

該公司的 Matt Stine 在 2013 年首次提出云原生，他定義了云原生的四個關鍵點：微服務 + 容器 + 持續交付 +。

微服務：幾乎所有云原生的定義都包含微服務。與微服務相比，它是一個單體應用程序。微服務有一個理論基礎，即康威定理，它指導如何分割服務。決定產品形態的是組織結構。微服務架構的用處是切割后服務是前饋的，內聚力更強，變更更容易；另一種定義服務的方法似乎是基于 DDD。

容器化：是應用最廣泛的容器引擎。容器化為微服務提供實現保障，起到應用隔離的作用。K8S 是一個容器編排系統，用于容器管理、容器之間的負載均衡，K8S 是用 Go 編寫的。

：這是一個組合詞，Dev+Ops，就是開發和運維的組合。與開發和產品不同的是，它們經常相遇。事實上，它還應該包括測試。它是一種敏捷思維、一種溝通文化和一種組織方法。為云原生提供持續交付能力。

持續交付：持續交付是開發不延遲，更新不停機，小步逃走，是一種反傳統的瀑布式開發模式，需要開發版本和穩定版本并存，雖然需要很多流程和工具的支持。

在實際實現中，符合云原生架構的應用特點是：使用開源棧（K8S+）進行容器化，基于微服務架構提高靈活性和可維護性，采用敏捷方法，支持持續迭代和人工運維，借助云平臺設施，可以實現彈性伸縮，動態調度，優化資源利用率。

四、為什么會出現云原生，解決了哪些痛點？

讓我們從云估計開始。在云計算普及之前，如果一個應用要發布，企業需要購買幾臺服務器，安裝在IDC機房。連接是安裝Linux系統和部署應用程序。我們假設我們已經用 Java 編寫了一個 Web 應用程序，如何部署它？先配置服務器，將編譯好的war包上傳到服務器，使用FTP，對安全意識稍有了解的選擇SCP，然后配置Nginx和MySQL等服務，然后調試最后一關運行應用，甚至如果它還活著。這些化工機器有很多缺點，但主要痛點如下：

擴展和維護困難。由于是化工機，所以需要先購買，再安裝到機房。當業務量激增時，再擴容已經來不及了。就術語而言，這意味著估計的資源是不靈活的；治安太差了。熟悉Linux的運維工程師很少服務器運維，精通的也很少。但系統安全只是一方面，應用部署的權限和流程會導致更大的安全漏洞；需求無法快速響應。開發、測試和運維是矛盾的，缺乏手動測試和部署。應用系統的上線部署是一個重大的變化，涉及大量的規劃和多輪測試，

解決方案是上云。上云并不能解決所有痛點，而是部分解決了前兩個痛點：

與化工機相比，虛擬機的創建、維護和銷毀都比化工機簡單得多，并且可以隨時擴展容量，很大程度上解決了“彈性估計”的問題。至于彈性程度，取決于應用。建筑和設計水平；與絕大多數中小企業相比，云服務商在網絡和服務器安全方面要強幾個數量級。只要選擇合適的官方鏡像，并配合使用防火墻規則，系統層面的安全問題就大大減少，重點可以放在應用本身的安全上。

所以第三個痛點“無法快速響應業務需求”云測算不能很好的解決。要實現持續交付和快速迭代，需要改變應用架構和軟件開發方式。這時候，云原生“微服務、容器”等特點的優勢就凸顯出來了。

五、使用云原生后會給應用系統開發帶來哪些變化？

1.本地部署的傳統應用往往是用c/c++和企業級java編寫的，而云原生應用則需要用以網絡為中心的go、node.js等新興語言編寫，而不是Java不能用，只說GO語言更適合云原生適配。2.本地部署的傳統應用程序可能需要停機更新服務器運維，而云原生應用程序應該仍然是最新的，需要支持頻繁的更改、持續交付和藍綠部署。3.傳統部署在本地的應用無法動態擴展，往往需要冗余資源來抵御流量高峰，而云原生應用則利用云的彈性來手動擴展和共享，降低成本，提高效率。4. 部署在本地的傳統應用對網絡資源有依賴，比如ip、端口等，甚至是硬編碼，而云原生應用對網絡和存儲則沒有這些限制。5.傳統的本地部署的應用一般都是手動運維的，而云原生的應用都是手動操作的。6.本地部署的傳統應用一般依賴系統環境，而云原生應用不硬連接任何系統環境，而是依賴具體的基礎設施，從而實現了良好的可移植性。7.本地部署的一些傳統應用是單體（）應用或者是強依賴，

那么，在云原生應用之后，似乎今天面臨的所有運維的棘手問題都消失了？

六、云原生使用現狀如何？

之前看過國外大中型企業的調查報告，顯示“60%以上的用戶在生產環境中應用了容器技術，1000節點規模的容器集群可以滿足生產需求近 80% 的用戶。” 作為容器的主要應用場景，80% 的用戶已經使用或計劃使用微服務。與此同時，該技術明顯升溫，近 30% 的用戶已經將其應用到生產環境中，但用戶在部署過程中仍面臨諸多挑戰。甚至預測“到2025年，95%的數字化運維將得到云原生平臺的支持”。這個數據和我目前接觸過的客戶的申請情況差不多，無論是ToB還是ToC，無論是標準化產品還是多元化。產品在云原生改進方面取得了長足的進步，最重要的原因是：“快速迭代和持續交付”。

七、使用云原生后會給IT運維帶來哪些變化？

云原生運維需要解決幾個關鍵問題： 1.標準化：標準化可以促進開發團隊和運維團隊的溝通協作。標準化也有助于生態分工，促進更多手工工具的出現。2.手動：只有手動運維才能支撐互聯網規模的挑戰，才能持續支撐業務的快速迭代和穩定性。3.數字化智能：人工運維，數據提升，人工智能化已成為未來發展的必然趨勢

上述問題對運維人員的變化是：

原本標準化的工作流程是用來協調人高效完成工作的，通過標準化流程轉化為人工化；

傳統上，通過開發人工處理模型來訓練AI，將知識積累以提高團隊能力轉化為運維能力的提升；

在微服務、多云環境和 IaaS 下，應用系統和基礎設施都被劃分為足夠小的業務服務，以實現持續交付和迭代。這種傳統的人工運維方式，早已難以管理這么多的對象。運維工程師無論是軟件運維、服務器運維、操作系統運維還是網絡運維，都必須能夠在原維護對象專有技能的基礎上進行人工運維。也未能推動運維工具的標準化。為此，運維工程師必須具備一定的開發能力。至于過程，傳統業務由人工協同完成，而在云源旗下，每只藍籌股的工作都由相應的人工工具完成。這樣，在原有流程能力的基礎上，運維流程主管必須具備安排不同自動化組件的能力，以實現從資源規劃、軟件部署、自動化業務驗證（測試）等一系列工作。事實上，運維的工作不會消失，只是運維工程師在云原生環境下沒有編程和開發能力是很難做到的。在原有流程能力的基礎上，運維流程總監必須具備安排不同自動化組件的能力，以實現從資源規劃、軟件部署、自動化業務驗證（測試）等一系列工作。事實上，運維的工作不會消失，只是運維工程師在云原生環境下沒有編程和開發能力是很難做到的。在原有流程能力的基礎上，運維流程總監必須具備安排不同自動化組件的能力，以實現從資源規劃、軟件部署、自動化業務驗證（測試）等一系列工作。事實上，運維的工作不會消失，只是運維工程師在云原生環境下沒有編程和開發能力是很難做到的。

傳統的運維工具，無論是監控還是運維流程，都以保證業務穩定性和保證快速響應為核心的標準化產品。差異也使得自愈處理的流程不統一，必須通過二次開發完成。這樣，運維工具的二次開發能力將決定該工具能否落地。

八、寫在最后

數字化轉型時代已經臨近，掃碼加入我們，以全新的思維方式學習ITIL4，數字化轉型時代必須掌握的新技能。

更多課程和服務

我們首次提出“咨詢式培訓”的培訓理念，指出“在培訓學校學習方法，在專題研討中解決問題，在研討課和輔導課中答疑解惑”。

如果您想使用ITIL4的理論來設計和優化IT部門的業務流程，建議您點擊以下鏈接：

如果您想利用外部專家的經驗和實力對IT部門的業務進行重組和重新設計，我們建議您點擊以下鏈接：