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

先從平臺工程說起

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

平臺工程定義為“設計和構建工具鏈和工作流的學科，為云原生時代的軟件工程組織提供自助服務功能。平臺工程師提供的集成產品通常被稱為‘內部開發人員平臺(IDP)’，涵蓋了應用程序整個生命周期的運營需求?！?br> 平臺和應用程序之間的界限在哪里？
“如果你可以把服務拿給另一個產品團隊，甚至給另一個公司，他們可以馬上使用，那么它就屬于平臺?！?/p>

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

內部平臺建設最終需要產出數據

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

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

收集數據簡單，治理規劃數據不易

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

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

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

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

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

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

“沒關系，度量下看看？不是說，通過度量來改進嗎？“

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

沒關系，有了數據，自然就知道了

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

這里給出幾點建議

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

數據治理過程逐步建模

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

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

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