中文字幕日韩精品一区二区免费_精品一区二区三区国产精品无卡在_国精品无码专区一区二区三区_国产αv三级中文在线

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

2022-10-03    分類: 網(wǎng)站建設(shè)

深入理解云計(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)爭(zhē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)用。

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

圖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é)同要求高:?jiǎn)蝹€(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)工作。

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

圖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í)不難理解,但是如何定義功能完整性一直有爭(zhēng)議,一個(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ì)拉長(zhǎng),客戶體驗(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ù)如賬單,也需要資源的概念才能更好地管理。

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

圖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)成本。

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

圖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)爭(zhē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)爭(zhēng)因素,阿里云接觸過許多大客戶都在API成熟度上有明確要求。 良好的開發(fā)體驗(yàn)和豐富的服務(wù)生態(tài)或?qū)⒊蔀樵茝S商的核心競(jìng)爭(zhē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)爭(zhē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)爭(zhēng)力。 OpenAPI不僅僅是API的問題,配套的服務(wù)體系必須完善。看看Linux系統(tǒng)上的開發(fā),并不是有個(gè)系統(tǒng)調(diào)用函數(shù)就OK了,需要文檔/代碼示例/各種調(diào)試工具,由此還衍生許多IDE工具。在阿里云上這種全鏈路服務(wù)還比較薄弱,客戶碰到問題要么反復(fù)提工單對(duì)公司服務(wù)資源造成很大壓力,要么客戶對(duì)服務(wù)不滿意,用腳投票影響阿里云口碑,損害公司長(zhǎng)期競(jìng)爭(zhē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ī)模化解決問題。

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

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

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

圖5 典型OpenAPI用戶使用路徑

長(zhǎng)長(zhǎng)的鏈路,任何一個(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)周期也長(zhǎng)。所以我們也嘗試收口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)治理大圖如下:

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

圖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://m.rwnh.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)

商城網(wǎng)站建設(shè)
金溪县| 池州市| 龙井市| 辉南县| 巴彦淖尔市| 洱源县| 通化县| 徐州市| 察隅县| 七台河市| 苍山县| 湘潭县| 宁海县| 乌什县| 蓝山县| 三亚市| 卢龙县| 鄂伦春自治旗| 镇原县| 辽宁省| 临洮县| 潼关县| 辽宁省| 日土县| 宜兰市| 额尔古纳市| 宜兰市| 赣州市| 息烽县| 龙胜| 大埔县| 华坪县| 辽阳县| 墨脱县| 通许县| 大宁县| 方正县| 察雅县| 广东省| 洪洞县| 梓潼县|