OpenAPI開放平臺(tái)幾乎是中大型技術(shù)服務(wù)企業(yè)的標(biāo)配，它有著怎樣的亮點(diǎn)？本文將解析Open API開放平臺(tái)的產(chǎn)品設(shè)計(jì)和運(yùn)營(yíng)，分享相關(guān)的企業(yè)治理思考，希望對(duì)你有所幫助。

OpenAPI開放平臺(tái)幾乎是中大型技術(shù)服務(wù)企業(yè)的標(biāo)配，客戶通過OpenAPI將企業(yè)服務(wù)快速集成到自身信息系統(tǒng)中，供應(yīng)商通過OpenAPI向企業(yè)提供服務(wù)，合作伙伴通過OpenAPI與企業(yè)高效協(xié)作。本文將詳盡地闡述Open API開放平臺(tái)的產(chǎn)品設(shè)計(jì)和運(yùn)營(yíng)，并分享對(duì)于OpenAPI相關(guān)的企業(yè)治理問題的一些思考。

OpenAP平臺(tái)產(chǎn)品簡(jiǎn)介

1. OpenAPI平臺(tái)的起源

互聯(lián)網(wǎng)出現(xiàn)前，信息系統(tǒng)是由ISV（Independent Software Vendor）部署在企業(yè)自身的機(jī)房里的，這些系統(tǒng)只能解決企業(yè)內(nèi)部特定辦公任務(wù)場(chǎng)景下的信息管理質(zhì)量和效率問題，例如Office三件套、Oracle財(cái)務(wù)軟件，企業(yè)間的業(yè)務(wù)往來還得靠線下的合同、單據(jù)、票據(jù)，例如通過采購(gòu)合同下采購(gòu)單。

互聯(lián)網(wǎng)出現(xiàn)后，開始出現(xiàn)一些間簡(jiǎn)單的網(wǎng)絡(luò)傳輸協(xié)議，如FTP文件傳輸協(xié)議、HTTP數(shù)據(jù)傳輸協(xié)議，在全球供應(yīng)鏈和貿(mào)易領(lǐng)域中，傳統(tǒng)線下業(yè)務(wù)單據(jù)開始被EDI(Electronic Data Interchange)技術(shù)所取代，標(biāo)準(zhǔn)委員會(huì)制定出一些電子單據(jù)的格式規(guī)范，例如X12標(biāo)準(zhǔn)的采購(gòu)訂單（850），企業(yè)只需將業(yè)務(wù)單據(jù)以標(biāo)準(zhǔn)格式存儲(chǔ)、傳輸，便可與全球采用EDI技術(shù)的貿(mào)易伙伴高效開展業(yè)務(wù)，企業(yè)間的信息交換進(jìn)入電子化時(shí)代。這個(gè)時(shí)代開始出現(xiàn)最早期的OpenAPI平臺(tái)，例如 中國(guó)電子口岸，通過提交申請(qǐng)表，企業(yè)即可對(duì)接海關(guān)的EDI接口，向海關(guān)提交電子化的報(bào)關(guān)表、通關(guān)申請(qǐng)單、通關(guān)貨物清單等。

隨著企業(yè)信息化技術(shù)、互聯(lián)網(wǎng)技術(shù)、網(wǎng)關(guān)技術(shù)的普及，信息存儲(chǔ)、交換的粒度和環(huán)境出現(xiàn)了顛覆性變化，此前企業(yè)間交換信息一般以單據(jù)為粒度，但現(xiàn)在企業(yè)間交換信息可以到細(xì)化到任意粒度，例如零售企業(yè)只將一個(gè)SKU的信息下發(fā)到物流服務(wù)商的倉(cāng)庫(kù)。此前企業(yè)間信息一般存儲(chǔ)到Oracle數(shù)據(jù)庫(kù)中，但現(xiàn)在企業(yè)間信息存儲(chǔ)的方式多種多樣，并且單位信息的存儲(chǔ)成本近乎無限低。因此逐漸發(fā)展出基于互聯(lián)網(wǎng)HTTP協(xié)議的信息交換技術(shù)，簡(jiǎn)稱API接口。相比于EDI技術(shù)，API接口的功能和信息格式可以按需自由定義，沒有任何約束，企業(yè)間交換信息更加自由。

如何定义B端产品及B端产品经理方法论

相较于C端产品，B端产品最大的特点是：面向特定领域用户，且数量少得多，但更注重对用户专业领域操作流程的深度挖掘——也就是专业性更强，与业务的结合更紧密。

查看详情 >

