DevOps 中 API 治理的工程问题和落地实践案例

行业背景：传统的 API 管理模式的割裂与落后

在传统的模式中，API 管理的各大模块之间往往是相互割裂的，不同的模块由不同的岗位人员使用不同的工具来进行管理，模块与模块之间的信息更依赖团队间的线下沟通进行传递，而且整体管理流程也同样是依赖人工干涉，API 管理的成本较高。

基于此，Eolink 提出了 API 全生命周期管理的解决方案，旨在一个平台上集成了API 的设计、开发、测试以及共享等所有环节，以促进研测自动化的构建。

API 的全生命周期管理与 Devops 是紧密相关的，Devops 中的各个环节都会对 API 治理有一定的业务诉求，很多时候企业需要一体化的 API 管理平台来提供相应的业务能力。

但在交付实践中我们也发现，仅建立一个提供业务能力的 API 全生命周期管理平台是远远不够的，业务功能仅是 API 全生命周期管理项目的门槛。所以我们今天主要讨论的是

API 全生命周期管理项目所交付的核心能力——工程问题解决能力。

API 治理过程中遇到的工程问题及其解决方案

在 Devops 工作流中进行 API 全生命周期管理时，成功交付的核心其实就是为企业提供工程问题的解决能力。 那么所谓工程问题都有哪些呢？

Eolink 在服务了超过 10 万家企业的实践中，我们总结了六大工程问题：研发工具链的集成、API 规范的整理、研发质量的保障、自动化体系的搭建、迭代跟踪管理、以及团队协作沟通。

案例一：某农商银行的 API 治理实践

接下来，我将选取其中一些关键的问题，结合案例给大家进一步地讲解。

首先是规范性的问题。我们曾服务过一家农商银行，银行其内部接口众多，主要分为三类：包括自研接口、外包供应商开发的接口以及上级机构需要调用的通用接口。****
而且由于缺乏规范性的接口管理体系，企业内部的接口往往以不同形式存储，使得搜索、查询以及进一步开发变得繁琐，团队成员在开发的过程中难以找到所需功能或重复开发功能。

因此，我们提出的解决方案是建立一个 API 管理仓库。在数据生成方面，通过 Eolink 平台提供的数据标准化生成能力将 API 数据转化为标准数据。 例如，基于 API 代码仓库生成 API 文档，或者基于网关日志生成 API 文档。通过这些能力，实现了各种不同场景下的非标数据均可转换成标准数据存储在 API 管理仓库中。

而一旦它们成为标准数据，我们就可以进行进一步的抽象分析，帮助真正地应用到研发实践中，特别是形成了常用的 API 模板规范，可以协助开发者团队更高效地开发新接口，从而真正实现降本增效。

案例二：某信息安全头部企业的 API 治理实践

下面，让我们进一步深入分析关于自动化搭建体系和表达的案例。

如某信息安全部门，该部门的测试任务比较多，他们发现测试同事经常忙于编写测试用例或脚本，导致整个研发流程等待时间较长，甚至使测试时间占据整体项目交付时间的三分之一。

在我们更进一步的分析发现，在这些测试时间中，约有 60% 的时间是花在编写接口用例和规划测试脚本上。因此，我们首要的目标是解决这 60% 时间浪费的问题。

在自动化体系搭建方面，我们实现了通过 Eolink 平台自动生成的能力来消除原有的等待环节，例如自动生成测试用例和自动化测试脚本等等。换句话说，我们可以基于 API 文档的接口自动生成测试用例，从而大大减少等待时间，提高整个体系的效率。

案例三：某知名证券公司的 API 治理实践

另一个关键问题是接口的质量，许多金融行业的客户在进行 API 全生命周期管理时，并不是一味的追求效率的提升，而是更加注重整个项目的质量和接口安全性。

面向对接口安全和质量有着更高要求的企业，我们也提供了解决方案，即通过在关键流程中识别重要的节点（如测试节点）。在这些节点之间我们可以创建一些卡点，我们称之为“质量门禁”。

这些“质量门禁”背后是具备自动化的逻辑判断能力的，其判断标准是来自 API 全生命周期管理平台提供的数据，并且这些数据可以直接提供给企业的 BPM 系统调用，随时切换自动质量门禁和人工审核模式。

这样的做法有一个明显的好处，即使我们默认了可以在整个生命周期内实施自动化，同时通过 API 系统，也可以进行人工干预，特别是在某些关键的节点上，例如:在发布 API 接口的节点增加人工审核。

案例四：某政企研究院的 API 治理实践

此外，当团队庞大时，沟通协作也可能成为一个问题。例如一些政企单位更多的会依赖外包供应商为其提供业务系统和服务，不同的项目由不同的服务商去负责，系统较多往往会导致单位内部各系统间接口的依赖关系更重。

特别是在接口调整之后可能会引发整个链路上的变更风险，例如甲供应商改了某接口后， 乙、丙供应商他们的接口可能也会受到影响，但是因为他们是两个独立的供应商团队，沟通起来特别困难。

针对这些链路相关的风险问题和沟通难题，Eolink 同样也提供了解决方案，即基于 API 关系的可视化管理。Eolink 平台提供了可以根据 API 调用的链路，自动化测试用例以及根据 API 文档中的入参和出参的关系生成 API 拓扑图的能力。

API 拓扑图可以让开发者快速了解 API 接口的上下游关系。 作为需要修改接口的开发人员，你可以快速找到修改接口文档可能影响到哪些团队、哪些系统的接口。

此外，对于受影响的系统和团队，Eolink 还提供了消息变更的通知策略。 根据 API 信息流的变更，Eolink 能够智能地分发相关的变更消息，通知对应的负责团队。例如，A 团队的接口已更改，B、C 团队是否需要调整，是否需要重新进行集成测试等等。

