魏航 劉軍 思科科技有限公司

1 引言

在現(xiàn)代市場競爭下，人們在任何地方得到的一次最佳體驗，很可能就會成為下一次在其他地方對體驗的最低期望，這意味著企業(yè)要想在開放競爭的市場中勝出，就必須進(jìn)行自己的數(shù)字化轉(zhuǎn)型，重新思考客戶最看重的是什么，并創(chuàng)建能夠充分利用競爭差異化優(yōu)勢的新運營模式。因此一直以來搭建以用戶體驗為中心的IT 架構(gòu)都是企業(yè)數(shù)字化轉(zhuǎn)型的核心議題。

2 當(dāng)前建設(shè)思路的誤區(qū)

當(dāng)前主要有兩類思路實現(xiàn)以用戶體驗為中心的IT 架構(gòu)。最為主流的思路是不斷完善IT 各個子系統(tǒng)的運維水平，包括遙測（Telemetry）、深度學(xué)習(xí)、形式化分析、自動化響應(yīng)等技術(shù)和工具的使用，能夠及時發(fā)現(xiàn)和優(yōu)化影響用戶體驗的各項指標(biāo)。但是將用戶的宏觀體驗量化為子系統(tǒng)的微觀指標(biāo)是一直以來的難點，即便近年流行的利用深度學(xué)習(xí)建立基線的技術(shù)也僅能為正常情況建模而無法準(zhǔn)確預(yù)測體驗惡化臨界點的位置。為了避免頻繁誤報，子系統(tǒng)的健康閾值往往制定得極為寬松，導(dǎo)致最終用戶體驗不可控。

另一種思路則采用從全局系統(tǒng)角度出發(fā)、端到端測量用戶體驗，但這類方案需要對應(yīng)用部署深層探針，一直以來都是開發(fā)團隊做非功能性測試的工具，產(chǎn)品定位上直接忽略前述IT 子系統(tǒng)在監(jiān)測管理上的各種手段，因而即便發(fā)現(xiàn)用戶體驗惡化，但對下層子系統(tǒng)故障點的定位和修復(fù)仍需漫長的周期，無疑將影響最終用戶體驗。

3 以用戶體驗為中心的IT 架構(gòu)

以上兩類問題的根源在于IT 的應(yīng)用開發(fā)部門（Dev）和系統(tǒng)運維部門（Ops）根深蒂固的隔閡，雖然早在2003 年谷歌就在《站點可靠性工程》一書中提出了Dev 和Ops 相互融合的觀點，但近年也僅在互聯(lián)網(wǎng)行業(yè)中少量敏捷開發(fā)類應(yīng)用上部分實現(xiàn)，大部分傳統(tǒng)企業(yè)都見不到真正的DevOps。主要原因在于缺少一套方法論框架（如圖1 所示），以及框架中的核心技術(shù)基礎(chǔ)——“軟件定義一切”（SDx）。本文將對此概要闡述。

圖1 ：以用戶體驗為中心的IT 方法論框架

3.1 策略層

首先整個體系需要建立在一套已經(jīng)實現(xiàn)了現(xiàn)代化軟件定義的基礎(chǔ)架構(gòu)之上，這類系統(tǒng)具有非常典型的特征——擁有一層屏蔽底層復(fù)雜機制、向外暴露抽象化功能的API 接口、并可對其編程實現(xiàn)策略驅(qū)動功能的“策略層”（Policy Layer）。策略層與被策略層控制的子系統(tǒng)具備如下特征：

由一系列子系統(tǒng)的自動化控制器/引擎構(gòu)成；

控制器與其所直接控制的底層資源之間構(gòu)成多個相對獨立的子系統(tǒng)；

每一個子系統(tǒng)遵循軟件開發(fā)中的面向?qū)ο竽K化特征，對內(nèi)高聚合、對外低耦合；

高聚合的子系統(tǒng)內(nèi)部最大自由度的實現(xiàn)專有、開放或開源的功能，包括之前所述高度發(fā)展的監(jiān)測管理手段，不受其他子系統(tǒng)制約；

子系統(tǒng)通過策略層的控制器對外暴露開放的API 接口，將內(nèi)部功能抽象，可通過軟件編程對其進(jìn)行定義，實現(xiàn)各類復(fù)雜功能組合；

每個子系統(tǒng)作為一個整體可迭代、可替換。

3.2 意圖層

在策略層之上是一層由數(shù)據(jù)驅(qū)動的“意圖層”（Intent Layer），具備如下特征：

由一系列跨子系統(tǒng)、基于數(shù)據(jù)實現(xiàn)分析和處理的洞察類控制器/引擎構(gòu)成；

廣泛采用最新的大數(shù)據(jù)處理、深度學(xué)習(xí)、形式化分析等智能處理手段，對基于現(xiàn)實場景的數(shù)據(jù)進(jìn)行深刻的洞察；

具備良好的可視化表現(xiàn)能力，將洞察以更為直觀的形式向管理員展示；