隨著云計(jì)算技術(shù)、SaaS服務(wù)技術(shù)的發(fā)展，市面上逐漸出現(xiàn)一批以撮合交易為主營(yíng)業(yè)務(wù)的特大型的平臺(tái)型企業(yè)（例如京東購(gòu)物平臺(tái)），上下游以這些企業(yè)為中心開展商業(yè)活動(dòng)，這些企業(yè)為了提升自身與上下游企業(yè)的信息交換效率，制定了一些標(biāo)準(zhǔn)的安全規(guī)范，針對(duì)業(yè)務(wù)定義了一些標(biāo)準(zhǔn)功能的API（如庫(kù)存同步、訂單拉取、軌跡回傳等），并將這些API文檔和安全規(guī)范公開展示出來，由此形成了目前市場(chǎng)上的OpenAPI開放平臺(tái)，例如京東JOS開放平臺(tái)。

2. OpenAPI平臺(tái)的核心業(yè)務(wù)流程

OpenAPI開放平臺(tái)也是典型的平臺(tái)型產(chǎn)品，平臺(tái)的業(yè)務(wù)流程是圍繞API的供給和消費(fèi)來進(jìn)行的：

• 供給方：設(shè)計(jì)并開發(fā)API→編寫配套使用文檔→發(fā)布API到平臺(tái)→API運(yùn)維答疑
• 消費(fèi)方：查找特定功能的API→申請(qǐng)API使用權(quán)限→使用API→問題咨詢→API運(yùn)行監(jiān)控
• 平臺(tái)方：審核API發(fā)布→審核API使用資質(zhì)→排查API運(yùn)行問題→迭代優(yōu)化API

可以直接體驗(yàn)淘寶開放平臺(tái)，對(duì)于開放平臺(tái)會(huì)有直觀的認(rèn)知。

3. OpenAPI平臺(tái)的類型

不同行業(yè)、類型的企業(yè)對(duì)于OpenAPI平臺(tái)的訴求不一致，主要分為以下幾種：

4. 本文的適用范圍

本文是針對(duì)大型企業(yè)建設(shè)「業(yè)務(wù)渠道」類的OpenAPI平臺(tái)而寫的，其中大部分方法同樣也適用于其他類型的OpenAPI平臺(tái)的建設(shè)。大型企業(yè)建設(shè)OpenAPI平臺(tái)時(shí)的工作除了建設(shè)標(biāo)準(zhǔn)技術(shù)對(duì)接模式和標(biāo)準(zhǔn)API等基礎(chǔ)產(chǎn)品能力外，還需要面臨一系列由于客制化工作帶來的產(chǎn)品和運(yùn)營(yíng)上的挑戰(zhàn)，例如KA客戶指定使用的技術(shù)模式與平臺(tái)標(biāo)準(zhǔn)不一致、大型項(xiàng)目里需要多個(gè)研發(fā)團(tuán)隊(duì)協(xié)作完成系統(tǒng)開發(fā)和對(duì)接，另外還要解決 API治理、服務(wù)機(jī)制建設(shè)等等難題。

一、產(chǎn)品設(shè)計(jì)

具體的產(chǎn)品設(shè)計(jì)方法論可以看如何做好B端產(chǎn)品規(guī)劃？這“一攬子工具”幫到你，本文介紹的是業(yè)務(wù)渠道型的OpenAPI平臺(tái)的建設(shè)，因此后文所有產(chǎn)品設(shè)計(jì)和運(yùn)營(yíng)也都圍繞這類OpenAPI平臺(tái)來展開。

1. 產(chǎn)品定位

【為誰(shuí)解決什么問題】業(yè)務(wù)渠道型的OpenAPI平臺(tái)為企業(yè)系統(tǒng)實(shí)施人員解決客戶導(dǎo)入過程中的的**系統(tǒng)對(duì)接效率**問題。在缺少OpenAPI平臺(tái)時(shí)，系統(tǒng)實(shí)施人員把每個(gè)客戶的導(dǎo)入當(dāng)做一個(gè)項(xiàng)目來做，拉著雙方的產(chǎn)研同學(xué)溝通對(duì)接方案，典型的工作流是 方案溝通→開發(fā)→測(cè)試聯(lián)調(diào)→上線。在擁有OpenAPI平臺(tái)后，企業(yè)內(nèi)部的標(biāo)準(zhǔn)API能力建設(shè)過程與客戶導(dǎo)入過程相分離，產(chǎn)研將標(biāo)準(zhǔn)API發(fā)布在平臺(tái)上，編寫配套文檔，客戶可通過平臺(tái)實(shí)現(xiàn)自助化的對(duì)接，大大提升系統(tǒng)對(duì)接效率。

【市面上的競(jìng)品】順豐開放平臺(tái)、菜鳥開放平臺(tái)

【用戶角色、核心用戶任務(wù)、關(guān)鍵產(chǎn)品能力】

2. 架構(gòu)設(shè)計(jì)

OpenAPI平臺(tái)在產(chǎn)品架構(gòu)上與一般的平臺(tái)型產(chǎn)品沒有區(qū)別，就是三個(gè)端：

