2021 年 DevOps 的八大趨勢 | IDCF

本文先看看別人的預測,最後我也憑藉本身在 DevOps 領域這幾年的經驗和認知,大膽預測DevOps 在2021年的發展與變化。前端

別人的預測

本文翻譯自 Andreja Velimirovic 的 《Top 8 DevOps Trends for 2021》 一文,原文地址[1]。

DevOps 是軟件有效交付的一個領先模型,並且此領域沒有停滯的跡象。DevOps 社區一直在搜尋優化開發效率、提升生產力的方式,所以思想和流程的轉變是以 DevOps 爲中心的軟件開發模式中的核心部分。git

此文章會就 2021 年 DevOps 的八大趨勢作一個解釋。github

繼續閱讀,瞭解2021年 DevOps 的指望,並瞭解你的團隊須要作什麼來保持競爭力。web

image.png

1、DevOps值得關注的趨勢

1.1 基礎設施自動化(IA)工具的成熟

基礎設施自動化工具可以使團隊在 on-premise 和雲環境中設計和自動化交付服務。在 2021 年,DevOps 團隊將使用 IA 以更高的可靠性來大規模實施自動化 IT 基礎設施的交付、配置和管理。數據庫

IA 工具可以給 DevOps 團隊提供衆多的收益:編程

  • 多雲和混合雲基礎設施的編排。
  • 不可變和可編程基礎設施的支持。
  • 自服務、按需所需環境的建立。
  • 高效的資源配置。實驗的簡單性。

咱們將在將來看到 IA 工具和其餘流水線組件的更多集成。經過將 CI/CD 概念應用於 IT 基礎設施,團隊將能享受到更多的敏捷性。segmentfault

查看持續集成、持續部署和持續交付之間的區別[2],三種實踐使 DevOps 團隊快速、精確的工做。

2021年的指望:企業將開始用企業級的 IA 工具取代自定義的設置。經過利用 IA 工具來自動化軟件的部署和配置,企業將得到:安全

  • 更快的開發。
  • 可重複、一致的基礎設施。
  • 因爲手動任務減小使成本下降。
  • 因爲跨全部物理和虛擬基礎設施的可靠性設置,更容易實現合規。

預計連續配置自動化(CCA) 的工具也會增長。這些工具提供了以代碼形式管理和交付配置更改的能力。CCA 工具的範圍將會繼續擴展至網絡、容器、合規及安全範疇。服務器

查看裸金屬[3]雲服務器是如何幫助實施基礎設施自動化管理流程的。

1.2  應用程序發佈編排(ARO)工具的使用

ARO 工具將流水線、環境管理和版本編排結合起來。這些工具可以帶來如下好處:網絡

  • 更多的靈活性:團隊能更快、更可靠的交付新應用、應對變動和修復缺陷。
  • 更高的生產力:更少的手動任務能容許成員更關注於高價值任務。
  • 更好的可視性:在資源調配過程當中,瓶頸和等待狀態變得可見。

ARO 工具將進一步提升產品發佈的質量和速度。公司將利用多種方式、DevOps 流水線[4]、流程及工具,在多團隊之間進行版本發佈活動。

2021 年指望什麼:ARO 工具將變得更加廣泛。新變動的快速交付將容許對市場需求的快速改變作出應對。

1.3 更復雜的工具鏈

DevOps 工具鏈是一系列支持流水線活動的工具集。設計良好的工具可以讓團隊:

  • 爲了共同目的而一塊兒工做。
  • 獲得精確的測量指標。
  • 獲取全部代碼變動的快速反饋。

DevOps 工具鏈正在變得愈來愈複雜和寬泛。CI 工具隨着新系統的發展而演進,這些系統可以讓建立和維護構建腳本變得簡單。流水線正在得到一些新的安全特性。支持包管理和容器管理的工具也正在迅速發展。

組織須經過避免重疊、衝突和功能差距來確保工具鏈的正確使用。

