深入理解云計算OpenAPI體系

提到API，從事技術(shù)的同學(xué)都十分熟悉，無(wú)論是在操作系統上開(kāi)發(fā)軟件，還是打造分布式網(wǎng)絡(luò )服務(wù)，都離不開(kāi)對各種API的調用。

一 導讀

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

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

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

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

圖1 飛天操作系統

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

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

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

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

圖2 OpenAPI用戶(hù)需求層次

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

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

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

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

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

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

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

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

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

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

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

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

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

面對客戶(hù)的需求，我們需要回答幾個(gè)問(wèn)題：

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

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

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

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

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

五 云計算需要沉淀統一的OpenAPI/資源元數據

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

那么統一OpenAPI/資源元數據能帶來(lái)哪些價(jià)值呢：

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

圖4 基于A(yíng)PI元數據無(wú)代碼自動(dòng)化生成

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

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

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

六 OpenAPI體驗是云客戶(hù)的核心體驗之一

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

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

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

七 OpenAPI客戶(hù)體驗需要強大的體系支撐

那么OpenAPI的客戶(hù)體驗能不能被度量?阿里云開(kāi)放平臺剛開(kāi)始發(fā)力OpenAPI時(shí)面臨的最大問(wèn)題是：客戶(hù)和內部都有人吐槽阿里云API不好用，都是點(diǎn)狀問(wèn)題拋出和客戶(hù)需求驅動(dòng)，沒(méi)有一個(gè)體系化的方法來(lái)衡量客戶(hù)體驗指標，且不能規?；鉀Q問(wèn)題。

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

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

圖5 典型OpenAPI用戶(hù)使用路徑

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

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

我們的做法是這樣的：

1 Step1 量化

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

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

2 Step 2：治理

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

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

3 Step3 產(chǎn)品化

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

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

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

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

八 總結

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

參考文獻：

https://apiacademy.co/2015/04/api-design-202-architectural-layers/

https://www.itread01.com/articles/1475911242.html

https://azure.microsoft.com/zh-cn/features/resource-graph/

https://maryamalshamsi98.wordpress.com/2014/05/21/linux-file-system-2/

原文鏈接：https://zhuanlan.51cto.com/art/202109/683898.htm