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

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

OpenAP平臺產品簡介

1. OpenAPI平臺的起源

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

互聯網出現后，開始出現一些間簡單的網絡傳輸協議，如FTP文件傳輸協議、HTTP數據傳輸協議，在全球供應鏈和貿易領域中，傳統線下業務單據開始被EDI(Electronic Data Interchange)技術所取代，標準委員會制定出一些電子單據的格式規范，例如X12標準的采購訂單（850），企業只需將業務單據以標準格式存儲、傳輸，便可與全球采用EDI技術的貿易伙伴高效開展業務，企業間的信息交換進入電子化時代。這個時代開始出現最早期的OpenAPI平臺，例如 中國電子口岸，通過提交申請表，企業即可對接海關的EDI接口，向海關提交電子化的報關表、通關申請單、通關貨物清單等。

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

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

2. OpenAPI平臺的核心業務流程

OpenAPI開放平臺也是典型的平臺型產品，平臺的業務流程是圍繞API的供給和消費來進行的：

• 供給方：設計并開發API→編寫配套使用文檔→發布API到平臺→API運維答疑
• 消費方：查找特定功能的API→申請API使用權限→使用API→問題咨詢→API運行監控
• 平臺方：審核API發布→審核API使用資質→排查API運行問題→迭代優化API

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

3. OpenAPI平臺的類型

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

4. 本文的適用范圍

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

一、產品設計

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

1. 產品定位

【為誰解決什么問題】業務渠道型的OpenAPI平臺為企業系統實施人員解決客戶導入過程中的的**系統對接效率**問題。在缺少OpenAPI平臺時，系統實施人員把每個客戶的導入當做一個項目來做，拉著雙方的產研同學溝通對接方案，典型的工作流是 方案溝通→開發→測試聯調→上線。在擁有OpenAPI平臺后，企業內部的標準API能力建設過程與客戶導入過程相分離，產研將標準API發布在平臺上，編寫配套文檔，客戶可通過平臺實現自助化的對接，大大提升系統對接效率。

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

【用戶角色、核心用戶任務、關鍵產品能力】

2. 架構設計

OpenAPI平臺在產品架構上與一般的平臺型產品沒有區別，就是三個端：

1. 公網客戶端（消費者）：給客戶做業務接入使用的端，相當于淘寶APP。特別的，客戶端由分為前臺和控制臺兩個部分，前臺用以展示API和文檔信息，后臺用以做應用創建、資質認證等實際的操作。
2. 內網管理端（生產者）：給業務線產研發布API的端，相當于淘寶商家后臺。特別的，管理端由分為前臺和控制臺兩個部分，前臺用以展示平臺規范、使用手冊等信息，后臺用以做API發布、運維監控等實際的操作。
3. 內網運營端（平臺運營）：給平臺運營同學做平臺內容管理、信息審核、運營監控的端，相當于淘小二工作臺。

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

可以在1.1的「用戶角色→核心任務→關鍵產品能力」的基礎上，采用文章從需求到功能，B端產品設計四步法中的方法歸納總結得出每個端的核心功能以及三端共用的底層能力，最終得出以下架構圖：

3. 能力清單

建議閱讀從需求到功能，B端產品設計四步法，基本原理就是：

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

通過這個方法，再根據1.1的用戶角色→核心任務→關鍵產品能力得出能力清單，在此不再貼錄能力清單。

4. 能力地圖

5. 版本規劃

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

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

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

二、產品運營篇

典型的平臺型產品 = 平臺交易工具 + 配套平臺流程規范 + 平臺運營治理，第一章已經講解平臺交易工具的建設，本章節著重講解平臺流程規范的建設和日常運營治理。

1. 平臺冷啟動

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

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

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

當平臺功能流程相對完整、穩定后，就可以將平臺的答疑工作交付給技術支持團隊，產品可以抽身出來擴大平臺的服務范圍，從服務一個業務線擴展到多個業務線。為了將這個業務線的最佳實踐快速復制到多個條線，一定需要將一些做法標準化，這就涉及到平臺流程規范的建設。

2. 平臺流程規范的建設

流程規范一方面是成功經驗的萃取，一方面是提升平臺相關角色在各種各樣場景下的協作效率，筆者根據業務流程階段，將平臺流程規范分為五大部分：

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

3. 平臺常態化運營和治理

3.1 客戶的對接體驗和效率

OpenAPI開放平臺的北極星指標的客戶對接體驗和對接周期。在產品的MVP版本，就應該建設這兩個指標的統計能力，這兩個指標的統計口徑可以因具體的業務而異，一種可供參考的指標口徑是：

• 對接體驗：客戶開發完畢后，需要進行對接體驗評分，評分后才可上線應用。以這個環節用戶評分的平均分為最終得分。
• 對接周期：每個客戶的對接周期 = 客戶產生第一筆訂單的時間 – 客戶注冊賬號的時間，最終以所有客戶對接周期的平均數作為平臺的對接周期。

實際上，平臺運營過程中不可能只看這兩個指標的最終數值，而是要找到影響這兩個指標的因素，逐個環節做優化，一種可能的拆解如下：

• 對接體驗 = 平臺工具使用體驗 + API使用體驗 + 客戶答疑體驗
• 對接周期 = 注冊賬號時長 + API選用時長 + API使用方法學習時長 + API調用代碼開發時長

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

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

3.2 系統的安全和穩定

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

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

一種可能的監控告警方案是：

• 針對客戶系統，如果系統多次重連都無法連接上客戶系統，則直接向客戶的研發、銷售支持團隊、技術支持團隊發送告警。
• 針對內部系統，在平臺上發布API后，自動為API創建一個監控看板，看板中包括TP99、可用率；當發生業務系統不可聯通或在業務層面上不可用時，影響這個API的可用率；業務系統的研發可以在平臺上配置這個API對應的告警規則，在可用率下降到下限或TP99超過上限時，系統向API的產品、研發負責人發出告警。

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

除了系統穩定性，系統安全性也非常重要，業務越權或數據泄露也會對公司運營造成重大影響。通過三方面措施來防止此類情況發生：

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

3.3 流程規范的持續建設

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

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

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

三、一些思考

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

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

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

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

Q3：如果一項數據涉及客戶隱私，容易帶來數據安全問題，但業務側期望開放此類數據供商家做經營，如何選擇？

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

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

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