以上是 Eolink 在 API 全生命周期管理中识别的一些常见工程问题和相应的解决方案。

API 治理问题的冰山分析模型

当然，由于时间有限，今天仅挑选其中几个问题进行讲解。但是我们解决了这些工程问题，项目是否就可以顺利交付呢？全生命周期管理就可以达到理想的效果吗？

实际上并非如此。在项目实施的过程中，我们可能会遇到更深层次的实施难点。这些实施难点可能与使用的系统、解决的业务等关系不大，但只要你涉及到客户的研发体系的流程优化，都有可能会遇到这类的挑战。

API 治理过程中实施难点及其解决方案

那么在面对 API 治理的实施难点时，我们又该如何解决这些挑战呢？

让我来给大家简单地阐述一下。第一个也是最常见的难点就是流程变更的阻力。 即使新流程被认为是更高效的，但是由于效率提升是需要时间的，而眼下新流程需要替代旧流程，这必然会给团队带来一定的变更成本，因为他们平时已经习惯使用旧流程，新流程可能不会立即见效，这种更替俨然成为团队的一种使用负担。

面对这些流程变更的阻力，首先，我们必须与各级别领导进行充分的沟通。 我们需要向他们解释项目的价值点，并与项目的决策链负责人对接，确保项目目标与其 KPI 一致，这样才能从上到下获得更多资源的支持。

其次，我们可以树立标杆项目。 一开始在全公司立即全面推行是不可取的，应该寻找一些经典的项目团队，将其作为标杆项目，形成对公司的解决方案和最佳实践，借助示范效应再对整个公司进行推广。在这个过程中，我们建议大家寻找公司内最复杂的团队，可能是他们的流程最多或者人员最多的团队，基于这些团队制定出来的实践项目是最有参考价值的。

正如小鹅通的王老师所说： “ 无论是 DevOps 还是 API 全生命周期管理都应该是渐进式的，不可能一开始就改变所有流程” 。

因此，我们需要分析现有流程，为企业规划不同阶段的改造路线。 最先要优化和实现自动化的是那些投入产出比最高的环节。其次是进行版本和规范的管控，使数据更加标准，以便在下一步进行拓展。然后就可以对接口资产进行全局管控，最后再进行与生产相关的接口运行态的管控。这就是整体解决流程变更阻力的一种可行的途径。

第二个实施难点是一线员工比较关心的问题。 一线开发工程师和测试工程师，基本上很少会在乎管理理念上的事情，他们通常关心如何快速适应新工具，同时确保满足当前的 KPI 和业绩要求。为了解决这个问题，这里我们提供两种解决思路。

一个是，在新的产品或工具上需要提供一些模板化的功能， 让员工可以基于某些模板快速创建资源，例如：创建标准的 API 模板或测试用例。

另外就是，推动 DevOps 和 API 全生命周期的实践更多的是为了实现企业内部各个流程的自动化。

这实际上是一个流程化配置的过程。对于这些流程化的配置，我们应该在界面上提供清晰且简单的可拖拉、可点选的元素，使用户能够在界面上快速配置完成自动化流程的搭建。

此外，实施难点上还有一个关键问题，即企业经常会面临新流程执行一段时间后，不清楚当前效果如何，未来又可能达到什么样的效果。 对于这些问题，我们提供了两个方案。

首先，对于整个过程的度量，我们引入了效能看板。 企业可以比较当前时间段和下一个时间段的数据，包括反馈团队效率、产出效能、工作堆积等等信息，从而实时监控团队的转型情况。

另外，我们提供了阶段性评估模型，不仅团队内部可以在不同时间段进行对比，也可以全面评估企业对于 API 全生命周期治理方面的水平。 这使得企业能够在未来的发展中更清晰地认识自身情况，以便进行有针对性的优化。

然后，关于自动化流程的落地， 前面我们强调界面化、可视化、可拖拉拽的工具的重要性。 这些工具能够使整个自动化流程的各个节点更容易调整，使用者只需简单的拖拉和点选就能完成流程的配置。

当然，除此之外，底层技术架构也需要提供更加灵活的方案。 我们推荐企业使用 Open API + Webhook 机制，这样能够更标准、更适配其他厂商同时与我们的平台进行对接，使客户能够更灵活地进行更多的自定义操作。操作更简单配置更快捷，最大限度降低使用者的心理负担，从而减轻工具更替的阻力。

最后一个值得注意的实施难点是企业差异化诉求的解决方案。 不同企业的需求各异，需要我们在不同维度上提供多样清晰的拓展点，方便团队和企业内部自己动手制作一些小工具。我们强烈推崇在 DevOps 平台或 API 全生命周期管理平台上提供插件化体系，以支持其他额外功能的灵活插拔，使技术架构更加灵活。

以上是一些实施的难点和解决方案的思路。接下来，我们聊一下实施方案设计的问题。

首先，我们需要了解这些实施难点的解决方案并不适用于所有的企业用户，只有快速上手模板是所有用户都能用得上。 对于一线员工和公有云企业用户而言，我们可以提供更普适的服务（如模板）来帮助其员工快速入门。

而像全面集成能力与流程配置、实践培训、专属解决方案这些服务，是需要深入了解具体的业务流程，才能制定对应方案的。 必须进行一定的业务调研，才能让项目与企业团队对齐目标，并且提供重新梳理整个研发流程和业务数据流向等等的服务。

还有就是，我们需要为企业提供效能分析服务，找出当前效能瓶颈在哪里，企业现在属于哪个治理能力阶段，分析如果实现了自动化可以减少多少人力成本，进行效益优先级分析；最后，我们将制定改造计划，包括制定迭代内容和迭代路线图，以确保在未来的半年到三年内，企业在 API 全生命周期方面改造后将达到什么水平。