金融信創(chuàng)是金融機構(gòu)重點投入以及技術(shù)迭代的方向，經(jīng)過多年階段迭代，進入難度更大的核心系統(tǒng)、關(guān)鍵業(yè)務(wù)系統(tǒng)的更替階段。DeepFlow 解決行業(yè)中普遍存在的分布式交易系統(tǒng)保障難、平臺雙軌多芯調(diào)優(yōu)難、云上資源把控難、分布式數(shù)據(jù)庫追蹤難等挑戰(zhàn)。

01  |   什么是 DeepFlow

DeepFlow 是一款高度自動化的一站式可觀測性平臺，旨在為復(fù)雜的云基礎(chǔ)設(shè)施及云原生應(yīng)用提供深度可觀測性。基于 eBPF 實現(xiàn)了應(yīng)用性能指標、分布式追蹤、持續(xù)性能剖析等觀測信號的零侵擾（Zero Code）采集，并結(jié)合智能標簽（SmartEncoding）技術(shù)實現(xiàn)了所有觀測信號的全棧（Full Stack）關(guān)聯(lián)和高效存取。

可以通過 Github（https://github.com/deepflowio/deepflow）了解 DeepFlow 的技術(shù)架構(gòu)以及可觀測性功能特性。

在金融行業(yè)關(guān)鍵業(yè)務(wù)系統(tǒng)測試投產(chǎn)、遷移上云、保障業(yè)務(wù)連續(xù)性、調(diào)優(yōu)升級等不同階段場景中持續(xù)提供觀測服務(wù)保障能力。

02  |   金融銀行業(yè)中面臨的可觀測性挑戰(zhàn)

▌ 關(guān)鍵業(yè)務(wù)系統(tǒng)升級上云后保障業(yè)務(wù)連續(xù)性

云平臺建設(shè)和試運行后，對于應(yīng)用遷移上云，金融客戶都是有嚴格的分階段及并發(fā)運行計劃。辦公、一般業(yè)務(wù)系統(tǒng)都逐步在云上運行，金融客戶也對云及云原生應(yīng)用深刻掌握。核心系統(tǒng)、關(guān)鍵業(yè)務(wù)系統(tǒng)在云上運行的計劃也都進入了實際落地的快車道。微服務(wù)化的核心系統(tǒng)一般都提供公共內(nèi)核服務(wù)、業(yè)務(wù)單元服務(wù)等，每個微服務(wù)都能獨立部署、運行及擴展，為銀行提供了靈活的業(yè)務(wù)擴展、系統(tǒng)整合及生態(tài)開放能力。

保障業(yè)務(wù)連續(xù)性始終是金融行業(yè)技術(shù)運營部門開展工作的核心，對信息系統(tǒng)有效監(jiān)控及告警是重要保障手段。絕大多數(shù)金融機構(gòu)科技運營部門都是以技術(shù)棧進行部門劃分，比如網(wǎng)絡(luò)、系統(tǒng)、應(yīng)用等，在邊界清晰的條件下，可以專注并深入地發(fā)揮技術(shù)能力。但資源池化、分布式以及微服務(wù)化后，技術(shù)邊界交疊融合，在保障業(yè)務(wù)連續(xù)性過程中，從單一技術(shù)棧視角難以全面洞察業(yè)務(wù)運行狀態(tài)。監(jiān)控需要多維度、多層面的數(shù)據(jù)關(guān)聯(lián)，從故障定界到根因定位，從熱點預(yù)警到容量預(yù)測，每個部門都面臨無從下手的挑戰(zhàn)，經(jīng)常出現(xiàn) "是又不是" 的判斷。部門已有的工具面臨新環(huán)境失效、數(shù)據(jù)收集單一，判斷依據(jù)不足等問題。面對已經(jīng)上線的業(yè)務(wù)，亟需系統(tǒng)化的、貼合的手段來保障。新型業(yè)務(wù)應(yīng)用對監(jiān)控效率、部門協(xié)作提出了全新要求。

