共计 3374 个字符，预计需要花费 9 分钟才能阅读完成。
作者|Lambros Charissis
翻译|Seal 软件
链接|https://medium.com/wise-engineering/platform-engineering-kpis…
平台即产品（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 的覆盖范围，咱们须要让平台和产品团队更轻松地获取数据并使其具备可操作性。
参考链接：
- https://theleanstartup.com/principles
- https://cloud.google.com/blog/products/devops-sre/using-the-f…
- https://queue.acm.org/detail.cfm?id=3454124
- https://ee-handbook.io/
- https://sre.google/books/
