都說DevOps落地難,到底難在哪裡?也許你還沒找到套路

DevOps在路上發表於2023-05-13

當你開啟這篇文章的時候,也許你也在為DevOps的落地而苦惱,也許你的組織正在嘗試DevOps轉型,作為一線的實踐者,說說我對這個“落地難”的看法,歡迎交流不同看法~

DevOps是實踐摸索出來的,別人的終究是別人的

如下圖所示,你可能在不同企業研發效能的分享都看到過,各種關於DevOps的書上有會提到DevOps的CALMS 框架該首字母縮寫詞由《DevOps 手冊》的合著者 Jez Humble 提出,且分別代表文化 (Culture)、自動化 (Automation)、精益 (Lean)、衡量 (Measurement) 和分享 (Sharing)),告訴你透過何種手段,何種步驟來推進DevOps落地實施。
u=3328176393,1689653015&fm=11&gp=0.png
你聽了,感覺說的都很有道理,可是好像沒有解決自己遇到的問題?

  • 不同的組織文化不同,領導有的懂技術,有的完全是外行
  • 不同的業務不同,網際網路的玩法對傳統企業是不適用的,特別是釋出節奏
  • 技術債務不同,新的專案可以輕鬆上路,老的專案只能“負重前行”
  • 研發團隊對轉型的態度不同,有的團隊很封閉,有的團隊很開放
  • 是否有“專家”角色幫助梳理整個流程
  • 有的買的商用平臺工具,有的自研平臺
  • 組織規模不同,幾十人,幾百人到上千人的轉型肯定不是一回事

所有這些因素決定了,可以參考,但是沒法照抄。因為DevOps轉型不僅僅是個技術問題而是一次“組織”的變革之旅。

你可能會遇到的轉型阻礙

提到組織,首先就是人,面對轉型他們大概都是這樣的想法和態度。

  • 對於領導,他們會經常問你,效果怎麼樣?你需要面對靈魂拷問,如何向不懂“DevOps”的領導解釋做這個實踐的意義。對於領導,他們更關注業務的增長,成本的降低,對於什麼最佳實踐,他們是不懂的
  • 對於團隊,他們會告訴你我知道有好處,我怎麼開始需要投入多少?你能給我提供什麼?我很忙,沒看到你們做這個事情的意義!你們提供給我的,不是我最急迫的!
  • 對於轉型團隊內部,需要告訴他們怎麼配合,可能你和他們不是一個部門,也許你們的目標並不完全一致

image.png
以下來自《中國DevOps現狀調查報告(2022)》

**組織缺少具備 DevOps 經驗的專家、組織不清楚 DevOps 的路線圖成為限制組織級 DevOps 轉型的 最大障礙。 **
調查顯示,28.65% 的企業組織缺少具備 DevOps 經驗的專家,導致推進緩慢甚至無從下手;25.47% 的組織不清楚 DevOps 的路線圖以及如何進行轉型,同比增長 5%;25.40% 的企業受限於組織行業的 限制。另有 21.10% 的企業專案團隊工作繁重,沒有時間進行 DevOps 改進。

image.png

別人的轉型之路?

普遍的轉型方式如下圖所示,無非就是

  • 自上而下,領導強勢要求
  • 自下而上,個別團隊試點,經驗推廣
  • 引進諮詢機構,或者成立轉型小組

image.png
可是現實是

  • 大老闆或CTO只是提了要求,指派了某位“領導”來負責這個事情,定期聽聽彙報,遇到不懂的領導死活講不清楚
  • 自下而上,如果組織規模較小(幾十人規模)還有可能,最多也只能推廣到自己的小部門
  • 引入諮詢機構,不是每個組織都有諮詢費,另外轉型是個漫長的過程,最終落地還是組織內部自己落地

到了這裡,只能感嘆“理想很美好,現實很骨感”。

面對現實,如何破局?

尋找“反抗軍”,找到你的目標使用者

在《獨角獸專案》這本書中,主角來到一個“陌生的雜亂無序,連一週都沒有產出成功構建的組織”,透過在和“各個角色”接觸過程中,發現了“反抗軍”,他們和主角一樣希望解決當前的困境。建議去看看,你可能有種似曾相識的感覺。
image.png

如何找到目標使用者

一般來說轉型初期,你可能會遇到以下這四種角色

  • 擁護者:這就是你要找的“反抗軍”,但是初期他們不會自己站出來,需要你“快速”甄別出來
  • 徘徊者:認可帶來的收益,但是對投入比較擔心,你需要展示真實的“案例”和收益給他看
  • 旁觀者:對轉型不是很關注,也不反對,屬於人云亦云型,跟隨者
  • 反對者:你的改進可能對他影響很大,觸及他的利益,或者他曾經受過“折騰”,對轉型喪失信心產生牴觸心理

