如果將DevOps應(yīng)用在的應(yīng)用程序生命周期中，它解決的問題很少。它用于自動化應(yīng)用程序裝配線，是實現(xiàn)數(shù)字化轉(zhuǎn)型的強大工具。

用查爾斯?狄更斯的話說，“這是最好的想法，也是最壞的想法。”這指的是什么？DevOps以及它是如何被解釋的。

DevOps的最佳理念是基礎(chǔ)架構(gòu)即代碼，即IaC。與手動構(gòu)建應(yīng)用程序環(huán)境不同，這是一個漫長且容易出錯的過程，IaC定義了在模板中構(gòu)建環(huán)境的“方式”，然后使用模板定義自動構(gòu)建該環(huán)境。

這以計算機速度而不是人類速度發(fā)生，而且同樣重要的是，每次都始終如一地完成，從而大大提高了應(yīng)用程序質(zhì)量。做得好，DevOps可以極大地提高應(yīng)用程序的速度。

這種應(yīng)用程序開發(fā)和部署的方法被稱為“左移”，因為它在應(yīng)用程序生命周期的早期移動了后期開發(fā)任務(wù)。

然而，DevOps挑戰(zhàn)比比皆是

然而，雖然DevOps的基礎(chǔ)設(shè)施即代碼是它的最佳理念，但它也是——正如它通常被實施——是最糟糕的理念之一。

開發(fā)人員經(jīng)常被告知他們應(yīng)該負責(zé)創(chuàng)建IaC模板。這有一些邏輯。畢竟，應(yīng)用程序的開發(fā)人員應(yīng)該最了解其基礎(chǔ)設(shè)施需求，對吧？

另一方面，這也使開發(fā)人員負責(zé)了解生產(chǎn)網(wǎng)絡(luò)要求、大規(guī)模存儲配置和彈性資源管理。由于這種繁重的需求，可以公平地說，根據(jù)應(yīng)用程序生產(chǎn)環(huán)境的復(fù)雜性，DevOps并不是靈丹妙藥。

然而，受左移口號的啟發(fā)，許多IT組織認為在應(yīng)用程序生命周期的早期移動其他任務(wù)是有意義的。因此，開發(fā)人員開始負責(zé)測試。和安全。和補丁管理。

不幸的是，正如通常所追求的那樣，這些任務(wù)并未被視為“代碼”。也就是說，以前負責(zé)他們的小組將責(zé)任連同通常用于執(zhí)行小組任務(wù)的手動清單一起傳遞給了開發(fā)人員。因此，開發(fā)人員在他們沒有特別專業(yè)知識的領(lǐng)域進行了大量的手動工作。

你猜怎么著？做某事的開發(fā)人員不會更快地完成任務(wù)，尤其是在主題專業(yè)知識較低的情況下。因此，DevOps方法的潛在速度通常仍然遠低于預(yù)期。

右移左移

那么，左移“作為代碼”方法的前進道路是什么?應(yīng)用程序是否注定要陷入由不堪重負的開發(fā)人員執(zhí)行的手動流程中?

一句話，沒有。但組織需要以正確的方式左移。以下是有關(guān)如何做到這一點的三個提示。

(1) 自動化所有任務(wù)

如果將基礎(chǔ)設(shè)施作為代碼進行是有意義的，那么將測試作為代碼進行、將安全作為代碼進行、將補丁管理作為代碼進行也是有意義的。換句話說，將DevOps的邏輯應(yīng)用于生產(chǎn)路徑中的所有步驟。

當(dāng)然，這意味著將開發(fā)技能應(yīng)用于這些任務(wù)，這需要開發(fā)人員。期望主題專家(例如，QA工作人員)的個人資料發(fā)生變化，以納入編程經(jīng)驗。這也意味著將每個任務(wù)自動化管理為自己的應(yīng)用程序，并具有自己的生命周期管理。

(2) 將生產(chǎn)路徑視為自動化產(chǎn)品

擁有最快生產(chǎn)路徑的技術(shù)組織將整個過程視為一個集成產(chǎn)品，在其各個子步驟中實現(xiàn)自動化。這意味著中間步驟之間的自動切換和消除手動批準。我在看著你，變更控制委員會。

在現(xiàn)實世界中，大多數(shù)手動批準步驟都是自動勾選審查框的正式儀式。如果從一個步驟到另一個步驟的切換可以簡化為自動點頭，那么它也可以簡化為自動切換，并具有明確定義的異常處理。

這也意味著生產(chǎn)路徑需要將整體作為產(chǎn)品本身進行管理，并進行架構(gòu)審查以確保所有自動化子系統(tǒng)相互配合。

如果這聽起來像是工作和投資，那你是對的。然而，如果沒有這個，生產(chǎn)路徑將保持緩慢，兩端的速度(通過Dev和Ops)在中間預(yù)訂相同的舊緩慢手動步驟。

(3) 更左移

雖然自動化所有任務(wù)(以及自動化整個流程)是很好的步驟，但如果易受攻擊或過時的代碼構(gòu)成應(yīng)用程序的基礎(chǔ)，那么確保良好的安全性仍然是一個挑戰(zhàn)。俗話說，垃圾進，垃圾出。

當(dāng)已知漏洞或有人對其進行攻擊時，這些類型的安全漏洞會變得更加糟糕。隨之而來的是更新代碼庫并將更新投入生產(chǎn)的瘋狂爭奪。

當(dāng)開發(fā)人員從一張白紙開始，直接從Internet下載庫和組件時，這個問題就很普遍。令人震驚的是，有多少基于容器的應(yīng)用程序是使用從DockerHub下載的圖像構(gòu)建的，盡管眾所周知，許多最流行的應(yīng)用程序都包含過時和/或易受攻擊的代碼。

更好的方法是為開發(fā)人員提供準備好的代碼庫，這些代碼庫已知是最新的，并且評估為沒有漏洞。這方面的機制稱為模板、框架或加速器。本質(zhì)上，開發(fā)人員將模板下載到首選IDE中，并從包含應(yīng)用程序功能的安全代碼基礎(chǔ)開始。

應(yīng)用程序更新完成后，將進入上述自動化過程。創(chuàng)建應(yīng)用程序工件并在生命周期的不同階段移動，直到最終部署。

這種代碼衛(wèi)生方法可以擴展到生命周期的其余部分，方法是讓一個進程位于特定應(yīng)用程序管道之外以監(jiān)控已公布的漏洞。如果發(fā)布了漏洞并提供了補丁，則會啟動應(yīng)用程序構(gòu)建和部署過程，該過程會自動更新相關(guān)工件并將其投入生產(chǎn)。

這避免了手動跟蹤每個應(yīng)用程序包含哪些庫和組件。它還避免了與嘗試確保更新每個相關(guān)應(yīng)用程序相關(guān)的危機管理，這不可避免地會遺漏一些并導(dǎo)致易受攻擊的應(yīng)用程序永遠無法修復(fù)。

這種“進一步左移”的新興行業(yè)術(shù)語是安全軟件供應(yīng)鏈，這種方法將在未來變得更加普遍，尤其是隨著越來越多的業(yè)務(wù)流程轉(zhuǎn)向數(shù)字機制。

事實上，DevOps既是一個好主意，也是一個壞主意，這取決于應(yīng)用的方式。在應(yīng)用程序生命周期上，它解決的問題很少。作為應(yīng)用程序裝配線的一部分的自動化概念，它是實現(xiàn)數(shù)字化轉(zhuǎn)型的強大工具。