嗨,彆著急做度量,平臺工程需要先從“資料治理”開始做起

DevOps在路上發表於2023-11-10

最近一直想寫一篇關於“資料治理”和“度量相關”的話題,一直太忙,今天靜下心來寫點自己的體會

先從平臺工程說起

DevOps的興起源於企業有意彌合運維與開發之間的裂隙,但在實施過程中有部分企業簡單粗暴地將其理解為“讓開發人員去負責運維的工作”,甚至讓高階開發人員接管了運維角色,導致了開發漸漸不堪重負。
這一現實引出了DevOps停滯背後的核心矛盾:開發者不想跟基礎設施打交道,但企業在發展過程中又需要專人管控自己的基礎設施。在此背景下,平臺工程應運而生。
image.png

平臺工程定義為“設計和構建工具鏈和工作流的學科,為雲原生時代的軟體工程組織提供自助服務功能。平臺工程師提供的整合產品通常被稱為‘內部開發人員平臺(IDP)’,涵蓋了應用程式整個生命週期的運營需求。”
平臺和應用程式之間的界限在哪裡?
“如果你可以把服務拿給另一個產品團隊,甚至給另一個公司,他們可以馬上使用,那麼它就屬於平臺。”

本質依然是“新瓶裝舊酒”,是對“DevOps實踐”提供“相對可參考性”的學科體系,除了技術以外,提供瞭如何建設,運營平臺,以及建立企業內部開發者關係的新思路。
事實上,DevOps和平臺工程並非這種“你死我活”的關係,在某種程度上,平臺工程有可能為DevOps帶來新生。

內部平臺建設最終需要產出資料

“市面上任何一種工具,都不可能與平臺一樣能夠滿足企業的全部需求。企業必須花費充足的時間和精力,定製符合自身需求的平臺。” 這是Gartner對於企業進行平臺工程建設的建議

市面上其實已經湧現了很多類似的平臺,比如阿里雲效,騰訊Coding之類的,對於中小型團隊,在沒有資源投入基礎設施建設的前提下,且對期望結果不是那麼高的情況下,這些平臺是合適的。
不過依然有“相當規模”(研發人員300人以上)的企業依然可能會選擇建設內部的”研發效能平臺“或者是”DevOps一體化平臺“,來解決個性化的問題。
企業建設平臺最終的目的就是收集到資料,對研發過程資料進行分析,也就是很火的一個名詞“效能度量”。

收集資料簡單,治理規劃資料不易

如下圖所示,由於研發效能度量涉及各個階段,來自不同的工具。
image.png
本文的目的不是談如何進行定義效能度量(PS:這又是另外一個很大的話題),而是聊聊資料怎麼收,如何正確合理的收集“有價值”的資料?
單純從工具層面,排除指標定義和計算外,收集資料本身只是個技術問題。不管是對接api,還是對接資料庫,BI工具很多。
image.png
可是單純的工具資料,本身很少帶“業務屬性”,這個其實對於企業最後的決策是沒有多大價值的。
如果把工具資料,再疊加如下圖左邊這些因素,才可能讓資料變的“有價值”,變得有“說服力”,不是嗎?
image.png
可是,左邊的問題,真的容易說清楚嗎?很多建設內部平臺的企業,左邊的問題一開始就是說不清楚的,如果能說清楚,就不會大費周折的搞這個事情了。似乎陷入了“雞生蛋,還是蛋生雞”的怪圈裡,無法自拔。

不要過分度量,而來度量而度量

其實一開始,企業也在努力的建設設計流程,可是流程是需要經過“真實考驗的”,是不是業務流程是否真的能運轉落地,或者切實得到認同?

“沒關係,度量下看看?不是說,透過度量來改進嗎?“

好像猛地一看,很合理,度量就是為了改進,管理大師都說了沒有度量,就沒有改進。
可是改進什麼呢?哪裡有問題呢?為什麼要改進?

沒關係,有了資料,自然就知道了

看似合理,其實隱藏一個致命的邏輯缺陷, 度量需要成本的,收入產出比如何?
度量指標的設定,需要具有“牽引改進”的重大意義,如果一個指標不能做到“牽引”作用,那麼就是個“假”指標。
image.png
這裡給出幾點建議

  • 對於問題很明顯的,不要一開始就去設計指標去度量它,需要立馬去改進,而不是度量它
  • 不要一開始搞很多指標,看都看不完,有幾個懂的?甚至多了,設計者本身都懵逼了
  • 不要上了就設計開發複雜系統去做度量,透過簡單的查資料庫,生成excel ,或者其他快捷手段(工具內建的能力),先撈一把資料看看再說,資料都是不對的,度量就是扯淡的
  • 不要一開始,就想的過於完美,最終你會發現會推倒重來

資料治理過程逐步建模

度量的前提一定是“資料治理”和“流程執行”,前者是保證規範性,後者是保證有效性。
企業在一開始建設之初,一定是有些已經使用的系統,這些系統裡都會有資料,需要從總體上考慮未來系統的目標和願景。

  • 對於已有資料,需要進行甄別,什麼是沒有價值的資料,是否一定要保留?意義何在?卸下包袱,也許重新開始呢?
  • 不同的工具產生的資料差異很大,想清楚最終業務視角需要看“什麼緯度”的資料,什麼是“帶頭大哥”,什麼是“牽引點”,誰是主誰是輔
  • 排除干擾,對於資料欄位,學會做減法
  • 流程領域是死的,工具是活的,從領域中去抽象實體

image.png
資料治理的過程,伴隨著規則的制定,流程的執行,沒有誰先誰後之說,根據“已有資料”去分析使用者行為和使用習慣,制定“被大部分人接受”的規則和流程,否定掉“少數人的個性化操作”。
最後,收集單純的資料很簡單,但是想得到“對業務有價值的資料”,需要漫長的【收集-整理-調研-分析-設計定義-執行-最佳化-調整-反饋-再調整】過程。
沒有人能一開始全部想清楚,按照“敏捷的思維”,不要過度設計,自己瞎YY, 讓使用者用實際行動產生資料,引導使用者行為,修正資料,這是作為“平臺工程”的實踐者需要去思考和琢磨的。

嗨,彆著急做度量,平臺工程需要先從“資料治理”開始做起

相關文章