DevOps落地實踐點滴和踩坑記錄-(1)

DevOps在路上 發表於 2022-06-12

記錄初衷

本人一直在從事企業內DevOps落地實踐的工作,走了不少彎路,也努力在想辦法解決面臨的問題,期間也經歷過不少人和事情,最近突然有想法把經歷過的,不管好的不好的都記錄下來,分享給和我一樣的一線實踐者。
我會通過一個個典型故事或場景來敘述,不談理論,不談技術, 只談遇到的人和事,我和我的團隊夥伴怎麼解決實踐中遇到的問題。

1)DevOps好像很火,我們也來做個搞吧

“DevOps好像大廠都在搞,聽說能提高效能,我們的專案經常延期,要不我們也搞吧~”可能這是很多企業領導實施DevOps的初衷, 這個初衷本沒有錯,可是真的準備好了嗎?想清楚做什麼了嗎?沒關係,可以請外部專家講下,聽下來感覺就是一大堆工具的組合,不就是開發一個一體化平臺嗎?
如果只是看到了別人的成果,沒有清楚中間付出的艱辛和改進,沒有好的方法論指導,很容易照貓畫虎,內部的改進“走形”!

2) 買了你們的平臺,多久能有效果出來?

在企業DevOps實踐初期,對於自研和外部採購還存在一些猶豫,一方面覺得如果自己投入資源研發,週期比較長,自己等不了,所以希望能夠儘快通過成熟的外部工具快速達到自己的期望的目標。於此同時,外部的DevOps平臺廠商或者諮詢就會看到機會開始介入,對自己的產品和方案進行推廣。對於外部的諮詢和廠商 ,領導常問的問題就是“我買了你們的平臺,多久能出效果?”,或 “你們過去的案例一般需要多久?”,“是不是我們買了你們的平臺,團隊可以馬上用了”,諸如此類的問題往往令外部的諮詢和銷售無法回答,因為真正做過落地實踐的人都清楚,不可能給出一個明確的答案。
其實,這種現象也反映了組織內領導沒有真正清楚這個事情到底要怎麼做,他們覺得工具能解決問題。這是對於DevOps的一個誤區。

3)“DevOps”應該從管理層認可開始

DevOps出現之後,大家也許曾經提出或者聽到過一個很關鍵卻又普遍的問題——“DevOps轉型應該從哪裡開始?”
工作中,並非所有人都信任DevOps,通常遇到的第一個難題是得到管理層的認可與支援,因為DevOps的核心含義可能會掀起公司的大變革。
但是即使有管理層支援,如果管理層沒有懂DevOps的帶頭人,往往也會出現“事倍功半”的情況,管理層基於得到結果,忽視了這是一次變革,不是某一個團隊就可以進行的。

4)通過工具平臺接入率來衡量改進效果?

在領導的支援下,企業開始打造自研效能平臺,但是怎麼推廣呢?往往會陷入一個誤區,就是開發了,大家接入使用就好了,接入使用效能自然就提高了。可是真的這麼簡單粗暴嗎?
接入率能說明什麼呢?接入好壞效果怎麼評價?什麼算接入?建立一條流水線,跑通了整個流程就算接入了,就能提高效能了?
企業為了推廣自己的平臺,讓團隊接入本來無可厚非,可是方法錯了,如果為了團隊的KPI, 團隊自然會投入人力接入,可能團隊自己沒有認識到這個事情的價值,只是因為領導需要我們這麼做。可以接入完了,團隊繼續按照自己過去的搞法玩,竹籃打水一場空。

5)找出問題比空喊口號更有用!-價值流分析

