深入理解云計(jì)算OpenAPI體系

一 導(dǎo)讀

提到API，從事技術(shù)的同學(xué)都十分熟悉，無論是在操作系統(tǒng)上開發(fā)軟件，還是打造分布式網(wǎng)絡(luò)服務(wù)，都離不開對(duì)各種API的調(diào)用。對(duì)應(yīng)用程序開發(fā)人員來說，都會(huì)通過各種編程語言、系統(tǒng)調(diào)用和各種類庫、編程框架構(gòu)建系統(tǒng)，為了提升開發(fā)效率和統(tǒng)一性，就出現(xiàn)了各種各樣的API標(biāo)準(zhǔn)，例如POSIX。這些標(biāo)準(zhǔn)的實(shí)現(xiàn)保障了應(yīng)用程序可以不做過多修改就能運(yùn)行在各種軟硬件平臺(tái)上，大大促進(jìn)了整個(gè)IT生態(tài)的發(fā)展。

然而就云計(jì)算的API來看，當(dāng)前并沒有類似POSIX這樣的API標(biāo)準(zhǔn)，基本上各大廠商各自為政。當(dāng)然，有一些業(yè)界主流標(biāo)準(zhǔn)例如OAS獲得多數(shù)云廠商的支持，但云廠商本身的API卻往往由于歷史原因、技術(shù)路線原因百花齊放，例如AWS的OpenAPI屬于RPC風(fēng)格，而Azure則是WebService風(fēng)格，GCP則是基于gRPC為主流。技術(shù)方面的論述很多，本文更想從客戶體驗(yàn)、研發(fā)效能的角度來闡述OpenAPI對(duì)云計(jì)算整體競(jìng)爭力的重要性。

二 云計(jì)算OpenAPI的特點(diǎn)

如果將阿里云飛天操作系統(tǒng)與傳統(tǒng)操作系統(tǒng)類比，那么它也是由內(nèi)核層、接口層、操作界面、業(yè)務(wù)應(yīng)用組成，計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等核心產(chǎn)品構(gòu)成了內(nèi)核，API層承擔(dān)內(nèi)核的管控和數(shù)據(jù)通信，各式各樣的控制界面則相當(dāng)于操作系統(tǒng)的Terminal/Windows/mac OS UI，基于云計(jì)算的各種行業(yè)應(yīng)用則是跑在這個(gè)操作系統(tǒng)上的應(yīng)用。

圖1 飛天操作系統(tǒng)

阿里云不同于傳統(tǒng)操作系統(tǒng)，OpenAPI自然也不同于其他業(yè)態(tài)的API體系，例如淘系、B2B的開放平臺(tái)。業(yè)務(wù)開放平臺(tái)輸出的是以業(yè)務(wù)數(shù)據(jù)為主的服務(wù)，目的是為了整合商業(yè)生態(tài)，而阿里云開放平臺(tái)輸出的是云操作系統(tǒng)的管控能力、數(shù)據(jù)操作能力和其他企業(yè)級(jí)能力。前者重心是服務(wù)商業(yè)模型，而后者重心是服務(wù)技術(shù)底座。因此，云計(jì)算的OpenAPI體系要以服務(wù)技術(shù)開發(fā)者和企業(yè)場(chǎng)景為中心，保障技術(shù)體系的健全穩(wěn)定，對(duì)外緊密對(duì)接行業(yè)技術(shù)體系(例如開源工具、三方廠商)，對(duì)內(nèi)促進(jìn)眾多云服務(wù)協(xié)同管理。

阿里云的OpenAPI有如下特點(diǎn)：