1. 公網(wǎng)客戶端（消費(fèi)者）：給客戶做業(yè)務(wù)接入使用的端，相當(dāng)于淘寶APP。特別的，客戶端由分為前臺(tái)和控制臺(tái)兩個(gè)部分，前臺(tái)用以展示API和文檔信息，后臺(tái)用以做應(yīng)用創(chuàng)建、資質(zhì)認(rèn)證等實(shí)際的操作。
2. 內(nèi)網(wǎng)管理端（生產(chǎn)者）：給業(yè)務(wù)線產(chǎn)研發(fā)布API的端，相當(dāng)于淘寶商家后臺(tái)。特別的，管理端由分為前臺(tái)和控制臺(tái)兩個(gè)部分，前臺(tái)用以展示平臺(tái)規(guī)范、使用手冊(cè)等信息，后臺(tái)用以做API發(fā)布、運(yùn)維監(jiān)控等實(shí)際的操作。
3. 內(nèi)網(wǎng)運(yùn)營(yíng)端（平臺(tái)運(yùn)營(yíng)）：給平臺(tái)運(yùn)營(yíng)同學(xué)做平臺(tái)內(nèi)容管理、信息審核、運(yùn)營(yíng)監(jiān)控的端，相當(dāng)于淘小二工作臺(tái)。

以上三個(gè)端都是具有人機(jī)交互界面的端，這三個(gè)端為用戶的接入體驗(yàn)和效率負(fù)責(zé)，實(shí)際上還有一大塊能力不易被感知，那就是API網(wǎng)關(guān)能力。API網(wǎng)關(guān)對(duì)API運(yùn)行的安全和穩(wěn)定負(fù)責(zé)，是雙方系統(tǒng)數(shù)據(jù)交互的最最基礎(chǔ)的保障。在一次次的API調(diào)用過程中，API網(wǎng)關(guān)負(fù)責(zé)識(shí)別用戶身份、加解密數(shù)據(jù)、攔截異常流量，從而保障內(nèi)部系統(tǒng)的安全，為客戶提供性能穩(wěn)定的API服務(wù)。API網(wǎng)關(guān)的建設(shè)由于技術(shù)性強(qiáng)一般由研發(fā)主導(dǎo)，而三端的建設(shè)則由產(chǎn)品主導(dǎo)。最簡(jiǎn)版的API網(wǎng)關(guān)可以只建設(shè)「API元數(shù)據(jù)、應(yīng)用AppKey管理、標(biāo)準(zhǔn)簽名、OAuth2.0鑒權(quán)能力，隨著平臺(tái)用戶量的增加和治理工作的開展，需要提供更多樣的安全策略供用戶選擇、健全基本的網(wǎng)關(guān)安全能力，保障雙方系統(tǒng)安全。

可以在1.1的「用戶角色→核心任務(wù)→關(guān)鍵產(chǎn)品能力」的基礎(chǔ)上，采用文章從需求到功能，B端產(chǎn)品設(shè)計(jì)四步法中的方法歸納總結(jié)得出每個(gè)端的核心功能以及三端共用的底層能力，最終得出以下架構(gòu)圖：

3. 能力清單

建議閱讀從需求到功能，B端產(chǎn)品設(shè)計(jì)四步法，基本原理就是：

1. 拆需求：一個(gè)最小的子需求，應(yīng)有3個(gè)要素組成，XX用戶在XX場(chǎng)景下的XX需求；
2. 拆事件：一個(gè)需求的結(jié)果 = 事件1+事件2+事件3+……，其中，事件X=用戶XX通過XX做XX；
3. 事件模塊化聚合：用戶通過XX做，這里面通過“XX”這個(gè)對(duì)象，就是產(chǎn)品的功能；這個(gè)步驟的主要作用，就是將離散的功能點(diǎn)所需要的承載體，聚類聚合；

通過這個(gè)方法，再根據(jù)1.1的用戶角色→核心任務(wù)→關(guān)鍵產(chǎn)品能力得出能力清單，在此不再貼錄能力清單。

4. 能力地圖

5. 版本規(guī)劃

MVP版本包括的功能集實(shí)際非常簡(jiǎn)單，只要保障「API發(fā)布→API展示→API使用」的主鏈路能通即可，其余API文檔、日志等功能都可以有替代方案，例如通過線下文檔替代在線文檔、通過微信答疑代替工單能力。但研發(fā)側(cè)還是要直接按產(chǎn)品側(cè)的架構(gòu)來搭建系統(tǒng)，一步到位，這樣才能在不變更系統(tǒng)架構(gòu)的情況下快速迭代增加功能。建議按以下進(jìn)行最初幾個(gè)版本的迭代：

