业务性能管理领域里的“摩尔定律”和实践

首先我们来看一下业务系统的监控落地需要经过三个阶段。第一阶段是业务系统的梳理。确定监控范围，落地监控对象，理清业务逻辑。第二个阶段是数据源的获取。主要有安装代理、日志分析和网络数据三种方式。 第三阶段是安装配置。这些阶段各占用比例如下图所示。上海天旦秉承着业务性能管理领域的“摩尔定律”，在建设的各个阶段都有独到的实现方法。

业务梳理也是业务性能管理系统落地慢的一个重要原因。 有商业银行的客户曾经做过尝试，投入一个懂网络也了解应用的运维人员去人工梳理一套信用卡系统的基础架构及应用逻辑，总共耗时8个月。而在这8个月中，业务系统的结构进行了改造，梳理的结果无法投入使用。

而梳理的准确性直接影响业务监控的可用性。 监控的实现，一定需要以管理的对象为基础。首先必须知道要管理哪些组件，还需要知道这些组件之间的访问关系。而高速增长的业务系统，和庞大异构的IT环境。很少有人能够有一份完全准确的应用逻辑图，也很少人能完全用脑子记住整个流程。无论哪种手段实现的业务监控，前期业务梳理是耗费大量时间和人力的过程。

在第一阶段的业务梳理过程中，服务路径梳理功能充分发挥了网络数据的价值。依托于真实的网络流量，利用数据包中真实的业务访问关系，建立了一套半自动化式、人机配合的业务梳理流程 ，主要包含了以下四个步骤。

根据网络数据，自动呈现应用组件，交付设备之间的IP链接关系，汇总并摘要显示Tcp 的会话数，使得服务端口显而易见，快速建立服务访问关系。

支持IP地址，设备名，服务端口号，以及其他符合条件的搜索，快速找出目标数据，方便对组件关系进行归类，整理。

根据IP地址和主机的对应关系（比如CMDB中导出的数据），通过搜索定位功能，将应用组件和交付设备进行归类提炼出简单、直观、面向业务的逻辑视图 。自动比较IP地址表和实际网路流量之间的差异，发现依赖关系及文档信息的缺失或错误。

为服务路径图建立档案库，自动实现系统变更的发现和更新。

通过以上四个过程，自动完成了应用组建的准确刻画，交付设备之间的访问关系。把若干人月的业务梳理周期降到了分钟级。同时，输出结果还可以非常方便地导入到CMDB中以帮助构建完全和真实业务一一对应的服务路径视图。

业务性能管理的数据源主要有三种。我们可以比较一下安装代理，日志分析和网络数据分析这三种手段自身的特性和实施过程中可能会遇见的一些问题。

代理的安装是在系统中植入一个程序。程序中规定了需要监控哪些参数，并且在业务运行的过程中实时地把业务的相关参数发给相关监控主服务器。

Web的代理不能给App使用，不同厂商中间件的代理也无法通用，还要考虑Esb，DB；Web前端基于Java平台，而系统中还有大量C、C++语言写的应用服务器，比如TUXEDO、WTC或者核心银行经常使用的CICS。再考虑App等软件的版本升级和应用定制等。假设操作系统的版本有X种，应用服务器的版本有Y种，上层应用则有Z个版本，这需要开发多少不同代理版本？ 基本是XxYxZ的组合。代理覆盖面不够的话会造成端到端监控中断。代理上线，或者系统、应用服务器、应用升级时对代理测试不充分会造成生产运行隐患。总的来说，安装代理，埋下的坑不少。

在实施过程中， 如何去实现采集数据的统一性？在复杂而异构的金融IT环境中，从Web到App，中间件到ESB，前置到核心，每个应用程序的日志都大相径庭。每段输出的参数各不相同，很难实现端到端的业务监控。如何尽可能的统一参数，是前期梳理过程中一个很重要环节，需要大量的时间投入。也有完全通过日志改造的方式，比如ARM，比如日志埋点来解决。但是这个投入很大，对新建系统或许可以，对于存量系统就比较困难。再者，如果后期运维过程中发现日志不能完全满足需求，还需要再进行改造。于是开发、测试、运行的流程将一次又一次地循环往复。

