摘要： 金融行业信创迁移过程中，故障定界困难、定位周期长、开发测试速度缓慢、生产运行风险高等因素正在不断地拖慢相关工作的效率和速度。如何让金融科技部门的业务信创迁移更快、更高效、更平滑？DeepFlow 通过 eBPF 带来的零侵扰、全栈、全链路可观测性技术，可以大幅度提升信创全系统的可观测性，从根本上扫除信创道路上故障诊断的技术阻碍。通过本篇案例您将了解到，某股份制银行在分布式核心交易业务向信创平台迁移的开发测试过程中，如何通过 DeepFlow 平台仅用 3 分钟时间将某次故障根因锁定到分布式核心数据库，快速消除不同运维技术栈之间的定位分歧，快速解决故障，加速开发测试速度。
01 信创迁移的核心矛盾
随着金融行业信创工作的不断推进，各银行的交易系统、支撑系统、基础服务系统正在加速信创迁移工作，但信创业务系统各种兼容适配的未知、不断涌现的异常、故障定位的困难正在不断地拖慢开发、迁移的效率和速度，成为信创工作的核心矛盾。
解决核心矛盾，加速信创工作效率和速度的关键在于，在开发测试、系统上线、业务迁移、生产运行的全生命周期中，提升信创系统的全栈可观测性，做到分钟级的故障诊断和 100% 的故障消除，不断提升系统的迭代演进速度。
某股份制银行的科技部门，通过 DeepFlow 可观测性平台带来的零侵扰、全栈、全链路、无抽样、精细化的可观测性数据，结合 “5W 故障诊断方法”，不仅打通了信创业务应用、中间件、分布式数据库以及信创平台的运维数据鸿沟，而且打破了不同技术栈之间的运维边界，最终实现了分钟级、任意异常的故障根因诊断，让应用服务纤毫必现，真正做到了分钟级的故障定界定位诊断能力，从根本上扫除了信创道路的技术阻碍。
通过一次对分布式核心交易系统 XX 中心子系统上线华为信创云前的非功能测试（性能压测）故障诊断复盘，可以“管中窥豹”，了解到在信创迁移过程中，DeepFlow 可观测性平台如何对具体故障快速诊断、快速定位、加速开发测试。
02 某银行 XX 子系统信创迁移中的故障
某股份制银行的分布式核心交易系统信创迁移工作计划安排紧密、任务繁重，在近日分布式 XX 中心子系统上线华为信创云的工作即将到达项目计划的截止日期时，却在上线前的非功能测试（性能压测）过程中遇到业务响应时延不定时劣化的异常，严重影响分布式核心交易系统信创迁移的整体工作进度，迫切需要快速清除投产上线的绊脚石。
开发项目组在故障诊断中先后将应用程序、华为信创云、云网络列为怀疑的对象，但经过各技术栈的反复诊断定位，均未发现异常。
后来又猜测国产分布式数据库可能是故障根因，但数据库运维团队检查日志后却反馈：未找到慢响应日志，业务响应时延劣化应该与数据库无关。
至此，经过连续一周的诊断定位，故障在各个团队间流转一遍之后，没有头绪，诊断工作回到原点。
于是，分布式 XX 中心子系统的开发工程师开始在 DeepFlow 平台使用 “5W 故障诊断方法”对业务异常进行端到端的快速诊断。
故障诊断的 “5W 方法”什么是 “5W 故障诊断方法”？
在 DeepFlow 平台中，从宏观到微观有序调阅可观测性数据，逐步回答如下 5 个问题，可以快速、有效诊断出问题根因，称之为“5W 故障诊断方法”：
- Who is in trouble?
- When is it in trouble?
- Which request is in trouble?
- Where is the root position?
- What is the root cause?
03 DeepFlow 故障诊断过程
分布式核心交易系统分布式 XX 中心子系统的业务端到端访问过程如下：
Client使用 SOFARPC 协议访问Gateway的接口；Gateway经过七层负载均衡将 SOFARPC 协议的 Request 转发至App-1的多个 Pod 实例；App-1使用 SOFARPC 协议调用App-2；App-1使用 MySQL 协议调用DataBase，并完成整个业务处理后向Gateway回复响应结果。
业务端到端访问过程在华为信创云中运行的 DeepFlow Agent 通过 eBPF 技术实时采集观测点 1~12 位置每一次应用调用的响应性能，因而可以清晰洞察每一次业务请求端到端过程中在每一个观测点的真实时延，从而用精细的数据快速定位故障。
下面开始在 DeepFlow 可观测性平台使用 “5W 故障诊断方法” 做故障快速诊断。
Step 1：确定首个观测对象
故障诊断的第一步，首先要回答 “Who is in trouble” 的问题，从而确定首个观测的对象。
此次业务响应时延劣化的故障诊断场景中，已明确知道入口 Gateway ——> App-1 的响应时延存在异常，因此将该路径作为首个观测对象。
Who is in trouble?Step 2：RED 指标监控，找出时间点
故障诊断的第二步，要回答 “When is it in trouble” 的问题。
打开 Gateway ——> App-1 路径的右滑窗，并在其中观测 RED 指标（请求量、错误率、响应时延）的历史曲线。
由于分布式核心交易系统的业务质量要求较高，需要保障每一个 Request 的响应时延，因此选择观测“最大时延”，并从历史指标曲线中找出问题发生时间点。
通过观测该路径的最大时延，我们发现在压测阶段周期性出现慢响应（大于 1 秒），于是我们可以将右滑窗的观测时间范围缩小到问题时段（20:20~21:00）。
When is it in trouble?Step 3：调用日志检索，找出慢响应
当确定问题发生时间点之后，第三步便要回答 “Which request is in trouble” 的问题。
进入右滑窗的调用日志进行过滤或排序，找出时延劣化的请求列表，此时发现问题时段出现了十余次慢响应。
Which request is in trouble?Step 4：调用链追踪，找出根因位置
找到劣化的请求列表后，第四步便可以抽样进行调用链追踪，回答 “Where is the root position” 的问题。
在十余次的慢响应调用日志中，选取其中 20:30 发生的一次 9.09s 慢响应做调用链追踪，发现：
观测点 1~观测点 4之间基本无时延差量，说明Gateway ——> App-1无阻塞发生；观测点 5~观测点 8之间基本无时延差量，说明App-1 ——> App-2无阻塞发生；观测点 5的右端出现 9.09s 空缺，说明App-1收到App-2的 SOFARPC 响应后间隔 9.09s 方才向Gateway回复最终响应。
因此，我们可以确定 App-1 的 观测点 5 右侧的 9.09s 空缺是此次慢响应的根因位置。
Where is the root position?Step 5：调用日志检索，锁定数据库
第五步回答 “What is the root cause” 的问题。
在 App-1 的 观测点 5 右侧出现 9.09s 空缺的原因可能有 2 个：
App-1自身的 Work 线程处理慢App-1向后端DataBase的调用响应慢
由于 App-1 采用跨线程异步模式且 MySQL 请求中未插入 TraceID，调用链追踪在此中断，所以调用链追踪火焰图中未出现 观测点 9 ~ 观测点 12，由此可以判断：空缺的 9s 很有可能大量消耗在 App-1 向后端 DataBase 的调用过程。
手动检索 App-1 ——> DataBase 在此 9.09s 范围内的调用日志，确认是否存在 DataBase 慢响应。
What is the root cause?通过调用日志检索，发现在问题时段，观测点 12 连续出现 3.98s、2.21s 两次数据库慢响应。
可以得出根因结论： 数据库慢响应导致分布式 XX 中心子系统偶发性应用慢响应。
至此，问题根因得以快速锁定和处置。
04 总结
DeepFlow 全栈、全链路、无抽样观测能力，使得开发人员和运维人员可以对任意调用在全栈、全链路位置的响应性能进行追踪和对比分析，用精细的数据诊断出每一次调用异常的故障根因，从而让应用服务纤毫必现！
DeepFlow 的精细数据结合大量用户实践总结的 “5W 故障诊断方法”，打通 metrics、tracing、logs、profiling 等观测数据的鸿沟，从而以分钟级的速度完成故障的有序、高效诊断。
并且 DeepFlow 通过 eBPF 带来的零侵扰、无需插码的技术特点，让数据库的观测数据采集变得轻松容易，从而打通 DBA 与应用侧的运维边界，实现数据库与应用的统一观测能力和端到端诊断能力。
全技术栈统一的诊断操作流、纤毫必现的诊断能力、分钟级的诊断速度，扫除信创道路的技术阻碍，飞速提升信创工作效率，信创迁移不再困难！
05 什么是 DeepFlow
DeepFlow 是云杉网络开发的一款可观测性产品，旨在为复杂的云原生及 AI 应用提供深度可观测性。DeepFlow 基于 eBPF 实现了应用性能指标、分布式追踪、持续性能剖析等观测信号的零侵扰（Zero Code）采集，并结合智能标签（SmartEncoding）技术实现了所有观测信号的全栈（Full Stack）关联和高效存取。使用 DeepFlow，可以让云原生及 AI 应用自动具有深度可观测性，从而消除开发者不断插桩的沉重负担，并为 DevOps/SRE 团队提供从代码到基础设施的监控及诊断能力。
GitHub 地址：https://github.com/deepflowio/deepflow
访问 DeepFlow Demo，体验零侵扰、全栈的可观测性。