2021 年的指望:工具鏈供應商將開始在整個開發和交付週期內提供更普遍的解決方案。企業將擁有不止一條工具鏈來支持不一樣技術棧和交付平臺(COTS、雲、主機、容器原生等等)。

1.4 DevSecOps 的升溫

雲原生安全會變得愈來愈重要,由於企業或者組織都在積極擁抱Kubernetes[5],serverless 和其餘基於雲計算的技術。團隊須要新的工具和流程來保護資產。這就是爲何咱們預測在2021年DevSecOps的採用會是很是普遍的。

DevSecOps 是將安全和合規[6]測試集成到開發的流水線中。DevSecOps 應該是:

  • 無縫銜接到軟件開發生命週期中。
  • 給相關利益干係人提供透明的結果。
  • 不會下降開發人員的敏捷性。
  • 不須要團隊離開他們的開發環境。
  • 提供運行時的安全保護。

DevSecOps 正在變成可編程的,所以在接下來的幾年指望可以看到更高層次的一些自動化。

請看DevOps 安全最佳實踐[7]來確保你的團隊正在以安全可靠的方式運營着。

2021 年指望什麼:DevOps 流水線中安全將再也不是被滯後考慮的事情。DevSecOps 將以更高的速度和標準的 CI/CD 測試工具進行集成。結果就是,公司將看到網絡安全[8]、合規、規則和協議執行以及整體 IT 效率方面的改善。

1.5 應用程序性能監控(APM)軟件

在軟件開發中,APM 在給開發人員提供快速反饋的過程當中扮演了着重要的角色。APM 關鍵包括:

  • 前端監控(觀察用戶交互的性能和行爲)。
  • 應用發現、跟蹤及診斷(ADTD 分析了 web 和應用程序服務器、微服務及基礎設施之間的關係)。
  • AIOps 使能分析(探測生命週期內的模式、異常及因果關係)。

在 2021 年,APM 將極大的縮短 MTTR(平均修復時間 Mean Time to Repair)、提升服務可用性和改善用戶體驗。高級的 APM 能力將幫助 DevOps 團隊:

  • 更好的理解業務流程。
  • 深刻了解業務運維。
  • 對問題進行優先排序和隔離。

2021 年指望什麼:APM 提供商將進一步擴展他們的服務提供能力,包括基礎設施監控和分析的集成(包括網絡、服務器、數據庫、日誌、容器、微服務以及雲計算服務)。廠商也將繼續在 APM 中使用機器學習(ML machine learning):

  • 下降系統噪音。
  • 異常預測和檢測。
  • 發現來龍去脈。

對客戶體驗的日益重視將推進 APM 軟件可以對客戶旅程有深刻的洞察力。組織將開始依賴更多的 APM 來保護及更好的理解他們的應用。

1.6  普遍的雲管理平臺(CMP)

雲管理平臺(CMP)幫助團隊來管理公有云、私有云及多雲服務和資源。CMP 能力多是單個產品或一系列廠商提供服務的一種結果展現。

在 2021 年,組織將開始使用 CMP 來下降運維成本,同時確保適當的服務等級。CMP 將給業務提供諸多能力:

  • 管理和編排。
  • 服務請求管理。
  • 目錄和分類。
  • 雲監控和分析[9]。
  • 資源優化。
  • 雲遷移、備份和災備。
  • 加強策略和法規聽從性要求。

同時服務於開發和 I&O(基礎設施和運維)人員的 CMP 能力在 2021 年將是必須的。CMP 必須是:

  • 在不傷害開發敏捷性的狀況下介入開發流程。
  • 容許 I&O 團隊更容易執行資源管理標準。

2021 年指望什麼:企業將更好的理解 CMP 可以提供什麼,不可以提供什麼。企業將部署 CMP 來增長整個 DevOps 團隊的靈活性。

閱讀五種雲部署模型[10]來找到一款適合你的。

1.7 更多不肯定的目標和要求

雙模 IT 運營使 I&O 團隊可以經過分析肯定的需求來支持用戶。雙模 IT 依賴於如下兩種工做模式:

  • 模式 1:團隊已知需求且指望它們可以帶來可預測的 IT 服務或產品。
  • 模式 2:需求是不肯定的且需求探索也在進行中。其結果是很難預測的。

