魏航 劉軍 思科科技有限公司
在現(xiàn)代市場競爭下,人們在任何地方得到的一次最佳體驗(yàn),很可能就會成為下一次在其他地方對體驗(yàn)的最低期望,這意味著企業(yè)要想在開放競爭的市場中勝出,就必須進(jìn)行自己的數(shù)字化轉(zhuǎn)型,重新思考客戶最看重的是什么,并創(chuàng)建能夠充分利用競爭差異化優(yōu)勢的新運(yùn)營模式。因此一直以來搭建以用戶體驗(yàn)為中心的IT 架構(gòu)都是企業(yè)數(shù)字化轉(zhuǎn)型的核心議題。
當(dāng)前主要有兩類思路實(shí)現(xiàn)以用戶體驗(yàn)為中心的IT 架構(gòu)。最為主流的思路是不斷完善IT 各個子系統(tǒng)的運(yùn)維水平,包括遙測(Telemetry)、深度學(xué)習(xí)、形式化分析、自動化響應(yīng)等技術(shù)和工具的使用,能夠及時發(fā)現(xiàn)和優(yōu)化影響用戶體驗(yàn)的各項(xiàng)指標(biāo)。但是將用戶的宏觀體驗(yàn)量化為子系統(tǒng)的微觀指標(biāo)是一直以來的難點(diǎn),即便近年流行的利用深度學(xué)習(xí)建立基線的技術(shù)也僅能為正常情況建模而無法準(zhǔn)確預(yù)測體驗(yàn)惡化臨界點(diǎn)的位置。為了避免頻繁誤報,子系統(tǒng)的健康閾值往往制定得極為寬松,導(dǎo)致最終用戶體驗(yàn)不可控。
另一種思路則采用從全局系統(tǒng)角度出發(fā)、端到端測量用戶體驗(yàn),但這類方案需要對應(yīng)用部署深層探針,一直以來都是開發(fā)團(tuán)隊(duì)做非功能性測試的工具,產(chǎn)品定位上直接忽略前述IT 子系統(tǒng)在監(jiān)測管理上的各種手段,因而即便發(fā)現(xiàn)用戶體驗(yàn)惡化,但對下層子系統(tǒng)故障點(diǎn)的定位和修復(fù)仍需漫長的周期,無疑將影響最終用戶體驗(yàn)。
以上兩類問題的根源在于IT 的應(yīng)用開發(fā)部門(Dev)和系統(tǒng)運(yùn)維部門(Ops)根深蒂固的隔閡,雖然早在2003 年谷歌就在《站點(diǎn)可靠性工程》一書中提出了Dev 和Ops 相互融合的觀點(diǎn),但近年也僅在互聯(lián)網(wǎng)行業(yè)中少量敏捷開發(fā)類應(yīng)用上部分實(shí)現(xiàn),大部分傳統(tǒng)企業(yè)都見不到真正的DevOps。主要原因在于缺少一套方法論框架(如圖1 所示),以及框架中的核心技術(shù)基礎(chǔ)——“軟件定義一切”(SDx)。本文將對此概要闡述。
圖1 :以用戶體驗(yàn)為中心的IT 方法論框架
首先整個體系需要建立在一套已經(jīng)實(shí)現(xiàn)了現(xiàn)代化軟件定義的基礎(chǔ)架構(gòu)之上,這類系統(tǒng)具有非常典型的特征——擁有一層屏蔽底層復(fù)雜機(jī)制、向外暴露抽象化功能的API 接口、并可對其編程實(shí)現(xiàn)策略驅(qū)動功能的“策略層”(Policy Layer)。策略層與被策略層控制的子系統(tǒng)具備如下特征:
由一系列子系統(tǒng)的自動化控制器/引擎構(gòu)成;
控制器與其所直接控制的底層資源之間構(gòu)成多個相對獨(dú)立的子系統(tǒng);
每一個子系統(tǒng)遵循軟件開發(fā)中的面向?qū)ο竽K化特征,對內(nèi)高聚合、對外低耦合;
高聚合的子系統(tǒng)內(nèi)部最大自由度的實(shí)現(xiàn)專有、開放或開源的功能,包括之前所述高度發(fā)展的監(jiān)測管理手段,不受其他子系統(tǒng)制約;
子系統(tǒng)通過策略層的控制器對外暴露開放的API 接口,將內(nèi)部功能抽象,可通過軟件編程對其進(jìn)行定義,實(shí)現(xiàn)各類復(fù)雜功能組合;
每個子系統(tǒng)作為一個整體可迭代、可替換。
在策略層之上是一層由數(shù)據(jù)驅(qū)動的“意圖層”(Intent Layer),具備如下特征:
由一系列跨子系統(tǒng)、基于數(shù)據(jù)實(shí)現(xiàn)分析和處理的洞察類控制器/引擎構(gòu)成;
廣泛采用最新的大數(shù)據(jù)處理、深度學(xué)習(xí)、形式化分析等智能處理手段,對基于現(xiàn)實(shí)場景的數(shù)據(jù)進(jìn)行深刻的洞察;
具備良好的可視化表現(xiàn)能力,將洞察以更為直觀的形式向管理員展示;
獨(dú)立或由人類輔助生成高階“意圖”,并通過可編程方式將意圖或體現(xiàn)意圖的策略輸送給策略層,以便后者能夠自動化的、精確的執(zhí)行意圖;
意圖是包含具備特定目的的高階策略的集合,采用陳述式(Declarative)而非命令式(Imperative)的表達(dá)。它描述系統(tǒng)最終的目標(biāo)狀態(tài)而非狀態(tài)遷移的具體過程。意圖包含了豐富的功能,包括對數(shù)據(jù)收集類型的要求、對資源調(diào)度任務(wù)的要求等等。
上文看到意圖層和策略層相互之間有緊密的關(guān)聯(lián),策略層向意圖層提供全場景的數(shù)據(jù),以便意圖層能夠基于全面準(zhǔn)確的場景進(jìn)行大數(shù)據(jù)分析和人工智能處理,從而做出深刻洞察,輔助管理員生成正確的意圖;而意圖層向策略層下達(dá)以策略形式表現(xiàn)的意圖以便后者正確執(zhí)行諸如數(shù)據(jù)收集、資源優(yōu)化和運(yùn)維管理等工作。二者形成了一種數(shù)據(jù)生成意圖、意圖驅(qū)動任務(wù)、任務(wù)數(shù)據(jù)反饋的智能閉環(huán)系統(tǒng),這正是Gartner 在“Innovation Insights”(ID: G00323513)報告中所描繪的“基于意圖的網(wǎng)絡(luò)”在整個IT 架構(gòu)中的擴(kuò)展。
“用例”(Use Cases)代表了數(shù)字化轉(zhuǎn)型中IT 架構(gòu)對業(yè)務(wù)支撐的具體任務(wù)和目標(biāo),常見的用例包括應(yīng)用體驗(yàn)優(yōu)化、ITaaS上線、業(yè)務(wù)沖擊分析、云遷移、云安全等等。
框架中意圖層、策略層和多云架構(gòu)層之間都是通過API 類方式互動,少量用例可預(yù)置于產(chǎn)品,更為通用的用例則必須通過編程實(shí)現(xiàn)軟件定義。因此每一個用例都相當(dāng)于一個具體的“應(yīng)用”,應(yīng)采用敏捷開發(fā)、精益理論的思想和方法論,以現(xiàn)代云原生軟件的開發(fā)方式實(shí)現(xiàn)持續(xù)集成、持續(xù)交付和部署(CI/CD),實(shí)現(xiàn)Infrastructure as Code 的理想模式。這些“應(yīng)用”最終應(yīng)被企業(yè)集成到更高階的IT 服務(wù)架構(gòu)體系中,作為IT 即服務(wù)(ITaaS)框架[2]的一部分,與企業(yè)的IT 治理、企業(yè)架構(gòu)(EA)融為一個有機(jī)整體,并成為企業(yè)數(shù)字化轉(zhuǎn)型的基礎(chǔ)和核心力量。
大部分用戶體驗(yàn)的惡化來自于多個子系統(tǒng)的“亞健康”而非單一子系統(tǒng)完全失效,即便手中握有強(qiáng)大的監(jiān)測工具,這些故障也往往令只關(guān)注單一子系統(tǒng)的工程師束手無策?!坝撵`丟包”就是多系統(tǒng)“亞健康”的典型案例,與網(wǎng)絡(luò)完全斷掉不同,隨機(jī)丟包會出現(xiàn)在多個線路、多個應(yīng)用上,也會隨時間突然消失,但用戶體驗(yàn)卻受到嚴(yán)重影響。這類故障使用傳統(tǒng)診斷需要幾十個小時,但建立了上文的IT 架構(gòu)后,意圖層端到端應(yīng)用監(jiān)測工具會發(fā)現(xiàn)用戶體驗(yàn)指標(biāo)下降,它雖不知道故障發(fā)生的原因和具體位置,但它可以以應(yīng)用視角將涉及的具體檢測目標(biāo)作為“意圖”交給策略層中專業(yè)的控制器,這些信息可以是具體的IP 地址、協(xié)議名稱和端口號,策略層中的SDN 控制器,在有了具體意圖后就可以用比日常強(qiáng)度高數(shù)倍的監(jiān)測和分析手段進(jìn)行深入挖掘。筆者所經(jīng)歷的案例中就通過這一手段快速找到“幽靈丟包”根源——系統(tǒng)部門和網(wǎng)絡(luò)部門對網(wǎng)卡雙活認(rèn)識的分歧導(dǎo)致網(wǎng)絡(luò)哈希算法后一部分包隨機(jī)的被引導(dǎo)到了錯誤的網(wǎng)卡上,整個自動化診斷過程只花費(fèi)幾分鐘,成功避免了用戶體驗(yàn)的進(jìn)一步惡化。
以用戶體驗(yàn)為中心的IT 架構(gòu)的核心是一套基于意圖的IT 資源調(diào)度框架和可軟件定義的子系統(tǒng)溝通模式,隨著企業(yè)數(shù)字化轉(zhuǎn)型的深入,該IT 架構(gòu)必將發(fā)揮日益顯著的作用。