實踐者的 DevOps 之路(1. 被誤解的 DevOps)

近幾年隨着敏捷在國內日趨流行,DevOps 作爲與敏捷方法論相輔相成的 IT 實踐也被廣大管理者所重視。在過去的幾年中我參與實施了大約十幾個 DevOps 的相關項目,有成功的,也有失敗的。而我的工作跨度也很大,既有作爲技術顧問,也有作爲 Scrum Master,或者是一名開發者甚至是一名運維。正是這些不同的項目,不同的角色讓我對 DevOps 有了更爲全面的理解與實踐。這次我希望通過一個系列的文章與大家一起分享,也算是自己做一個階段性的總結。

本文是系列的第一篇,我先談談日常遇見的對 DevOps 的一些誤解。

DevOps 是銀彈

我遇見的大部分想要進行 DevOps 的組織或是團隊最直接的原因就是發佈困難。例如有些公司的每一次發佈猶如孕婦分娩,而且還是難產的那種。整個發佈流程充斥着各種「祖傳」腳本,手工摻雜自動,相同的操作都可能引致不同的結果。每次發佈是否成功都需要些運氣,就算是這樣發佈後還可能遇到類似忘記運行某個腳本這樣的低級失誤。

這些團隊管理者的訴求就是: 給我一個按鈕,上面寫着「發佈」,按一下就凡事搞定!最好這個按鈕還是聲控的 ????。

但是從系統化思考的角度出發,我們不應該簡單的在結果周圍找原因,應該從更寬泛的視角去尋找引起問題的根因與解決方案。發佈上線的自動化並不是 DevOps 的核心問題域,只是 DevOps 的一種最基礎的表現形式而已。

而遇到這些問題的團隊或是組織的共同問題就是它們往往不是一個真正的敏捷團隊。發佈遇到的問題只是前序流程中問題的累積,在最後一個環節爆發而已。你很難單純地用 DevOps 幫助到一個每月發佈一次,缺乏自動化測試,開發運維對立情緒嚴重的團隊做到每天 100 次部署的程度。

所以在考慮實施 DevOps 之前先想一想想要解決問題的根本原因,而不是一味指望 DevOps 一槍解決掉那個狼人。

DevOps 就是採購軟件平臺

作爲第一種錯誤思維的延續,很多管理者的第一反應是購買一個「按鈕」。細心的你會發現這幾年 DevOps 軟件猶如雨後春筍,有大量軟件公司研發了所謂 DevOps 平臺軟件,彷彿購買了這些軟件就走上了 DevOps 之路。

這種想法其實與購買了 JIRA 就等於是個敏捷團隊的想法如出一轍。看一下經典的 DevOps 「三步法」,其實其中與所謂 DevOps 軟件平臺沒有什麼必然的聯繫,工具永遠是工具,只有遇到合適的人,工具纔有價值,否則可能適得其反。

我在許多項目中遇到的情況是,客戶上了一套高價採購的 DevOps 平臺,經過千辛萬苦之後將一些系統的部署流程移植到了這套系統上,本以爲之後可以高枕無憂,但是之後發現完全不是那麼一回事。

由於系統仍然是基於一個巨大的單體應用,因此發佈頻率依然是一個月一次,無法快速靈活的提升業務價值,還是整個敏捷流程最後一公里的短板。而發佈頻率的冗長造成代碼衝突概率增加,這些衝突又無法自動 merge,絕大部分仍然要靠人工解決,結果還是效率低下。

因爲缺乏自動化測試,發佈程序的質量毫無改變,上線之後該有的 bug 還是有。全局監控機制的缺失造成反饋迴路的緩慢與滯後,系統的穩定性並沒有發生實質性的改變。

類似的例子可以寫出很多,最終的結果是管理者質疑 DevOps 的價值,但是卻忘了 DevOps 並不是軟件系統的別名,而應該是全方位,涵蓋整個開發流程的方案,從最片面的一點去尋找全局的成功無異於緣木求魚,終不可得。

DevOps 就是開發幹運維的活

可能是因爲名字的關係,許多的 IT 管理者覺得 DevOps 就是開發,運維二合爲一,開發幹運維的活,運維也做一些開發的工作。這隻能說對了一半,的確在 DevOps 的實踐中應該打破開發與運維的隔閡,讓開發-運維一體化。但這並不是簡單的讓一個人幹另一個人的活,而是應該在組織文化,全功能團隊,自動化運維工具的基礎上建立的工作角色轉換。

曾在一個項目裏遇到領導一聲令下,開發開始負責部署環境,系統上線的工作,而運維則開始寫起了業務系統的代碼。開發這邊遇到一些網絡防火牆的配置抓耳撓腮,搞了半天還是問了運維的兄弟纔算搞定部分的配置。而運維這邊以前是使用 shell + python 爲主,對 Java 一竅不通,只能 copy 代碼,一邊問開發的同事,一邊修修改改,勉強通過編譯,但是正確性不得而知。

最後的結果是開發與運維的關係空前的團結,互相理解對方工作的不易,但是開發效率,系統穩定性卻是下降的慘不忍睹。DevOps 目標在於培養開發-運維一體化的文化以及 T 型人才,而不是簡單的工作內容的互換。

開發與運維都有各自的技能長處,在實際工作中也存在不同的側重點與分工,這是客觀存在,不容迴避的。但是一些通用的團隊文化纔是 DevOps 關心的,例如自動化,例如使用工具解決問題等,如何做好這些是 DevOps 落地的真正挑戰。

反思

在過往的項目中我看到了太多對 DevOps 的誤解,人們往往在短期內高估某項技術的價值,但是在長期內又會低估它的價值,DevOps 亦是如此。錯誤的預期 + 錯誤的實踐方法造成了很多 DevOps 的失敗案例,下一篇中我會帶來我對 DevOps 的認識與實踐之路,希望你能夠喜歡。

相關閱讀:

面對疫情這樣的複雜問題,有什麼招呢?

疫情中的員工關懷,我只服這家公司

DevOps關鍵能力之產品和流程 - 重磅新書預覽《加速》

小說體敏捷/DevOps轉型教科書

和實戰經驗分享

購書指南


紙質書、電子書在京東噹噹亞馬遜、微信讀書等渠道已全面上架,搜索關鍵字“獵豹 敏捷”即可找到。點擊閱讀原文可直接購書。

有聲書已登錄喜馬拉雅、微信讀書,適合路上聽書的你。

關注公衆號看其他原創作品

敏於思 捷於行 

堅持每週輸出一篇高質量文章

覺得好看,點個“在看”或轉發給朋友們,歡迎你留言

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章