對於模式 2 的擁抱,可以帶來新的業務機遇。這些策略涉及高度的不肯定性,同時存在於業務和 IT 術語範疇內。公司將優先考慮敏捷性和項目的平均時間價值,產品團隊將尋求新的策略,提升用戶體驗。

2021 年指望什麼:I&O 團隊將不得不學習新的技能來增長敏捷性,提高業務價值。對當前流程的改變就像模式 2 中的機遇同樣,須要作進一步的簡化。

1.8 AgileOps 的進一步發展

AgileOps 是一套通過驗證的敏捷和 DevOps 方法,能夠被 I&O 用來改善敏捷性。AgileOps 技術有助於簡化其餘業務領域內的軟件開發和相關任務:

  • 爲了支持開發,I&O 團隊成員應該學習DevOps 和敏捷實踐[11]。
  • 對於不涉及開發的用例,團隊成員應該知道 Kanban、Gemba Kaizen 及普遍的自動化等這些概念。
  • 學習 scrum、精益流程及持續改進將幫助 I&O 改進產品管理技術。

2021 年指望什麼:日益增加的對用戶需求快速響應的需求將推進 AgileOps 的增加。I&O 團隊成員將使用敏捷、精益及 DevOps 概念來在不涉及應用程序開發的領域內獲取更多的敏捷性。

2、2021年(及之後)DevOps的將來

image.png

2.1 基於模板的實踐成爲一種約束

成功的 DevOps 須要團隊是自組織的,並且可以根據特定的產品需求來調整他們自身的流程。DevOps 團隊將開始將標準化的方法和框架發展成定製的工做方式。

到 2023 年,75% 的公司將經過調整敏捷實踐來和產品與團隊的實際狀況相匹配。結果就是,應用程序的交付節奏會加快。咱們還將看到新興技術的崛起,這些技術強調的是實踐而非理論,例如本質和自律的敏捷。

主要影響有:

  • 對特定產品(或一組相關產品)的分配將持續更長時間。
  • 熟悉產品將提升團隊效率。
  • 對敏捷和 DevOps 來講,持續學習和適應變得更加劇要。
  • 團隊將開始經過面向實踐的技術方式來描述工做。

團隊建議:

  • 制定方針,可是容許團隊選擇其實踐和工做方式。
  • 在定製過程以前,確保團隊瞭解敏捷開發是如何工做的。
  • 組織研討會與同事分享知識。
  • 以面向實踐的技術作實驗,來記錄相應的方法。

2.2 I&O 團隊將變得更敏捷

採用雲原生架構和可編程的基礎設施,將須要 I&O 團隊變得更加敏捷。I&O 團隊將不得不在基本腳本以外來擴展他們的開發技能。

可靠性工程師須要 I&O 團隊可以和開發及產品團隊更有效的進行協做。解決可靠性挑戰須要對系統設計和運維有一個清楚的認識。

到 2023 年,60% 的 I&O 團隊領導將提升他們的開發技能以支持業務創新。I&O 團隊將變得更擅長於:

  • 系統架構。
  • IT 運維人工智能(AIOps)。
  • 應用程序開發。
  • 測試自動化。

主要影響有:

  • 軟件工程師技能將使 I&O 來推進業務創新。
  • I&O 將和開發團隊有比以往更多的協做。
  • I&O 將採用新技能的優點來提升效率及減小技術債。

團隊推薦:

  • 隨着時間的推移,構建你的 I&O 能力。規劃你的發展需求,併爲如何知足這些需求制定長期計劃。
  • 在招聘新人才和內部員工培訓之間找到平衡點。
  • 注意留住員工,由於 I&O 對工程技能的需求將超過供給。

2.3 產品團隊自助服務平臺

一般,維護基礎設施的產品團隊缺少時間或專業技能來優化平臺使用。這些團隊必須將寶貴的資源從以用戶爲中心的創新轉移到平臺維護、升級和管理上。

