Wise 的平台工程 KPI 探索之旅

平台即产品（PaaP）已经成为软件企业构建内部平台的一种流行方式。在众多软件公司争夺市场份额的同时，还有另一种更为微妙的竞争正在兴起，例如怎样让软件工程师以最快的速度发布新功能？是否拥有最有效的内部平台？
 

在这篇文章中，我将分享 Wise 的平台工程团队构建 KPI 树的方法。从产品开发过程开始，是如何塑造平台愿景，从而产生一组可操作的 KPI，以及如何使用这些 KPI 来识别平台最大的问题并持续衡量平台的性能。
 

产品开发流程

KPI 树的目的是帮助我们实施基于假设驱动的实验和验证学习[1]的产品开发流程。虽然有大量关于实施产品开发流程的文献，但更困难的部分是确定适用于平台工程领域的指标。
 

构建-测量-学习反馈循环由愿景和模型提供信息
 

如上图所示，产品开发过程从平台愿景和模型开始。这些是应该不太会有改变的常量部分。模型是指标及其相互关系的表示。KPI 树是我们在选择后确定的模型表示类型。让我们从定义我们的平台愿景开始，该愿景最终会告知我们认为平台可以影响并负责的相关指标或 KPI。
 

平台愿景

平台愿景构成了我们的最高目标，如果没有平台愿景，我们就不知道应该衡量什么。特别是对于 Wise 的自治团队文化，愿景对于建立一致性和问责制至关重要。在我们的产品管理团队中，我们广泛讨论了我们的公司愿景是否可以作为我们的平台愿景。
 

货币无国界——即时、方便、透明并免费

 
尽管 Wise 愿景（或使命）是最终激励我们的因素，但我们得出的结论是，它作为平台愿景并不能很好地为平台服务。我们的平台及团队做出的贡献让 Wise 更接近实现其愿景，但便利性与我们的平台工程工作之间的联系并不明显。因此，我们决定定义一个更相关的愿景。
 

为 Wise 的稳定性奠定基础，使团队能够比其他人更自信、更快、更高效地交付产品

 
尽管这一愿景并非 Wise 特有，但它满足了我们最重要的要求：这个愿景能够有效激励平台工程团队，并明确了我们想要实现的结果。每个团队和小队都应该能够认同这一愿景，并且平台工程师应该清楚他们的日常工作如何促成这一愿景。基于这些愿景和目标，我们构建了属于平台工程团队特有的 KPI，这些 KPI 将作为我们 KPI 树的基础。
 

平台 KPI 树

如下所示，我们添加了一个额外的 KPI，为风险 Risk。风险构成了一种无形的约束，这意味着必须在保持在 Wise 的风险偏好范围内的同时实现生产力、稳定性和效率。
 

平台 KPI
 

根据 KPI 树的四大基础，我们现在可以开始推导模型。如果我们的目标是让 Wise 更加稳定，我们需要了解提高 Wise 可靠性的根据是什么。为了创建这些模型，我们依赖于现有框架以及围绕开发人员生产力和 SRE 的研究。以下是我们列出的一些重要参考资料：

• 加速书籍和四个关键指标[2]
• 开发人员生产力的 SPACE 框架[3]
• 工程效能手册[4]
• 谷歌 SRE 书籍[5]
   

阅读上述材料是一个很好的开端，但平台工程领域没有非常全面的相关示例。因此我们花了很多时间自己集思广益和开发模型。通过分享我们的方法，希望我们可以帮助其他平台团队加快这一过程。
 

注意事项

• KPI 树是模型，本质上是不完美的。也许有更正式的方法来创建 KPI 树，但对我们来说，如果一个指标对其父指标（Parent Metric）有重大影响，该指标就可以成为一个单独的分支。
   

• 好的指标应该是可操作的，具有可重现的结果，并准确地反映现实。我们的几个平台工程 KPI 由我们的产品工程团队和平台共同承担责任，因此平台有时无法做到可以复现结果。
   

• 在这里我分享的 只是 KPI 树的一部分。本文中所分享的 KPI 已足够传达我们的方法并帮助您开始进行类似 KPI 制定尝试。
   

• 请注意，KPI 树并不能取代用户研究。指标将帮助您确定值得调查的领域，从而实现有针对性和更有效的用户研究。但是您仍然需要花时间采访您的客户，以补充您通过指标获得的见解。
   