你覺得你們團隊能給團隊帶來哪些效能提升?”有次和上層開會,領導的這個靈魂拷問讓我記憶猶新,說實在的,作為深諳DevOps理論和實踐的一線實踐者竟然不知如何回答。下來請教了很多行業內大咖,“找出問題就基本成功一半了”,這是一個專家的回答。突然我意識到,這不是就剛開始來找團隊做的“價值流分析”嗎,找到問題所在,走著走著迷失了方向~
image.png
雖然各家企業DevOps落地方案各不相同,但是有一個基本的共識就是到底要解決什麼問題,只有真的弄清楚問題,才能想辦法解決。
在實施初期,我們一般會選擇比較有代表性的專案,進行調研和分析。我們會從需求管理、開發、程式碼管理、構建、測試、部署、釋出這幾個方面進行調研和分析,判斷專案是否適合遷移到DevOps平臺,專案研發過程的某些環節是否需要進行改進和完善。

  • 需求管理:需求管理工具、使用者故事、任務、迭代等
  • 開發:開發語言、開發工具、技術框架、執行環境、元件劃分及依賴關係等
  • 程式碼管理:程式碼及文件管理工具、程式碼庫分支及用途、分支策略、程式碼質量檢測工具及質量指標等
  • 構建:構建工具、構建過程及構建策略、構建介質策略、中間介質及最終介質管理等
  • 測試:用例和Bug管理、自動化測試工具、驗收標準等
  • 部署:環境規劃、環境配置、部署方式、依賴的中介軟體和公共元件等
  • 釋出:上線交付物、釋出流程、應用及資料備份方式、回滾方式等

本階段產出文件:調研問卷、提升建議和改進方案。
image.png

6) 尋找“反抗軍”因為他們真的痛

專案試點是非常重要的環節,也是後續能否進行推廣的重要評判依據。經過前期的專案改進,以及流程規範的普及推廣,試點專案作出適當調整,試點專案的遷移是對之前所有工作的一個重要檢驗。
在試點階段,一方面是要通過試點專案的規範化改造,打造同類專案的流程規範,形成可複製的流水線模式;另一方面看遷移前後給試點專案帶來哪些好的效果,是否符合預期,是否還有需要改進的空間,平臺能力是否需要提升等等。專案試點階段產出的文件和手冊是後續推廣的重要資源。當試點專案的遷移達到預期效果,就可以進行DevOps平臺的普及推廣
但往往啟動階段,就會面臨誰是第一個“吃螃蟹”的團隊,這個時候尋找合適的“反抗軍”是至關重要的,因為他們真的“很痛”,受研發效能底下困擾已久,他們迫切需要改變。這個初心比任何的行政命令更有效,這是發自他們內心的!
在和這些團隊一起協作的時候,也需要主要投入產出比,上來不要找一些高大上的,不切實際的最佳實踐。先讓他們看到效果甜頭,他們才願意投入資源進行改造。當然,過程中必要的溝通技巧,和團隊leader的個人關係也要搞好。

7) 平臺建設思路

在DevOps實施過程中,工具鏈的打通必然涉及各種工具的整合。除了DevOps平臺本身已經整合的Jira、Gitlab、Jenkins、Nexus、SonarQube等工具,比較常見的是對客戶已有工具等整合,如客戶自建的專案管理平臺、CMDB平臺、自動化測試平臺等等。
對於使用者自建工具的整合,首先需要去理清整合的真正目的是什麼,能為使用者帶來哪些價值。比如,對專案管理平臺的整合,DevOps平臺可以對專案等迭代、需求、任務等資訊進行收集和彙總,最終專案的進度、成本一目瞭然。再比如,對CMDB的整合,對於CD過程中使用的資源(主機、容器),直接從CMDB拉取資料即可,無需在DevOps平臺中重新配置一遍。

這裡建議,對已有工具的整合,整合的是資料,目的是讓資料流轉和彙總起來,而非做功能的整合。

規範化、統一化
專案遷移到DevOps平臺,各個專案可以在一個統一的DevOps平臺進行CICD,無需各自搭建持續整合平臺。通過制定合理的規範,不同的專案遵守一致的規範,避免了程式碼庫、CICD流程的管理混亂和不規範。制定度量指標和規範,對軟體開發成果和開發過程的測量和分析,幫助對軟體開發過程持續進行改進,有效提高軟體交付質量和效率。