到 2023 年,70% 的公司將爲產品團隊交付共享的、自助的服務平臺。這些平臺將使應用程序的部署頻率提升 25%。其餘的收益包括:

  • 更少的工具鏈重疊。
  • 治理和安全的一致性標準。
  • 更高的用戶滿意度。
  • 更大的業務敏捷性。
  • 內部平臺將更具響應性,對產品團隊的約束更少。

主要的影響有:

  • 企業對威脅和機遇的反應更快。
  • I&O 團隊成員將開始將平臺視爲隨着業務需求變化而不斷改進的產品。
  • 企業將減小重疊和冗餘、實現規模經濟並創建高標準的治理。

團隊建議:

  • 創建專門的平臺團隊,爲產品團隊提供更高的靈活性。
  • 組織社區分享來確保平臺知足全部消費者的需求。

2.4 混沌工程將變成常規測試手段

到 2023 年,40% 的 DevOps 團隊將使用混沌工程做爲他們測試套件標準的一部分。結果就是,咱們會看到非計劃的宕機會減小 20%。

混沌工程依賴於故障注入來發現錯誤和缺陷,這些錯誤和缺陷一般用其餘測試手段發現不了的。混沌實驗對於具備多個可移動部件的複雜 IT 系統來講是一種理想手段。

瞭解更多的混沌工程[12],學習不可預測的測試手段是如何構建系統的韌性的。

主要影響:

  • 雲生產環境的混沌實驗將變成持續交付流程的一個標準部分。
  • 大型企業將開始使用混沌工程以更快的速度擴大規模。

團隊推薦:

  • 建立社區實踐來構建混沌工程意識和技能。
  • 培訓使用開源的混沌工程工具。
  • 建立可重用的實驗,以幫助不一樣的團隊擴展方法並經過熟悉的測試創建信心。

2.5 快速故障恢復

爲了可以爲用戶持續的交付價值,應用程序必須一直在線且可用。在將來幾年,故障恢復將是DevOps的一大改進領域。

到 2023 年,60% 的組織會將系統恢復能力的測試變成 CI/CD 流水線的一部分。

咱們的CI/CD 指南[13]解釋瞭如何自動化發佈版本,以讓 DevOps 團隊和組織都能獲益。

主要影響:

  • 恢復測試變成了自動化測試流程標準的一部分。
  • QA 將更多的關注於缺陷修復。
  • 團隊將更加了解當前系統的可靠性和彈性。

團隊建議:

  • 將故障處理的整個流程自動化,就像缺陷發生在生產上同樣。
  • 確保系統恢復失敗的全部事件都通過根本緣由分析。
  • 擴展QA機制,包括按期驗證和系統可恢復性驗證。

3、儘早採用DevOps,保持競爭力

根據上述趨勢來採用 DevOps 的公司,將會提升他們的設計、構建、部署和維護高質量產品的能力。及時擁抱這些趨勢,會讓公司可以在一個競爭激勵的年份裏,保持充足的競爭力。

個人預測

如下爲做者本身的預測。

在 DevOps 領域浪蕩了幾年,閒來無事的時候,也會想一想 DevOps 的過去、如今及將來,在此也斗膽預測一下。

一、再莫提 CI/CD 了

不提 CI/CD 不意味着 CI/CD 已經不重要或者不須要了。偏偏相反,CI/CD 做爲 DevOps 的兩大關鍵核心能力,對 DevOps 的推動及落地實踐來講相當重要。之因此說再莫提 CI/CD,是由於 CI/CD 的發展已經像雲計算的發展同樣了,像水、像電,對人們來講已經觸手可及了。若是還在處於認知和實踐 CI/CD 的路途中,那就須要加倍努力了,畢竟這是一個只有努力奔跑才能留在原地的社會。

CI/CD 將更多的以研發效能平臺的方式出現。

另外,拋棄實現了 CI/CD 就等於實現了 DevOps 的愚蠢觀念吧。

二、雲原生的「入侵」

