中国工商银行股份有限公司数据中心(北京)专家 黄文宇

　　为了加强业务连续性管理，大型企业或机构的数据中心集中监控逐步从传统的面向技术组件的资源监控转变为面向业务的服务监控，从而把IT软硬件单元故障与业务服务联系起来，可以自动快速地确定并展示信息事件对业务的影响范围和程度。推动这一转变的动因是，传统的资源监控只能为IT技术人员使用，不能及时准确地反映信息事件对业务的影响范围和程度，使得业务人员和IT人员难以相互配合进行应急响应，也无法适应业务可用率管理的需求。

　　面向业务的监控的基础是建立业务服务模型。业务服务模型通过从IT的维度对业务进行诠释分解和从业务的维度对IT资源进行可用性管理，衔接业务与底层IT基础架构，弥补业务部门与IT部门联动中的空白。

　　尽管业务服务模型的概念已经提出了一段时间，但到目前为止还没有业界通用的实现方法，特别是对于大型主机平台的基于CICS/IMS的传统集约化联机交易处理系统(OLTP)，由于集成的业务种类较多，IT软硬件资源数量庞大(如交易类型或程序多达数千个、数据库表数量多达上万个)，相互关系复杂(如中间件集群、数据库集群、操作系统集群以及交易、程序、数据库表的相互访问调用关系)，如何准确清晰地建立IT组件和业务的关系，如何根据某个IT组件(如数据库表、程序)的故障事件判断业务影响的范围和程度，如何找出多个相关故障事件并发情况下的根源事件，还没有可借鉴的方法和先例。

　　本文基于大型主机(CICS/IMS)联机交易处理系统，介绍了面向监控的业务服务模型建立的方法，准确描述并关联了主机软硬件单元的相互关系(实关系)及其与业务的逻辑关系(虚关系)，在此基础上建立了一个针对故障事件或故障恢复事件的业务影响分析处理系统，实现从IT单元故障事件向业务影响范围和程度的自动、快速、准确地转换和展示，满足了面向业务服务监控的需求，并辅助进行问题根源分析。

　　一、总体思路

　　大型主机联机交易处理系统(CICS/IMS)具有良好的层级结构，IT组件包括交易、程序、数据表、中间件子系统、数据库子系统、操作系统等，其间存在着实实在在的关联关系，这可以通过配置信息或工具软件自动发现。系统中的故障事件可能直接影响某个IT组件的可用性，也可能通过该IT组件间接影响其他IT组件的可用性。

　　主机联机交易处理系统支撑多种业务，业务种类可按颗粒度划分，其中单个交易为最小颗粒度业务单位，其他业务种类可以通过交易的集合来表示。由于交易既是IT组件实关系模型的组成部分，也是业务组合虚关系模型的基本组成部分，因此可以在交易层将两个模型结合起来。IT组件的可用性变化可以通过实关系模型转化为对交易可用性的影响，再由交易可用性变化转化为对业务可用性的影响，从而实现通过IT组件故障事件分析对业务的影响，并找出不同事件对各IT组件和业务划分影响的相关性。

　　二、面向业务影响分析的业务服务树模型

　　业务服务树模型可以将技术和业务相结合，很好地将IT人员和业务人员对信息系统的不同视角结合起来，并将应用交易、程序和数据库表的关联关系纳入业务服务模型，可更准确、更细颗粒度地反映业务影响范围、快速定位问题根源，它还将集群组虚节点纳入业务服务模型，从而简化了业务服务模型，提高了业务影响分析的效率。

　　1.联机交易处理系统的实关系模型

　　大型主机联机交易处理系统一般宏观上分为交易层、中间件层、数据库层三个层次。交易层由各类应用交易(CICS或IMS Transaction)组成，交易是一个基本的业务服务单元，通过交易调用不同的应用程序(Program)执行特定的功能，因此微观上该层又分为交易和程序两层;中间件层由多个CICS或IMS子系统组成，应用交易运行在中间件子系统中;数据库层包括应用数据库表和数据库子系统，数据库表运行在数据库子系统中，交易通过调用程序访问一个或多个应用数据库表。中间件、数据库层通常还有一类冗余组关系。例如，多个功能对等的CICS子系统组成的CICS群组，如CICSPLEX的AOR组、TOR组;多个功能对等的DB2 子系统组成的DB2 Data Sharing群组。由于单个群组内的各个子系统在功能上是相互冗余的，单个组件(或子系统)的失效并不影响整个群组的可用性，因此也不会影响运行在这些群组的应用交易的可用性。