數(shù)量多：當(dāng)前阿里云OpenAPI數(shù)量高達(dá)1萬多個(gè)，每天調(diào)用量上百億，分布在近300個(gè)產(chǎn)品上。 增速快：業(yè)務(wù)發(fā)展快，近年來每年數(shù)量的增速接近100%。 API類型多：OpenAPI大體分為管控、數(shù)據(jù)兩類，管控類又分為RPC/ROA兩種形式，數(shù)據(jù)類又會(huì)分為數(shù)據(jù)流、文件等具體類型，還有很多業(yè)務(wù)需要有自己的格式。 產(chǎn)品協(xié)同要求高：單個(gè)OpenAPI是不能滿足用戶要求的，場(chǎng)景化的用戶需求需要多個(gè)產(chǎn)品的多個(gè)OpenAPI組合才能服務(wù)，這對(duì)API編排、產(chǎn)品間API協(xié)同提出了更高的要求。例如在穩(wěn)定性方面，一個(gè)產(chǎn)品的OpenAPI出問題有可能造成整個(gè)管控鏈路的雪崩。 企業(yè)能力需求強(qiáng)烈：OpenAPI主要是用來進(jìn)行云資源管理或數(shù)據(jù)傳輸?shù)?，操作?duì)象都是用戶資產(chǎn)，除了常規(guī)的身份管理、權(quán)限管理外，對(duì)企業(yè)來說還要服務(wù)于運(yùn)維、財(cái)務(wù)、法務(wù)、監(jiān)管等部門，當(dāng)涉及眾多的云產(chǎn)品時(shí)對(duì)架構(gòu)和底層設(shè)施的完備性、準(zhǔn)確性、及時(shí)性要求很高。 與行業(yè)技術(shù)趨勢(shì)結(jié)合緊密：云是全球化的，作為平臺(tái)它要想服務(wù)好各種場(chǎng)景、人群就離不開與各種業(yè)界標(biāo)準(zhǔn)和技術(shù)體系相結(jié)合，云計(jì)算與開源行業(yè)高度結(jié)合證明了我們做的技術(shù)不能閉門造車。 穩(wěn)定性風(fēng)險(xiǎn)加大：商業(yè)開放平臺(tái)的OpenAPI如果不穩(wěn)定影響的可能只是客戶側(cè)某個(gè)業(yè)務(wù)功能模塊或流程，但是云OpenAPI出問題影響的可能是客戶底層技術(shù)系統(tǒng)，爆炸半徑會(huì)更大。 調(diào)用熱點(diǎn)集中：調(diào)用量分布基本符合二八原則，20%的云產(chǎn)品承擔(dān)了80%的調(diào)用量，核心產(chǎn)品的體驗(yàn)決定了用戶對(duì)阿里云的體感，保障客戶典型場(chǎng)景的運(yùn)作至關(guān)重要。

上述特點(diǎn)決定了云上的OpenAPI相比于傳統(tǒng)開放平臺(tái)，要側(cè)重技術(shù)能力的建設(shè)，同時(shí)又要兼顧客戶企業(yè)級(jí)場(chǎng)景，才能做好體驗(yàn)工作。

圖2 OpenAPI用戶需求層次

三 管理自動(dòng)化是企業(yè)客戶的核心訴求

那么云計(jì)算客戶在OpenAPI領(lǐng)域核心體驗(yàn)是什么?以阿里云上某實(shí)際案例來分析，具體要點(diǎn)包括：

客戶希望全部的流程都是能夠自動(dòng)化的，從代碼提交到服務(wù)器部署全部通過自動(dòng)化工具進(jìn)行。 許多客戶希望使用混合云體系，云上云下兩部分結(jié)合，業(yè)務(wù)系統(tǒng)與云平臺(tái)緊密集成。 客戶系統(tǒng)中大量使用多種開源軟件，例如Git/Jfrog/Terraform等，希望能夠整合形成完整的自動(dòng)化流程。

總結(jié)起來客戶的核心訴求是：客戶業(yè)務(wù)系統(tǒng)要能夠與云平臺(tái)高度自動(dòng)化地集成。不僅是客戶，云廠商經(jīng)常強(qiáng)調(diào)彈性、自愈等概念，其背后也是高度自動(dòng)化的架構(gòu)在支撐。

要做到高度自動(dòng)化地集成，對(duì)OpenAPI體系是全方位的要求。對(duì)比一下POSIX，一套標(biāo)準(zhǔn)的、完備的、質(zhì)量良好的API能夠促進(jìn)各操作系統(tǒng)之間的兼容性，確保上層應(yīng)用的開發(fā)移植成本最低。而對(duì)于云計(jì)算，這樣的規(guī)范應(yīng)該在哪幾個(gè)方面來滿足客戶的需求呢，實(shí)踐中我們總結(jié)如下：

