PayPal 系列教程（三）：解密大规模 API 转换

关键点

• 在您的组织中寻找有效的战略。
• 建立一支拥有人才的强力队伍，以构建信誉并提供良好的用户体验。
• 找到一个让开发人员参与的较好的“推”和“拉”激励平衡。
• 在集中治理和联邦制度之间找到适当的平衡。
• 理解如何融入到 SDLC 中，并且如何在每个阶段添加最好的价值。

这是本次三部分系列的第三篇，该系统文章揭示了 PayPal 如何更好地采用 API 优先规则构建平台服务。 第一部分，我们解释了原因，关于如何解耦、API 驱动体系架构，以及大规模处理情况下的基础设施。第二部分，我们深入探讨了 API 本身是如何管理的。本文我们将会近距离研究程序方面以及执行和操作时必须克服的挑战。

Deepak Nadig: 当您第一次启动这个项目时，最大的挑战是什么？

Erik Hogan:我想起了一些。

在最初阶段，我们面对的是一个已经习惯了现状，并且产品阻止已经经历了从瀑布时代过渡到敏捷时代的工程变化。这个组织没有明确的态度，但是长期存在的开发团队有一个声音，就是它们对于改革有很强的抵抗力及对应的影响力。类似被设计用来重构平台的方案，或者做一个 SOA 转型，这些在过去几年中已经有过成功和失败。人们有理由担心这种新的努力只会导致更复杂、更混乱和更多的技术债出现。因此，仅仅让他们购买并支持这个项目是有一定难度的。

了解一家公司的业务范围和能力是另一个重大挑战。长达十五年的开发工作产生了大量的代码、解决了大量的用户用例，这些很多都是没有文档化的。对于现有业务流程的良好理解是必要的，利于 API 产品组合最终成为我们实际的准确愿景。

最后是如何构建程序。不会存在蓝图，我们必须制定一个切实可行且符合组织细微差别和成熟程度的战略。这些都需要时间。业务和过去的发展没有紧密结合。我们基本上是从零开始的。

Deepak Nadig: 您针对这些障碍，做了什么去克服它们？

Erik Hogan:我们开始得比较有策略性。

对于进展的压力往往是自上而下的。首席执行官、首席技术官，以及相当一部分技术 VP，他们都认为需要做出改变，并且这些程序上的改变应该作为解决方案的一部分。从这一点来看，我们不需要向上层领导推销价值观。他们明白，如果保持现状，我们不可能提高开发的敏捷度，不可能在尽量短的时间内推出新的产品。他们会和其他人一样，对缓慢的创新和高成本的集成感到失望。

我们探索了几种不同的参与模式。第一种就是在各个领域招募技术领导者，让他们变成“冠军”。当时的想法是创造可以在组织内部传播概念和标准的专家。我们召集他们开会、做一些培训，但是最终什么都没发生。拥护者喜欢这个想法，但是没有实质性的动力继续推进变化，一切工作依然照旧。另外一些领导者或多或少是出于领导的压力“自愿”参与其中的。他们不仅不相信我们在做的事情，而且他们也不会被追究责任，最终这个模式失败了。

我们也扩展了开发工具，以鼓励和我们一起使用设计模式和标准。虽然这种做法本身具有大量的价值，并且它们也确实是成功的要素，但是对于服务组合的重构和能力边界的加强是不够的。例如，如果你有一头猪，涂点口红这样的做法并不能根本上地改变只能做熏肉和猪排的实际情况，你需要对如何解耦和构建敏捷平台继续自己深入的思考。

反复思考之后，我们最终决定开始构建一个切实可行的愿景。基于数据驱动，管理层需要一些简单的指标，用来跟踪项目的进展情况，进而对团队负责。他们最感兴趣的是工作我们做到哪了，什么时候可以“完工”。我们知道这个过程可能需要长达数年时间，因此我们需要一个模型，使我们能够灵活地进行阶段性的转换。

我们提出了一个 API 成熟度模型的想法，这个想法封装了我们开发的标准。我们编写了客观可用的标准，并以 1-5 的比例绘制了它们。基于优先级，我们强调设计完好的接口，以符合企业能力模型作为首要目标。这个想法是如果我们可以让接口设计得比较好，我们可以在业务能力之间构建稳定的边界，开始迁移遗留的接口，并逐步重构基础服务的实现。我们最终完成了一个封装完好的微服务系列，这样我们可以通过 API 获得商业敏捷和集成所带来的最大价值，而不需要正面应对整个系统重构。这一步代表了成熟度 3 级。成熟度 5 级是实现完整数据和服务封装的 API。另一方面，允许平稳过渡的临时步骤。

