一 導(dǎo)讀

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

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

二 云計算OpenAPI的特點

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

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

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

阿里云的OpenAPI有如下特點：

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

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

圖2 OpenAPI用戶需求層次

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

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

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

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

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

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

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

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

四 云計算需要面向資源編程

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

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

然而，客戶的困惑卻是真實存在的：

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

面對客戶的需求，我們需要回答幾個問題：

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

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

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

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

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

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

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

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

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

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

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

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

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

六 OpenAPI體驗是云客戶的核心體驗之一

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

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

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

七 OpenAPI客戶體驗需要強大的體系支撐

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

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

阿里云的OpenAPI體驗是一個全鏈路問題，如下圖：

圖5 典型OpenAPI用戶使用路徑

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

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

我們的做法是這樣的：

1 Step1 量化

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

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

2 Step 2：治理

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

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

3 Step3 產(chǎn)品化

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

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

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

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

八 總結(jié)

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

分享名稱：深入理解云計算OpenAPI體系
鏈接地址：http://aaarwkj.com/news/200902.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、品牌網(wǎng)站建設(shè)、營銷型網(wǎng)站建設(shè)、App開發(fā)、自適應(yīng)網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)

廣告

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