據(jù)預(yù)測(cè),未來(lái) 10 年中,企業(yè)或組織的數(shù)字化轉(zhuǎn)型會(huì)達(dá)到高峰,將比過(guò)去幾十年的總和還要多。而這一進(jìn)程,開(kāi)發(fā)工程師必須找到更加有效的開(kāi)發(fā)方式,才能實(shí)現(xiàn)。
在這一層面來(lái)說(shuō),DevOps 是數(shù)字業(yè)務(wù)轉(zhuǎn)型計(jì)劃的核心。目前,企業(yè)越來(lái)越重視DevOps,并開(kāi)始向這種開(kāi)發(fā)方式轉(zhuǎn)型。但是,如此多聲稱專注于 DevOps 的企業(yè)或組織,真的都做對(duì)了嗎?
在大多數(shù)的 DevOps 實(shí)踐中,僅僅涉及到了特定工具的使用,企業(yè)非常松散地遵循著某些 DevOps 原則。然而,要想真正成為一個(gè)以 DevOps 為中心的組織,這些遠(yuǎn)遠(yuǎn)不夠。參照以下 7 點(diǎn),或許能夠幫助你及時(shí)糾偏:
一、部署是完全自動(dòng)化的
每一個(gè)項(xiàng)目工程通常都包含了很多的代碼文件、配置文件、第三方文件、圖片、樣式文件等不同部分,要想將這些部分有效組裝、最終形成最后的應(yīng)用結(jié)果,往往需要借助構(gòu)建工具或策略。
構(gòu)建過(guò)程如果僅僅依賴人工,就會(huì)十分繁瑣。于是,自動(dòng)化構(gòu)建、自動(dòng)化發(fā)布、自動(dòng)化部署的想法和探索就浮現(xiàn)了。自動(dòng)化的出現(xiàn),將大大提升工作效率。
在 DevOps 實(shí)踐中,是需要從頭到尾完全自動(dòng)化部署的。自動(dòng)部署的意義不僅僅在于節(jié)省時(shí)間,更多是避免問(wèn)題的出現(xiàn),手動(dòng)部署更常出現(xiàn)因?yàn)槿藶殄e(cuò)誤引起的問(wèn)題,而自動(dòng)部署可以在問(wèn)題出現(xiàn)時(shí)迅速恢復(fù)到以前的版本。
二、有頻繁且快速的發(fā)布周期
天下武功唯快不破。想要獲得更強(qiáng)大的競(jìng)爭(zhēng)力,只有不斷部署和快速修復(fù)。DevOps 中一個(gè)核心功能就是 CI/CD(持續(xù)集成/持續(xù)交付),尋找更有效的自動(dòng)化和部署更新迭代的方法,讓開(kāi)發(fā)人員提高生產(chǎn)效率、并快速地發(fā)布到生產(chǎn)環(huán)境中。
CI/CD 通過(guò)在構(gòu)建、測(cè)試和部署應(yīng)用程序時(shí)強(qiáng)制自動(dòng)化完成。這種 DevOps 方法的精髓在于:
1)通過(guò)頻繁的代碼庫(kù)提交、自動(dòng)化構(gòu)建等來(lái)提高生產(chǎn)力;2)通過(guò)集成自動(dòng)化測(cè)試以及開(kāi)發(fā)期間的測(cè)試,增加在開(kāi)發(fā)早期發(fā)現(xiàn)錯(cuò)誤的機(jī)會(huì);3)得益于頻繁的測(cè)試和自動(dòng)化部署系統(tǒng),可以更快地發(fā)布版本。
三、注重可觀察性
國(guó)外的一份報(bào)告顯示,可觀察性正在成為 DevOps 實(shí)踐中絕對(duì)不能缺少的一環(huán)。在跨越多個(gè)流程的數(shù)字業(yè)務(wù)轉(zhuǎn)型中,可觀察性有非常重要的意義。
New Relic 對(duì) 1300 名 IT 領(lǐng)導(dǎo)者、軟件工程師和開(kāi)發(fā)人員進(jìn)行的一項(xiàng)全球調(diào)查發(fā)現(xiàn),90% 的受訪者認(rèn)為可觀察性對(duì)業(yè)務(wù)至關(guān)重要。只有更多地基于事實(shí)而非直覺(jué),才能作出明智的決策,越來(lái)越多的團(tuán)隊(duì)開(kāi)始從整個(gè)企業(yè)應(yīng)用程序環(huán)境中收集數(shù)據(jù),來(lái)提高整個(gè)開(kāi)發(fā)過(guò)程的可觀察性,可觀察性也在生產(chǎn)前和生產(chǎn)后的環(huán)境中扮演越來(lái)越重要的角色。
四、有持續(xù)的反饋循環(huán)
初期,DevOpsDays 活動(dòng)的發(fā)起人和 DevOps 這個(gè)詞的創(chuàng)始人 Patrick Debois 發(fā)現(xiàn),有關(guān) DevOps 的話題相互交織在一起形成了四個(gè)不同的反饋環(huán),如上圖所示。
其中,藍(lán)色氣泡代表技術(shù),黃色氣泡代表過(guò)程管理。一起形成了 4 個(gè)循環(huán)。開(kāi)發(fā)-測(cè)試反饋環(huán)(黑色箭頭反饋環(huán));開(kāi)發(fā)-運(yùn)維反饋環(huán)(綠色箭頭反饋環(huán));業(yè)務(wù)-運(yùn)維反饋環(huán)(紅色箭頭反饋環(huán));業(yè)務(wù)-用戶反饋環(huán)(紫色箭頭反饋環(huán))。
在現(xiàn)在的 DevOps 理念中,出現(xiàn)錯(cuò)誤并不可怕,可怕的是沒(méi)有一個(gè)持續(xù)的反饋循環(huán)系統(tǒng)來(lái)檢測(cè)何時(shí)何地出現(xiàn)問(wèn)題。反饋循環(huán)需要在發(fā)生錯(cuò)誤時(shí)快速通知,從而使問(wèn)題得到更快地解決。
很多時(shí)候,我們遇到問(wèn)題僅僅是簡(jiǎn)單地解決了它,并沒(méi)有花時(shí)間分析問(wèn)題發(fā)生的原因以及如何防止問(wèn)題再次出現(xiàn)。這樣的循環(huán)是不完整的。從某種程度上,如果你設(shè)置了一個(gè)系統(tǒng)來(lái)識(shí)別問(wèn)題、修復(fù)問(wèn)題和改進(jìn)問(wèn)題,還需要認(rèn)真分析,才意味著你在正確地實(shí)踐 DevOps。
具體來(lái)說(shuō),一個(gè)監(jiān)控系統(tǒng)需要觀察并記錄系統(tǒng)狀態(tài)變化和數(shù)據(jù)的流程:1)狀態(tài)的變化:可以通過(guò)狀態(tài)的直接度量或者更新日志來(lái)表示;2)數(shù)據(jù):可以通過(guò)記錄內(nèi)部組件和外部系統(tǒng)之間的請(qǐng)求和響應(yīng)來(lái)記錄。
五、開(kāi)發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)一起工作
Dev(開(kāi)發(fā)) 和 Ops(運(yùn)維) 的矛盾主要是面向適應(yīng)性的敏捷軟件交付和面向經(jīng)驗(yàn)性的傳統(tǒng)運(yùn)維之間的矛盾。這個(gè)矛盾最先由 John Allspaw 和 Paul Hammond 在“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”提出,并以“Cooperation”作為整個(gè)演講的核心,講述了他們解決這個(gè)矛盾的實(shí)踐經(jīng)驗(yàn)。
在一個(gè)組織中,如果相關(guān)利益者的利益不一致,在既定流程的進(jìn)行中一定會(huì)碰到諸多阻力。而在這一點(diǎn)上,首先做的就是把 Dev 和 Ops 的利益一致化,從而減少 Ops 對(duì)軟件交付的阻力。
在傳統(tǒng)觀念中,開(kāi)發(fā)的工作是增添新的功能,而運(yùn)維的工作則是保證站點(diǎn)的穩(wěn)定和高性能。 而在 DevOps 的觀念中,Ops 的工作目標(biāo)應(yīng)該是激活業(yè)務(wù)(enable the business ),與 Dev 是一致的。
至此,DevOps 眾所周知的主要好處就是打破開(kāi)發(fā)和運(yùn)營(yíng)之間的孤島。在維基百科上,DevOps 的解釋也著重于一種重視“軟件開(kāi)發(fā)人員(Dev)”和“IT運(yùn)維技術(shù)人員(Ops)”之間溝通合作的文化、運(yùn)動(dòng)或慣例。因此,開(kāi)發(fā)、測(cè)試和 IT 運(yùn)維團(tuán)隊(duì)之間的溝通對(duì)于 DevOps 的成功至關(guān)重要。
六、目標(biāo)明確
雖然不同團(tuán)隊(duì)之間的溝通至關(guān)重要,但明確定義每個(gè)人都在努力實(shí)現(xiàn)的目標(biāo)同樣重要。歸根結(jié)底,所有團(tuán)隊(duì)都有同一個(gè)目標(biāo):讓組織更有效率。
但是,他們?yōu)閷?shí)現(xiàn)這一目標(biāo)而遵循的個(gè)人實(shí)踐可能會(huì)有所不同。團(tuán)隊(duì)成員應(yīng)了解實(shí)現(xiàn)目標(biāo)所需滿足的精確要求,而不是做出假設(shè)或任其發(fā)展。
七、使用正確的工具和平臺(tái)
DevOps 不僅僅是一種文化轉(zhuǎn)變——它需要強(qiáng)大的工具才能實(shí)現(xiàn)。在實(shí)踐過(guò)程中,如果你發(fā)現(xiàn)往往需要花費(fèi)大量時(shí)間來(lái)解決出現(xiàn)的問(wèn)題,那么很可能是因?yàn)槟銢](méi)有選擇正確的 DevOps 工具。
幸運(yùn)的是,目前的市場(chǎng)上有大量且廣泛的 DevOps 工具可以選擇,以適應(yīng)當(dāng)前現(xiàn)有的所有的數(shù)字化基礎(chǔ)設(shè)施。盡管工具是 DevOps 的重要組成部分,但是要記住,真正使改變發(fā)生的是實(shí)踐。
在眾多 DevOps 工具中,近兩年來(lái)被業(yè)內(nèi)廣泛關(guān)注的飛算SoFlu因其對(duì)軟件開(kāi)發(fā)流程的變革而被大量企業(yè)應(yīng)用于DevOps落地,飛算SoFlu是一款管理加開(kāi)發(fā)工具,通過(guò)可視化編程的方式滿足開(kāi)發(fā)需求。使用平臺(tái)的一個(gè)ID相當(dāng)于一個(gè)10人科技團(tuán)隊(duì),從而使用戶有更多精力可以更多關(guān)注自身業(yè)務(wù)。飛算SoFlu中包含的三大核心技術(shù),全都是 DevOps 實(shí)踐中所要關(guān)注的重點(diǎn):
1)可視化開(kāi)發(fā)
改變傳統(tǒng)開(kāi)發(fā)方法,業(yè)務(wù)邏輯可視化展示,降低開(kāi)發(fā)門檻,無(wú)需編寫代碼,在設(shè)計(jì)業(yè)務(wù)邏輯時(shí)就形成微服務(wù)應(yīng)用。
2)平臺(tái)組件
可視化平臺(tái)組件是一類通用的技術(shù)功能模塊,平臺(tái)支持循環(huán)條件判斷,函數(shù)調(diào)用,通過(guò)拖拽方式以及參數(shù)配置實(shí)現(xiàn)等同于編寫復(fù)雜代碼的業(yè)務(wù)邏輯,有別于通過(guò)組件排列組合。
3)管理方式
主要通過(guò)管理平臺(tái)來(lái)管理需求、研發(fā)、測(cè)試、部署、上線、運(yùn)維等整個(gè)軟件生命周期,經(jīng)驗(yàn)沉淀、知識(shí)積累,將管理制度真正的落地。
截至目前,飛算SoFlu已為包括醫(yī)療、金融、制造、零售等在內(nèi)的八大行業(yè)的上百家機(jī)構(gòu)提供了技術(shù)服務(wù),助力其落地DevOps,提升研發(fā)效率。
一個(gè)典型的案例是,飛算SoFlu在某大型國(guó)有銀行的應(yīng)用。該銀行原本需要3天才能開(kāi)發(fā)完成的接口,使用飛算SoFlu,僅用了5個(gè)小時(shí)。其IT負(fù)責(zé)人表示,使用飛算SoFlu后,銀行軟件中心的整體研發(fā)效率獲得了大幅提升。
飛算SoFlu的DevOps功能正是在不斷的實(shí)踐中完善升級(jí),從實(shí)際業(yè)務(wù)出發(fā),真正讓企業(yè)實(shí)現(xiàn)降本增效。