　　以传统CICS/DB2组成的大型机联机交易系统为例，考虑上述层次关系和冗余组关系，其关系模型如图1所示。

　　上述实关系模型中包含了CICS群组，这对于简化交易和CICS子系统的关联关系数量非常重要。如果有M类交易运行在N个完全相同的CICS子系统中，就有M×N个交易运行在CICS子系统的关联关系中。如果在交易和CICS子系统间增加一个CICS群组，那么交易和群组的关联关系为M×1，群组和CICS子系统的关系为1×N个，总的关系数量变为(M+N)个。如假定1000类交易运行在10个相同的CICS子系统中，如果没有AOR群组节点，交易节点和CICS 子系统节点之间的关系是10×1000个;如果建立了一个AOR组节点，那么交易节点和AOR组的关系是1000×1个，AOR组节点和REGION之间的包含关系是1×10个，关系总数只有1100个，即关联关系数量减少了89%。关联关系数量对后续的业务影响分析非常重要，可减少运算量，提高业务状态监控的实时性。DB2群组也起到了简化数据库表与数据库子系统之间的关系的作用。

　　2. 业务服务虚关系层次模型

　　业务服务通常由不同应用系统组成的有机整体来提供，可以按业务类别、业务部门、业务产品、业务渠道、业务地域等不同维度进行逻辑分类。不同企业或机构的业务服务分类方法可能各不相同，颗粒度差异较大，但通常情况下会根据逻辑层次进行划分：最底层(第0层)为基本的业务服务单位，如Web Service或交易;第1层为基本服务或交易的不同组合⋯⋯层次越高，离信息系统的基本物理组件越远。每个业务类别或渠道对应一组业务交易。图2为简化的业务虚关系模型(由业务服务群层、业务类别/渠道层、业务交易层组成)。

　　3.面向业务影响分析的业务服务树模型

　　面向业务监控的业务服务模型要求将IT系统的实体模型和业务层次模型清晰地结合起来，将每个IT组件故障或性能事件自动、快速地映射到不同层次的业务服务的状态，以快速、准确地确定业务影响范围和程度，调动IT人员和业务人员协作应对，同时对业务可用性管理提供信息系统支撑。

　　对于大型机联机交易处理系统而言，交易既是信息系统的基本功能单元，也是最小的业务服务单位，是联系信息系统实关系模型和业务虚关系模型的基础和纽带，因而可以无缝地将上述IT组件的实关系和业务服务的虚关系模型结合起来，形成主机业务服务树模型。如图3所示。

　　该模型逻辑上共5层：业务群组层、业务类型/业务渠道层、交易层、中间件层、数据库层;细化为7个层级：业务群组、业务类型/业务渠道层、交易、程序、数据库表、数据库群组、数据库子系统。每一层级有多个节点，相邻两层节点之间有直接的关联关系(有连接线)，单个上层节点和下层多个节点组成父子关系，如表1所示;而跨层节点之间无直接关联关系(无连接线)。

　　父子关系有以下4种类型。

　　①“包含”关系(或称集合关系)：父节点包含多个独立的子节点，如业务服务群包含多个业务种类和渠道，业务渠道包含多个交易;

　　②“集群”关系：父节点是多个子节点的集群，如CICS 群组包含多个CICS子系统;DB2 群组包含多个DB2子系统。此类关系的特点是多个子节点完全冗余(或称为对等)，单个接点故障不影响父节点的可用性;

　　③“运行在”关系：父节点运行在子节点上，如交易运行在CICS组，数据库表运行在DB2中等;

　　④“调用访问”关系：父节点调用或访问子节点，如CICS调用程序，程序访问数据库表。

　　4. 模型特点

　　(1)实现技术和业务的结合

　　业务服务树模型把大型主机联机交易处理系统的软件组件和相关资源概括为层次化实关系模型(一般分为交易层、中间件/数据库层、操作系统层)，把基于应用交易的业务服务逻辑模型概括为层次化虚关系模型(一般分为交易层、业务/渠道层、业务服务群层)，在交易层将两个层次模型无缝结合起来，形成面向业务服务监控的层次化业务服务模型。将技术人员和业务人员不同视角结合起来，将不同颗粒度的资源对象和业务服务对象体现在不同的层次，方法简明易行，特别适合复杂信息系统的面向业务监控建模。

　　(2)将应用交易、程序和数据库表的关联关系纳入业务服务模型，能更准确、更细颗粒度地反映业务影响范围，快速定位问题根源