▌ 保障信創(chuàng)替換后的系統(tǒng)性能

以金融信創(chuàng)的重要軟件部分數(shù)據(jù)庫為例，關(guān)系到金融業(yè)務(wù)系統(tǒng)的整體功能與性能。分布式數(shù)據(jù)庫將傳統(tǒng)數(shù)據(jù)庫各部分組件進行分布式部署，通過網(wǎng)絡(luò)通信進行協(xié)同工作，在處理及運維上避免了集中式系統(tǒng)的短板，在提升了整體交易能力的吞吐同時，由于組件之間網(wǎng)絡(luò)通信的傳輸成本，也會存在每筆交易請求的處理時間（ART，Application Response Time）增加的風(fēng)險；由于數(shù)據(jù)庫運行的資源節(jié)點增加，也會增加處理交易、事務(wù)及 SQL 語言執(zhí)行的運維管理復(fù)雜度。

▌ 提升操作系統(tǒng)、芯片架構(gòu)選型評估效率

金融銀行業(yè)進入信創(chuàng)關(guān)鍵業(yè)務(wù)替換期，在早期辦公、一般業(yè)務(wù)系統(tǒng)替代的實踐中積累了經(jīng)驗和指標，核心系統(tǒng)、關(guān)鍵業(yè)務(wù)的信創(chuàng)替換后，對穩(wěn)定性、性能要求更加嚴格。由于技術(shù)路線選型將持續(xù)影響后續(xù)IT系統(tǒng)規(guī)劃、建設(shè)及投入，所以在信創(chuàng)評估選型過程中需要格外的謹慎及細致，除了同業(yè)內(nèi)交流對比外，各行也都投入了大量的人力、物力進行評估。

從 CPU、操作系統(tǒng)、數(shù)據(jù)庫、中間件、應(yīng)用系統(tǒng)在不同組合下的運行效果、性能參數(shù)、壓力表現(xiàn)等都需要一手數(shù)據(jù)以明確調(diào)優(yōu)方法；進行局部替換后，對整體業(yè)務(wù)應(yīng)用的影響評估也同樣需要一手數(shù)據(jù)進行判斷。"哪個平臺表現(xiàn)好？"，"資源消耗的熱點函數(shù)是哪個？"需要統(tǒng)一的觀測數(shù)據(jù)收集能力提升評估準確性及效率。

▌ 提升核心系統(tǒng)測試調(diào)優(yōu)效率

分布式系統(tǒng)開發(fā)進入非功能測試階段、上線試運行階段時，就進入了重協(xié)作的工作周期。核心系統(tǒng)、關(guān)鍵業(yè)務(wù)系統(tǒng)上線工作是一個體系工作，涉及到軟件研發(fā)中心、數(shù)據(jù)運營中心、供應(yīng)商等多個部門組織，且有嚴格的規(guī)劃及流程，測試調(diào)優(yōu)效率直接影響上線流程。缺乏對環(huán)境、系統(tǒng)、平臺以及交易應(yīng)用等整體運行數(shù)據(jù)收集、統(tǒng)一視角、關(guān)聯(lián)能力，僅單一視角的工程師在發(fā)揮專業(yè)技能之前，如優(yōu)化數(shù)據(jù)庫查詢、調(diào)整網(wǎng)絡(luò)配置、修改應(yīng)用函數(shù)代碼等工作，通常首要面臨的是難以獨立界定故障、性能瓶頸的邊界和所屬。團隊間會商舉證、工單流轉(zhuǎn)、現(xiàn)象重現(xiàn)、數(shù)據(jù)臨時獲取等都是效率損耗的節(jié)點。在非功能測試環(huán)節(jié)中，讓測試系統(tǒng)具備可觀測性，快速確定性能瓶頸是值得期待的事情。

03  |   技術(shù)

