最近一直想寫一篇關(guān)于“數(shù)據(jù)治理”和“度量相關(guān)”的話題，一直太忙，今天靜下心來寫點(diǎn)自己的體會

先從平臺工程說起

DevOps的興起源于企業(yè)有意彌合運(yùn)維與開發(fā)之間的裂隙，但在實(shí)施過程中有部分企業(yè)簡單粗暴地將其理解為“讓開發(fā)人員去負(fù)責(zé)運(yùn)維的工作”，甚至讓高級開發(fā)人員接管了運(yùn)維角色，導(dǎo)致了開發(fā)漸漸不堪重負(fù)。
這一現(xiàn)實(shí)引出了DevOps停滯背后的核心矛盾：開發(fā)者不想跟基礎(chǔ)設(shè)施打交道，但企業(yè)在發(fā)展過程中又需要專人管控自己的基礎(chǔ)設(shè)施。在此背景下，平臺工程應(yīng)運(yùn)而生。

平臺工程定義為“設(shè)計(jì)和構(gòu)建工具鏈和工作流的學(xué)科，為云原生時(shí)代的軟件工程組織提供自助服務(wù)功能。平臺工程師提供的集成產(chǎn)品通常被稱為‘內(nèi)部開發(fā)人員平臺(IDP)’，涵蓋了應(yīng)用程序整個(gè)生命周期的運(yùn)營需求。”
平臺和應(yīng)用程序之間的界限在哪里？
“如果你可以把服務(wù)拿給另一個(gè)產(chǎn)品團(tuán)隊(duì)，甚至給另一個(gè)公司，他們可以馬上使用，那么它就屬于平臺。”

本質(zhì)依然是“新瓶裝舊酒”，是對“DevOps實(shí)踐”提供“相對可參考性”的學(xué)科體系，除了技術(shù)以外，提供了如何建設(shè)，運(yùn)營平臺，以及建立企業(yè)內(nèi)部開發(fā)者關(guān)系的新思路。
事實(shí)上，DevOps和平臺工程并非這種“你死我活”的關(guān)系，在某種程度上，平臺工程有可能為DevOps帶來新生。

內(nèi)部平臺建設(shè)最終需要產(chǎn)出數(shù)據(jù)

“市面上任何一種工具，都不可能與平臺一樣能夠滿足企業(yè)的全部需求。企業(yè)必須花費(fèi)充足的時(shí)間和精力，定制符合自身需求的平臺。” 這是Gartner對于企業(yè)進(jìn)行平臺工程建設(shè)的建議

市面上其實(shí)已經(jīng)涌現(xiàn)了很多類似的平臺，比如阿里云效，騰訊Coding之類的，對于中小型團(tuán)隊(duì)，在沒有資源投入基礎(chǔ)設(shè)施建設(shè)的前提下，且對期望結(jié)果不是那么高的情況下，這些平臺是合適的。
不過依然有“相當(dāng)規(guī)模”（研發(fā)人員300人以上）的企業(yè)依然可能會選擇建設(shè)內(nèi)部的”研發(fā)效能平臺“或者是”DevOps一體化平臺“，來解決個(gè)性化的問題。
企業(yè)建設(shè)平臺最終的目的就是收集到數(shù)據(jù)，對研發(fā)過程數(shù)據(jù)進(jìn)行分析，也就是很火的一個(gè)名詞“效能度量”。

收集數(shù)據(jù)簡單，治理規(guī)劃數(shù)據(jù)不易

如下圖所示，由于研發(fā)效能度量涉及各個(gè)階段，來自不同的工具。

本文的目的不是談如何進(jìn)行定義效能度量（PS:這又是另外一個(gè)很大的話題），而是聊聊數(shù)據(jù)怎么收，如何正確合理的收集“有價(jià)值”的數(shù)據(jù)？
單純從工具層面，排除指標(biāo)定義和計(jì)算外，收集數(shù)據(jù)本身只是個(gè)技術(shù)問題。不管是對接api，還是對接數(shù)據(jù)庫，BI工具很多。

可是單純的工具數(shù)據(jù)，本身很少帶“業(yè)務(wù)屬性”，這個(gè)其實(shí)對于企業(yè)最后的決策是沒有多大價(jià)值的。
如果把工具數(shù)據(jù)，再疊加如下圖左邊這些因素，才可能讓數(shù)據(jù)變的“有價(jià)值”，變得有“說服力”，不是嗎？