为了计算完成的百分比，我们需要一个分母。我们的方式是定义业务能力模型，模拟那些我们认为在最终状态属于主要资源和最终输出。一个由六或七个业务架构师组成的团队花费了一年中的大部分时间用来分析用例、采访领域内的领袖、代码取证，以及记录业务满足模型的过程。并不是意味着完美，而是为我们提供了可以用来跟踪进展的假想分母。

最终，我们向管理层兜售了我们的想法，我们制定了第 1 年让组合的目标百分比达到成熟度 3 级，关键是我们获得了承诺，他们承诺会把这个目标下沉到他们所有的经理。这些都是用于产品和工程组织。在一个步骤中，我们讨论了度量、逐步推进和优先级安排问题。关键的是，我们有一个简单的、数字化表达进展程度的，公司内每一个人都能懂的模型。从内部营销的角度来看，这些简直是太棒了。我们设定了通过 RESTful 对外暴露组合的 75% 的目标，在 2014 年底前完成符合标准的 API。我们通过很大的优势取得了胜利。

Deepak Nadig: 你们团队有多大，扮演的角色是什么？

Erik Hogan：这一举措最终生成了平台产品组。刚开始时大约有 7 个人。这是参与分解业务架构、定义业务功能、管理 API 产品组合，以及管理基础设施和工具等路线的核心团队，这些路线让整个程序成为可能。

团队中的程序都是非常资深和技术能力很高的产品经理，很多都拥有工程北京，对设计大规模平台有强烈的热情。每个构建的 API 由团队审查，并针对目标业务架构进行评估。他们决定命名，并且尝试确保产品组合中的一致性。更重要的是，他们总是尝试从客户的角度出发，确保内部概念、缩略语以及术语不会“泄露”到外部接口。开发人员倾向聚焦于特别的问题。这些投资组合经理是为了应用一个整体的、平台化的试图，帮助强化开发者的 API 工作变得尽可能的可重用。

另一个核心团队是 API 设计团队。这些特殊的工程师是系统架构、接口设计技能、客户体验，以及教育和指导热情的混合组合。处理这些技能并不罕见，但是在一个人身上找到所有这些技能是很难得的。我们很幸运找到了一些真正优秀的人才，他们能够把团队打造为项目的核心力量。他们的工作不仅仅是定义和维护标准，而是传播他们、教育组织，以及审查 API 说明书，根据成熟度模型中的标准拉动请求。这些和开发人员之间的直接交互是许多教育和学习机构实际操作的。我们有很多地方都有可信度。在最初的一年里，我们这个团队有 3 到 4 个人。他们负责审查所有的 API，所以他们确实很忙。

第三组是一个小型 Scrum 团队，他们聚焦于扩展项目所需的基础设施。我们开始的时候对任何商业产品都不会满意，所以我们构建了属于自己的产品，一个内部开发者门户。它提供了所有 API 的可被发现方式、自动化的成熟度得分计算，提供一些基本的工作流，跟踪生命周期状态，以及加强版本管理政策。这个核心系统也产生系统状态的必须报告，并且将这些提供给不同的团队和业务部门。随着时间的推移，团队也构建库、API，以及插件，用于简化 SDLC 以及让开发者更容易部署他们的 API。

最后一个团队是项目管理团队，它的工作是协调所有团队的工作，并且全面地控制跨领域风险。特别是开始阶段，我们发现跨组织内部的业务单元的不同团队之间存在大量重复开发工作。组合驱动方式的一个明显优点是减少重复投资和更好的可重用性。这种方式需要来自资深领导者的艰难的决策，并且这些决策最终导致团队被重新分配到其他项目组。项目管理层在促进这些成果方面发挥了关键作用。

Deepak Nadig: 除了设置顶层目标以外，你还做了什么，鼓励开发人员和产品经理参与其中？

Erik Hogan:公平来说，大多数开发人员实际上从一开始就支持我们的行动。我们建议从专有解决方案转移为更多的工业标准方式，比如 REST 和 OAuth2。任何一个最近可以了解到外部世界，并且没有参与到即将被取代的那些人，直觉让他们理解采用和别人相同标准所带来的价值。这些也让他们个人很感兴趣，因为他们可以使用更流行的工具和技术，可以提升他们的市场竞争力。

在我们给他们做一些我们正在做的事情的培训之后，很多人不会立即就改变自己的想法。有少数反对派会一直坚守到最后，但是我们表达了明确的目标和计划之后，势头有了明显变化。

我们尝试找到创新型方式，“拉着”开发人员进入我们的计划。我们针对最佳新服务设立了每月之星奖项，并且在所有人员都参与的会议上公开表彰该团队。几个月之后，团队们开始积极地游说项目，以赢得该奖项，所以肯定会有一些效果了。