eBPF 技術(shù)是可觀測性的關(guān)鍵技術(shù)，是在多技術(shù)棧融合，分布式核心系統(tǒng)運行在云原生環(huán)境的時間點上，打開了可觀測性實現(xiàn)的技術(shù)窗口。

▌ 什么是 eBPF

eBPF 是一項革命性技術(shù)，不再需要修改編譯內(nèi)核源代碼或者加載內(nèi)核模塊，就可以高效地在內(nèi)核中運行用戶編寫的沙箱程序（Sandbox Programs），并且保證內(nèi)核安全運行。比傳統(tǒng)的內(nèi)核編程更加方便快捷，能基于現(xiàn)有的系統(tǒng)抽象層來打造功能更加豐富的基礎(chǔ)設(shè)施軟件，而不會增加系統(tǒng)的復(fù)雜度，也不會犧牲執(zhí)行效率和安全性。

從實現(xiàn)來看，eBPF 是一個基于寄存器的虛擬機，使用自定義的 64 位指令集，能夠在 Linux 內(nèi)核內(nèi)運行即時編譯的eBPF程序，并能訪問相應(yīng)內(nèi)核函數(shù)和內(nèi)存。在選定內(nèi)核函數(shù)被執(zhí)行時，相應(yīng)的 eBPF 程序也被執(zhí)行，程序的目的豐富多樣，包括網(wǎng)絡(luò)、安全、度量性能、應(yīng)用追蹤等等。

eBPF 解決了在內(nèi)核編程中的經(jīng)常遇到的挑戰(zhàn)，使內(nèi)核釋放出巨大的可能性。在此之前，內(nèi)核編程主要有直接修改內(nèi)核代碼和編寫內(nèi)核模塊兩種方式。直接修改內(nèi)核代碼需要重新編譯內(nèi)核，通過編寫 API 調(diào)用實現(xiàn)應(yīng)用功能，用戶環(huán)境兼容、維護性是一大挑戰(zhàn)，難以在客戶生產(chǎn)環(huán)境中采用。通過加載的內(nèi)核模塊同樣面臨內(nèi)核版本的更新，內(nèi)核 API 的變化，所以內(nèi)核模塊需要隨著每一個內(nèi)核版本的發(fā)布而更新。eBPF 通過嚴格的運行驗證及限制解決了工程師內(nèi)核編程中最大的問題，安全穩(wěn)定問題，釋懷了時刻要小心的 Kernel Panic 惡夢。

▌ eBPF 的演進

eBPF 是由 BP F技術(shù)演進擴展而來（The BSD Packet Filter: A New Architecture for User-level Packet Capture，1992，https://www.tcpdump.org/papers/bpf-usenix93.pdf），BPF 最初是為 Tcpdump 等工具獲取和過濾匹配特定規(guī)則的網(wǎng)絡(luò)數(shù)據(jù)包方法，更多的目的是為了處理內(nèi)核中網(wǎng)絡(luò)相關(guān)問題。Alexei Starovoitov 在2014年引入了擴展 BPF（extenal BPF）設(shè)計，可以直接將 BPF 虛擬機開放至用戶空間。在內(nèi)核內(nèi)運行用戶空間程序的能力被證明是非常強大的，eBPF 不僅繼承了 BPF 初衷，適合編寫網(wǎng)絡(luò)程序，可以編寫附加到網(wǎng)絡(luò)套接字以過濾流量、分類流量和運行網(wǎng)絡(luò)分類器操作的程序，甚至可以使用 eBPF 程序修改已建立的網(wǎng)絡(luò)套接字的設(shè)置。而且由于 eBPF 程序可以訪問內(nèi)核數(shù)據(jù)結(jié)構(gòu)，開發(fā)人員可以編寫和測試新的調(diào)試代碼，而無需重新編譯內(nèi)核，具備在幾乎所有類型的事件、內(nèi)核函數(shù)上執(zhí)行特定動作的能力，比如在安全、調(diào)試內(nèi)核和性能分析等方面。

