Spotify的基礎設施團隊分享了他們是如何通過對數據進行優先級排序來構建一個自動化的數據收集平臺，從而在DevOps中實現了數據驅動決策，並提高了開發人員的生產效率和產品價值的。
Spotify的基礎設施團隊使用Gradle（Gradle Enterprise Edition）作爲其Android應用程序的構建系統。它能生成、收集和存儲需要根據本地開發經驗來理解軟件所需的數據。它需要共同關注數據管道和儀表板的可視化。對於iOS系統數據的生成、收集和存儲，目前還沒有一個成熟的解決方案，所以該團隊自己開發了這些工具。
Spotify在數據領域已經投入了很長一段時間了。Spotify的技術學習團隊推出了數據大學（Data University），這是一系列涵蓋數據科學和工程學各個方面的培訓課程，旨在幫助工程師解決與產品相關的問題。
Android基礎設施團隊將這些經驗教訓運用到他們的構建時間和本地開發經驗中，但他們發現他們缺乏驅動決策的數據。
Spotify通過召集某些特定“部落”小組來專門提供數據基礎設施，併爲工程師配備構建模塊來收集數據並可視化數據輸入，從而解決了這種數據需求。他們指出，目前仍然存在許多挑戰，例如如何將這種數據驅動的方法應用到他們的架構決策中。
該團隊使用這一新的數據基礎設施來闡明技術和產品團隊應該在哪些方面進行投資來減少構建時間。當他們查看構建時間趨勢以及Swift和ObjC中使用的組件總數時，他們認識到投資於Swift優化是有意義的。
這項針對數據驅動決策的技術投資與哈佛商業評論分析服務公司（Harvard Business Review Analysis Services）最近的一項研究結果截然不同，該研究顯示，只有7%的企業爲其團隊提供了推動基於數據的決策和自主權所需的分析工具和資源。
從本質上講，Spotify的方法很簡單：團隊提出他們解答不了的問題，然後在積壓的待辦事務中（backlog）優先處理這些問題。在數據可用且問題得到解答之後，團隊在評估階段收集反饋，以瞭解該工作是否對本地開發過程產生了影響。爲了防止數據質量的惡化，團隊必須對每個組件的數據一致性和數據管道進行質量檢查。
在計劃階段，團隊使用歷史數據來確定需要改進的場景。這些數據可能無法描述當前的情況，但它提供了確定改進的基線。如果他們已經瞭解了特定情況下系統的構建時間，那麼他們希望保持相同的數值，或者改進這些數值，而不管代碼庫的增長情況是怎樣的。這一點是至關重要的，因爲隨着系統變得越來越複雜，DevOps工作流通常也會變得複雜且不透明。
敏捷自然傾向於優先考慮產品，因此DevOps面臨的挑戰是，如何在增加特性以提高產品效率和提高開發效率或提高服務可靠性之間找到折衷點。
在計劃階段，團隊引入了一些任務來收集和顯示驗證更改所需的數據。此階段提出的問題是關鍵的輸出之一，例如：“我們是否收集了足夠多的信息來檢查開發人員是否打開了遠程緩存？”或者“在單個PR中他們平均更改了多少個組件？”
隨着基礎設施團隊的數據計劃在內部得到更廣泛的認可，其他團隊開始優先考慮與平臺相關的工作。產品團隊開始重視數據可視化，以驗證驅動移動DevOps團隊決策過程的產品討論。
產品團隊的數據驅動決策有助於評估解決方案的有效性和採用的滿意度。產品經理通常從早期階段就開始使用用戶調查來評估產品了。相比之下，數據驅動的過程將這種評估帶到了產品概念化中。
InfoQ的數據驅動決策系列概述了數據驅動決策是如何支持軟件交付中的三個主要活動的——產品管理、開發和運維。
原文鏈接：