研發效能提升
視覺化和可編排,無需編寫pipeline指令碼,一次配置,多次執行。提交或合併程式碼出發、定時觸發或手動一鍵執行構建和部署,提高研發人員效率。有效減少系統變更部署上線的時間,快速響應業務變化。

報表展示、可度量
從效率、質量、進度三個維度展示任務、程式碼、構建、部署相關資料,結合專案看板、報表和度量指標,各環節干係人可以對進度、質量等進行判斷和干預。
DevOps的建設是難以短期內完成的,需要進行總體規劃,然後分階段實施。無論是工具的整合,還是度量體系的實施,都需要按部就班、循序漸進,逐步完成建設,最終實現預期目標。

8) 以終為始,確立統一的目標,避免各自為政

上面一點提到了工具的整合,在企業組織內部,工具可能會分佈在不同的部門裡,主要涉及到專案管理,需求管理,程式碼管理,構建部署,測試等,DevOps效能平臺的目標是拉通所有的工具,進行資料的整合。雖然說是工具的整合,其實不如說是工具背後部門間協作方式,和如何建立共同目標。
過去一段時間,筆者經歷過各工具背後的部門間思想沒有統一,大家名義上都在為一個目標服務,但是缺乏有效的統一目標和方案,說白了各自為政,這給後期的平臺度量整合帶來很大的麻煩,有可能系統要重新設計,各系統間的資料模型需要花大力氣去適配和調整。
所以,其實在DevOps建設團隊的內部也需要通過虛擬的組織和明確的領導模式來合作,避免資源浪費和衝突。一個明確的建設體系和組織,至關重要,自己都是鬆散的,怎麼整合資料,怎麼說服研發團隊?

9)規範在哪裡?避免停留在“紙面上”的規範

程式碼庫規範:包括分支和標籤命名規範、分支管理規範(管理流程、hotfix流程、分支策略)、程式碼提交規範。
以分支開發、主幹釋出為例,管理流程規範中會涉及程式碼庫準備、開發整合、驗收測試、釋出環節,每個分支的用途,每個環節中涉及的角色,角色的操作流程都有詳細規範。

CICD流程規範:命名規範:元件、介質倉庫、構建定義、構建產物別名、釋出定義。流水線規範:開發流水線、使用者驗收測試流水線及回滾流水線、釋出流水線及回滾流水線、hotfix流水線。
通過制定流水線的規範,形成不同型別專案的CICD流程模版,可以作為組織級規範進行審計。

除了以上規範外,還包括專案管理規範,敏捷開發規範,測試管理規範,安全規範,釋出規範,版本號規範等等。有的組織可能之前有了類似的規範,但是大多都停留在“紙面上”,實際落地很難,除非在研發過程有嚴格的卡點稽核,否則團隊很難落地執行。另一方面,規範先行很有必要,否則自研平臺的開發就會形成無水之源,無本之木。
規範的建立,需要結合企業實際情況,需要流程制定部門和研發團隊共同制定,並且基於可以落地的方式,而不是空口理論和舉措,離開工具的標準,規範簡直就是“白紙一張”!

10) 基於現狀進行自研平臺的開發,避免脫離團隊實際

對於流水線的定義和設計,需要考慮客戶的環境規劃和網路策略。一般情況下,會設計和定義開發測試流水線、使用者驗收測試流水線、釋出流水線這些常規流水線,對應開發測試環境、使用者驗收環境、生產環境。開發測試流水線經過多次執行,業務系統形成穩定版本,交付到使用者驗收測試流水線,通過使用者驗收測試之後,再轉到釋出流水線進行釋出上線;這個過程也設計到程式碼分支和標籤的維護。