1. 版本1：按產(chǎn)品架構(gòu)設(shè)計(jì)，搭建系統(tǒng)框架，在各端上完整展示菜單，菜單點(diǎn)擊后均顯示同一個(gè)頁(yè)面，頁(yè)面提示“功能正在建設(shè)中”，最終的產(chǎn)品效果相當(dāng)于一個(gè)空殼系統(tǒng)。
2. 版本2：MVP，研發(fā)將核心功能邏輯的架構(gòu)設(shè)計(jì)好，并實(shí)現(xiàn)核心功能的最簡(jiǎn)版，相關(guān)核心功能有「產(chǎn)研發(fā)布API→公網(wǎng)客戶端展示API→客戶申請(qǐng)資質(zhì)認(rèn)證→平臺(tái)運(yùn)營(yíng)審批資質(zhì)→客戶申請(qǐng)API使用權(quán)限→平臺(tái)運(yùn)營(yíng)審批API使用申請(qǐng)→API調(diào)用時(shí)簽名校驗(yàn)」，以「發(fā)布API」功能為例，最簡(jiǎn)版可以做成表單填寫，填寫完成即發(fā)布完成，先不建設(shè)API狀態(tài)機(jī)、API文檔編寫這些復(fù)雜的功能。這個(gè)版本上線后，就可以提供給產(chǎn)研和客戶使用。
3. 版本3：建設(shè)對(duì)接周期統(tǒng)計(jì)能力和體驗(yàn)評(píng)價(jià)能力，以體驗(yàn)和效率為導(dǎo)向建設(shè)平臺(tái)。建設(shè)完整的文檔編寫和展示能力，在過去的運(yùn)營(yíng)經(jīng)驗(yàn)中，最大成本源自于線下文檔的版本變更，每個(gè)人手里拿到的文檔版本不一致，導(dǎo)致各種返工。并且專門的API文檔能力能大大提升客戶學(xué)習(xí)使用API的效率。
4. 版本4：圍繞客戶的接入效率，建設(shè)完整的API導(dǎo)航、API調(diào)試工具、日志工具等能力。
5. 版本5：圍繞客戶的接入體驗(yàn)，進(jìn)一步優(yōu)化各類工具的使用體驗(yàn)。

本章節(jié)只講解產(chǎn)品功能建設(shè)上的版本規(guī)劃，實(shí)際上各個(gè)版本還要配套運(yùn)營(yíng)動(dòng)作，才能使平臺(tái)最終變得可用、好用。關(guān)于平臺(tái)的運(yùn)營(yíng)請(qǐng)看第二章。

二、產(chǎn)品運(yùn)營(yíng)篇

典型的平臺(tái)型產(chǎn)品 = 平臺(tái)交易工具 + 配套平臺(tái)流程規(guī)范 + 平臺(tái)運(yùn)營(yíng)治理，第一章已經(jīng)講解平臺(tái)交易工具的建設(shè)，本章節(jié)著重講解平臺(tái)流程規(guī)范的建設(shè)和日常運(yùn)營(yíng)治理。

1. 平臺(tái)冷啟動(dòng)

當(dāng)產(chǎn)品MVP版本建設(shè)好后，理論上可以投產(chǎn)使用，但由于功能非常簡(jiǎn)陋、不健全，實(shí)際是無法交付給運(yùn)營(yíng)的。此時(shí)，產(chǎn)品需要完成冷啟動(dòng)工作：

1. 編寫客戶端、管理端的使用手冊(cè)（線下版）；
2. 尋找合作部門，講解平臺(tái)的建設(shè)目標(biāo)、使用方法，與他們?cè)跇I(yè)務(wù)維度共建一套完整的API；
3. 尋找試點(diǎn)客戶，引導(dǎo)客戶使用這些API，并解答客戶疑問，根據(jù)客戶問題不斷優(yōu)化文檔；
4. 做好數(shù)據(jù)采集，平臺(tái)的核心運(yùn)營(yíng)指標(biāo)是客戶對(duì)接的體驗(yàn)和效率，未來平臺(tái)的持續(xù)建設(shè)也是圍繞這兩個(gè)指標(biāo)進(jìn)行的，因此在平臺(tái)上線運(yùn)營(yíng)之初就應(yīng)該具備這兩個(gè)指標(biāo)的采集能力，具體的指標(biāo)運(yùn)營(yíng)可以看章節(jié)2.3；

在冷啟動(dòng)過程中，實(shí)際產(chǎn)品承擔(dān)了運(yùn)營(yíng)和技術(shù)支持的職能，這樣產(chǎn)品可以深入一線了解客戶關(guān)心的問題、深入理解好的使用手冊(cè)應(yīng)該包含的內(nèi)容，為后期平臺(tái)的體驗(yàn)優(yōu)化、規(guī)范制定提供實(shí)戰(zhàn)經(jīng)驗(yàn)。通常平臺(tái)冷啟動(dòng)需要持續(xù)3個(gè)月時(shí)間，這期間平臺(tái)功能、平臺(tái)上的API、配套手冊(cè)均已經(jīng)過多次迭代，客戶根據(jù)手冊(cè)基本能自助完成對(duì)接。

