随着公司采用 API 优先的设计实践来构建现代应用，衡量这些 API 的运行性能和价值成为当务之急。构建一个可明确定义 API 指标并将其与关键绩效指标 (KPI) 挂钩的框架是确保 API 策略成功的最重要步骤之一。
通常情况下，KPI 与具体目标紧密相关。它们有着明确的时间框架，并与 API 策略需要交付的成果相匹配。相比之下，API 指标是重要的数据点。并非所有指标都是 KPI，但每个 KPI 都基于指标。
那么您应该如何着手呢？首先，您需要从一开始就明确 API 策略的目标，然后再选择与该目标匹配的指标。切记每个团队需要根据对自身的重要性和对业务的必要性衡量并跟踪不同的指标。
概括地说，公司可跟踪三大类 API 指标，并且不同类别的指标反映不同的问题：
您可以把这三大类指标想象成一个金字塔。底端的运维指标衡量各个 API 及其支持性基础架构的战术性能。顶端的产品指标衡量 API 创造的业务价值。两者通过采用指标联系在一起，采用指标跟踪 API 程序在最终用户（开发人员）中的增长情况。一般来说，产品指标和采用指标与您需要衡量的业务成效相关，而运维指标则与您需要维护的技术标准相关。
本文详解了 12 个必须衡量的具体指标，介绍了它们如何支持基础架构和应用团队，并解释了这些指标与 KPI 的关系。
运维指标
在初始阶段，运维指标通常是第一个需要衡量的指标。它们是战术性指标，可提供有关 API 运行情况的洞察。运维指标通常不是 KPI。但它们可帮助您衡量团队所构建软件的质量和性能，并针对新问题提供早期指标，或者帮助您深挖并发现可能影响关键 KPI 的问题。
您可以根据团队和职责跟踪不同的运行指标。
基础架构团队
平台运维团队负责维护、连接并保护不同团队用于交付应用的基础架构和技术组合。就 API 程序而言，这通常包括 API 网关和 API 开发人员门户。
平台运维等基础架构团队的关键指标包括：
- 正常运行时间——即使是最基本的指标之一，正常运行时间也是衡量服务可用性的黄金标准。它通常与服务水平协议 (SLA) 相关。
- CPU 和内存使用率——跟踪 API 网关的资源使用率对于确定何时可能需要扩展实例至关重要。它还可作为早期预警指标提示即将发生故障或者由于错误导致使用量激增。
- 总通过率和错误率——衡量 API 触发 HTTP 错误状态代码（非
200）的频率可帮助您了解 API 的易错率。这项综合指标所提供的信息可帮助您判断您的团队投入生产的 API 的整体质量。
应用团队
应用团队由 API 开发人员和服务所有者组成，负责构建和运维各个服务或应用。这些服务或应用可用作大型产品的一部分，与合作伙伴产品相集成，或用于给开发人员提供 API 即服务。
应用团队需要衡量以下指标：
- 每分钟请求数——该性能指标衡量您的 API 每分钟处理的请求数。虽然它随时间变化，但您通常希望限制每分钟请求数，以确保为 API 用户提供最佳体验。
- 平均和最大延迟——跟踪您的 API 接收请求和返回响应所需的平均时间至关重要。缓慢的 API 会对用户体验产生不良影响，进而对业务造成不利影响。
- 每分钟错误数——真理往往相通，没有完美的 API。出错无可避免，迟早发生。您需要监控错误，并实施计划周详的行动方案将其尽快修复，以免错误突然加剧。
请参阅由 NGINX 提供的 O’Reilly 电子书《掌握 API 架构》的第 3-5 章，深入了解 API 操作以及对业务至关重要的 KPI 和指标。
采纳指标
API 优先的企业不能只着眼于工程指标，还应了解开发人员正如何与您的 API 进行交互。您还需要衡量并监控 API 开发人员体验，以确保开发人员采用您的 API 并从中获得价值。
下面列举几个采用指标的示例：
- 唯一 API 消费者——该指标通常通过月活用户数量衡量有多少开发人员正在使用您的 API。理想情况下，随着越来越多的开发人员将您的 API 集成到其应用中，这个指标会不断增长。
- API 使用量增长——该指标也衡量 API 采用率，而且通常是衡量 API 采用率的首选指标。理想情况下，随着更多应用和开发人员使用 API，API 流量会逐月增长。
- 首次调用时间——该指标衡量开发人员创建帐户、生成 API 凭证和运行首次 API 调用所需的时间。让开发人员尽快打开工作局面是一个高度优先事项，因此这个指标是衡量整体 API 开发人员体验的最重要指标。
注：我们建议至少有一个 KPI 衡量 API 采纳率。这可帮助您推算 API 程序的整体增长。例如，您可以设置一个 KPI，跟踪使用您的 API 创建持续集成或应用的开发人员数量的增长情况。
产品指标
API 产品指标在帮助了解 API 的价值方面发挥着重要作用。虽然只有一小部分 API 可以带来直接的收入贡献，但每个 API 均需为业务创造价值。
需要衡量的关键产品指标包括：
- 直接和间接收入——这些指标衡量 API 不同的收入贡献方式。其中一些 API 可直接变现，另一些支持与业务合作伙伴产品的集成，或者是对客户至关重要的第三方集成。与跟踪 API 采用率一样，跟踪间接收入可帮助开发人员为合作伙伴构建创收型应用。
- 每个 API 的应用数——API 需要可重复使用。这个指标衡量有多少应用与 API 相集成，以了解哪些 API 创造的价值最大。
- 合作伙伴数量——API 通常支持构建业务关系。跟踪合作伙伴的 API 集成数量有助于推动采用，并向其他业务部门展现价值。
注：这些产品指标与业务影响密切相关，您可以根据自己的业务目标选择将一些产品指标转化为 KPI。举例来说，如果您的 API 策略的业务目标是通过第三方提供商触达更多客户，则可跟踪使用您的 API 的合作伙伴数量以及通过这些集成产生的间接收入。
请参阅《掌握 API 架构》的第 3-5 章，更深入地了解 API 产品的生命周期，包括业务和运维 KPI。
结语
将 API 指标和业务 KPI 相关联是企业制定数据驱动型决策并确保 API 策略提供所需价值的主要方法之一。此外，实现 API 可视化有助于基础架构和应用团队衡量对各自最重要的运维指标。
NGINX 实现了数十个重要 API 指标的可视化。您可以查看实时和历史指标，并轻松地将其导出至您首选的应用性能监控 (application performance monitoring, or APM) 或数据分析解决方案中。
立即开启 NGINX Management Suite 30 天免费试用，包括 API Connectivity Manager、NGINX Plus（作为 API 网关）及 NGINX App Protect （可为 API 提供安全防护）。