獨立或由人類輔助生成高階“意圖”，并通過可編程方式將意圖或體現(xiàn)意圖的策略輸送給策略層，以便后者能夠自動化的、精確的執(zhí)行意圖；

意圖是包含具備特定目的的高階策略的集合，采用陳述式（Declarative）而非命令式（Imperative）的表達(dá)。它描述系統(tǒng)最終的目標(biāo)狀態(tài)而非狀態(tài)遷移的具體過程。意圖包含了豐富的功能，包括對數(shù)據(jù)收集類型的要求、對資源調(diào)度任務(wù)的要求等等。

3.3 策略層和意圖層的關(guān)系

上文看到意圖層和策略層相互之間有緊密的關(guān)聯(lián)，策略層向意圖層提供全場景的數(shù)據(jù)，以便意圖層能夠基于全面準(zhǔn)確的場景進(jìn)行大數(shù)據(jù)分析和人工智能處理，從而做出深刻洞察，輔助管理員生成正確的意圖；而意圖層向策略層下達(dá)以策略形式表現(xiàn)的意圖以便后者正確執(zhí)行諸如數(shù)據(jù)收集、資源優(yōu)化和運維管理等工作。二者形成了一種數(shù)據(jù)生成意圖、意圖驅(qū)動任務(wù)、任務(wù)數(shù)據(jù)反饋的智能閉環(huán)系統(tǒng)，這正是Gartner 在“Innovation Insights”（ID： G00323513）報告中所描繪的“基于意圖的網(wǎng)絡(luò)”在整個IT 架構(gòu)中的擴展。

3.4 用例

“用例”（Use Cases）代表了數(shù)字化轉(zhuǎn)型中IT 架構(gòu)對業(yè)務(wù)支撐的具體任務(wù)和目標(biāo)，常見的用例包括應(yīng)用體驗優(yōu)化、ITaaS上線、業(yè)務(wù)沖擊分析、云遷移、云安全等等。

3.5 軟件定義一切

框架中意圖層、策略層和多云架構(gòu)層之間都是通過API 類方式互動，少量用例可預(yù)置于產(chǎn)品，更為通用的用例則必須通過編程實現(xiàn)軟件定義。因此每一個用例都相當(dāng)于一個具體的“應(yīng)用”，應(yīng)采用敏捷開發(fā)、精益理論的思想和方法論，以現(xiàn)代云原生軟件的開發(fā)方式實現(xiàn)持續(xù)集成、持續(xù)交付和部署（CI/CD），實現(xiàn)Infrastructure as Code 的理想模式。這些“應(yīng)用”最終應(yīng)被企業(yè)集成到更高階的IT 服務(wù)架構(gòu)體系中，作為IT 即服務(wù)（ITaaS）框架[2]的一部分，與企業(yè)的IT 治理、企業(yè)架構(gòu)（EA）融為一個有機整體，并成為企業(yè)數(shù)字化轉(zhuǎn)型的基礎(chǔ)和核心力量。

4 案例分析

大部分用戶體驗的惡化來自于多個子系統(tǒng)的“亞健康”而非單一子系統(tǒng)完全失效，即便手中握有強大的監(jiān)測工具，這些故障也往往令只關(guān)注單一子系統(tǒng)的工程師束手無策?！坝撵`丟包”就是多系統(tǒng)“亞健康”的典型案例，與網(wǎng)絡(luò)完全斷掉不同，隨機丟包會出現(xiàn)在多個線路、多個應(yīng)用上，也會隨時間突然消失，但用戶體驗卻受到嚴(yán)重影響。這類故障使用傳統(tǒng)診斷需要幾十個小時，但建立了上文的IT 架構(gòu)后，意圖層端到端應(yīng)用監(jiān)測工具會發(fā)現(xiàn)用戶體驗指標(biāo)下降，它雖不知道故障發(fā)生的原因和具體位置，但它可以以應(yīng)用視角將涉及的具體檢測目標(biāo)作為“意圖”交給策略層中專業(yè)的控制器，這些信息可以是具體的IP 地址、協(xié)議名稱和端口號，策略層中的SDN 控制器，在有了具體意圖后就可以用比日常強度高數(shù)倍的監(jiān)測和分析手段進(jìn)行深入挖掘。筆者所經(jīng)歷的案例中就通過這一手段快速找到“幽靈丟包”根源——系統(tǒng)部門和網(wǎng)絡(luò)部門對網(wǎng)卡雙活認(rèn)識的分歧導(dǎo)致網(wǎng)絡(luò)哈希算法后一部分包隨機的被引導(dǎo)到了錯誤的網(wǎng)卡上，整個自動化診斷過程只花費幾分鐘，成功避免了用戶體驗的進(jìn)一步惡化。

5 結(jié)束語

以用戶體驗為中心的IT 架構(gòu)的核心是一套基于意圖的IT 資源調(diào)度框架和可軟件定義的子系統(tǒng)溝通模式，隨著企業(yè)數(shù)字化轉(zhuǎn)型的深入，該IT 架構(gòu)必將發(fā)揮日益顯著的作用。