2022年之前，你不得不了解的一些DevOps趨勢

2021年已經(jīng)走進尾聲，這一年全球依舊遮蔽在疫情的陰霾之下，這并不是什么好事情。然而，由疫情所激發(fā)的信息技術(shù)爆發(fā)卻是一件好事。

在過去十年，我們見證了數(shù)字化轉(zhuǎn)型的快速發(fā)展，也見證了DevOps概念的誕生；而在過去一年中，DevOps經(jīng)歷了前所未有的飛速成長。

接下來，本文就為大家介紹在過去的一年中DevOps經(jīng)歷了哪些蓬勃發(fā)展。作為時代洪流中的當(dāng)局者，我們又該怎樣應(yīng)對？

一、2021年我們見證的DevOps發(fā)展

1、DevOps成為任何數(shù)字業(yè)務(wù)轉(zhuǎn)型的核心

由于買方行為的重大變化和持續(xù)的供應(yīng)鏈危機，各種規(guī)模的組織都不得不調(diào)整其業(yè)務(wù)模式。DevOps團隊是所有主要數(shù)字業(yè)務(wù)轉(zhuǎn)型計劃的核心，因此對DevOps專業(yè)知識的需求正在迅猛上升，呈現(xiàn)了嚴(yán)重的供不應(yīng)求趨勢。

據(jù)預(yù)測，未來10年我們將看到比過去40年更多的數(shù)字化轉(zhuǎn)型。如果沒有開發(fā)人員和工程師攜手合作，如果不能做到更快速地構(gòu)建和部署，恐怕一些企業(yè)的發(fā)展愿景將難以實現(xiàn)。

2、低代碼值得依賴嗎？

疫情導(dǎo)致人們對驅(qū)動數(shù)字工作流的需求激增。低代碼的出現(xiàn)，可能減少專業(yè)開發(fā)人員構(gòu)建應(yīng)用程序所需要的時間，這是好事。

但是，值得注意的是，低代碼目前依舊難以勝任復(fù)雜框架的構(gòu)建，過程代碼構(gòu)建依舊不可替代。從這一維度上來說，低代碼可以在比較低層次上加快開發(fā)人員的部署速度，但無法替代更加高級的功能構(gòu)建。

或許，下一代的低代碼將很快由非專業(yè)的個人來參與開發(fā)，屆時涌來如此多的代碼會吞沒DevOps管道嗎？這還有待觀察。

3、微服務(wù)優(yōu)勢凸顯

構(gòu)建應(yīng)用程序的架構(gòu)用松散耦合的服務(wù)來構(gòu)建框架的核心概念可以追溯到1990年代。下一個時代，將是面向服務(wù)框架（SOA）的天下。

當(dāng)然，微服務(wù)本身已經(jīng)存在好幾年了。然而，隨著容器作為構(gòu)建微服務(wù)的軟件工件的興起，微服務(wù)的優(yōu)勢得到有力凸顯：微服務(wù)構(gòu)建不僅需要更少的時間，而且更易于維護且更具彈性。

4、可觀察性是DevOps的一項重大進步

可觀察性的概念可以追溯到線性動態(tài)系統(tǒng)?？捎^察性的最基本形式就是——衡量外部輸出的信息，從而推斷出系統(tǒng)內(nèi)部狀態(tài)的程度。

在2021年，眾多IT供應(yīng)商推出了各種類型的可觀察性平臺。這些可觀察平臺使DevOps團隊可以更輕松地查詢機器數(shù)據(jù)，在問題造成進一步中斷之前主動發(fā)現(xiàn)問題產(chǎn)生的根本原因。

與通常僅提供預(yù)定義指標(biāo)來識別特定平臺的監(jiān)控平臺相比，這無疑是重大進步。

5、AI將更好地改變DevOps

管理DevOps環(huán)境涉及高度的復(fù)雜性。尤其是在數(shù)據(jù)爆發(fā)的現(xiàn)在，數(shù)據(jù)的快速擴散使DevOps團隊難以有效地載入、攝取和解鎖數(shù)據(jù)，而想要根據(jù)信息做出良好的業(yè)務(wù)決策就更難了。

AI可以加快軟件發(fā)布步伐，幫助企業(yè)實現(xiàn)持續(xù)交付。這使程序員能夠以大約10倍的速度發(fā)布軟件，并允許在發(fā)布程序之前對其進行審查。