此外和代理的方式一样，面对着占用主机资源的问题。一般来说，日志有5个级别。从Fatal致命错误的输出到Debug细颗粒的度事件，只有设定在Debug级别时，才会有详细的过程信息输出，但Debug的开启会大大的占用主机资源。对于开发平台来说，不管是云计算还是容器，都在极力削减所谓的VM TAX所带来的性能开销，一个Debug日志直接把所有的资源节省都消耗殆尽。再者对于昂贵的大型主机，日志开销掉的MIPS是一笔无论如何都无法忽略不计的成本。

这就是此商业银行为什么需要半年才能完成一个业务系统的原因。代理和日志的方式，不再那么适合大规模异构的复杂环境。那么有没有其他的实现方法呢？

在IT系统中有一种流淌在底层的数据，就是网络数据。现阶段，金融业所有的业务系统都基于网络的传输。业务从使用者的发起，数据包从公网经过了防火墙，负载均衡，递到了数据中心的Web服务器，到Esb，再到核心，再到银联，人行等外联机构。业务处理过程中的消息都是通过网络来进行传递的 。

上海天旦正是采用这种实时、客观、天然包含业务关系，并且格式统一的标准数据源。无需去做代码定制，无需去统一输出格式，更无需去在应用服务中去植入代码消耗主机自身资源，当然也不会因为代码的植入而等待重启服务。网络数据的使用，已经规避了传统监控方式在前期定制开发的过程，大大缩短了建设周期。

业务级别的交易监控，要求业务性能管理系统必须能够解析这些数据包并且识别协议。

网络中的数据包是以二进制的方式传输的。 这种二进制的报文对于非专业的认识来说是形同天书 。如何识别和翻译这些报文，是基于此类监控方法落地过程种一个重要的阶段，是能否实现监控的关键，因此，需要投入大量的时间和资源。

在金融行业中有很多通用协议，例如，银联的CUPS2.1, 人行系列等等。但同时，有着更多的私有协议。 为了安全的角度，各家银行都会在标准公开的协议上做一些细微的更改。上海天旦在10余年金融行业服务中，有着长足的解码积累。不但能够完全支持所有标准公有协议，对于私有的识别也有者大量的积累，是目前，业务唯一能支持 Tuxedo、WTC、IBM SNA（多种封装）解析的厂商。

长期的解码累计，天旦在项目实施过程中，可以实现下图协议的即插即用，省去了大量的协议解码时间。

依托着于解码积累，天旦将以解协议进行建模并加载到解码器中，实现了高效易用的解码引擎。全新开发的Smart Decoder能够智能识别已知协议并完成解码。智能解码引擎的出现，再次将现场实施速度大幅度提升。

银行存在着许多私有协议，而这样的私有协议往往以标准协议为模版，在共有协议的基础上稍做改动。 智能解码引擎可以自动识别其母协议模版，并且给出关键字建议，这使得这类私有协议的解码是通过web界面，自动化的手段协助实现 。改变了人工分析排查的过程，从而大大提高了安装效率。

在长期和客户接触过程中发现，运维人员并不清楚几十套甚至上百套应用系统的协议。现场实施的时候，需要不断地去尝试不同的解码方式才能确定使用哪种协议，而智能解码模块，可以根据协议的标准模型，自动匹配协议、解码、验证、并输出结果。

自动解码引擎使得协议解码的速度再次插上了翅膀。

业务性能管理系统的建设就是一场和时间的赛跑。随着自动化业务梳理，网络数据源及智能解码引擎的使用，已经使运维监控的落地速度在两年之内降低了90%。上海天旦提出的业务性能管理领域的“摩尔定律”依然有效。大数据，云计算，p2p，互联网金融 ……业务全天候运行着，IT环境越来越复杂，交易量成倍的翻翻。 上海天旦将继续不懈追随并延续“摩尔定律”，让业务性能监控的落地最终做到和业务上线同步。