有的客戶,階段交付物是某個版本的工件介質,並且介質庫可以多環境共享或者同步,這種情況下需要在開發測試流水線中設計構建環節和部署環節,在使用者驗收流水線和釋出流水線不需要構建環節,因為交付介質像下一個環境同步即可。流水線設計如下:
DevOps落地實踐點滴和踩坑記錄-(1)
有的客戶階段交付物是程式碼,且各個環境有網路策略限制。這種型別的流水線,不同環境需要根據對應的程式碼分支或標籤將介質構建出來,然後再進行部署。
DevOps落地實踐點滴和踩坑記錄-(1)
這裡想強調的是,自研平臺的開發不能離開業務研發團隊的實際場景,必須和他們進行溝通交流,如果單靠借鑑業界的通用流程,很可能最後會發現,團隊需要的根本不是這樣的。即不要離開業務場景去開發平臺,需要和業務團隊進行緊密的溝通和麵談,瞭解他們的需求,這也需要投入人力去梳理形成方案。如圖所示,通過團隊溝通形成交付流水線流程圖,可以清晰的讓雙方達成共識。
image.png

11) 工具並不能解決問題, 必須依靠完整的DevOps體系

  • 立項:務必獲取高層領導的支援與推動;
  • 目標:分階段建設,明確年度目標,不宜貪大求全;
  • 組織:結合建設目標和現狀,明確牽頭部門,關注跨部門協同的難點;
  • 落地:規則約束,可先研討、線下驗證,再線上約束、逐步調整,且不宜初期就設定過於細緻的規約;
  • 文化:切勿重系統、輕文化,一定要關注人文關懷,重視組織文化建設,保障一個相對溫和的實踐環境。
  • 完整的 DevOps 體系建設,不僅僅是新工具、新規則,更是新文化,而且在文化變革打頭陣的情況下,很可能取得更好、更持久的成果,讓組織具備自我糾偏的能力。

企業的DevOps實踐絕對不是自研一套平臺或者買一套商用平臺,缺乏規範指引,團隊賦能和培訓,指標引導等要素會寸步難行,這真的不是誇張,而是來自一線的真實感受。這也是為什麼DevOps落地如此之難的原因!
image.png
工具拉通,以平臺為抓手,規範為指導,度量為方向,推進落地
image.png

12) 建立虛擬的工程效能改進組織

如圖所示,左邊需要建立虛擬的研發效能組織,包括專案管理,平臺研發,運營推廣,規範審計,敏捷教練,工程教練等諸多部門和角色,右側對接業務開發團隊,需要建立定期溝通機制,瞭解團隊平臺需求,同時提供最佳實踐的培訓和賦能。於此同時,度量指標結合規範一起制定,幫助團隊持續改進。
image.png

13) 度量-效能提升永遠繞不開的痛

度量,這是研發效能永恆的話題。拋開度量的業務和技術本身,探討度量的所見所聞和所思。
企業管理者之所以關注效能提升,目標就是希望能看到度量資料,這是他們的剛需,其實並不是研發團隊的剛需。如果真的把度量資料曝露在領導面前,研發團隊的一舉一動就擺在明面上了,一切以資料說話。這就是度量的兩面性的根源。

那麼在做自研效能平臺時候,如何考慮度量的建設呢?我把之前提問專家的回覆貼出來。

  • “如果做DevOps自研平臺,什麼時候引入度量合適?”
    無論是用devops工具平臺自動收集度量資料,還是通過手工收集,合理的度量越早引入越好。因為度量資料的收集,需要經歷一個較長的過程,才能看到供改進參考的資料。

  • “可不可以邊做,邊設計指標收單點區域性指標資料?”
    可以,而且DevOps自研平臺,也應該是小步迭代地實現度量資料的收集。不要一上來就設計和實現大批量的度量資料。因為大批量交付度量指標,會讓這批度量指標很晚才能交付,不利於儘早度量。

  • “如果問題很明顯了,有必要做度量,去暴露問題嗎?感覺既然很明顯了,就先改進解決問題”
    問題很明顯了,也有必要做度量。一方面能通過度量資料,讓領導和團隊看到現狀。另一方面,在改進問題期間,收集度量資料所形成的變化趨勢,能讓大家看到改進舉措是否能有所成效。

目前,真正進行內部度量體系的建設,快被搞崩潰了。前期的基礎資料準備相當重要,業務之複雜遠超工程領域,後面再單獨寫文章聊。
image.png

未完待續

先寫這些,後面遇到更多的坑,再分享出來。