當(dāng)平臺(tái)功能流程相對(duì)完整、穩(wěn)定后，就可以將平臺(tái)的答疑工作交付給技術(shù)支持團(tuán)隊(duì)，產(chǎn)品可以抽身出來擴(kuò)大平臺(tái)的服務(wù)范圍，從服務(wù)一個(gè)業(yè)務(wù)線擴(kuò)展到多個(gè)業(yè)務(wù)線。為了將這個(gè)業(yè)務(wù)線的最佳實(shí)踐快速?gòu)?fù)制到多個(gè)條線，一定需要將一些做法標(biāo)準(zhǔn)化，這就涉及到平臺(tái)流程規(guī)范的建設(shè)。

2. 平臺(tái)流程規(guī)范的建設(shè)

流程規(guī)范一方面是成功經(jīng)驗(yàn)的萃取，一方面是提升平臺(tái)相關(guān)角色在各種各樣場(chǎng)景下的協(xié)作效率，筆者根據(jù)業(yè)務(wù)流程階段，將平臺(tái)流程規(guī)范分為五大部分：

這些流程規(guī)范需要經(jīng)過各部門主要負(fù)責(zé)人、架構(gòu)師評(píng)審后，才能得到落地，否則內(nèi)部產(chǎn)研會(huì)挑戰(zhàn)平臺(tái)側(cè)制定的標(biāo)準(zhǔn)，特別是有些標(biāo)準(zhǔn)比較苛刻。當(dāng)平臺(tái)側(cè)推動(dòng)各方按流程規(guī)范來解決日常問題，基本驗(yàn)證流程規(guī)范的可落地性和合理性之后（事實(shí)上中間要經(jīng)過多次修訂），就可以考慮將流程固化為平臺(tái)的功能流程，將規(guī)范固化為平臺(tái)的校驗(yàn)項(xiàng)，使得平臺(tái)用戶自然而然就會(huì)遵守流程規(guī)范。

3. 平臺(tái)常態(tài)化運(yùn)營(yíng)和治理

3.1 客戶的對(duì)接體驗(yàn)和效率

OpenAPI開放平臺(tái)的北極星指標(biāo)的客戶對(duì)接體驗(yàn)和對(duì)接周期。在產(chǎn)品的MVP版本，就應(yīng)該建設(shè)這兩個(gè)指標(biāo)的統(tǒng)計(jì)能力，這兩個(gè)指標(biāo)的統(tǒng)計(jì)口徑可以因具體的業(yè)務(wù)而異，一種可供參考的指標(biāo)口徑是：

• 對(duì)接體驗(yàn)：客戶開發(fā)完畢后，需要進(jìn)行對(duì)接體驗(yàn)評(píng)分，評(píng)分后才可上線應(yīng)用。以這個(gè)環(huán)節(jié)用戶評(píng)分的平均分為最終得分。
• 對(duì)接周期：每個(gè)客戶的對(duì)接周期 = 客戶產(chǎn)生第一筆訂單的時(shí)間 – 客戶注冊(cè)賬號(hào)的時(shí)間，最終以所有客戶對(duì)接周期的平均數(shù)作為平臺(tái)的對(duì)接周期。

實(shí)際上，平臺(tái)運(yùn)營(yíng)過程中不可能只看這兩個(gè)指標(biāo)的最終數(shù)值，而是要找到影響這兩個(gè)指標(biāo)的因素，逐個(gè)環(huán)節(jié)做優(yōu)化，一種可能的拆解如下：

• 對(duì)接體驗(yàn) = 平臺(tái)工具使用體驗(yàn) + API使用體驗(yàn) + 客戶答疑體驗(yàn)
• 對(duì)接周期 = 注冊(cè)賬號(hào)時(shí)長(zhǎng) + API選用時(shí)長(zhǎng) + API使用方法學(xué)習(xí)時(shí)長(zhǎng) + API調(diào)用代碼開發(fā)時(shí)長(zhǎng)

如此圍繞北極星指標(biāo)，就有大量的治理工作要做：

• 平臺(tái)工單治理：針對(duì)工單中高頻出現(xiàn)的問題，要么通過平臺(tái)優(yōu)化徹底消滅問題，要么通過工具流程的優(yōu)化縮短問題解決的時(shí)長(zhǎng)，最終應(yīng)該達(dá)到降低平均每個(gè)客戶提交的工單數(shù)量的效果。
• 平臺(tái)文檔治理：為客戶提供文檔評(píng)價(jià)功能，針對(duì)客戶反饋的平臺(tái)不詳細(xì)的問題，定期給文檔編寫人發(fā)文檔優(yōu)化工單，持續(xù)提升文檔質(zhì)量。
• 平臺(tái)API治理：對(duì)標(biāo)行業(yè)，持續(xù)優(yōu)化API分類、API名稱，避免出現(xiàn)同樣功能的API，優(yōu)化檢索排名邏輯，最終提升客戶查找API的效率；針對(duì)高頻出現(xiàn)未知問題的API、字段含義難以理解反復(fù)被咨詢的API，推動(dòng)API的重塑，用新的API替換舊API，最終提升客戶使用API的效率。