我们主办了黑客马拉松，鼓励采用创新方式使用新的 API。这些举动的重要性不仅仅激励服务开发人员，而且在 SDLC 里消除错误和漏洞。副作用是向他们当前项目的外部客户显示了服务的开发人员。对许多人来说，这是一个奇怪的想法，即便客户没有咨询开发人员，他们依然可以和服务进行对接。这种方式他们其实是不适应的。这是文化上的转变，也描述了为什么优秀的文档事实上是多么的重要。API 不仅仅是项目。它们是需要持续支持的产品，希望能有较好的开发经验。

Deepak Nadig: 经常会有类似于这样的潜在项目，高开低走。你们做了什么，以确保不断地长期成功？

Erik Hogan:这是非常真实的。通常项目起初推动力很像，被放在最高优先级，也取得了一些进展，接着组织进入到了下一个阶段，一些新的事物。在某种程度上，在这种情况下也是如此。

我认为关键是思考你的团队的长期战略，并且对环境中的变化作出快速反应。程序本身也是一种产品。戴上你的产品帽，强迫自己思考自己的客户，他们需要什么，你的竞争优势是什么，以及如何维持增长。程序是为了满足商业目标而存在的，你需要确保你做得很好，贡献了预期的价值。

在我们的例子中，我们在第一年前进的动力来自大量高层的帮助。第二年，有了大量的组织级别变动，我们迎来了新的 CEO，我们上市了，有一套非常不同的优先级设置。我们的能见度急剧下降。

主动的结果迫使我们加倍满足开发人员客户的满意度。我们开始变得更加以客户为中心，敏感领域不条不紊地改进。我们完善了我们的工具，加快了评审过程，提升了开发人员的培训，并且消除了一些非必要的成熟度标准。过程中的摩擦减少了，更多的开发人员积极地参与其中。

我们注意到的另一件事情是，这个过程中客户比以往更早回来找我们，要求在 SDLC 阶段的早期提供更多的帮助。我们的产品被作为核心产品“销售”给他们 -API 设计专业知识，该知识对那些心怀构建伟大服务的开发人员来说，很有价值。我们在很多情况下节省了他们的时间，让他们最终产出了更好的产品。更多来自各个领域的本地开发人员参与其中，不断地传播着积极的反馈，好像飞轮效应。

另一个策略是我们尽可能地采用分散方式。这通常是原始计划的一部分，但是我们感到我们需要把事情集中起来，直到我们构建了一个可复用过程，并且改良基础设施以支持他们。第二年年末，我们开始在培训各个领域的开发人员方面取得了一些成功，培训他们如何构建自己的 API 成熟度评估过程。我们在进入第三年后推进了大规模的培训，积极招募和培训足够多的开发人员处理大部分的 API 审查工作。由于他们已经看到了自己构建的服务质量的积极影响，所以各个领域都开始构建自己的计划，在每个团队里拥有“认证的”API 设计者。我们正在转向更多的支持和监督角色，方法本身也变成每个团队的原生部分。

为了实现长期的存在，你也应该针对 SDLC 的每个阶段解决如何集成和贡献。起初，我们首先聚焦于设计阶段，这样我们希望能够确保好的 API 设计，并尽可能遵循设计第一法则。然后我们转入开发阶段，通过提供库给开发人员，让他们用于验证服务的实现是否和 API 说明书相吻合。这个方法利用功能测试生成一个报告，该报告明确存在差异的地方。这在识别错误和不向后兼容变更（偷偷实行）时非常有效，而不仅仅是 API 规范。最后，我们更紧密地与部署工具和生产环境相结合，审查正在进行的 API 一致性和安装检查，确保符合最小的成熟度要求。

总的来说，尽管存在一些激烈的组织变革和优先级变化，我们已经成功地保持了势头和发展趋势。就我的经验来看，这些是很多项目正在面临和斗争的问题。

关于采访者

Erik Hogan已经在过去的 20 年间学习如何成为一名出色的产品经理。大部分时间被花费在了理解如何成为一名客户的优胜者以及可信赖的领导者。他获得了很大的成功，成功地将复杂的问题分解成可重用的部件，并精确地为工程人员提供他们需要快速执行的东西。最近，他正在运用简单、讲故事、聚焦于有效的组织改变等方式应用基础产品概念，这是一种非常不同的“产品”。当他询问妻子成功标准的时候，他的妻子还是会感到愤怒。

关于受访者

Deepak Nadig是 Intuit 公司一位杰出的架构师。在加入 Intuit 之前，Deepak 是 PayPal 公司的 API 平台的工程领导，并负责领导和改造 PayPal 的 API，这些 API 被在内部和外部使用，处理 1000 亿美元的支付交易。Deepak 在工程师领导和系统架构领域有超过 16 年的工作经验，特别是类似于 eBay 的高可扩展在线网站，以及类似于 VeriFone 和 HP 的企业软件公司。Deepak 是技术大会的常客，致力于使用技术改造企业。

原文地址： Untangling an API-First Transformation at Scale. Lessons Learnt at PayPal – Part 3