S2E1: 如何为 OpenAPI 的指标分类

作为一个好的 OpenAPI 业务同学,应该同时关注 OpenAPI 的基建指标和用户相关指标,从而更好的通过指标,数据驱动优化业务。

S2E1: 如何为 OpenAPI 的指标分类
Photo by Luke Chesser / Unsplash

Hi,

一如昨天所说, S2E1,我们从指标开始聊起。


在正式去看一个个具体的指标和设计之前,我想先和你聊聊指标的分类。分类是一门艺术,好的分类可以帮助我们更好的理解世界。通过将对象进行分类,我可以快速给自己所面临的问题找到答案,这是我们的处事的方法和手段。

OpenAPI 作为一个业务,自然也有着其自己的业务指标和属性,通过这些业务指标,我们可以快速的了解到业务的属性和状态,从而规划在当前周期或下一个周期需要推进和执行的事情。

不过,由于 OpenAPI 业务本身的特殊性,大部分时候往往是由研发同学牵头在跟进业务,产品同学更多是辅助角色在关注 OpenAPI 相关业务,这也导致我们过去在关注 OpenAPI 的各项指标时,往往会关注其基建指标(Infrastructure metrics),而忽视用户相关指标(User-related metrics)。

不同的指标用途不同,只关注基建指标,则会让我们开发出性能极强,但毫无卵用的 OpenAPI;只关注用户中心指标,可能能够发现我们的用户体验很不好,但又无法根因到具体的问题;因此,作为一个好的 OpenAPI 业务同学,应该同时关注 OpenAPI 的基建指标和用户相关指标,从而更好的通过指标,数据驱动优化业务。

什么是基建指标?

基建指标的特点是不以用户为中心,而是更多关注的是大盘上的全局趋势,我们会通过关注基建指标,来了解业务本身的情况。OpenAPI 是否是稳定的、我们是否需要对我们的服务做一些什么。常见的基建指标包括:SLA、CPU 使用率、内存使用量、API 调用量、错误率、调用的平均时延等一系列与我们的技术相关的指标。从技术视角来看,基建指标往往是一些具有时间属性的数据,我们通过把这些具有时间属性的数据进行聚合、分析,得到我们想要的分析纬度。

moesif 的指标看板

这些指标往往关注的是我们在当前的基建之上,还需要做哪些事情,来帮助我们优化服务的稳定性、可用性。

在基建指标上,我们常用的指标包括:

  • SLA:作为一个 API,服务自身的 SLA 是需要关注的,API 作为一个后台调用的产品,崩溃后如果没有监控,可能很难会被发现。在实际使用过程中,我们需要通过很多手段监控我们自己的 API 的 SLA,从而确保在对客服务中不出岔子。
  • QPS(Queries Per Second):OpenAPI 作为一个高并发的服务, QPS 是一个重要的观测指标,通过对 QPS 的观察,可以在出现问题时,快速评估是否是量变导致的质变。同时也是一个系统性能优化的指标。
  • RT(Response Time):Response Time 在开放平台是一个重要的观察指标。对于开发者来说,需要通过 OpenAPI 的调用来完成业务逻辑,如果 Response Time 过长,则可能会导致开发者链路上的超时或体验差等问题,因此,Response Time 也是一个非常重要的指标。这里需要注意的是,Response Time 除了要关注平均值,也需要关注 PCT 95、PCT99 和极值,这些指标引导了业务系统中的峰值和方差,对于 OpenAPI 来说,稳定的 Response Time 对于开发者来说,是更加可预期的。
  • 成功率:成功率展示了我们的服务到底服务的如何,一方面,我们会重点关注 200 成功的比率,成功的比率可以间接的展示出我们的系统在实际使用上的情况。而另一方面,我们也会重点关注 500 失败的比率,每一个 500 报错,对应的可能都是我们在代码系统中存在的 Bug,需要尽快修复,以避免更大的问题。
  • Top N API:Top N API 可以帮助我们快速找到业务中被开发者广泛使用的 OpenAPI,从而引导我们进行不同的工作重心的投入和安排。此外,也可以围绕着 TOP N API ,进行用户引导和宣传,让开发者更加深入的使用我们提供给开发者的 API 。

什么是用户相关的指标?

和基建指标更加关注大局不同,基建指标则更加关注每一个具体的用户的使用体验。通过对于用户中心指标的分析,可以发现我们在 OpenAPI 的设计上的使用问题,同时找到用户中的核心用户、先锋用户,对于用户进行进一步的触达,撬动更大范围的用户影响力。和基建指标相比,用户相关的指标不以时间维度聚合,而是以用户为维度聚合,通过将这些数据聚合起来,我们可以得到对于产品的洞察。