接下来，我们将展示我们的平台工程 North Star KPI 的 KPI 树：生产力、稳定性、效率和风险。
 

生产力

开发人员生产力是一个有争议的话题，重要的是不要滥用指标来衡量个人绩效。生产力 KPI 树有三个分支，它们分为单独的部分以便于可视化：交付时间、部署频率和开发人员满意度。
 

交付时间

交付时间是我们认为代码更改与将此更改发布给我们的最终客户之间的时间。这个 KPI 树主要衡量 CI/CD 过程中的摩擦。
 

交付时间 KPI 树
 

部署频率

简而言之，部署频率 KPI 树包含在进行代码更改之前捕获摩擦的指标。例如，在开发人员更改服务之前，他们需要阅读文档以了解其工作原理。
 

部署频率 KPI 树
 

开发者满意度

将开发人员的满意度视为生产力的一部分可能很抽象。但事实证明开发人员生产力和开发人员满意度是正相关且相互依赖的。一些人认为，平台工程作为一个领域对开发人员的幸福感没有足够的影响，因为平台工程对薪酬或个人成长机会等因素没有影响。事实上，尽管平台工程无法完全将开发人员的满意度作为一个单独领域对待，但平台中的大部分工作都提升开发者体验和满意度做出了贡献。由于开发者满意度与生产力密切相关，因此对该指标密切关注至关重要。
 

开发人员满意度 KPI 树
 

稳定性

快速交付通常只是工作的一部分。稳定性 KPI 树衡量内部平台让产品工程师能够自信地进行更改且不会破坏最终客户体验的能力。它反映了 Wise 服务的整体可用性，并起到了应对变化的平衡作用。内部开发中平台的稳定性根据包括提供可靠的云原生平台以及咨询产品团队的护栏和最佳实践。
 

稳定性 KPI 树
 

效率

生产力的目标是在输入相同的情况下获得更多的输出，而效率的目标是在保持相同输出的同时减少输入。在我们的方法中，效率 KPI 树涵盖与成本相关的指标。这是云资源、基础设施和许可证的成本，以及我们平台工程团队的成本。
 

效率KPI树
 

风险

作为金融服务提供商，风险管理是我们的首要任务之一。作为一个平台工程组织，我们负责 Wise 的基础，并负有实施变更控制和适当安全措施的特殊责任。我们还认为我们的产品团队偏离最佳实践和黄金路径是风险的一部分。
 

风险 KPI 树
 

KPI 树级别

如注意事项中所述，出于本文的目的，我们仅描述了每个级别的 KPI 子集，并将深度限制为三到四个级别。为了展示 KPI 树可以达到多深，您可以在下面看到交付时间这一分支下的垂直展开画面。
 

具有五个级别的示例 KPI 树
 

现在我们对平台领域的相关根据和指标有了一定的理解，这是就需要使用到一些能够收集和分析这些指标信息的工具。在下一部分中，我将分享如何可视化 KPI 树以使其可分析和操作。
 

平台 KPI 仪表板

在进行 KPI 可视化时，我们需要牢记一点：平台 KPI 是产品团队和平台工程团队共同的责任。下图展示了平台使用的全局工程视图，当然我们根据团队提供了筛选功能。平台工程对比视图可以为各个团队量身定制，帮助他们进行基准测试并最终优化他们的绩效和表现。
 

平台 KPI 仪表板线框
 

所有 KPI 树的总范围包括 200 多个不同的指标，但我们并未对所有指标无差别进行衡量。我们会根据潜在影响来确定优先级，这样有助于我们决定将多少时间投入在哪一方面以获得更好的成果。如上所示的线框图以两种方式为我们服务：首先，设定预期目标，并以此作为与平台外的利益相关者讨论的基础。然后，在实施团队内部建立一致性并将 KPI 仪表盘可视化。
 

下一步

全面衡量总结出的 KPI 数能够帮助你了解需要关注的领域并量化平台工作的影响。目前我们对 KPI 树的上面两层已经有较好的理解了，但分支下的指标覆盖范围仍不完整。这也意味着的 KPI 发生变化时，我们缺乏推断原因的基础数据。为了加快平台 KPI 的覆盖范围，我们需要让平台和产品团队更轻松地获取数据并使其具有可操作性。
 

参考链接：

1. The Lean Startup | Methodology
2. https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance
3. The SPACE of Developer Productivity - ACM Queue
4. Introduction - Engineering Effectiveness Handbook
5. https://sre.google/books/