最近一直想寫一篇關於“資料治理”和“度量相關”的話題，一直太忙，今天靜下心來寫點自己的體會
先從平臺工程說起
DevOps的興起源於企業有意彌合運維與開發之間的裂隙，但在實施過程中有部分企業簡單粗暴地將其理解為“讓開發人員去負責運維的工作”，甚至讓高階開發人員接管了運維角色，導致了開發漸漸不堪重負。
這一現實引出了DevOps停滯背後的核心矛盾：開發者不想跟基礎設施打交道，但企業在發展過程中又需要專人管控自己的基礎設施。在此背景下，平臺工程應運而生。
平臺工程定義為“設計和構建工具鏈和工作流的學科，為雲原生時代的軟體工程組織提供自助服務功能。平臺工程師提供的整合產品通常被稱為‘內部開發人員平臺(IDP)’，涵蓋了應用程式整個生命週期的運營需求。”
平臺和應用程式之間的界限在哪裡？
“如果你可以把服務拿給另一個產品團隊，甚至給另一個公司，他們可以馬上使用，那麼它就屬於平臺。”
本質依然是“新瓶裝舊酒”，是對“DevOps實踐”提供“相對可參考性”的學科體系，除了技術以外，提供瞭如何建設，運營平臺，以及建立企業內部開發者關係的新思路。
事實上，DevOps和平臺工程並非這種“你死我活”的關係，在某種程度上，平臺工程有可能為DevOps帶來新生。
內部平臺建設最終需要產出資料
“市面上任何一種工具，都不可能與平臺一樣能夠滿足企業的全部需求。企業必須花費充足的時間和精力，定製符合自身需求的平臺。” 這是Gartner對於企業進行平臺工程建設的建議
市面上其實已經湧現了很多類似的平臺，比如阿里雲效，騰訊Coding之類的，對於中小型團隊，在沒有資源投入基礎設施建設的前提下，且對期望結果不是那麼高的情況下，這些平臺是合適的。
不過依然有“相當規模”（研發人員300人以上）的企業依然可能會選擇建設內部的”研發效能平臺“或者是”DevOps一體化平臺“，來解決個性化的問題。
企業建設平臺最終的目的就是收集到資料，對研發過程資料進行分析，也就是很火的一個名詞“效能度量”。
收集資料簡單，治理規劃資料不易
如下圖所示，由於研發效能度量涉及各個階段，來自不同的工具。
本文的目的不是談如何進行定義效能度量（PS:這又是另外一個很大的話題），而是聊聊資料怎麼收，如何正確合理的收集“有價值”的資料？
單純從工具層面，排除指標定義和計算外，收集資料本身只是個技術問題。不管是對接api，還是對接資料庫，BI工具很多。
可是單純的工具資料，本身很少帶“業務屬性”，這個其實對於企業最後的決策是沒有多大價值的。
如果把工具資料，再疊加如下圖左邊這些因素，才可能讓資料變的“有價值”，變得有“說服力”，不是嗎？
可是，左邊的問題，真的容易說清楚嗎？很多建設內部平臺的企業，左邊的問題一開始就是說不清楚的，如果能說清楚，就不會大費周折的搞這個事情了。似乎陷入了“雞生蛋，還是蛋生雞”的怪圈裡，無法自拔。
不要過分度量，而來度量而度量
其實一開始，企業也在努力的建設設計流程，可是流程是需要經過“真實考驗的”，是不是業務流程是否真的能運轉落地，或者切實得到認同？
“沒關係，度量下看看？不是說，透過度量來改進嗎？“
好像猛地一看，很合理，度量就是為了改進，管理大師都說了沒有度量，就沒有改進。
可是改進什麼呢？哪裡有問題呢？為什麼要改進？
沒關係，有了資料，自然就知道了
看似合理，其實隱藏一個致命的邏輯缺陷, 度量需要成本的，收入產出比如何？
度量指標的設定，需要具有“牽引改進”的重大意義，如果一個指標不能做到“牽引”作用，那麼就是個“假”指標。 
這裡給出幾點建議
- 對於問題很明顯的，不要一開始就去設計指標去度量它，需要立馬去改進，而不是度量它
- 不要一開始搞很多指標，看都看不完，有幾個懂的？甚至多了，設計者本身都懵逼了
- 不要上了就設計開發複雜系統去做度量，透過簡單的查資料庫，生成excel ,或者其他快捷手段（工具內建的能力），先撈一把資料看看再說，資料都是不對的，度量就是扯淡的
- 不要一開始，就想的過於完美，最終你會發現會推倒重來
資料治理過程逐步建模
度量的前提一定是“資料治理”和“流程執行”，前者是保證規範性，後者是保證有效性。
企業在一開始建設之初，一定是有些已經使用的系統，這些系統裡都會有資料，需要從總體上考慮未來系統的目標和願景。
- 對於已有資料，需要進行甄別，什麼是沒有價值的資料，是否一定要保留？意義何在？卸下包袱，也許重新開始呢？
- 不同的工具產生的資料差異很大，想清楚最終業務視角需要看“什麼緯度”的資料，什麼是“帶頭大哥”，什麼是“牽引點”，誰是主誰是輔
- 排除干擾，對於資料欄位，學會做減法
- 流程領域是死的，工具是活的，從領域中去抽象實體
資料治理的過程，伴隨著規則的制定，流程的執行，沒有誰先誰後之說，根據“已有資料”去分析使用者行為和使用習慣，制定“被大部分人接受”的規則和流程，否定掉“少數人的個性化操作”。
最後，收集單純的資料很簡單，但是想得到“對業務有價值的資料”，需要漫長的【收集-整理-調研-分析-設計定義-執行-最佳化-調整-反饋-再調整】過程。
沒有人能一開始全部想清楚，按照“敏捷的思維”，不要過度設計，自己瞎YY, 讓使用者用實際行動產生資料，引導使用者行為，修正資料，這是作為“平臺工程”的實踐者需要去思考和琢磨的。