3.2 系統(tǒng)的安全和穩(wěn)定

事實(shí)上，除了在客戶導(dǎo)入環(huán)節(jié)進(jìn)行提效外，客戶業(yè)務(wù)開展過程中，為客戶提供持續(xù)穩(wěn)定的系統(tǒng)服務(wù)也非常重要?？蛻粲唵螣o法下發(fā)、接收不到訂單信息回傳將會(huì)給客戶直接帶來經(jīng)濟(jì)損失，特別的，一些企業(yè)對(duì)于API的時(shí)延也非常敏感，過高的時(shí)延將直接讓客戶感覺到系統(tǒng)卡頓，影響系統(tǒng)操作體驗(yàn)。因此，平臺(tái)需要在兩個(gè)層面持續(xù)做好監(jiān)控，及時(shí)發(fā)出告警：

• 客戶系統(tǒng)和內(nèi)部業(yè)務(wù)系統(tǒng)的連通性：客戶的網(wǎng)絡(luò)配置變更或者內(nèi)部系統(tǒng)部署問題，都會(huì)導(dǎo)致數(shù)據(jù)傳輸通道中斷；
• API在業(yè)務(wù)層面的可用性：有些情況下，內(nèi)部系統(tǒng)上線出現(xiàn)故障，會(huì)導(dǎo)致特定客戶群體的服務(wù)受到影響，而內(nèi)部系統(tǒng)自身卻感知不到，因?yàn)檫@部分客戶群里的單量占總單量比例太小了；

一種可能的監(jiān)控告警方案是：

• 針對(duì)客戶系統(tǒng)，如果系統(tǒng)多次重連都無法連接上客戶系統(tǒng)，則直接向客戶的研發(fā)、銷售支持團(tuán)隊(duì)、技術(shù)支持團(tuán)隊(duì)發(fā)送告警。
• 針對(duì)內(nèi)部系統(tǒng)，在平臺(tái)上發(fā)布API后，自動(dòng)為API創(chuàng)建一個(gè)監(jiān)控看板，看板中包括TP99、可用率；當(dāng)發(fā)生業(yè)務(wù)系統(tǒng)不可聯(lián)通或在業(yè)務(wù)層面上不可用時(shí)，影響這個(gè)API的可用率；業(yè)務(wù)系統(tǒng)的研發(fā)可以在平臺(tái)上配置這個(gè)API對(duì)應(yīng)的告警規(guī)則，在可用率下降到下限或TP99超過上限時(shí)，系統(tǒng)向API的產(chǎn)品、研發(fā)負(fù)責(zé)人發(fā)出告警。

這里特別要注意的一點(diǎn)是，盡量將平臺(tái)的監(jiān)控告警和研發(fā)日常系統(tǒng)監(jiān)控告警集成到同一平臺(tái)，這樣研發(fā)會(huì)更愿意配置告警、關(guān)注告警。另一方面，一旦告警發(fā)出，需要有恰當(dāng)?shù)牧鞒虣C(jī)制來解決問題，通常需要平臺(tái)與IT運(yùn)維質(zhì)量團(tuán)隊(duì)共同商議流程機(jī)制，保障流程機(jī)制能落地；一旦告警轉(zhuǎn)換問客戶提交的故障單，還會(huì)涉及扣減研發(fā)團(tuán)隊(duì)質(zhì)量分，影響研發(fā)團(tuán)隊(duì)績(jī)效。

除了系統(tǒng)穩(wěn)定性，系統(tǒng)安全性也非常重要，業(yè)務(wù)越權(quán)或數(shù)據(jù)泄露也會(huì)對(duì)公司運(yùn)營(yíng)造成重大影響。通過三方面措施來防止此類情況發(fā)生：

