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