▌ eBPF 的優(yōu)勢

前面提到安全穩(wěn)定問題，這是 eBPF 的技術(shù)優(yōu)勢，eBPF 程序是一個 64 位的指令序列，運行將嚴格考慮到兩個方面：所有的 eBPF 指令在加載時必須是可驗證的，以確保內(nèi)核的安全；eBPF 代碼需要盡可能快地被執(zhí)行。

強安全: BPF 驗證器（BPF Verifier）會保證每個程序能夠安全運行，它會去檢查將要運行到內(nèi)核空間的程序的每一行是否安全可靠，如果檢查不通過，它將拒絕這個程序被加載到內(nèi)核中去，從而保證內(nèi)核本身不會崩潰，這是不同于開發(fā)內(nèi)核模塊的。

高性能: 一旦通過了 BPF 驗證器，那么它就會進入JIT編譯階段，利用 Just-In-Time 編譯器，編譯生成的是通用的字節(jié)碼，它是完全可移植的，可以在 x86 和 ARM 等任意 CPU 架構(gòu)上加載，這樣能獲得本地編譯后的程序運行速度，而且是安全可靠的。

除此之外，為什么說 eBPF 打開了可觀測性實現(xiàn)的技術(shù)窗口，就是在系統(tǒng)平臺層面能夠獲取全棧的運行數(shù)據(jù)，包括應(yīng)用調(diào)用、網(wǎng)絡(luò)拓撲、平臺事件等，云、容器及系統(tǒng)部門天然具備全棧數(shù)據(jù)獲取的角色和使命，這也印證了可觀測性應(yīng)該是云服務(wù)的一個能力。

04  |   DeepFlow 組件

數(shù)據(jù)平臺通常架構(gòu)包括采集端和處理端，DeepFlow 可觀測性平臺也是如此，由 Agent、 Server 兩部分組成，面向云原生環(huán)境，可直接使用云環(huán)境進行部署擴展。完全兼容各類型云平臺、容器平臺以及多語言開發(fā)的應(yīng)用系統(tǒng)。

DeepFlow Agent 組件運行在數(shù)據(jù)收集端，在不侵入應(yīng)用、業(yè)務(wù)資源（容器 PoD、虛擬機等）的條件下，按功能開啟選項收集各類型數(shù)據(jù)，包括網(wǎng)絡(luò)流量、應(yīng)用系統(tǒng)調(diào)用追蹤、CPU 性能剖析、平臺事件、日志等類型數(shù)據(jù)，對數(shù)據(jù)進行分布式預(yù)處理后傳輸至 DeepFlow Server 存儲分析端。

在動輒上萬節(jié)點（容器 Node）規(guī)模的金融環(huán)境中收集數(shù)據(jù)不同于實驗室環(huán)境操作，可用性、安全性、穩(wěn)定性及高性能都是方案選擇的首要條件。Agent 分布式設(shè)計，避免數(shù)據(jù)集中處理架構(gòu)存在的性能瓶頸，零侵入設(shè)計避免對應(yīng)用程序改造和干擾運行，進程方式運行避免對生產(chǎn)業(yè)務(wù)造成運行風(fēng)險。

在以上條件下，各種部署形態(tài)的 DeepFlow Agent 為客戶提供三個核心功能抽象能力：

▌ 數(shù)據(jù)收集抽象層

相比于部署在物理網(wǎng)絡(luò)用于流量分析的重型裝備，云杉流量采集器像是《三體》中描述的質(zhì)子，極簡的部署，極微的體量，卻能捕捉到每個最小交互單元的流量數(shù)據(jù)包。

穩(wěn)定性自不必多說，最終要看客戶實踐及生產(chǎn)應(yīng)用，DeepFlow 率先支持了國內(nèi)最大的金融行業(yè)云的可觀測性建設(shè)，DeepFlow 也是金融銀行業(yè)客戶在可觀測性建設(shè)中被最多選擇的產(chǎn)品。

