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的数据驱动决策系列概述了数据驱动决策是如何支持软件交付中的三个主要活动的——产品管理、开发和运维。
原文链接：