風(fēng)格一致性：POSIX API的風(fēng)格基本是一致的，例如文件處理API，其核心錯(cuò)誤碼都是一致的。一致的風(fēng)格、術(shù)語、錯(cuò)誤、操作模式，可以讓應(yīng)用程序開發(fā)者降低理解成本，提升效率。而如果不同產(chǎn)品API設(shè)計(jì)風(fēng)格不一致，用戶理解成本很高，使用不便，就會(huì)對(duì)云平臺(tái)專業(yè)性產(chǎn)生質(zhì)疑。例如，當(dāng)前阿里云的OpenAPI就存在專業(yè)術(shù)語在不同產(chǎn)品中描述不一樣，同樣的資源信息各產(chǎn)品屬性和數(shù)據(jù)不一致，分頁API的形式不一致，甚至大小寫命名也不一樣的問題。 功能完整性：功能完整其實(shí)不難理解，但是如何定義功能完整性一直有爭議，一個(gè)云產(chǎn)品是開放10個(gè)API就夠了，還是開放100個(gè)才夠?有點(diǎn)見仁見智，況且產(chǎn)品也是在一直演進(jìn)的。POSIX文件處理涵蓋了一套標(biāo)準(zhǔn)的文件處理API，包括create/close/dup/dup2/fcntl/flock/fsync/lseek/mkstemp/open/read/sync/write等 API，所有關(guān)于文件操作可能的API都存在了，這樣用戶才能精細(xì)控制文件。所以對(duì)于云上資源，由于客戶需要對(duì)其進(jìn)行全生命周期自動(dòng)化管理，那么客戶視角的所有管理動(dòng)作都應(yīng)該被開放。在實(shí)踐中一般用實(shí)體關(guān)系模型去設(shè)計(jì)一組相互配合的API，不可隨意零散處理。 服務(wù)有效性：實(shí)踐中大的問題是不同團(tuán)隊(duì)對(duì)于API SLA的標(biāo)準(zhǔn)不一樣。例如在可用性上有些產(chǎn)品要求99.99%，有些產(chǎn)品覺得99%也能接受。極端的例子，如果某些OpenAPI只能允許一個(gè)并發(fā)，這樣的OpenAPI對(duì)用戶來說是沒有服務(wù)質(zhì)量可言的，自動(dòng)化也會(huì)因?yàn)楦鞣N異常被終止。同時(shí)，如果必須某些限制，例如限流，ToB場(chǎng)景下是要告知客戶的，否則客戶端將不知道如何去優(yōu)化自己的調(diào)用頻率。 配套體系健全性：客戶體驗(yàn)是客戶從知曉到使用產(chǎn)品的心理感受的全過程。Linux/Mac上的開發(fā)體驗(yàn)很優(yōu)秀是因?yàn)榕涮椎墓ぞ哝満艹墒?，具備完整的體系。云上客戶基于OpenAPI開發(fā)時(shí)也應(yīng)該能夠獲取專業(yè)的、詳細(xì)的工具支持和技術(shù)支持，就像Visual Studio要有MSDN，Java開發(fā)要能夠有IDE，任何語言都需要debug工具一樣。像SDK、文檔、調(diào)試工具是必備產(chǎn)品，同時(shí)諸如代碼示例、API調(diào)用可視化等功能也是非常有價(jià)值的。

除此之外，云計(jì)算內(nèi)部系統(tǒng)也需要通過API實(shí)現(xiàn)高度自動(dòng)化。一些典型的場(chǎng)景例如專有云部署、新region擴(kuò)建、單產(chǎn)品擴(kuò)容，如果不能夠自動(dòng)化部署，對(duì)公司整體人效是不利的，更重要的是實(shí)施時(shí)間會(huì)拉長，客戶體驗(yàn)也會(huì)變差。

要解決上述問題，主要難點(diǎn)在于如何統(tǒng)一標(biāo)準(zhǔn)、如何建立全面的配套平臺(tái)體系、如何衡量服務(wù)質(zhì)量、如何持續(xù)推動(dòng)服務(wù)達(dá)標(biāo)以及如何考察客戶體驗(yàn)。

四 云計(jì)算需要面向資源編程

Linux/UNIX世界中，有個(gè)著名的說法： 萬物皆可文件化。那么云上的萬物能否資源化呢?