應(yīng)用全鏈路調(diào)用追蹤始終是運維側(cè)的難題，主要就是代價大以及追不全，主要表現(xiàn)在追蹤需要應(yīng)用改造支持，部門間協(xié)調(diào)數(shù)據(jù)，第三方應(yīng)用，如中間件、數(shù)據(jù)庫沒有辦法插碼追蹤。隨著云原生發(fā)展，數(shù)據(jù)中心的系統(tǒng)部門（云管理部門、容器部門）成為了天選的觀測數(shù)據(jù)收集部門，上至應(yīng)用管理，下至網(wǎng)絡(luò)配置，都融入和平臺之中。eBPF 技術(shù)打開了貫穿上下的技術(shù)窗口，DeepFlow 實現(xiàn)了這點。

▌ 數(shù)據(jù)接入抽象層

并不是所有數(shù)據(jù)都通過 DeepFlow Agent 來收集，客戶通常已經(jīng)投產(chǎn)了很多工具，積累了相應(yīng)的數(shù)據(jù)。通過標準技術(shù)接口接入更多數(shù)據(jù)源數(shù)據(jù)，是更高效地進行數(shù)據(jù)消費，以及降低總體存儲成本、維護成本的選擇。在云原生范疇中，最常見的接入的數(shù)據(jù)就是 Prometheus，猶如 Kubernetes 的雙生子，Prometheus 必然出現(xiàn)在客戶的運維工具中，來監(jiān)控容器資源狀態(tài)。不幸的是，大部分生產(chǎn)環(huán)境中都使用得不是太好，一個主要原因就是不同于測試使用，生產(chǎn)規(guī)模不斷變大后，后端的數(shù)據(jù)處理沒人搞。Prometheus 數(shù)據(jù)寫入 DeepFlow Server 后，第一，Prometheus 數(shù)據(jù)可以關(guān)聯(lián)到更多維度的觀測數(shù)據(jù)；第二，數(shù)據(jù)存儲由 DeepFlow Server 負責(zé)。

▌ 私有解析抽象層

在核心系統(tǒng)以及關(guān)鍵業(yè)務(wù)應(yīng)用中，會面臨私有協(xié)議、交易標識、流水號提取等場景，通過可編程的 Wasm（WebAssembly）組件，熱加載在 DeepFlow Agent 中運行，可以在收集端按需獲取相應(yīng)標識，并上報存儲分析后端 DeepFlow Server。這對更詳盡地獲取應(yīng)用調(diào)用追蹤數(shù)據(jù)并串聯(lián)起來提供了完備的方式，并且對私有協(xié)議解析提供了擴展方式，大大提升私有協(xié)議追蹤的效率。

DeepFlow Server 組件基于 ClickHouse 并優(yōu)化后實現(xiàn)觀測數(shù)據(jù)存儲，再通過 Autotagging 技術(shù)實現(xiàn)自動為多維觀測數(shù)據(jù)注入統(tǒng)一屬性標簽，SmartEncoding 技術(shù)通過標簽與觀測數(shù)據(jù)分離，平衡存儲開銷與查詢體驗。DeepFlow Server 可選擇部署在獨立物理服務(wù)器或者云上資源池中。選擇已有的云上計算服務(wù)是大部分客戶的選擇，可以選擇云上服務(wù)器、容器、SQL 數(shù)據(jù)庫、對象存儲等云上服務(wù)快速完成部署實施。

05  |   方案

數(shù)據(jù)平臺通常架構(gòu)包括采集端和處理端，DeepFlow 可觀測性平臺也是如此，由 Agent、 Server 兩部分組成，面向云原生環(huán)境，可直接使用云環(huán)境進行部署擴展。完全兼容各類型云平臺、容器平臺以及多語言開發(fā)的應(yīng)用系統(tǒng)。