1. 三層鑒權(quán)：API使用鑒權(quán)、平臺(tái)的OAuth鑒權(quán)、系統(tǒng)的業(yè)務(wù)鑒權(quán)。API使用鑒權(quán)主要是客戶系統(tǒng)調(diào)用某個(gè)API時(shí)，API網(wǎng)關(guān)識(shí)別客戶系統(tǒng)是否有調(diào)用這個(gè)API的權(quán)限。OAuth鑒權(quán)主要是API網(wǎng)關(guān)識(shí)別當(dāng)前appKey是否能獲取某個(gè)賬號(hào)內(nèi)的數(shù)據(jù)。業(yè)務(wù)鑒權(quán)主要是識(shí)別這個(gè)賬號(hào)能獲取哪些業(yè)務(wù)數(shù)據(jù)，例如在電商平臺(tái)場(chǎng)景下，賬號(hào)通常與店鋪綁定，業(yè)務(wù)系統(tǒng)需要識(shí)別此次請(qǐng)求的數(shù)據(jù)所屬的店鋪與賬號(hào)所屬店鋪是否一致。API使用鑒權(quán)、平臺(tái)的OAuth鑒權(quán)由平臺(tái)功能來保障，系統(tǒng)的業(yè)務(wù)鑒權(quán)則是在每個(gè)接口發(fā)布上線前，強(qiáng)制評(píng)審接口對(duì)應(yīng)的代碼，檢查是否有對(duì)應(yīng)的業(yè)務(wù)鑒權(quán)。
2. 安全測(cè)試：邀請(qǐng)安全部對(duì)于平臺(tái)上的接口進(jìn)行攻擊測(cè)試，如果發(fā)現(xiàn)漏洞，則發(fā)送安全工單，要求責(zé)任團(tuán)隊(duì)限期整改。
3. 異常識(shí)別：當(dāng)系統(tǒng)識(shí)別到某個(gè)客戶系統(tǒng)的調(diào)用量成倍增加時(shí)，應(yīng)該向平臺(tái)運(yùn)營(yíng)發(fā)出告警，人工排查該客戶系統(tǒng)是否存在攻擊行為，如果確實(shí)存在攻擊，則應(yīng)進(jìn)行系統(tǒng)限流，然后與客戶溝通整改。

3.3 流程規(guī)范的持續(xù)建設(shè)

平臺(tái)在「0-1大規(guī)模能力建設(shè) + 平臺(tái)專項(xiàng)治理」這兩個(gè)階段，實(shí)際會(huì)投入大量人力，在平臺(tái)功能和業(yè)務(wù)穩(wěn)定后，必然會(huì)面臨成本問題，能否以一個(gè)比較低的成本來持續(xù)運(yùn)營(yíng)平臺(tái)？經(jīng)過筆者的實(shí)踐驗(yàn)證，是可以做到的。平臺(tái)的運(yùn)營(yíng)成本來自于三方面：

1. 內(nèi)部員工的教育成本：為了保障平臺(tái)的高效易用，產(chǎn)研需要按照一定標(biāo)準(zhǔn)建設(shè)、維護(hù)API，平臺(tái)需要按照規(guī)范審核這些API和配套文檔，同時(shí)一線的銷售、系統(tǒng)實(shí)施需要學(xué)習(xí)使用平臺(tái)，這樣他們才能更好的服務(wù)客戶。企業(yè)人員更替頻繁，平臺(tái)需要不斷給新的同事講解平臺(tái)標(biāo)準(zhǔn)和使用方法，帶來了不小的運(yùn)營(yíng)成本。筆者的經(jīng)驗(yàn)是，制作一個(gè)內(nèi)部的門戶網(wǎng)站，展示平臺(tái)期望的各個(gè)用戶角色需要完成的關(guān)鍵任務(wù)，并總結(jié)精良的使用手冊(cè)和實(shí)踐案例，配以培訓(xùn)視頻；將平臺(tái)的流程規(guī)范全部固化到系統(tǒng)，讓系統(tǒng)校驗(yàn)代替人工審核，大幅減少審核工作。
2. 外部客戶的服務(wù)成本：一方面，客戶的各類問題層出不窮，但實(shí)際絕大部分不是平臺(tái)工具的問題，而是API的問題，這些問題應(yīng)該思考如果通過技術(shù)支持團(tuán)隊(duì)分流到對(duì)應(yīng)的產(chǎn)研團(tuán)隊(duì)；另外一方面，有些客戶的研發(fā)水平比較低，平臺(tái)制作了一部分Demo供客戶參考，客戶照葫蘆畫瓢，平臺(tái)無需再向客戶解釋各類技術(shù)名詞概念。
3. 平臺(tái)的穩(wěn)定性治理：為了保障平臺(tái)技術(shù)服務(wù)的安全穩(wěn)定，需要投入一定的研發(fā)人力做定期巡檢，一種比較好的方式是形成一個(gè)定期OpsReview的文檔模版，將文檔中需要的數(shù)據(jù)看板全部線上化，把巡檢的模式固定下來，這樣每次巡檢的成本大概可以控制在兩三個(gè)小時(shí)。

實(shí)際上，所有成本的降低都指向了流程規(guī)范的持續(xù)建設(shè)，當(dāng)問題發(fā)生時(shí)知道怎么處理，日常工作事項(xiàng)可以模板化，不需要花太多精力。

三、一些思考

Q1：開放平臺(tái)和平臺(tái)上的API是由一個(gè)部門來建設(shè)比較好，還是分開比較好？