阿里云對(duì)外的OpenAPI都是基于HTTP協(xié)議，RESTful規(guī)范有提出基于資源設(shè)計(jì)的理念。 而實(shí)際工作中，能堅(jiān)持這樣的原則的API卻不多。經(jīng)常會(huì)碰到的疑問是“什么樣的東西應(yīng)該定義為資源?”“我的API沒有資源化設(shè)計(jì)不也工作的挺好?”“我設(shè)計(jì)的時(shí)候有資源概念，但是客戶沒這需求啊?”。

然而，客戶的困惑卻是真實(shí)存在的：

想自建一個(gè)資源管理系統(tǒng)，阿里云上怎么能知道我擁有的所有資源列表? 那如果通過OpenAPI獲取，怎么能知道這個(gè)API對(duì)應(yīng)的是什么資源，資源能做什么操作，資源與資源之間有什么關(guān)系呢? 不同的產(chǎn)品在同一個(gè)資源類型情況下，怎么返回的屬性不一樣啊? 想查詢不同產(chǎn)品若干資源的組合狀態(tài)，目前一個(gè)個(gè)寫代碼太麻煩了，有什么好辦法么? 自己去理那么多API對(duì)應(yīng)的資源類型工作量太大了，能不能說說阿里云自己是怎么做的?

面對(duì)客戶的需求，我們需要回答幾個(gè)問題：

什么是資源?哪些資源應(yīng)該被管理?無需管理的服務(wù)是否也要被定義為資源? 阿里云到底有哪些資源類型，統(tǒng)一的列表在哪里?能不能通過OpenAPI自動(dòng)化獲取? 這些資源類型的屬性是怎樣的?能做什么操作?對(duì)應(yīng)的API是什么?資源有哪些狀態(tài)?資源與資源之間的關(guān)系是什么?能不能保證資源都是一致的? 用什么方法能夠面向資源編程減少開發(fā)成本?

對(duì)于云計(jì)算場(chǎng)景，如果沒有資源模型，內(nèi)部研發(fā)效率也會(huì)受到影響。原因是企業(yè)客戶不同于個(gè)人客戶，相對(duì)成熟的企業(yè)都對(duì)人、財(cái)、物、權(quán)、法的監(jiān)管需求強(qiáng)烈，面對(duì)內(nèi)部管理、盈利、監(jiān)管約束等挑戰(zhàn)，一套成熟的IT治理體系對(duì)資源概念的依賴是極高的，如阿里云的RAM/ActionTrail/Config/RD/ResourceManager等。沒有資源模型，這些產(chǎn)品就要各自定義資源，分別找云產(chǎn)品溝通，實(shí)施落地進(jìn)度和質(zhì)量也不能保證一致。開源軟件也一樣，例如Terraform就是面向資源的。甚至很多平臺(tái)服務(wù)如賬單，也需要資源的概念才能更好地管理。

圖3 資源生產(chǎn)者和消費(fèi)者

如果能夠統(tǒng)一資源模型，就相當(dāng)于客戶和阿里云在有一套面向?qū)ο蟮腏ava類或者數(shù)據(jù)庫表，凡是依賴該資源模型的產(chǎn)品都將從中受益，理解更容易，溝通上保持一致性，研發(fā)上可以提供統(tǒng)一的技術(shù)方案提高效率。

所以，面向資源編程的API設(shè)計(jì)，對(duì)于客戶和云平臺(tái)自身都是非常重要的，如果前期不考慮，后期會(huì)付出更大的成本，必將影響阿里云整體服務(wù)質(zhì)量。

五 云計(jì)算需要沉淀統(tǒng)一的OpenAPI/資源元數(shù)據(jù)

元數(shù)據(jù)是關(guān)于數(shù)據(jù)的數(shù)據(jù)，它描述的是數(shù)據(jù)組織、數(shù)據(jù)域及其關(guān)系的信息。元數(shù)據(jù)平臺(tái)并不是新鮮事物，比如在大數(shù)據(jù)領(lǐng)域就有很多應(yīng)用。由于阿里云有數(shù)百個(gè)產(chǎn)品，上萬個(gè)OpenAPI，所以資源的數(shù)量也必定是龐大的，這時(shí)候就有必要有一個(gè)統(tǒng)一的平臺(tái)來管理資源信息。而資源只是一種抽象，背后還需要依賴 OpenAPI的元數(shù)據(jù)，兩者結(jié)合才能對(duì)外提供完整的服務(wù)。