▌ 需求與部署

觀測數(shù)據(jù)收集并不是一味地越多越好，越細越好，這是與訴求、成本相關(guān)的。DeepFlow 可根據(jù)不同場景需求、發(fā)展階段提供可配置的部署選擇，包括觀測功能、目標區(qū)域。DeepFlow 企業(yè)版本提供包括應(yīng)用、網(wǎng)絡(luò)、數(shù)據(jù)庫、CPU 性能、日志等可選功能。

以大多數(shù)保障業(yè)務(wù)連續(xù)性，定界排障的場景為例，DeepFlow Agent 覆蓋完整的交易調(diào)用請求路徑，包括網(wǎng)關(guān)功能區(qū)、計算區(qū)以及數(shù)據(jù)庫區(qū)。根據(jù)實際運行環(huán)境，也可以選擇僅部署計算區(qū)域，重點關(guān)注虛擬機、容器間的請求調(diào)用，再逐步擴大部署范圍。

云內(nèi)流量分析對象是成千上萬的業(yè)務(wù) pod、虛擬機，以及他們之間交互形成的又一個指數(shù)量級的網(wǎng)絡(luò)路徑，想要把這種體量的流量數(shù)據(jù)包發(fā)送出來再進行集中處理計算顯然不是明智的選擇。這就給流量采集器提出了一個更加嚴苛的要求：以極小的資源消耗，保證強大的本地計算能力。DeepFlow 流量采集器在騰訊全棧專有云中進行了完美適配，經(jīng)過現(xiàn)場多輪測試結(jié)果可知：在規(guī)定資源占用的前提下（1C1G），單個流量采集器計算處理能力大于 10Gbps，這無疑是客戶工程師心中的又一粒定心丸。

從覆蓋范圍上看，這種流量采集器部署實現(xiàn)了對整個 A 金融行業(yè)云兩地多區(qū)域的的全面覆蓋。這種規(guī)模是在傳統(tǒng)網(wǎng)絡(luò)流量監(jiān)控角度上難以想象的。采集流量范圍更加廣，管理流量的規(guī)模更加龐大，粒度更加精細化，才能夠適應(yīng)云數(shù)據(jù)中心當(dāng)下的監(jiān)控需求，是新架構(gòu)、新場景下對于網(wǎng)絡(luò)流量監(jiān)控的必然要求。

▌ 運行與服務(wù)

排障僅是 DeepFlow 可觀測性能力在工具價值方面的體現(xiàn)，可觀測性是伴隨云原生、信創(chuàng)改造中長期、體系進行發(fā)展的，圍繞著不斷沉淀的觀測數(shù)據(jù)，不斷開拓、深化觀測應(yīng)用場景，對客戶的服務(wù)體系尤為重要。服務(wù)源自產(chǎn)品領(lǐng)先性、客戶覆蓋及廣泛的生產(chǎn)實踐經(jīng)驗總結(jié)，為客戶在云原生發(fā)展中推動 "觀測數(shù)據(jù)、觀測場景、觀測價值" 飛輪不斷旋轉(zhuǎn)。

▌ DeepFlow 服務(wù)行業(yè)客戶，主要包括觀測工具服務(wù)，觀測數(shù)據(jù)服務(wù)、數(shù)據(jù)底座服務(wù)、觀測智能體服務(wù)四大類。

I. 觀測工具服務(wù)： 目標是幫助客戶使用 DeepFlow 產(chǎn)品，解決監(jiān)控業(yè)務(wù)系統(tǒng)中 "黑盒""盲點""斷鏈" 的直接需求，通常是面對客戶單一部門進行服務(wù)，著重解決客戶在保障業(yè)務(wù)連續(xù)性過程中，對于分布式、微服務(wù)、云原生環(huán)境中監(jiān)控手段缺失或失效的問題，直接對應(yīng)客戶部門的履職和責(zé)任。服務(wù)效果就是 "分鐘級定界故障" 以及洞察系統(tǒng)運行狀態(tài)。