由此，從挑戰(zhàn)大量高度復(fù)雜數(shù)據(jù)上來說，DevOps的未來將由人工智能驅(qū)動。如果是要集成和分析數(shù)據(jù)，人工智能驅(qū)動的解決方案將是第一選擇。

Gartner指出，到2023年，40%的DevOps團隊將利用具有內(nèi)置AI功能的應(yīng)用程序和基礎(chǔ)設(shè)施監(jiān)控解決方案。Gartner預(yù)測，AIOps市場將以每年在3億至5億美元之間的驚人速度增長。

二、2022年DevOps實踐的4個關(guān)鍵點

1、評估流程永遠都是第一步

DevOps其實不是一個非常好理解的概念。如果我們不能很好了解DevOps是什么以及它對組織的意義，那將可能是一個災(zāi)難。

不僅如此，團隊中的每一個人都需要同步自己對DevOps的了解，只有團隊充分溝通且“同意”，DevOps實踐才能順利。這也就是為什么所有公司在切換至DevOps時的難點和重點都是——文化建設(shè)和學(xué)習(xí)。

此外，對開發(fā)周期的評估也應(yīng)該是全方位的、從頭到尾的。開發(fā)的不同流程，有不同的瓶頸，只有找到當(dāng)前流程不足的領(lǐng)域，才能在實施DevOps時鎖定重點。

2、協(xié)作和目標(biāo)是DevOps團隊的預(yù)備動作

在實施DevOps之前，就應(yīng)該要確定團隊有沒有準(zhǔn)備好一起工作和溝通。向每一位成員灌輸強烈的協(xié)作意識，并為他們提供有助于他們溝通和協(xié)作的工具。

此外，明確的目標(biāo)則為DevOps實踐設(shè)立方向，否則任何DevOps實踐都將毫無意義。通常，我們可以從一個更小、更容易實現(xiàn)的目標(biāo)開始，之后再轉(zhuǎn)向更大、更復(fù)雜的目標(biāo)，以防止一次性改變太多帶來不可修復(fù)的破壞。

3、自動化是DevOps的重要組成部分

在DevOps過程中，我們應(yīng)該盡可能多地使用自動化手段。無論是掃描錯誤配置的代碼還是自動化測試，現(xiàn)下都有各種不同的自動化工具來實現(xiàn)，這對效率的提升無疑是巨大的。

在這個基礎(chǔ)上，如果還想進一步的自動化，項目就不得不考量團隊是否能跟上了。所以，最好的辦法是，從需要大量時間和手工的工作入手，去一步步實現(xiàn)自動化。采用自動化之初，也最好讓團隊先監(jiān)控幾周，看看進展如何。

4、了解關(guān)鍵指標(biāo)是重中之重

從實施DevOps的一開始就應(yīng)該設(shè)置關(guān)鍵指標(biāo)。如果沒有指標(biāo)，我們將無法跟蹤進展，也無法及時發(fā)現(xiàn)問題。

大多數(shù)組織需要關(guān)注的DevOps關(guān)鍵指標(biāo)都涉及這3點：交付時間、部署時間和平均恢復(fù)時間。而這三項指標(biāo)都能在飛算SoFlu全自動軟件工程平臺上得到很好的體現(xiàn)。

飛算SoFlu全自動開發(fā)平臺項目發(fā)布的應(yīng)用服務(wù)，在監(jiān)控運維指標(biāo)方面已集成健康檢查、審計、統(tǒng)計和HTTP追蹤等運維性能指標(biāo)數(shù)據(jù)，所有的這些特性可以通過JMX或者HTTP endpoints來獲得。

同時還可以與外部應(yīng)用監(jiān)控系統(tǒng)整合對接，可以方便地通過第三方系統(tǒng)進行監(jiān)控告警，比如Prometheus、Influxdb、Grafana等。這些系統(tǒng)提供了非常好的儀表盤、圖標(biāo)、分析和告警等功能，使用戶可以通過統(tǒng)一的接口輕松地監(jiān)控和管理應(yīng)用。

就以Prometheus+Grafana環(huán)境為例，全自動開發(fā)平臺項目能夠以美觀漂亮的界面展示程序IO、內(nèi)存、JVM等性能指標(biāo)情況（如下圖所示）：

詳情請戳：www.feisuanyz.com