构建数字化转型企业以用户体验为中心的IT 架构

时间：2024-05-04

魏航刘军思科科技有限公司

1 引言

在现代市场竞争下，人们在任何地方得到的一次最佳体验，很可能就会成为下一次在其他地方对体验的最低期望，这意味着企业要想在开放竞争的市场中胜出，就必须进行自己的数字化转型，重新思考客户最看重的是什么，并创建能够充分利用竞争差异化优势的新运营模式。因此一直以来搭建以用户体验为中心的IT 架构都是企业数字化转型的核心议题。

2 当前建设思路的误区

当前主要有两类思路实现以用户体验为中心的IT 架构。最为主流的思路是不断完善IT 各个子系统的运维水平，包括遥测（Telemetry）、深度学习、形式化分析、自动化响应等技术和工具的使用，能够及时发现和优化影响用户体验的各项指标。但是将用户的宏观体验量化为子系统的微观指标是一直以来的难点，即便近年流行的利用深度学习建立基线的技术也仅能为正常情况建模而无法准确预测体验恶化临界点的位置。为了避免频繁误报，子系统的健康阈值往往制定得极为宽松，导致最终用户体验不可控。

另一种思路则采用从全局系统角度出发、端到端测量用户体验，但这类方案需要对应用部署深层探针，一直以来都是开发团队做非功能性测试的工具，产品定位上直接忽略前述IT 子系统在监测管理上的各种手段，因而即便发现用户体验恶化，但对下层子系统故障点的定位和修复仍需漫长的周期，无疑将影响最终用户体验。

3 以用户体验为中心的IT 架构

以上两类问题的根源在于IT 的应用开发部门（Dev）和系统运维部门（Ops）根深蒂固的隔阂，虽然早在2003 年谷歌就在《站点可靠性工程》一书中提出了Dev 和Ops 相互融合的观点，但近年也仅在互联网行业中少量敏捷开发类应用上部分实现，大部分传统企业都见不到真正的DevOps。主要原因在于缺少一套方法论框架（如图1 所示），以及框架中的核心技术基础——“软件定义一切”（SDx）。本文将对此概要阐述。

图1 ：以用户体验为中心的IT 方法论框架

3.1 策略层

首先整个体系需要建立在一套已经实现了现代化软件定义的基础架构之上，这类系统具有非常典型的特征——拥有一层屏蔽底层复杂机制、向外暴露抽象化功能的API 接口、并可对其编程实现策略驱动功能的“策略层”（Policy Layer）。策略层与被策略层控制的子系统具备如下特征：

由一系列子系统的自动化控制器/引擎构成；

控制器与其所直接控制的底层资源之间构成多个相对独立的子系统；

每一个子系统遵循软件开发中的面向对象模块化特征，对内高聚合、对外低耦合；

高聚合的子系统内部最大自由度的实现专有、开放或开源的功能，包括之前所述高度发展的监测管理手段，不受其他子系统制约；

子系统通过策略层的控制器对外暴露开放的API 接口，将内部功能抽象，可通过软件编程对其进行定义，实现各类复杂功能组合；

每个子系统作为一个整体可迭代、可替换。

3.2 意图层

在策略层之上是一层由数据驱动的“意图层”（Intent Layer），具备如下特征：

由一系列跨子系统、基于数据实现分析和处理的洞察类控制器/引擎构成；

广泛采用最新的大数据处理、深度学习、形式化分析等智能处理手段，对基于现实场景的数据进行深刻的洞察；

具备良好的可视化表现能力，将洞察以更为直观的形式向管理员展示；

独立或由人类辅助生成高阶“意图”，并通过可编程方式将意图或体现意图的策略输送给策略层，以便后者能够自动化的、精确的执行意图；

意图是包含具备特定目的的高阶策略的集合，采用陈述式（Declarative）而非命令式（Imperative）的表达。它描述系统最终的目标状态而非状态迁移的具体过程。意图包含了丰富的功能，包括对数据收集类型的要求、对资源调度任务的要求等等。

3.3 策略层和意图层的关系

上文看到意图层和策略层相互之间有紧密的关联，策略层向意图层提供全场景的数据，以便意图层能够基于全面准确的场景进行大数据分析和人工智能处理，从而做出深刻洞察，辅助管理员生成正确的意图；而意图层向策略层下达以策略形式表现的意图以便后者正确执行诸如数据收集、资源优化和运维管理等工作。二者形成了一种数据生成意图、意图驱动任务、任务数据反馈的智能闭环系统，这正是Gartner 在“Innovation Insights”（ID： G00323513）报告中所描绘的“基于意图的网络”在整个IT 架构中的扩展。

3.4 用例

“用例”（Use Cases）代表了数字化转型中IT 架构对业务支撑的具体任务和目标，常见的用例包括应用体验优化、ITaaS上线、业务冲击分析、云迁移、云安全等等。

3.5 软件定义一切

框架中意图层、策略层和多云架构层之间都是通过API 类方式互动，少量用例可预置于产品，更为通用的用例则必须通过编程实现软件定义。因此每一个用例都相当于一个具体的“应用”，应采用敏捷开发、精益理论的思想和方法论，以现代云原生软件的开发方式实现持续集成、持续交付和部署（CI/CD），实现Infrastructure as Code 的理想模式。这些“应用”最终应被企业集成到更高阶的IT 服务架构体系中，作为IT 即服务（ITaaS）框架[2]的一部分，与企业的IT 治理、企业架构（EA）融为一个有机整体，并成为企业数字化转型的基础和核心力量。

4 案例分析

大部分用户体验的恶化来自于多个子系统的“亚健康”而非单一子系统完全失效，即便手中握有强大的监测工具，这些故障也往往令只关注单一子系统的工程师束手无策。“幽灵丢包”就是多系统“亚健康”的典型案例，与网络完全断掉不同，随机丢包会出现在多个线路、多个应用上，也会随时间突然消失，但用户体验却受到严重影响。这类故障使用传统诊断需要几十个小时，但建立了上文的IT 架构后，意图层端到端应用监测工具会发现用户体验指标下降，它虽不知道故障发生的原因和具体位置，但它可以以应用视角将涉及的具体检测目标作为“意图”交给策略层中专业的控制器，这些信息可以是具体的IP 地址、协议名称和端口号，策略层中的SDN 控制器，在有了具体意图后就可以用比日常强度高数倍的监测和分析手段进行深入挖掘。笔者所经历的案例中就通过这一手段快速找到“幽灵丢包”根源——系统部门和网络部门对网卡双活认识的分歧导致网络哈希算法后一部分包随机的被引导到了错误的网卡上，整个自动化诊断过程只花费几分钟，成功避免了用户体验的进一步恶化。