可是，左邊的問題，真的容易說清楚嗎？很多建設(shè)內(nèi)部平臺的企業(yè)，左邊的問題一開始就是說不清楚的，如果能說清楚，就不會大費(fèi)周折的搞這個(gè)事情了。似乎陷入了“雞生蛋，還是蛋生雞”的怪圈里，無法自拔。

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

其實(shí)一開始，企業(yè)也在努力的建設(shè)設(shè)計(jì)流程，可是流程是需要經(jīng)過“真實(shí)考驗(yàn)的”，是不是業(yè)務(wù)流程是否真的能運(yùn)轉(zhuǎn)落地，或者切實(shí)得到認(rèn)同？

“沒關(guān)系，度量下看看？不是說，通過度量來改進(jìn)嗎？“

好像猛地一看，很合理，度量就是為了改進(jìn)，管理大師都說了沒有度量，就沒有改進(jìn)。
可是改進(jìn)什么呢？哪里有問題呢？為什么要改進(jìn)？

沒關(guān)系，有了數(shù)據(jù)，自然就知道了

看似合理，其實(shí)隱藏一個(gè)致命的邏輯缺陷, 度量需要成本的，收入產(chǎn)出比如何？
度量指標(biāo)的設(shè)定，需要具有“牽引改進(jìn)”的重大意義，如果一個(gè)指標(biāo)不能做到“牽引”作用，那么就是個(gè)“假”指標(biāo)。

這里給出幾點(diǎn)建議

• 對于問題很明顯的，不要一開始就去設(shè)計(jì)指標(biāo)去度量它，需要立馬去改進(jìn)，而不是度量它
• 不要一開始搞很多指標(biāo)，看都看不完，有幾個(gè)懂的？甚至多了，設(shè)計(jì)者本身都懵逼了
• 不要上了就設(shè)計(jì)開發(fā)復(fù)雜系統(tǒng)去做度量，通過簡單的查數(shù)據(jù)庫，生成excel ,或者其他快捷手段（工具內(nèi)置的能力），先撈一把數(shù)據(jù)看看再說，數(shù)據(jù)都是不對的，度量就是扯淡的
• 不要一開始，就想的過于完美，最終你會發(fā)現(xiàn)會推倒重來
  

數(shù)據(jù)治理過程逐步建模

度量的前提一定是“數(shù)據(jù)治理”和“流程執(zhí)行”，前者是保證規(guī)范性，后者是保證有效性。
企業(yè)在一開始建設(shè)之初，一定是有些已經(jīng)使用的系統(tǒng)，這些系統(tǒng)里都會有數(shù)據(jù)，需要從總體上考慮未來系統(tǒng)的目標(biāo)和愿景。

• 對于已有數(shù)據(jù)，需要進(jìn)行甄別，什么是沒有價(jià)值的數(shù)據(jù)，是否一定要保留？意義何在？卸下包袱，也許重新開始呢？
• 不同的工具產(chǎn)生的數(shù)據(jù)差異很大，想清楚最終業(yè)務(wù)視角需要看“什么緯度”的數(shù)據(jù)，什么是“帶頭大哥”，什么是“牽引點(diǎn)”，誰是主誰是輔
• 排除干擾，對于數(shù)據(jù)字段，學(xué)會做減法
• 流程領(lǐng)域是死的，工具是活的，從領(lǐng)域中去抽象實(shí)體

數(shù)據(jù)治理的過程，伴隨著規(guī)則的制定，流程的執(zhí)行，沒有誰先誰后之說，根據(jù)“已有數(shù)據(jù)”去分析用戶行為和使用習(xí)慣，制定“被大部分人接受”的規(guī)則和流程，否定掉“少數(shù)人的個(gè)性化操作”。
最后，收集單純的數(shù)據(jù)很簡單，但是想得到“對業(yè)務(wù)有價(jià)值的數(shù)據(jù)”，需要漫長的【收集-整理-調(diào)研-分析-設(shè)計(jì)定義-運(yùn)行-優(yōu)化-調(diào)整-反饋-再調(diào)整】過程。
沒有人能一開始全部想清楚，按照“敏捷的思維”，不要過度設(shè)計(jì)，自己瞎YY, 讓用戶用實(shí)際行動(dòng)產(chǎn)生數(shù)據(jù)，引導(dǎo)用戶行為，修正數(shù)據(jù)，這是作為“平臺工程”的實(shí)踐者需要去思考和琢磨的。

總結(jié)

以上是生活随笔為你收集整理的嗨，别着急做度量，平台工程需要先从“数据治理”开始做起的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。