　　该模型将应用交易、程序和数据库表的关联关系纳入业务服务模型，将交易类事件、程序类事件和数据库表类事件都纳入集中监控和业务影响分析的范围，拓宽了业务影响分析的事件范围，同时能更准确地体现故障事件影响的IT组件和业务范围，快速定位位于最底层的组件对象，找到问题根源，丰富问题分析手段，提高监控和应急处理的效率和准确度。

　　(3)将集群组虚节点纳入业务服务模型，简化业务服务模型，提高业务影响分析的效率

　　信息系统监控软件一般不包含集群组信息。但大型主机联机交易处理系统的交易数量多，CICS子系统可能多达上百个，数据库子系统为4个以上，如果没有集群组，关联关系数量将非常庞大，不仅模型复杂，而且计算量很大。本模型将集群组虚节点纳入业务服务模型，大大简化了业务服务模型中关系的数量，减少了业务影响分析的运算量，提高了业务影响分析的效率。

　　三、业务影响分析算法

　　面向业务的监控关注主机系统事件对资源节点和业务节点状态的影响，根据节点的状态属性(STATUS)其可分为完全可用、部分可用、完全不可用三类。一个故障类事件或故障恢复类事件一般能直接对应到资源节点的状态变化，称为“事件驱动状态规则”;也会间接影响到上层业务服务节点的可用性状态，这种间接影响的算法规则称为“层级状态驱动算法”。

　　1. 事件驱动状态规则

　　并非所有事件都会造成业务影响，业务影响分析先要确定哪些事件与业务模型相关，即确定外部事件的选取规则。显然，原则上只有影响业务可用性的事件才被选择，或者说，会直接或间接导致业务模型节点状态变化的事件才被选择。按事件对节点状态的影响性质来分，外部事件一般可分为故障事件、故障恢复事件、性能事件、性能恢复事件四种。外部事件发生后，可依据事件驱动状态规则确定节点的最新状态。事件驱动状态规则如表2所示。

　　2. 层级状态驱动算法

　　IT组件节点的可用性可能会间接影响到关联节点的可用性，这种影响对应到业务服务层次模型中，是子节点对父节点的影响。由于某个节点既是下层节点的父节点，又是上层节点的子节点，这种影响可能会逐层向上传播，直到父节点状态不改变为止，因此我们称这种间接影响传播规则为层级状态驱动规则。上层交易、业务渠道甚至业务群节点的状态发生改变，意味着故障事件影响到了业务的可用性，受影响的节点集合就是影响的范围，每个节点的状态代表影响的程度。

　　不同的父子关系，代表了子节点状态变化对父节点状态的影响方式，或者说不同的父子关系有不同的状态传播规则。对应图3所示的业务服务模型，层级状态驱动规则如表3所示。

　　四、业务影响分析处理系统

　　典型的业务影响分析处理系统逻辑架构如图4所示，由两部分组成：模型建立和业务影响分析处理，包含6个模块：模型读入模块、模型数据库模块、模型动态创建模块、事件输入接口、业务影响分析模块、输出模块。

　　模型读入模块负责读入业务服务节点、IT组件节点(或称资源节点)、资源节点关联关系、业务服务组合关系，存入模型关系型数据库。其中部分资源节点及其关联关系可以由一些工具软件(CICS InterdependencyAnalyzer软件)自动发现生成。

　　模型动态创建模块通过读取数据库信息，依据层次模型模板，动态创建业务服务树模型。层次模型模板可方便地控制哪些层次节点及其关系纳入业务模型树。

　　事件输入接口负责接收、解析、过滤外部事件监控系统发来的故障事件或恢复事件信息，转发给业务影响分析模块。

　　业务影响分析模块根据事件驱动状态规则，重置故障节点状态;并根据层级状态驱动规则，分析对其他关联节点状态的影响;对于同时到达的多个事件，还要找到与最底层节点相关的事件，这代表了问题的根源。

　　输出模块展示业务服务模型节点的最新状态，同时把所有非正常状态节点用树状图形方式显示;如果涉及上层业务渠道或业务群组，这些节点就代表故障事件的业务影响范围，节点的状态代表业务影响的程度，而最底层的节点相关事件通常代表故障的根源。

　　该系统实现对故障事件的自动化业务影响分析和展示，可动态展示业务影响范围和程度，以及业务和故障组件之间的关联关系。在多个事件并发的情况下，可根据故障状态树展示，准确快速地定位到最底层的故障节点，即故障根源。