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