那么統(tǒng)一OpenAPI/資源元數(shù)據(jù)能帶來哪些價(jià)值呢：

促進(jìn)產(chǎn)品體驗(yàn)一致性：阿里云各個(gè)產(chǎn)品線獨(dú)立發(fā)展，但是會(huì)面臨此資源非彼資源的尷尬境地，每個(gè)產(chǎn)品都有自己的認(rèn)識(shí)，非常不利于統(tǒng)一客戶體驗(yàn)。 提升溝通效率：統(tǒng)一的模型就像一個(gè)標(biāo)準(zhǔn)的數(shù)據(jù)庫schema，能夠讓相關(guān)的業(yè)務(wù)方都能夠在一個(gè)語境中溝通。 提升研發(fā)效率：結(jié)構(gòu)化的標(biāo)準(zhǔn)模型，能夠讓程序代替人來處理模式化的數(shù)據(jù);以Terraform為例，有了資源元數(shù)據(jù)，可以直接編寫自動(dòng)化腳本生成terraform模塊，將云產(chǎn)品的接入效率提升了50%左右，過程中就節(jié)省了Go語言研發(fā)資源和聯(lián)調(diào)成本。

圖4 基于API元數(shù)據(jù)無代碼自動(dòng)化生成

提升業(yè)務(wù)質(zhì)量持續(xù)保障：軟件研發(fā)有個(gè)痛點(diǎn)是云產(chǎn)品初次發(fā)布后，如果隨著業(yè)務(wù)迭代，如何保障過往的功能正確性。以阿里云的RAM產(chǎn)品為例，如果我們能夠?qū)①Y源元數(shù)據(jù)、API訪問日志、RAM的Policy與云產(chǎn)品實(shí)際鑒權(quán)日志放在一起，通過對(duì)比元數(shù)據(jù)聲明內(nèi)容與實(shí)際發(fā)生的動(dòng)作，就可以檢查云產(chǎn)品的鑒權(quán)行為是否符合預(yù)期。相比于人治，基于數(shù)據(jù)和代碼的自動(dòng)化平臺(tái)檢查機(jī)制會(huì)更高效、更準(zhǔn)確。

更多的業(yè)務(wù)場(chǎng)景賦能：Azure有一個(gè)產(chǎn)品叫Resource Graph Explorer，它能夠按照資源維度管理平臺(tái)上所有的資源，跨地域也不是問題，有點(diǎn)類似于Windows的資源管理器。完善的元數(shù)據(jù)管理，將使得這類產(chǎn)品的研發(fā)變得可能?？赡苡腥藭?huì)有疑問：沒有元數(shù)據(jù)就不能做嗎?理論上可以，但是一定是事倍功半，因?yàn)樗枰c各產(chǎn)品反復(fù)協(xié)調(diào)溝通，成本極高，而不是用一套平臺(tái)來承載著標(biāo)準(zhǔn)化的生產(chǎn)流程，且不好復(fù)用，不可同日而語。

所以統(tǒng)一的阿里云OpenAPI/資源元數(shù)據(jù)管理，對(duì)內(nèi)價(jià)值是許多圍繞資源的業(yè)務(wù)開發(fā)都將變得更加輕松，甚至無代碼化，提升業(yè)務(wù)效能，對(duì)外客戶將能得到與內(nèi)部一致的業(yè)務(wù)模型，提升用戶體驗(yàn)，更加方便地集成。

六 OpenAPI體驗(yàn)是云客戶的核心體驗(yàn)之一

云操作系統(tǒng)想服務(wù)好客戶，經(jīng)過優(yōu)良設(shè)計(jì)的API是必需品，否則用戶很難快速高效地基于API層來開發(fā)和部署應(yīng)用服務(wù)，會(huì)對(duì)商業(yè)競(jìng)爭力造成嚴(yán)重影響，一個(gè)各種理念能力都是頂級(jí)但卻難以管理的操作系統(tǒng)誰愿意使用呢?