II. 觀測數(shù)據(jù)服務(wù)： 目標是通過數(shù)據(jù)提升客戶部門間的協(xié)作效率。所服務(wù)的金融銀行業(yè)客戶，主要是一部兩中心的架構(gòu)，研發(fā)中心、數(shù)據(jù)中心都會根據(jù)技術(shù)棧進行劃分部門，單一技術(shù)棧雖然具備專業(yè)深度但在總體狀態(tài)上存在局限性。觀測數(shù)據(jù)服務(wù)就是有效對接各技術(shù)棧現(xiàn)有的工作流程、運維工具，這并不是一個簡單的技術(shù)工具問題，而是服務(wù)能力。首先要解決的就是多部門的"數(shù)據(jù)信任"，通常需要"事實說話"，在第一類別服務(wù)過程中，確實體會到想要的"盲點"數(shù)據(jù)通過 DeepFlow 可以快速獲取，并準確地、高效地解決過手頭問題。其次就是對接數(shù)據(jù)，"缺啥補啥"，將觀測數(shù)據(jù)融入到各部門的已有工具和工作流程中。在云杉的服務(wù)過程實踐中，在業(yè)務(wù)系統(tǒng)上線、技術(shù)選型場景中，都實現(xiàn)了跨中心的多部門數(shù)據(jù)服務(wù)。服務(wù)效果就是幫助各部門在工作中輕松得到想要的缺失數(shù)據(jù)。

III. 數(shù)據(jù)底座服務(wù)： 目標是通過 DeepFlow 數(shù)據(jù)接入能力關(guān)聯(lián)更多數(shù)據(jù)源，降低客戶數(shù)據(jù)總體存儲成本，結(jié)合觀測工具服務(wù)、觀測數(shù)據(jù)服務(wù)提升數(shù)據(jù)使用效率。服務(wù)效果是有效沉淀客戶生產(chǎn)IT系統(tǒng)的私有運行數(shù)據(jù)并結(jié)構(gòu)化、語義化，以具備智能應(yīng)用的數(shù)據(jù)基礎(chǔ)。

IV. 觀測智能體服務(wù)： 目標是在具備數(shù)據(jù)與智能大模型的條件下，迅速在客戶選擇的智能平臺上運行面向運維體系的智能應(yīng)用。保證智能應(yīng)用不至于 "表面繡花"，真正起到躍層提升效率的效果，場景化以及融入工作流程尤其重要。服務(wù)效果是在明確的場景或環(huán)節(jié)中替換目前對觀測數(shù)據(jù)的人工分析工作。

06  |   價值

▌ 云建設(shè)及試運行階段

"不僅僅聽云服務(wù)商的說法"

在驗證平臺運行是否符合需求及預(yù)期過程中，DeepFlow 最大的價值是獨立、客觀地支撐客戶進行驗證及優(yōu)化平臺，供客觀全棧運行數(shù)據(jù)，獨立于云服務(wù)商進行性能評估及數(shù)據(jù)說明，尤其在網(wǎng)絡(luò)路徑、拓撲呈現(xiàn)、鏈路追蹤、資源匯總提供比對依據(jù)。

▌ 核心系統(tǒng)開發(fā)及調(diào)試階段

"提升非功能測試效率"

優(yōu)化交易響應(yīng)時間是非功能測試中重要的目標，通常銀行交易業(yè)務(wù)每筆交易需要在 60-80ms 中處理完成，每筆交易響應(yīng)過程，需要經(jīng)過多個微服務(wù)調(diào)用，涉及業(yè)務(wù)單元、公共服務(wù)、網(wǎng)絡(luò)傳輸、負載均衡等。輕松串起每筆交易的調(diào)用追蹤，并能有效關(guān)聯(lián)至網(wǎng)絡(luò)、資源、日志等維度數(shù)據(jù)，是每個開發(fā)調(diào)試人員向往的理想環(huán)境，以快速定位性能瓶頸的調(diào)用、資源等，快速發(fā)揮工程師的優(yōu)化手藝。