A1：取決于平臺(tái)承載的業(yè)務(wù)范圍的大小。一方面，為了服務(wù)好客戶，API開發(fā)部門通常需要掌握OpenAPI相關(guān)的設(shè)計(jì)標(biāo)準(zhǔn)、運(yùn)營(yíng)運(yùn)維工作、客戶服務(wù)流程，如果API開發(fā)部門和開放平臺(tái)是兩個(gè)獨(dú)立的部門，那勢(shì)必會(huì)帶來溝通和培訓(xùn)成本。另一方面，一個(gè)團(tuán)隊(duì)的知識(shí)領(lǐng)域是有限的，如果平臺(tái)承載的業(yè)務(wù)多種多樣，那幾乎不可能由一個(gè)團(tuán)隊(duì)來完成所有業(yè)務(wù)的API的設(shè)計(jì)。因此，企業(yè)業(yè)務(wù)相對(duì)單一時(shí)，API和平臺(tái)應(yīng)該由同一個(gè)部門來建設(shè)；企業(yè)業(yè)務(wù)多種多樣時(shí)，勢(shì)必會(huì)出現(xiàn)多個(gè)API建設(shè)部門和獨(dú)立的平臺(tái)建設(shè)部門。

Q2：作為一個(gè)大企業(yè)，是所有業(yè)務(wù)共用一個(gè)OpenAPI平臺(tái)好，還是每個(gè)業(yè)務(wù)各自建一個(gè)開放平臺(tái)好？

A2：需要從兩個(gè)維度來考慮這個(gè)問題，一是各業(yè)務(wù)的屬性的相似度，業(yè)務(wù)屬性差異比較大的業(yè)務(wù)就不適合共用OpenAPI平臺(tái)，例如阿里的云計(jì)算業(yè)務(wù)和電商業(yè)務(wù)顯然不適合共用一套開放平臺(tái)，因?yàn)槎叩臉I(yè)務(wù)流程完全不同；二是組織架構(gòu)的設(shè)定，為了服務(wù)好客戶，平臺(tái)需要組織各業(yè)務(wù)線的系統(tǒng)實(shí)施、業(yè)務(wù)運(yùn)營(yíng)、產(chǎn)品研發(fā)、技術(shù)支持等部門共同服務(wù)客戶，平臺(tái)能承載的業(yè)務(wù)服務(wù)范圍，取決于平臺(tái)能統(tǒng)籌的業(yè)務(wù)部門范圍，例如京東零售的JOS平臺(tái)無法統(tǒng)籌京東科技相關(guān)部門，因此二者的開放平臺(tái)最好分開建。

Q3：如果一項(xiàng)數(shù)據(jù)涉及客戶隱私，容易帶來數(shù)據(jù)安全問題，但業(yè)務(wù)側(cè)期望開放此類數(shù)據(jù)供商家做經(jīng)營(yíng)，如何選擇？

A3：企業(yè)的合規(guī)安全運(yùn)營(yíng)是數(shù)據(jù)開放的底線，如果數(shù)據(jù)泄露不會(huì)給企業(yè)經(jīng)營(yíng)運(yùn)營(yíng)帶來根本性的損害，并且法律并未命令禁止對(duì)外提供此類數(shù)據(jù)，那么就應(yīng)該開放此類數(shù)據(jù)以支持業(yè)務(wù)發(fā)展，并對(duì)數(shù)據(jù)使用方做好監(jiān)管，限制數(shù)據(jù)使用量。

Q4：OpenAPI平臺(tái)是一個(gè)平臺(tái)型產(chǎn)品嗎？平臺(tái)交易雙方主體是誰(shuí)？

A4：雖然叫OpenAPI平臺(tái)，但嚴(yán)格意義上說，OpenAPI平臺(tái)的工具屬性大于平臺(tái)屬性。如果說平臺(tái)上的商品是API的話，平臺(tái)側(cè)的工作非是提升客戶需求和業(yè)務(wù)線API之間匹配的效率。實(shí)際上客戶需要的API直接由客戶要對(duì)接的業(yè)務(wù)線決定，平臺(tái)的工作是將客戶的需求傳遞給業(yè)務(wù)線，并督促業(yè)務(wù)線按照一定的標(biāo)準(zhǔn)向客戶交付API。因此平臺(tái)是提供了一個(gè)組織多個(gè)角色共同服務(wù)客戶的協(xié)作工具，核心價(jià)值是提升客戶消費(fèi)API過程中的體驗(yàn)和效率。OpenAPI平臺(tái)的平臺(tái)屬性體現(xiàn)在兩方面，一是通過平臺(tái)將API的供需雙方連接起來，二是平臺(tái)其承擔(dān)了雙方對(duì)接過程中規(guī)范制定和監(jiān)督執(zhí)行的職能。