OpenAPI是云產(chǎn)品的服務(wù)契約。云平臺(tái)不但要保障服務(wù)質(zhì)量，而且一旦上線下線極難，產(chǎn)品很難冒風(fēng)險(xiǎn)去強(qiáng)行關(guān)閉某個(gè)API，不兼容變更也不行，等同于違約，有可能造成客戶業(yè)務(wù)系統(tǒng)的崩潰，隨后就是法律風(fēng)險(xiǎn)、輿情風(fēng)險(xiǎn)和客戶流失。 OpenAPI的成熟度很重要?？蛻粼谑褂迷品?wù)的時(shí)候貨比三家，除了價(jià)格、穩(wěn)定、功能等因素外，是否能夠快速、方便地與客戶業(yè)務(wù)系統(tǒng)集成是重要競(jìng)爭因素，阿里云接觸過許多大客戶都在API成熟度上有明確要求。 良好的開發(fā)體驗(yàn)和豐富的服務(wù)生態(tài)或?qū)⒊蔀樵茝S商的核心競(jìng)爭力。Windows靠視窗系統(tǒng)的體驗(yàn)代差霸占消費(fèi)級(jí)操作系統(tǒng)市場(chǎng)，Linux/Unix在windows環(huán)伺下靠企業(yè)級(jí)開發(fā)能力占據(jù)企業(yè)級(jí)市場(chǎng)，macOS的良好開發(fā)體驗(yàn)又在windows一統(tǒng)天下的局面下殺出一條血路，都說明最終制勝必須圍繞客戶體驗(yàn)展開。當(dāng)各廠商在核心服務(wù)能力上隨著時(shí)間的推移逐漸同質(zhì)化之后，差異化競(jìng)爭力就在于價(jià)格、體驗(yàn)、服務(wù)了，而現(xiàn)在國外競(jìng)對(duì)在體驗(yàn)上的優(yōu)勢(shì)也是多年沉淀下來的護(hù)城河，不投入時(shí)間和資源來沉淀是不可能比肩的。 客戶視角在云計(jì)算場(chǎng)景下尤為重要。其邏輯不是我們有什么接口可以開放，而是客戶需要我們開放什么接口。功能接口開放度不足可能會(huì)導(dǎo)致客戶的生產(chǎn)流程中斷，嚴(yán)重影響客戶的信心。 符合行業(yè)規(guī)范的API更容易兼容業(yè)界技術(shù)工具和合作伙伴，更容易為社區(qū)所接受。比如現(xiàn)在應(yīng)該很難出現(xiàn)一個(gè)不支持POSIX標(biāo)準(zhǔn)的操作系統(tǒng)了，不兼容就意味著沒有市場(chǎng)。草率設(shè)計(jì)的API會(huì)導(dǎo)致業(yè)務(wù)難以和外部生態(tài)協(xié)作，如果又必須合作會(huì)對(duì)內(nèi)部研發(fā)資源造成壓力，從而影響業(yè)務(wù)發(fā)展速度和商業(yè)競(jìng)爭力。 OpenAPI不僅僅是API的問題，配套的服務(wù)體系必須完善?？纯碙inux系統(tǒng)上的開發(fā)，并不是有個(gè)系統(tǒng)調(diào)用函數(shù)就OK了，需要文檔/代碼示例/各種調(diào)試工具，由此還衍生許多IDE工具。在阿里云上這種全鏈路服務(wù)還比較薄弱，客戶碰到問題要么反復(fù)提工單對(duì)公司服務(wù)資源造成很大壓力，要么客戶對(duì)服務(wù)不滿意，用腳投票影響阿里云口碑，損害公司長期競(jìng)爭力。

因此，OpenAPI不止是技術(shù)問題，也是產(chǎn)品問題，是產(chǎn)品體驗(yàn)的重要組成部分，需要慎重對(duì)待。

七 OpenAPI客戶體驗(yàn)需要強(qiáng)大的體系支撐

那么OpenAPI的客戶體驗(yàn)?zāi)懿荒鼙欢攘?阿里云開放平臺(tái)剛開始發(fā)力OpenAPI時(shí)面臨的大問題是：客戶和內(nèi)部都有人吐槽阿里云API不好用，都是點(diǎn)狀問題拋出和客戶需求驅(qū)動(dòng)，沒有一個(gè)體系化的方法來衡量客戶體驗(yàn)指標(biāo)，且不能規(guī)?；鉀Q問題。

