DevOps和左移的三個小貼士
如果將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)該負責創(chuàng)建IaC模板。這有一些邏輯。畢竟,應(yīng)用程序的開發(fā)人員應(yīng)該最了解其基礎(chǔ)設(shè)施需求,對吧?
另一方面,這也使開發(fā)人員負責了解生產(chǎn)網(wǎng)絡(luò)要求、大規(guī)模存儲配置和彈性資源管理。由于這種繁重的需求,可以公平地說,根據(jù)應(yīng)用程序生產(chǎn)環(huán)境的復(fù)雜性,DevOps并不是靈丹妙藥。
然而,受左移口號的啟發(fā),許多IT組織認為在應(yīng)用程序生命周期的早期移動其他任務(wù)是有意義的。因此,開發(fā)人員開始負責測試。和安全。和補丁管理。
不幸的是,正如通常所追求的那樣,這些任務(wù)并未被視為“代碼”。也就是說,以前負責他們的小組將責任連同通常用于執(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)路徑中的所有步驟。
當然,這意味著將開發(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)。俗話說,垃圾進,垃圾出。
當已知漏洞或有人對其進行攻擊時,這些類型的安全漏洞會變得更加糟糕。隨之而來的是更新代碼庫并將更新投入生產(chǎn)的瘋狂爭奪。
當開發(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)型的強大工具。