自 2008 年在多倫多敏捷會議上,Petrick Debois 提出“DevOps”一詞以來。經過十三年的發展,DevOps 已經被視為企業發展的關鍵,絕大多數的組織都正在引入 DevOps 以應對更復雜的開發需求和環境。但如何才能成功實踐 DevOps 至今依舊是待解問題。

Puppet 發布的2021年度DevOps 狀況調查報告指出,83% 的 IT 決策者表明他們的組織正在實施 DevOps 實踐;與此同時,絕大多數組織仍然停留在 DevOps 演變的中期階段。企業在落地 DevOps 實踐時,仍面臨許多挑戰,因此,業界也在多年的實踐之中,總結出一些關鍵要素,來幫助推動 DevOps 實踐。

DevOps 關鍵要素

目前 DevOps 實踐中的一些關鍵要素注重文化層面,由DevOps 標準核心編寫專家總結出 4 個關鍵要素。

一個關鍵因素是 IT 部門和業務部門的目標要對齊。

IT 部門和業務部門常常有矛盾。如業務部門對 IT 部門的不滿來自四個方面,一是 IT 人員與業務部門溝通補償,缺乏系統性的運營管理思維,導致業務部門認為雙方愿景無法匹配;二是 IT 部門聚焦過程而非結果;三是 IT 部門總是在解決自己的問題,忽略了產出,同時會不斷有新的問題出現;四是對于業務部門來說,整個 IT 內部像是一個黑盒子,因為管理部門通常會說 IT 部門是無法控制的黑盒,專注于技術,缺乏溝通,同時 IT 人員及各種服務設備越來越貴,功能不透明等等都讓業務部門認為難以溝通。

反過來,為什么 IT 部門做了很多事情但是業務部門不買賬?IT 部門對業務部門也有許多不滿,他們會認為業務部門的許多需求不夠清醒,從開發初期到上線需求一直在改;另外業務只提出高優先級,常常沒有低優先級,難以分出哪個需求是最高優先;不知道業務指標和收益,不清楚開發出來的功能有多大效果。

因此,目標對齊非常重要,IT 部門和業務部門之間要做好充分的聯合,聚焦客戶價值,關注客戶的實際需求、滿意度等等。

第二個關鍵要素是人員和文化。

傳統的開發模式下一般是項目制,同時把各個項目分割成不同的開發階段,包括需求、定義、設計、編碼、單測等等,同時使用里程碑方式,嚴格定義開發階段的輸出,達不到相應輸出則不能展開下一階段工作。這種工作模式將開發階段定義成黑盒,希望每個人階段的技術人員只關注自己階段的工作,好處是可以讓不同角色的人員專注本質工作,提高階段效率;壞處是出現問題可能會互相推諉,并且由于每個開發階段的信息相對封閉,會造成大面積的理解偏差。

Puppet 發布的 2021 年度 DevOps 狀況調查報告同時還指出,絕大多數組織仍然停留在 DevOps 演變的中期階段,其中文化問題是 DevOps 取得成功的最大障礙。

調查結果顯示,只有 18% 的受訪者擁有高效的 DevOps 團隊,4% 處于低功能狀態,大多數(78%)處于中間狀態。雖然處于中間狀態的組織表示,他們正在建立 DevOps 文化。但 Puppet field CTO Nigel Kersten 認為,“仍然存在組織對變革的抵制,這是一個真正的問題。而且人們真的沒有看到他們實際上試圖通過 DevOps 實現的實際價值。”中層最常見的文化阻礙因素包括有:不鼓勵風險的文化 (21%)、不明確的責任 (20%)、不優先考慮快速流程優化 (18%) 和不充分的反饋循環 (17%)。

因此做好 DevOps 的文化工作,讓團隊熟悉 DevOps 的流程及相關操作規范至關重要。

第三個要素是流程。

對于一個項目來說,在立項之初,大家對項目的關注度和期望很高,因此剛開始時有較高的能見度,但在執行過程中,能見度會越來越低。所以在敏捷開發中會采用迭代開發方式,項目全程可見度高,并且不斷與客戶探討相關需求,根據反饋做改進,這樣達到的最終結果是業務價值持續穩步上升,同時風險也被很好地控制。

第四個要素是平臺。

在挑選平臺時,往往要注意的點通常包括自動化、可視化、自主服務。自動化需要做到標準化;同時通過平臺達到自動服務也非常關鍵;還有可視化,包括端到端流水線的可視化,度量可視化,業務數據、研發效能、質量、速度、滿意度等等皆可通過可視化方式改進。

關于自動化,有三個關鍵前提。第一是標準化,需要有相應流程和規范的梳理,只有形成流程和規范的標準,后續的相關維護與功能拓展才能使用版本化的管理方式。第二方面,對于平臺化建設的自助服務,其中最關鍵的是打造一個盡可能傻瓜式的自助服務平臺。第三方面涉及平臺度量的可視化,包括合規的展示,安全和開源合規也尤為重要,此外關于可靠性的展示也非常重要。

關于第四要素平臺的一些特質,飛算云智總裁陳定瑋在近期的訪談中也提到,飛算 SoFlu 全自動軟件工程平臺上通過制定系列標準,來規范軟件工程全流程開發管理。飛算 SoFlu 全自動軟件工程平臺團隊將前沿大廠使用的開發規范結合實際遇到的問題處理方式后,從效率、安全等多方面考慮,制定了自己的代碼規范。比如,限定每行代碼的寫法、有些地方不允許 SQL 拼接、Join 不允許超過三次等。除了規范,所有的代碼還必須接受嚴格檢測,確定沒問題后才會被提交到代碼倉庫。同理,所有組件也必須經過代碼質量管理工具掃描無誤后才讓用戶使用?，F在,飛算 SoFlu 全自動軟件工程平臺的質量管理平臺上已經有一千多條標準,而新的規則也在不斷被加入其中。

企業的 DevOps 實踐

在這些關鍵要素的基礎之上,企業想要完整落地 DevOps 實踐,首先需要確立從項目到產品的研發模式。第二借助 DevOps 平臺,通過那些服務屬性的功能,支持產品開發與業務上線,同時建立相應的防御和審批措施。第三在部署方面,新的部署方式可能逐漸會有運維人員支持做上線,演變成平臺全流程支持,隨著平臺建設越來越完善,能夠提供足夠多的監控和審計功能,當項目制演變成產品制之后,產品開發團隊就完全可以做到自助式流程變更甚至代碼提交等等。第四,要非常注重用戶體驗,包括在做 DevOps 自動化部署平臺時,也要關注運維相關體驗,從開發到測試以及最后維護環節所有使用人員的體驗。

對于企業引入 DevOps 流程,在平臺之上實現敏捷開發,陳定瑋也提出了自己的看法,在他看來,平臺如果不能真正幫助企業降本增效,反而是害了企業。因此,他也一直強調自己是交鑰匙工程,“未來企業不需要繼續依托我們進行維護和迭代,并且在部署層面可以節省企業很多資源。平臺分布式、可彈性擴縮容的設計理念相當于幫企業做了中長期的規劃,只需要適時增加硬件資源即可幫助業務快速上升,無需對結構進行大的調整。”

未來,隨著 DevOps 平臺的不斷發展與完善,企業在落地 DevOps 實踐時,將有更多可依靠的標準,趁手的工具,以及專業的指導,來達成愈發成熟的實踐。

責任編輯：劉沙