阿里云的 OpenAPI數(shù)量1萬多個(gè)，點(diǎn)狀的、模糊的反饋對(duì)解決全局問題沒有幫助，且用戶其實(shí)是對(duì)具體產(chǎn)品有概念，但針對(duì)OpenAPI概念性卻不強(qiáng)，調(diào)研主觀偏差更大。

阿里云的OpenAPI體驗(yàn)是一個(gè)全鏈路問題，如下圖：

圖5 典型OpenAPI用戶使用路徑

長長的鏈路，任何一個(gè)環(huán)節(jié)沒做好都有可能導(dǎo)致用戶體驗(yàn)不好;而且反饋的信息也是五花八門，難以抽取有效信息。因此有幾個(gè)核心問題需要依次解決：

什么樣的客戶聲音是清晰明確的? 如何能夠拿到這些客戶聲音，有哪些渠道? 如何處理這些聲音，如何清洗分類，如何定位根因，分析是哪個(gè)環(huán)節(jié)的問題? 如何建立總體和細(xì)分量化指標(biāo)，進(jìn)而針對(duì)性治理，形成閉環(huán)? 如何推動(dòng)及運(yùn)營? 最終如何檢驗(yàn)治理效果?

我們的做法是這樣的：

1 Step1 量化

要有具體用戶問題： 能夠反映客戶具體問題的信息，過去主流是靠工單，但是工單反饋的用戶只是冰山一角，更多的信息沒有被看到。電話、釘群信息、網(wǎng)站反饋等內(nèi)容也應(yīng)該被納入進(jìn)來，這些信息加起來就是一個(gè)個(gè)具體的問題，很多問題匯集在一起就形成了很有價(jià)值的大數(shù)據(jù)集，可以給數(shù)據(jù)化治理奠定數(shù)據(jù)基礎(chǔ)。 獲取數(shù)據(jù)：我們嘗試聯(lián)系工單系統(tǒng)、內(nèi)部平臺(tái)、釘群等渠道，需要拉通各個(gè)平臺(tái)的數(shù)據(jù)。 數(shù)據(jù)清洗：客戶、工單數(shù)據(jù)是非結(jié)構(gòu)化數(shù)據(jù)，需要自然語言處理方面的技術(shù)，阿里云開放平臺(tái)與達(dá)摩院合作，通過對(duì)特定目標(biāo)分類輸入關(guān)鍵詞、打標(biāo)簽等方式訓(xùn)練AI，由AI對(duì)大量的數(shù)據(jù)進(jìn)行自動(dòng)化抽取、歸類、量化，對(duì)客戶聲音和根因進(jìn)行較好的分類和量化。 業(yè)務(wù)價(jià)值：通過根因分析得出客戶主要問題分類后，針對(duì)性地優(yōu)化升級(jí)產(chǎn)品，以問題的單位用戶工單量為效果指標(biāo)，來檢驗(yàn)產(chǎn)品改進(jìn)效果。有些問題是從趨勢(shì)中發(fā)現(xiàn)的，需要升級(jí)產(chǎn)品，例如客戶抱怨找不到SDK或API，我們就要優(yōu)化API搜索。有些問題是已知內(nèi)部問題，例如API可用性問題，就制定機(jī)制去督促業(yè)務(wù)改進(jìn)。 改進(jìn)效果衡量：首先要有具體指標(biāo)，目前主要還是工單降量。但是我們覺得還不夠，因?yàn)楣沃皇潜揭唤?，?shù)量不夠多，也不夠細(xì)節(jié)，流轉(zhuǎn)周期也長。所以我們也嘗試收口OpenAPI開發(fā)者門戶，一方面標(biāo)準(zhǔn)化產(chǎn)品體驗(yàn)，另一方面直接觸達(dá)終端客戶拿到最詳細(xì)的反饋。比如，客戶的反饋能夠詳細(xì)到：當(dāng)某個(gè)API的頁碼設(shè)定為0會(huì)導(dǎo)致功能異常、文檔細(xì)節(jié)不對(duì)、必填非必填描述不對(duì)這樣的精準(zhǔn)問題。