對於前面兩類角色,是你主要爭取合作的物件,特別是擁護者,要能切實解決他們的問題,贏得信任。對於後面兩類角色,轉型初期,他們絕不是你的“目標使用者”,他們往往在整個組織裡的地位比較重要,業務壓力也是最大的,你必須保持足夠耐心。
每個團隊的leader的風格和經歷也很重要,如果曾經在高效的組織工作過,他們帶領的團隊也可能是你合作的目標,但是他們的要求會很高,這個也可能是個小小的“阻礙”。
image.png

識別改進點,解決關鍵問題

尋找目標使用者的過程,其實也是識別他們痛點的過程,你需要幫助他們找到問題,剛開始他們是不清楚到底哪裡病了,只是知道痛而已。通常有以下幾種方式引導識別問題

價值流分析

DevOps的理論基礎就是“精益思想”,所以透過精益價值流分析是比較普遍的做法,但是這種更適合“工作坊”,另外需要團隊理解什麼是“精益”,什麼是價值流,這種評估方式適合有一定經驗的專家教練引導。
價值流.jpg

能力評價體系

這種透過行業標準的方式,對照參考,尋找差距,制定改進計劃,更多適用於企業評級,比較正式。
image.png

團隊訪談

上面兩種方式都是比較高大上,偏正式的套路,需要一定的組織能力和引導能力,如果你已經參與上述活動,恭喜你,已經有專家在指導你們做改進了。
這裡提供一個更“省錢”,更容易執行的方式,出去跑“客戶”,和研發團隊“促膝長談”,引導他們說出自己的問題(注意,引導交談方式,別被研發團隊帶偏了,你要引導他們到你的思路上)

  • 你們現在的痛點是什麼?
  • 我這裡有這樣一個能力或方案,你們看行不行?這樣可以幫助你們xxxxx
  • 你的問題可能另外一個方式更合適,也能幫助你解決

找出共性問題,建立改進清單

引導說出共性問題

透過前期的團隊訪談或者工作坊,你需要梳理出來“普遍”的共性問題(PS: 砍掉那些稀奇古怪的個性化需求),並且告訴團隊問題解決後能帶來的收益,繪製一個宏偉的藍圖,畫個大餅~
在人力有限情況下,儘可能把大家拉到一個“同性問題”上,最好還是價效比高的問題(PS: 投資少,見效果,快速取得客戶信任),對於“底子”差的組織,更是如此。

評估團隊,制定不同策略

不同的團隊情況不同,底子也不同,痛點不同,建立團隊的檔案。如果有可能,制定明確的標準和要求,也許會事半功倍
注意:團隊可能比較關心獲得這些收益需要哪些投入,這個可能你需要提前準備好應對的方案和各種輔導材料準備,避免使用者流失。

共同制定改進清單,跟蹤評價

