DeepFlow 助力四川银行构建业务交易全链路观测体系

一笔交易响应变慢，问题究竟出在应用处理、下游服务、数据库，还是网络？随着银行核心系统走向云原生、分布式与国产化架构，交易背后的调用路径越来越长，保障业务连续性，需要把客户感知到的异常与技术运行证据快速联系起来。

DeepFlow 助力四川银行新一代信息科技工程建设，构建覆盖金融信创云 2000 余个节点的全栈可观测平台，以业务交易串联应用、系统与网络数据。在这一基础上，进一步推进业务连续性观测智能体建设，将全链路数据与面向场景的智能分析相结合，推动运维工作围绕业务影响、异常原因和恢复情况陆续展开。

一、新架构下的运维挑战要沿着交易链路解决

新一代信息科技工程建设范围涵盖云基础设施、分布式应用和核心交易系统。应用容器化，以及操作系统、中间件、数据库等技术栈的国产化演进，为业务发展提供了新的技术基础，同时也面临运行环境多样、服务依赖复杂、交易链路难以贯通观测的挑战。

在这样的环境中，一笔交易需要经过多个应用服务，并依赖容器、虚拟机、宿主机、网络和数据库等资源。某个环节的时延增加，可能沿调用关系传导，最终表现为业务响应变慢。运维团队既要找到异常位置，也要判断关联了哪些业务、影响持续了多久。

传统监控体系中，基础指标、应用调用、日志和网络数据往往分散在不同工具内。排查人员需要跨页面查找、跨专业核对，才能逐步还原问题。多语言应用与复杂基础设施并存，也使依赖应用改造的采集方式面临覆盖和维护上的挑战。

因此构建一套能够沿业务交易横向追踪调用、纵向关联技术栈的观测体系是关键，让业务现象与底层证据在同一视角下呈现，为快速判断和协同排障提供依据。

二、DeepFlow 以业务交易连接全栈运行数据

2.1 从业务表现追踪到异常环节

基于 DeepFlow 将业务、应用、系统与网络数据纳入统一观测体系。运维人员可以从交易或服务出发，沿业务网关、应用服务、中间件和数据库等调用环节展开分析，并关联其承载的容器、虚拟机、宿主机及网络资源。

当业务响应时延升高时，团队能够沿调用路径查看耗时分布，进一步核对下游依赖、数据库访问、系统资源和网络传输等情况；发现底层异常后，也可以借助业务拓扑查看相关服务。业务表现与技术证据由此建立联系，帮助不同专业的人员围绕同一对象、同一时段开展分析。>>>>

2.2 减少改造依赖 适应云原生与国产化

DeepFlow 通过 eBPF 等技术采集应用、系统和网络运行数据，减少对业务代码埋点和改造的依赖，为多语言应用和多类基础设施提供统一观测基础。统一的资源标识、业务拓扑和时间范围，进一步将各层数据关联起来，减少人工拼接信息的工作。

结合 WebAssembly 可编程能力，平台可按业务观测需求提取相关信息，将技术侧调用情况与交易成功率、响应时延、吞吐量和错误率等业务表现联系起来。运维人员能够先了解业务健康状况，再进入具体链路和异常环节，按需下钻运行证据。>>>>

2.3 让同一套观测数据贯穿日常运行

这套体系既支撑日常监测，也用于投产切换、性能波动和故障分析。正常运行时，持续关注业务指标和服务依赖；发生异常时，沿已有对象与时间范围开展追踪和对比。应用、系统和网络团队能够共享分析依据，减少重复取数与口径核对，为后续智能体调用查询、诊断能力奠定基础。

三、全链路观测为智能体提供可验证的分析依据

统一观测解决了数据关联的问题。面对不断增加的系统和依赖关系，如何更高效地使用这些数据，成为运维能力进一步提升的方向。在 DeepFlow 平台基础上，推进业务连续性观测智能体建设，围绕智能巡检、告警诊断、链路分析和智能问数组织场景能力。

智能体的作用贯穿一次分析任务：理解运维人员提出的问题，确认业务对象和异常时段，结合已有线索选择查询步骤，再根据工具返回的证据决定继续下钻还是调整方向。DeepFlow 提供的拓扑、指标、链路及相关运行数据，使这些分析步骤能够落到具体对象和真实证据上。>>>>

3.1 从自然语言问题进入业务分析

运维人员可以围绕某项业务的响应变化、服务状态或历史趋势提出问题。智能体明确对象与时间范围后，通过获准使用的工具开展查询、对比和分析，并整理结果。数据筛选、统计计算与链路诊断由平台工具完成，智能体负责组织步骤和解释证据，帮助人员减少跨页面查询与手工汇总。>>>>

3.2 从巡检线索接续到链路诊断

智能巡检按计划检查重要业务，关注业务健康、长尾交易和风险线索。发现异常后，检查对象、时间范围和相关证据可以随任务进入告警诊断或链路分析，减少重新描述问题和重复查找数据。

不同场景围绕同一业务对象接续工作：查询提供线索，巡检发现变化，告警触发分析，链路追踪进一步核对异常位置和依赖关系。全链路观测数据成为这些任务共同使用的事实基础。>>>>

3.3 从排障经验走向可复用的分析方法

业务说明、指标解释、排障手册和历史案例，可以帮助智能体选择验证方向；当前原因是否成立，仍需与实时数据核对。分析结果保留关键证据、候选原因和待确认事项，由责任人员复核。经确认的处理方法可进一步补充为场景知识，使一次排障的积累能够服务于后续同类问题。

四、围绕一次交易变慢连接分析与恢复验证

以交易响应变慢为例，全链路观测与智能体相结合的分析方式，可以先确认异常业务和时段，对比时延、错误率与吞吐量，界定问题范围；随后沿业务拓扑追踪上下游调用，核对耗时变化及关联资源状态，根据每一步证据继续下钻。

这一过程能够将排查中的关键问题串联起来：异常集中在哪个环节，是否来自下游依赖，系统和网络是否存在关联变化，现有证据是否足以支持判断。最终形成的结果同时呈现业务现象、关键证据、候选原因与处置建议，供专业人员复核。

生产操作继续执行银行既有审批流程。处置完成后，再围绕同一业务对象核对指标和链路表现，验证恢复情况。这样的分析方式，让故障定位与业务恢复衔接起来，也让事后复盘拥有可回查的依据。

智能体建设采用行内部署方式，沿用现有权限与审计要求。日常分析以只读任务为主，工具调用和查询范围受控，任务支持暂停或中止，使智能分析能够融入银行既有运维管理流程。

五、从看清交易链路到提升业务连续性保障能力

自 DeepFlow 全栈可观测平台 2024 年 9 月上线以来，已覆盖金融信创云 2000 余个节点，为核心系统迁移与持续运行提供支撑，并用于系统切换、存款业务故障等生产问题的排查。

这一实践的价值，体现在业务与技术视角的连接：运维人员能够从交易表现进入调用路径，再关联底层运行证据；应用、系统和网络团队能够共享数据依据，协同缩小问题范围。持续积累的全链路数据，也为巡检、查询和诊断等智能体场景提供了可复用的能力基础。

DeepFlow 以业务交易全链路观测连接运行事实与运维行动，为银行在云原生和国产化架构下提升金融业务连续性保障能力提供支撑。