通過上述動(dòng)作，我們能夠自動(dòng)化分析出OpenAPI用戶的主要痛點(diǎn)，并建立數(shù)字化趨勢(shì)圖去跟蹤。

2 Step 2：治理

有法可依：制定了《阿里云OpenAPI規(guī)范》，目前已經(jīng)迭代到1.3版，涵蓋設(shè)計(jì)風(fēng)格、服務(wù)質(zhì)量、資源規(guī)范、域名規(guī)范、文檔規(guī)范等子項(xiàng)，在標(biāo)準(zhǔn)層面統(tǒng)一大家認(rèn)知。 執(zhí)法必嚴(yán)：想要讓規(guī)范落地只有文本不行，必須有配套的平臺(tái)機(jī)制。 收口阿里云所有API管理，從提升研發(fā)效率和全生命周期體系化管理的角度持續(xù)提升API管理平臺(tái)的核心能力。 將規(guī)范的審查規(guī)則沉淀到規(guī)則引擎中，用戶在開發(fā)API的時(shí)候自動(dòng)化掃描檢查問題，不通過就打回。對(duì)于無法自動(dòng)化約束的規(guī)范，建立審核流程和管理層審批流程，提高不合規(guī)問題的生產(chǎn)成本，不斷提升自動(dòng)化審核比例。 針對(duì)API的質(zhì)量進(jìn)行數(shù)字化治理，通過質(zhì)量分量化評(píng)估各個(gè)BU各個(gè)產(chǎn)品API質(zhì)量，定期同步督促改進(jìn)。 違法必究：聯(lián)合阿里云用戶體驗(yàn)部門一起推動(dòng)問題改進(jìn)，并通過檢查用戶側(cè)工單降量情況來驗(yàn)證效果。

上述能力，都沉淀在內(nèi)部管理平臺(tái)上，內(nèi)部云產(chǎn)品可以一站式管理API及流程化參與API治理過程。

3 Step3 產(chǎn)品化

目標(biāo)是收口外部用戶的產(chǎn)品體驗(yàn)。以前OpenAPI的各項(xiàng)功能是分散割裂的，后續(xù)我們將所有與OpenAPI相關(guān)的功能集成正在一個(gè)產(chǎn)品中，即OpenAPI開發(fā)者門戶 ，除了通過集中的產(chǎn)品建設(shè)提升用戶體驗(yàn)外，還針對(duì)使用鏈路增加了troubleshooting、搜索、codesample等模塊。

通過以上三步，我們整體OpenAPI體驗(yàn)治理大圖如下：

圖6 用戶體驗(yàn)管理閉環(huán)示意圖

通過這套體系運(yùn)轉(zhuǎn)中發(fā)現(xiàn)的問題，都會(huì)通過API管理平臺(tái)和API開發(fā)者門戶的功能上不斷的完善，去逐步提升用戶體驗(yàn)，從2020年的工單情況看，有比較明顯的下降。

八 總結(jié)

阿里云是個(gè)龐大的分布式操作系統(tǒng)，OpenAPI相當(dāng)于用戶層操作內(nèi)核層的重要通道，保障它的穩(wěn)定、功能、性能、體驗(yàn)關(guān)系到客戶的核心體驗(yàn)，關(guān)系到公司形象和生態(tài)拓展，也關(guān)系到內(nèi)部產(chǎn)品質(zhì)量和研發(fā)效率。接入層必須做深、做厚、做強(qiáng)才能讓內(nèi)外部客戶被服務(wù)好。從團(tuán)隊(duì)兩年的實(shí)踐來看，數(shù)字化、體系化的做好基礎(chǔ)建設(shè)才能做好OpenAPI體驗(yàn)。本文就云上OpenAPI的幾個(gè)重要概念進(jìn)行論述，希望能拋磚引玉，引起大家對(duì)OpenAPI體系價(jià)值的興趣和關(guān)注。

文章題目：深入理解云計(jì)算OpenAPI體系
文章分享：http://www.muchs.cn/news2/200902.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、做網(wǎng)站、App開發(fā)、網(wǎng)站維護(hù)、ChatGPT、網(wǎng)站營銷

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)