你需要和團隊的代表(這裡最好是固定的研發效能愛好者,也許他會讓改進事半功倍共同制定改進清單,剛開始定一個“小目標”,週期別太長了,不要超過一個月。
目標感-進展感-協作感
記住這三個關鍵詞,如果沒有清晰的目標,雙方感覺不到進展,溝通完後沒有任何協作,或者單方的努力,都可能導致改進失敗。作為教練,你需要保持這個警惕,與團隊要有互動,時刻保持“關心”。
小時候,你改掉一個壞毛病,不還要老師父母在屁股後面整天說,同理,你要時刻向團隊灌輸最佳實踐,保持和他們的互動。
image.png

平臺工程團隊及時響應使用者需求

一般在你的背後,應該有個平臺工程團隊建設與之配套的效能提升有關的基礎設施(程式碼倉庫,製品庫,流水線,程式碼掃描,自動化測試等)。
image.png
他們需要針對目標使用者的需求和問題,做出快速反應除了自助服務開發,教育和協作也成為挑戰。平臺工程師發現,他們花越來越多的時間培訓應用程式開發人員,讓他們瞭解最佳實踐和如何最好地使用平臺。應用程式開發人員還發現他們依賴於其他應用程式開發人員團隊,並期望平臺工程團隊為他們提供與不同團隊高效協作的工具。
image.png

保持曝光率,不斷洗腦

組織改進的過程是個長期而艱難的過程,不要指望某個工具,某次培訓宣講,就能達到預期效果。為了讓你的使用者知道“你們”和你們的“平臺”,需要提高曝光率,你要當作一個“產品”在運營,你要和你的使用者建立聯絡,收集他們的需求,聽取他們的心聲,但是如果他們連你的工具有什麼功能都不知道,能夠帶給他們的收益都不清楚,你的“產品功能”再牛逼,也是沒有任何價值的。

  • 定期透過組織內部渠道(論壇,郵件,公眾號)等打廣告
  • 定期組織關於平臺功能和DevOps實踐的培訓分享
  • 建立使用者行為分析體系,你需要知道推出的哪個功能使用者喜歡,活躍度高
  • 定期釋出優秀實踐案例

團結一切可以團結的力量

DevOps貫穿整個研發過程,所以會涉及到不同的部門,特別是“部門牆”很嚴重的組織。有人會說,DevOps不就是要推翻“部門牆”的嗎?那個是理想狀態,現實不會和書上說的那樣。
一般來說,你可能需要打交道的會涉及專案管理部門,企業IT部門,技術中臺部門,安全部門等組織級公共部門,這是另外一波你要合作的物件。
特別是,專案管理部門(PMO),組織的流程規範都是透過他們發出的,但是往往他們並不具備相應的能力,你們需要合作。當然,怎麼合作也是有講究的,往往他們並不懂技術,更多你要做解釋,尋求理解支援。
image.png

定期彙報,展示成果

做了這麼多,你需要去彙報了,要去面對領導的“靈魂拷問”,效果怎麼樣?這也是比較頭痛的問題,難在哪裡呢?

  • 特別是傳統企業,甚至可能都不是IT企業,領導不懂技術,更別提DevOps了
  • 你講最佳實踐,講技術方案,講敏捷如何好,DevOps如何好,都沒用,效果呢?

這裡其實就是值得討論的一個問題,什麼是效果?
很明顯,你需要告訴他效能提高多少?那什麼是效能?如何定義效能?是否能提供資料?什麼資料?領導是否認可這些資料,構建頻率/時長/前置時間等等,是否他們明白背後的意識呢?
留個思考題,歡迎討論~
image.png

轉型過程避坑指南

開始要想清楚

  • 組織解決什麼問題,也許一開始是會想不清楚,那麼聘請外部專家是個合適的選擇
  • 引入什麼工具,什麼是合適的工具,能花錢買的千萬別自己開發,能開發的也不要一股腦都是商用,工具是助力的,不是添堵的
  • 轉型組織的構成有那些人,是否合適,要能各展所長
  • 要做長遠規劃,一年目標,三年目標,五年目標

image.png

切記“大躍進”

不要急於匆忙上馬,不要以為買個工具或平臺,就可以全面使用接入了,這個要衡量下是否真的能解決問題。往往這是“自上而下”往下推,由領導發號施令產生的,他們急於看到效果,往往不瞭解什麼是DevOps.
這樣做的後果是,團隊不再信任改進,抱怨聲一大堆,最後可能就失敗了。

多走進團隊,多引導

研發團隊是你的使用者,你需要走進他們,瞭解真實情況,不要以為外面商業的平臺就一定能解決他們的問題,特別是大型組織,他們的需求千奇百怪,往往你需要適應他們,再去改進。而不是上來就說,你們怎麼不好,不是最佳實踐,商業平臺必須這麼玩,這個真的要看團隊的底子好不好。
組織轉型的過程,其實是改變別人十幾年工作習慣的問題,是需要引導,培訓,指導,提升認知的,讓他們知道什麼是好的,什麼是不好的。

不要過度迷信成熟度模型

雖然我上面也提到了成熟度模型,但是這個僅僅是個參考。鞋子合不合適還是要看穿鞋的人,“成熟度”只是給你定義了標準的鞋子應該如何生產。對穿慣了布鞋的人來說,他需要的只是輕便合腳,對於穿慣了運動鞋的人來說,他需要的是能夠彈跳好。同理,團隊/組織的基礎目標不同,不能一概而論,也許他只只適合爬個小山丘,沒必要要求他能爬珠穆朗瑪峰,不現實,他要的也許是“減肥”,而不是成為“專業運動員”。
過度迷信成熟度,往往容易走偏,給轉型帶來不利因素。

總結:落地套路關鍵詞

image.png
總結下,DevOps落地是以“技術工具”為實現手段,“各種最佳實踐”為賦能指引,“組織級流程規範”為牽引,透過各部門角色的合作,對現有“混亂”狀態進行改造的過程。
人們總說擁抱變化,但是當變化到來時,他們卻拒絕變化,因為已經習慣,即使低效無趣,也不想改變。所以,做了DevOps的實踐者,你需要找到合適的套路去影響他們。

  • 贏得使用者信任,建立良好的合作關係,甚至是個人關係
  • 投資回報率優先,不要試圖強加一些不切實際的最佳實踐和要求給團隊,他們需要“投入少,見效快”。改進是有成本的,尋找收益最大化的方案
  • 利益分析,互相吹捧,互相成就
  • 提供真實的,一定數量的成功案例
  • 保持耐心,循序漸進,接受不完美

參考

相關文章