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

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

OpenAP平臺產(chǎn)品簡介

1. OpenAPI平臺的起源

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

互聯(lián)網(wǎng)出現(xiàn)后，開始出現(xià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)委員會制定出一些電子單據(jù)的格式規(guī)范，例如X12標(biāo)準(zhǔn)的采購訂單（850），企業(yè)只需將業(yè)務(wù)單據(jù)以標(biāo)準(zhǔn)格式存儲、傳輸，便可與全球采用EDI技術(shù)的貿(mào)易伙伴高效開展業(yè)務(wù)，企業(yè)間的信息交換進入電子化時代。這個時代開始出現(xiàn)最早期的OpenAPI平臺，例如 中國電子口岸，通過提交申請表，企業(yè)即可對接海關(guān)的EDI接口，向海關(guān)提交電子化的報關(guān)表、通關(guān)申請單、通關(guān)貨物清單等。

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

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

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

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

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

可以直接體驗淘寶開放平臺，對于開放平臺會有直觀的認(rèn)知。

3. OpenAPI平臺的類型

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

4. 本文的適用范圍

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

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

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

1. 產(chǎn)品定位

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

【市面上的競品】順豐開放平臺、菜鳥開放平臺

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

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

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

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

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

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

3. 能力清單

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

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

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

4. 能力地圖

5. 版本規(guī)劃

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

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

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

二、產(chǎn)品運營篇

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

1. 平臺冷啟動

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

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

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

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

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

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

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

3. 平臺常態(tài)化運營和治理

3.1 客戶的對接體驗和效率

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

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

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

• 對接體驗 = 平臺工具使用體驗 + API使用體驗 + 客戶答疑體驗
• 對接周期 = 注冊賬號時長 + API選用時長 + API使用方法學(xué)習(xí)時長 + API調(diào)用代碼開發(fā)時長

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、一些思考

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

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

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

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

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

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

Q4：OpenAPI平臺是一個平臺型產(chǎn)品嗎？平臺交易雙方主體是誰？

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