信創(chuàng)數(shù)據(jù)庫、信創(chuàng)處理器、信創(chuàng)系統(tǒng)等環(huán)境中，對于測試交易過程中，建立統(tǒng)一性能看板，詳細記錄從函數(shù)粒度占用CPU、到調(diào)用請求處理延時的性能數(shù)據(jù)，本質(zhì)改觀分布式系統(tǒng)適配、評估平臺，路線選型的效率瓶頸。

▌ 關(guān)鍵業(yè)務(wù)應(yīng)用上線階段

"明察上線不同環(huán)境后的性能差異"

通常關(guān)鍵業(yè)務(wù)上線是行里的重要事件，涉及開發(fā)中心、數(shù)據(jù)中心以及各服務(wù)商多部門協(xié)作。在上線階段，人員都是各領(lǐng)域的專家，雖然開發(fā)環(huán)境、測試環(huán)境、試運行環(huán)境都是盡可能地統(tǒng)一規(guī)格進行建設(shè)，但經(jīng)過使用運行，仍然存在不可避免的差別，導(dǎo)致上線系統(tǒng)在功能、性能上達不到預(yù)期。雖然多部門的專家都待命，但通常解決問題并不是很順暢且多有反復(fù)。當(dāng)試運行環(huán)境具備觀測能力，對于運行狀態(tài)、測試交易進行實時記錄，每個團隊都有統(tǒng)一的數(shù)據(jù)視角，各技術(shù)棧專家，開發(fā)工程師可以快速獲取上下文，鎖定問題范圍，專業(yè)的工程師都能在自身技術(shù)棧的范圍內(nèi)充分發(fā)揮作用，大大提升判斷瓶頸、復(fù)現(xiàn)問題、修復(fù)補丁、驗證測試等不同環(huán)節(jié)中的協(xié)作效率。

▌ 業(yè)務(wù)應(yīng)用生產(chǎn)運行階段

"分鐘級定界故障"

系統(tǒng)正式上線生產(chǎn)環(huán)境后，進入生產(chǎn)運維保障側(cè)后就是保障業(yè)務(wù)連續(xù)性。經(jīng)過了大量嚴謹?shù)臏y試和上線流程約束后，不會出現(xiàn)重大功能性故障。但既然是系統(tǒng)，由于外界內(nèi)部的因素，總不能保證 100% 穩(wěn)定服務(wù)。大部分客戶都是使用工單，進行運維側(cè)處理各類運維故障的手段流程。避免工單無止盡地在部門間流轉(zhuǎn)，分鐘級定界問題，呈現(xiàn)可信的多維度觀測數(shù)據(jù)，降低 MTTR（Mean Time To Repair，平均修復(fù)時間）。

▌ 運維智能化階段

"不再是人工的智能"

運維經(jīng)驗以及多技術(shù)棧的廣度和深度，束縛著運維效率的提升。DeepFlow Agent、Server 組件低代價完成收集及沉淀觀測數(shù)據(jù)，并進行標記、關(guān)聯(lián)及語義化編碼。觀測數(shù)據(jù)結(jié)合大模型后，即可使用 DeepFlow 智能體，將以上不同場景的數(shù)據(jù)分析工作，轉(zhuǎn)移至群聊中的助理機器人、工單派送中的分發(fā)機器人、排障過程中的根因機器人，總結(jié)過程中的報表機器人來進行，提升運維質(zhì)量及效率。

DeepFlow 產(chǎn)品及服務(wù)伴隨金融行業(yè)客戶的云原生系統(tǒng)及信創(chuàng)發(fā)展，持續(xù)領(lǐng)先，持續(xù)服務(wù)。