雲原生以摧枯拉朽之勢衝擊着 IT。各企業和組織對雲原生也展示出積極擁抱的態勢。Kubernetes,服務網格(典型如 Istio),Serverless 儼然成了雲原生技術發展的三駕馬車。Kubernetes 已經成爲了容器編排的實施標準,也能夠說是雲原生的基座。服務網格的發展也是如火如荼,Serverless 更是衆多頂級廠商極力佈局的戰場。

可是,目前爲止,雲原生也具備着無可爭議的複雜性。如何在雲原生的浪潮中來實施 DevOps 是每一個企業或組織所面臨的共同挑戰。作好以下幾點可以加速這一進程:

  • 對雲原生有一個全面的認知。
  • 提高軟件開發相關人員的技能。
  • 選取適合團隊的工具鏈(非最新、非最貴)。
  • 有序推動雲原生的落地(可參考CNCF Trail Map[14])。

不該該再糾結於要不要轉向雲原生,而應該更關注於如何作好雲原生的落地實踐。

三、DevSecOps 繼續備受關注

安全是一個老生常談的話題,在企業數字化轉型、採用敏捷開發、擁抱雲原生的狀況下,安全的重要的就更無須多言了。安全能力將持續的集成在軟件開發流程中。將安全融入 DevOps 的 DevSecOps 應該具備以下特色:

  • 儘可能左移,讓安全在開發早期介入。
  • 持續的自動化測試,作到安全的持續檢測。
  • 藉助機器學習(ML)來作漏洞識別與安全防禦等工做。

四、人工智能(AI)的持續介入

AI 可以幫助團隊來完成環境管理、漏洞識別、應用監控等重要工做。這能減小一些手動的、重複性的工做。然而,如何將複雜程度高、門檻高的 AI 融入 DevOps 中,也面臨不少的挑戰。

五、「人」應該被重點關照

DevOps 的問題歸根結底是人的問題,詳情可查看這篇公衆號 DevOps 的問題是關於人性的問題,你信嗎?。人是 IT 的核心要素。人才更是一個企業或組織可以長久發展的根本。一直以來,人們只關注用戶側,可是對 IT 開發相關人員卻被忽略了。應該作一些下面的事情:

  • 提供學習的環境:內外部分享和培訓的機會(哪怕是須要花錢的)。
  • 鼓勵參加開源社區:開源是 IT 發展的強大推進力,參加開源社區能使每一個人的眼界變寬,將開源技術帶入工做中,能縮短嘗試時間,同時帶來創新價值。
  • 重視人員的反饋:常常獲取人員對於現有流程、使用工具、工做環境等方面的反饋,及時做出有效調整,讓人員有歸屬感、幸福感,人員纔會有激情去全身心投入工做。

帶來的價值會有:

  • 創新變得容易:眼界變寬了,知識面豐富了。利用自身能力改進現有系統,引發新系統天然也就水到渠成了。
  • 忠誠度提升:員工將制定與本公司相關的我的五年計劃,而不是考慮下一份工做在哪兒。吸引更多的人才加入:畢竟人人都想加入一個「好」公司。

結束語

雖然,DevOps 走過了十多個年頭,依舊是那句話路漫漫其修遠兮,吾將上下而求索。

參考資料

[1] https://phoenixnap.com/blog/d...

[2] https://phoenixnap.com/blog/c...

[3] https://phoenixnap.com/bare-m...

[4] https://phoenixnap.com/blog/d...

[5] https://phoenixnap.com/blog/s...

[6] https://phoenixnap.com/kb/und...

[7] https://phoenixnap.com/blog/d...

[8] https://phoenixnap.com/blog/c...

[9] https://phoenixnap.com/blog/c...

[10] https://phoenixnap.com/blog/c...

[11] https://phoenixnap.com/blog/d...

[12] https://phoenixnap.com/blog/c...

[13] https://phoenixnap.com/blog/w...

[14] https://github.com/cncf/trailmap

來源:DevSecOps SIG
做者:小馬哥

相關文章
相關標籤/搜索