一组用户行为的追踪表格。用户中心指标往往需要能下钻到用户的粒度

这些洞察可以引导我们关注一个用户的行为和路径,从而得出一个用户是如何使用我们的产品的;我们又是在哪个环节流失了用户的。

用户中心指标因为其组织形式,决定了往往关注的是一些特定的个体,比如:

  • 某个 OpenAPI 的月活是多少?以及调用这个 OpenAPI 的最多的用户是谁?:这个数据可以帮助我们发现我们的用户中的 VIP 用户。产研可以和这些用户沟通,了解他们的需求和问题,并帮助他们解决具体的问题。
  • 哪些用户的使用深度最深,流失的可能性最低?:通过分析用户的用量,从而分析出深度用户和浅度用户,并找到那些使用量在逐步降低的用户,可以和他们沟通是否遇到了什么问题,是否需要进一步的帮助。
  • 某个 API 的增长情况如何,最近一个月那些用户开始使用 OpenAPI?:通过这个数据,你可以发现你的 API 的增长情况,并进一步分析他们是如何使用你的 OpenAPI 的,并通过对他们进行定向的触达和营销,从而进一步增大产品的价值。

用户中心指标会更加导向产品的迭代方案,但同时,其建设成本也会更高,你需要提供一整个声明周期的数据,才能判断用户的行为,预测下一步动作。当你的用户量级足够大的时候,用户中心的指标,会帮助你发现用户的问题,解决问题,取得更大的成功。

总结

如果你到了一个新的业务当中,不知道怎么下手时,不妨先问问自己 —— 我的基建指标有了么?我的用户中心指标有了么?毕竟,有了指标和数据的支撑,才好量化自己行为的有效性。

如果有,那就对着数据去分析,看看业务的技术基础如何?用户感知如何?用户到底是在哪个环节流失 / 转化失败的。如果没有,那不妨按图索骥,先把指标建立起来,然后围绕着这些指标,一步步去解决你的问题。


One More Thing

最近我使用阶跃星辰的大模型,做了一套工作流,来帮助我阅读海外的开发者生态的文章。在阅读过程中,如果我发现不错的文章,也会通过 Newsletter 推送给大家。

由于非 APILetter 的标准系列文章,所以我单独开了一个新的系列 — 他山之石,本 Newsletter 的读者也会默认收到这些推送。如果你不喜欢,后续收到第一封推送后,取消推送即可。

Read more

加更: 聊聊 APILetter 的新计划

加更: 聊聊 APILetter 的新计划

Hi,你好, APILetter 从创刊号,到 S1E6,经历了一年的时间。 虽然在定更新节奏时,我就考虑到自己拖更的可能性,但确实没想到我拖更这么严重,在 2022 年,一口气更新了 3 篇,然后就是长达半年的拖更。不过,总算是把第六篇写完,算是给 Season 1 做个了结。 过去 APILetter 的出现,是源自我在研究 RESTFul 架构时发现的问题:国内有太多解释什么是 RESTFul 规范的文章,但你点进去看,篇篇都是复制粘贴。 而 API 是开发者生态中非常重要的一环,它不应该被草率的对待,开发者们值得用上更好的 API。既然没有人写关于 API 的严肃内容,那就从我开始吧。刚好我在研究相关的内容,那就写一些 API 到底应该是什么样的。 也正是抱着这个想法,我开始了一篇篇的创作,

By 白宦成
S1E6 为什么 OpenAPI 的设计如此重要?

S1E6 为什么 OpenAPI 的设计如此重要?

在 APILetter 的 S1E6,我想和你聊聊 OpenAPI 设计的重要性。 在整个 S1 的文章中,我用了接近 4 篇的篇幅来介绍 OpenAPI 的设计,从一开始介绍为什么要使用 RESTFul ,到 API 的错误码设计理念,辅以批量接口设计的实例,再加上最后这篇重要性的强调,三分之二的比重,意在让你深刻认识到,OpenAPI 的设计至关重要。 为什么 OpenAPI 的设计如此重要? 在企业内部工作时,常常需要找到平衡质量和速度之间的折衷方案。当项目时间非常紧迫时,往往会牺牲一些质量。但如果项目有足够的时间,就有更高的概率能够设计出一个质量更好、开发者体验更佳的 OpenAPI。 然而,OpenAPI 是一项非常重要的任务,不能马马虎虎。一个坏的设计会让团队持续在 OpenAPI 开发上投入更多的精力。 沟通难度高带来的维护成本增高问题 和企业团队内部使用的 API 不同,OpenAPI 的用户是外部团队,

By 白宦成