- 4.87 MB
- 185页
- 1、本文档共5页，可阅读全部内容。
- 2、本文档内容版权归属内容提供方，所产生的收益全部归内容提供方所有。如果您对本文有版权争议，可选择认领，认领后既往收益都归您。
- 3、本文档由用户上传，本站不保证质量和数量令人满意，可能有诸多瑕疵，付费之前，请仔细先通过免费阅读内容等途径辨别内容交易风险。如存在严重挂羊头卖狗肉之情形，可联系本站下载客服投诉处理。
- 文档侵权举报电话：19940600175。
CTG-MBOSSCRM2.0业务交付流程监控系统功能技术规范CTG-MBOSSCRM2.0业务交付流程监控系统功能技术规范中国电信集团公司2010年3月
目录1文档说明....................................................................................................................................................11.1编制说明...........................................................................................................................................11.2适用范围...........................................................................................................................................21.3阅读指南...........................................................................................................................................21.4术语定义...........................................................................................................................................31.5起草单位...........................................................................................................................................41.6解释权..............................................................................................................................................41.7版权..................................................................................................................................................42总体说明....................................................................................................................................................52.1驱动力分析.......................................................................................................................................52.2建设目标...........................................................................................................................................62.3系统定位...........................................................................................................................................62.3.1在CRM2.0中的定位...................................................................................................................62.3.2在ITSM中的定位.......................................................................................................................72.3.3监控层次定位..............................................................................................................................82.3.4监控对象定位..............................................................................................................................83系统总体架构..........................................................................................................................................103.1功能架构.........................................................................................................................................103.2部署架构.........................................................................................................................................113.3技术架构.........................................................................................................................................133.3.1技术原则....................................................................................................................................133.3.2技术架构....................................................................................................................................143.4系统边界.........................................................................................................................................163.4.1集成接口边界............................................................................................................................163.4.2数据处理边界............................................................................................................................184系统功能..................................................................................................................................................224.1统一采集与控制.............................................................................................................................224.1.1采集策略管理............................................................................................................................23版权所有，注意保密i
4.1.2配置采集....................................................................................................................................234.1.3告警采集....................................................................................................................................244.1.4性能采集....................................................................................................................................264.1.5操作控制....................................................................................................................................274.2CRM应用监控模块...........................................................................................................................284.2.1应用拓扑管理............................................................................................................................304.2.2应用运行监测............................................................................................................................334.2.3应用交易跟踪（可选）............................................................................................................364.3业务交付流程监控模块.................................................................................................................404.3.1业务建模....................................................................................................................................404.3.2业务运营指标监测....................................................................................................................484.3.3业务运营质量分析....................................................................................................................514.3.4可用性探测................................................................................................................................534.3.5业务稽核....................................................................................................................................574.3.6订单监测....................................................................................................................................594.4告警处理.........................................................................................................................................644.4.1告警判断....................................................................................................................................644.4.2告警定位....................................................................................................................................654.4.3告警丰富....................................................................................................................................664.4.4告警过滤....................................................................................................................................664.4.5告警压缩....................................................................................................................................674.4.6告警操作....................................................................................................................................674.5控制管理.........................................................................................................................................704.6综合展现.........................................................................................................................................714.6.1告警展现....................................................................................................................................714.6.2综合视图....................................................................................................................................734.6.3统计报表....................................................................................................................................734.7系统管理.........................................................................................................................................744.7.1用户管理....................................................................................................................................744.7.2权限管理....................................................................................................................................764.7.3日志管理....................................................................................................................................764.7.4自身管理....................................................................................................................................78版权所有，注意保密ii
5集成架构..................................................................................................................................................805.1集成综述.........................................................................................................................................805.1.1集成接口视图............................................................................................................................805.1.2集成接口方式............................................................................................................................815.2集成接口.........................................................................................................................................895.2.1IT服务管理系统接口................................................................................................................895.2.2IT基础设施监控系统接口........................................................................................................975.2.3集团业务交付流程监控系统接口..........................................................................................1015.2.4被管对象系统接口..................................................................................................................1085.2.5其它系统接口..........................................................................................................................1146技术要求................................................................................................................................................1166.1总体要求.......................................................................................................................................1166.2性能要求.......................................................................................................................................1176.3可靠性要求...................................................................................................................................1176.4易用性要求...................................................................................................................................1186.5可维护性要求...............................................................................................................................1196.6接口要求.......................................................................................................................................1206.7数据生命周期要求.......................................................................................................................1217实施演进策略........................................................................................................................................1227.1实施原则.......................................................................................................................................1227.2实施演进.......................................................................................................................................1227.2.1第一阶段：基础平台搭建、实现主动管理..........................................................................1247.2.2第二阶段：增加监控范围、强化端到端的业务数据监控..................................................1257.2.3第三阶段：主动监控、优化服务..........................................................................................1277.3部署方案.......................................................................................................................................1278附录一监控指标体系...........................................................................................................................1298.1指标建设方法...............................................................................................................................1298.1.1指标建设范围..........................................................................................................................1298.1.2指标建设步骤..........................................................................................................................1338.1.3指标参数说明..........................................................................................................................136版权所有，注意保密iii
8.2业务监控指标...............................................................................................................................1388.2.1业务流程指标..........................................................................................................................1388.2.2业务功能指标..........................................................................................................................1578.2.3服务接口指标..........................................................................................................................1598.2.4业务稽核指标..........................................................................................................................1638.3应用监控指标...............................................................................................................................1668.3.1应用进程监测..........................................................................................................................1668.3.2应用服务器监测......................................................................................................................1678.3.3数据文件监测..........................................................................................................................1688.3.4业务服务监测..........................................................................................................................1689附录二监测指标编码规则...................................................................................................................17010附录三接口属性定义..........................................................................................................................17410.1信息项类型...................................................................................................................................17410.2配置项状态编码...........................................................................................................................17410.3事件来源.......................................................................................................................................17410.4告警类型.......................................................................................................................................17510.5告警级别.......................................................................................................................................17510.6所属系统类型...............................................................................................................................17510.7事件分类.......................................................................................................................................17610.8省份代码.......................................................................................................................................17711附录四规范编制人员名单...................................................................................................................17912附录五参考文档...................................................................................................................................180版权所有，注意保密iv
1文档说明1.1编制说明本规范规定了中国电信业务交付流程监控系统（简称SFM）的定位、建设目标和总体架构，从系统功能、系统接口、技术要求、系统演进、监控指标定义、测试规范等方面进行了规范性描述，供中国电信内部使用。本规范是CTG-MBOSSCRM2.0规范集中的一个分册，具体规定业务交付流程监控系统的功能要求、技术要求、指标要求、实施规划等。它在CTG-MBOSSCRM2.0规范集中的位置如下所示：图1.1业务交付流程监控系统规范定位本规范和中国电信IT服务管理规范集IT监控系统分册的关系：本规范定义的业务交付流程监控系统包括CRM应用监控模块和业务交付流程监控模块，分别对应IT服务管理规范集中IT监控系统分册中的应用软件监控系统和端到端的业务监控系统两个系统。本规范定义了对CRM域各系统的应用监控的功能要求，以及对跨系统端到端的业务交付流程的监控功能和监控指标要求。是对IT服务管理规范IT监控系统分册版权所有，注意保密1
在CRM域落地的细化描述。1.2适用范围本规范适用于中国电信各省（直辖市、自治区）业务交付流程监控系统的设计、开发、建设和入网测试，是中国电信各省（直辖市、自治区）公司电信业务交付流程监控系统建设的技术指导性文件。1.3阅读指南本规范包括以下章节：第一章，主要描述本规范的编制说明、适用范围、规范定位以及阅读指南等文档说明性内容。第二章，分析系统建设的驱动力，明确系统建设目标，阐述系统在CRM域中的定位以及与中国电信ITSM系统之间的关系，并对规范中用到的术语进行统一说明。第三章，从整体角度阐述系统功能范围、系统部署模式、系统技术架构要求，提出了基本的系统集成架构，并对数据处理相关功能的系统边界提出了建议。第四章，对系统业务功能进行了具体说明，详细阐述了各功能的定义，实现目标与功能要求。第五章，对系统集成架构进行了具体说明，明确了可选择的接口实现方式，并详细阐述了各系统接口的定义及数据内容要求。第六章，阐述系统技术要求，提出对系统的总体技术要求，并从性能、可靠性，易用性、可维护性等方面对业务交付流程监控系统提出具体的技术要求。第七章，阐述业务交付流程监控系统规划实施的演进策略，包括分阶段的功能实现演进路线和监控对象范围的演进路线。附录一，监控指标体系，对业务交付流程监控系统监控范围内的应用、业务类监控对象进行指标梳理，明确监控指标内容。附录二，监控指标编码规则，阐述了统一的指标编码规则。附录三，接口属性定义，明确了集成接口中选择字段的选择项如省份代码、告警级别版权所有，注意保密2
等。附录四，规范编制人员名单。附录五，参考文档。1.4术语定义术语解释SFM业务交付流程监控系统(ServiceFulfillmentMonitoringSystem)ITSP2.0中国电信企业信息化战略规划2.0版本CMDB配置管理数据库(ConfigurationManagementDatabase)配置项(ConfigurationItems)，即CMDB中管理的企业IT资产。配置项包括应CI用软件、系统软件、基础架构、IT服务、文档等IT服务管理是一种以流程为导向、以客户和业务为中心的方法，它通过整合ITITSM服务与组织的业务，提高IT服务提供和服务支持能力和水平，包括事件管理、配置管理、问题管理、变更管理等流程。中国电信CTG-MBOSS规范集的重要组成部分，主要分为IT服务管理和IT监控ITSM规范两部分，其中IT服务管理主要包括CMDB的管理和流程管理，IT监控部分包括基础设施监控、应用监控和端到端的业务监控三部分。KPI关键性能指标(KeyPerformanceIndicators)KQI关键质量指标(KeyQuantityIndicators)SLA服务级别协议VSOP增值业务订购关系管理平台SOA面向服务架构(Service-OrientedArchitecture)J2EEJava2平台企业版(Java2PlatformEnterpriseEdition)WASWEB应用服务器(WebApplicationServer)CSB渠道服务总线版权所有，注意保密3
业务交付流程ServiceFulfillment，本规范定位为订单处理流程组件是实现特定功能，遵循某一个组件模型的约定并可独立部署与运行的软件组件/业务组件单元服务是组件实现并对外提供的功能与操作集合。业务服务有标准的接口，可以服务/业务服务被注册到服务总线上被其它业务服务调用。通过数据比对发现业务处理和业务办理中的数据差异，保证业务运行过程中业业务稽核务处理流程的完整性和正确性、业务数据完整性和一致性被管对象指IT监控系统所监视和控制的对象。又称作网元、元素、节点等。指基于企业业务目标对IT环境的整体容量进行规划设计，对支持当前IT服务容量管理的应用系统、IT基础架构的性能及负载情况、提供IT服务的组织能力进行监控与报告，并对IT资源的使用进行控制和优化。1.5起草单位本规范起草单位为中国电信集团公司。1.6解释权本规范的解释权属于中国电信集团公司。1.7版权本规范的版权属于中国电信集团公司。版权所有，注意保密4
2总体说明2.1驱动力分析在经济全球化的大背景下，信息化日益成为社会经济发展的重要推动力，信息化和工业化融合已成为国家的重要发展战略。因此，企业的信息化水平及IT运营能力必然成为现代企业未来制胜的关键。当前，我国电信行业已进入全业务运营阶段，随着3G牌照的发放，运营商间的竞争日趋激烈，为有效增强中国电信综合竞争能力，需要尽快提升中国电信企业信息化的整体能力，包括IT系统的建设能力和运营能力。为适应市场需求，建立“以客户为导向”的运营管理机制，有效落实精细化管理理念，需要不断深入发掘影响系统和业务运营的关键要素，加强业务内部及业务流程的运作和分析能力，为快速定位系统故障、提升业务应用程序运行效率，及时发现业务运营方面的漏洞提供有力支撑，并不断促进支撑能力的稳步提升和服务质量的持续改进。从以下几个方面驱动了业务交付流程监控系统的建设。战略规划要求：按照中国电信ITSP2.0要求，在2011年以前IT整体达到“主动服务、优化管理”的阶段目标。通过主动管理快速响应各类IT需求，不断提升IT管控的技术支撑水平。全业务运营带来的需求：在全业务运营的情况下，需要主动发现IT服务潜在问题，提前消除隐患；主动深入一线和前端，提高IT响应速度和响应能力；主动出击，引导、梳理、细化、完善IT能力；主动发现企业运营、管理中的问题，为业务发展、精确管理和运营提供决策支持。提升内外部客户感知的必要性：全业务融合的竞争更加要求中国电信提高以客户为中心的服务水平，要求IT为以客户为中心的客户服务感知提供更好的支撑及保障。内部管理水平提升的需求：oCRM域各系统作为电信公司和电信客户的接触点，基本上所有关于订单受理、订单开通等业务流程的故障投诉都会先由CRM运维人员来处理，但是版权所有，注意保密5
CRM运维人员对于订单端到端的业务流程没有监控手段，难以定位故障o运维人员对于面向客户的业务流程涉及到IT系统整体的运行情况缺乏了解，无法预先发现性能下降、系统故障等情况，并预先作出应对措施；o运维人员对业务运行过程中发生的问题，无法迅速判断原因并快速做出相应的动作o业务人员无法及时了解业务运行状态，无法及时了解业务运行过程中的问题和故障2.2建设目标针对面向客户的业务流程，实现对端到端业务交付流程运行状况的全面、准确、及时反映；通过对业务运行指标的分析及早发现业务和系统运行过程中的潜在问题；帮助运维人员快速定位应用程序漏洞或系统故障，控制业务差错，保障业务质量；进而为业务流程优化提供依据：关注面向客户的业务流程和功能，实现对业务运营的实时监控：从业务运营角度出发，针对业务可用性和性能指标进行实时监控，并通过对性能指标的分析及时发现业务运营过程中的渐进性异常，保证业务的可用性和连续性。建立纵向拓扑模型，支持根源分析和故障预警：构建业务、应用、基础设施之间的支撑关系模型，为业务、应用问题预警和故障的根源分析提供系统支撑。建立业务视图，实现业务运营状态可视化：以业务为主线，综合展现相关系统支撑、业务运营数据，为业务人员提供详细、完整、实时的业务运行全景视图。运用分析手段，支持IT综合运营管理：实现对IT支撑系统的综合运营分析，探索信息技术系统的关键点和改进方向，同时为容量管理、服务级别管理等IT服务内容提供基础数据。2.3系统定位2.3.1在CRM2.0中的定位业务交付流程监控系统在CRM2.0中的定位如下：版权所有，注意保密6
公众客户政企客户客户经理营业员客服代表代理商CP/SP面向客户面向内部员工客户面向合作伙伴10001自助终端门户掌厅门户号门户直销渠道门户10000接触门户SP/CP门户网厅门户门户营业厅门户代理商门户统一讣证平台(UAM)渠道服务总线(CSB)增值业务订购关产品与套餐管理系CRM系统系管理平台统(PPM)(VSOP)业务交付流程监控系统(SFM)图2.1业务交付流程监控系统在CRM域的定位2.3.2在ITSM中的定位业务交付流程监控系统在ITSM平台中的定位如下：业务交付流程监控模块实现对ServiceFulfillment端到端流程的监控CRM应用监控模块实现针对CRM域各系统的应用和业务监控图2.2业务交付流程监控系统在ITSM平台中的定位业务交付流程监控系统包括两个模块：版权所有，注意保密7
业务交付流程监控模块实现针对业务交付端到端流程的业务数据监控功能CRM应用监控模块实现针对CRM域各系统的应用软件监控功能。2.3.3监控层次定位业务交付流程监控系统的监控层次如下：监控层次监控对象监控内容监控信息采集源SFM业务流程业务流程KQIKQI和和KPIKPI指标：业务量、业务处指标：业务量、业务处业务交付业务交付CRMCRM、、1000010000号、网号、网业务交付涉及的端到业务交付涉及的端到理时间（平均理时间（平均//最大最大//最小）、异常量最小）、异常量//比率比率流程监控流程监控厅、厅、EAI/ESBEAI/ESB、服务开、服务开业务层业务层端业务流程、业务功端业务流程、业务功业务功能可用性和响应时间业务功能可用性和响应时间模块模块通、激活、计费等业通、激活、计费等业能、业务数据能、业务数据周边接口可用性、响应时间周边接口可用性、响应时间务交付流程相关系统务交付流程相关系统端到端流程实例告警和状态查看端到端流程实例告警和状态查看应用进程工作状态、性能信息应用进程工作状态、性能信息CRMCRM应用应用CRMCRM域各应用系统的域各应用系统的应用服务器工作状态、性能指标应用服务器工作状态、性能指标CRMCRM域各应用系统域各应用系统监控模块监控模块应用层应用层应用进程、应用服务应用进程、应用服务业务组件工作状态、性能指标业务组件工作状态、性能指标应用服务器应用服务器器、业务服务、交易器、业务服务、交易业务服务的运行状态业务服务的运行状态CSBCSB总线总线交易跟踪和问题分析交易跟踪和问题分析软件平台（操作系统、数据库）的可用性、响软件平台（操作系统、数据库）的可用性、响软件软件操作系统、数据库等操作系统、数据库等应时间、资源占用情况等；线程等资源使用情应时间、资源占用情况等；线程等资源使用情软件平台软件平台平台平台基础设施基础设施况；况；监控系统监控系统主机、存储、备份设主机、存储、备份设硬件硬件主机主机//存储的资源使用情况，运行状况等；存储的资源使用情况，运行状况等；硬件硬件备等备等网络网络网络设备网络设备网络连接，网络连接，QoSQoS等；等；网络网络图2.3业务交付流程监控系统监控层次图2.3.4监控对象定位业务交付流程监控系统在CTG-MBOSS2.0中的监控对象分布如下：版权所有，注意保密8
图2.4业务交付流程监控系统监控对象图其中，CRM应用监控模块的监控对象主要涉及CRM域各系统，业务交付流程监控模块的监控对象主要涉及CRM域系统、计费系统、服务开通系统等业务交付流程相关系统。版权所有，注意保密9
3系统总体架构3.1功能架构业务交付流程监控系统的主要功能包括：统一采集与控制、CRM应用监控模块、业务交付流程监控模块、告警处理、控制管理、系统管理、接口和综合展现。综合展现告警展现综合视图统计报表系统应用拓扑管理业务建模业务运营业务运营告警判断接口管理拓扑模型管理业务指标监测质量分析业务流程管理过程建模业务过程平衡性核查告警定位IT服务管理CRM应用支撑业指标监测业务运营告系统接口用户业务运营关系建模务业务支撑质量分析质量分析警告警丰富管理交关系建模业务支撑处应用参数管理关系监测应付业务理告警过滤IT基础设施权限用流参数管理监控系统应用运行监测订单监测管理监程业务稽核告警压缩应用运行控指标监测监可用性探测集团控业务数据订单流程告警操作两级接口日志模应用拓扑用例管理告警管理块模型监测模一致性核查应用支撑块关系监测探测处理订单状态控制管理与被管对象业务数据查询接口自身控制管理探测回退准确性稽核管理应用交易跟踪其它系统统一接口采集策略管理告警采集性能采集配置采集操作控制采集与控制被管对象图3.1业务交付流程监控系统功能架构图统一采集与控制统一采集作为业务交付流程监控系统后台支撑功能，负责根据用户制定的采集策略直接从各被管对象、或者间接从接口系统(基础设施监控系统以及CMDB)中获取告警、性能、配置等数据信息，用于指标数据的生成和处理。统一控制为实现对被管对象的控制管理功能提供命令传递和结果反馈通道，如通过远程登录主机、安装Agent代理等方式，完成对被管对象的控制。CRM应用监控模块CRM应用监控模块实现对CRM域各应用系统中的应用进程、应用服务器（J2EE容器）、业务服务等应用级对象的性能和可用性数据进行监测。版权所有，注意保密10
业务交付流程监控模块业务交付流程监控模块实现对反映业务交付流程运行状态的关键性能指标、关键质量指标、业务功能可用性、服务接口可用性、业务数据一致性及准确性进行统一监测与稽核。告警处理对来自被管对象的各类业务、应用、基础设施告警数据进行统一的定位、丰富、过滤、压缩处理，以提升告警的准确性，进而通过短信、邮件等方式通知维护人员处理，从而提升告警处理的及时性，缩短排障时间，为及时恢复应用、业务的正常运行打下良好基础。控制管理向操作人员提供集中的被管对象操控界面，以实现运维操作集中化、提升日常运维工作效率、并提高相关操作的规范性、安全性。综合展现提出操作人员与业务交付流程监控系统进行信息交互的界面要求，主要涉及告警展现、综合监控视图、综合报表等信息分析和展示功能。系统管理实现对业务交付流程监控系统操作用户的用户账号管理、用户权限管理、系统操作日志管理以及对业务交付流程监控系统自身的管理。接口管理实现业务交付流程监控系统与外部系统的接口，包括与IT服务管理系统接口、与基础设施监控系统接口、与集团业务交付流程监控系统接口、订单告警与状态查询接口、通知接口、统一认证接口等。3.2部署架构按照中国电信核心业务系统建设的体系结构，业务交付流程监控系统的体系结构分为两级，采用两级管理模式进行管理，如下图所示：版权所有，注意保密11
告警通知告警事件集团SFM集团ITSM服务管理系统集团SFM集团维护人员指标、告警信息控制请求基础设施性能数据、告警数据管控指标被管集团CRM集团服务…业务稽核对象域系统开通系统…订单查询集团基础设施监控系统集团省公司告警通知告警事件省SFM省ITSM服务管理系统省SFM省维护人员指标、告警、流控制请求基础设施性能数据、告警数据程实例信息被管省CRM域省级服务…省级EAI省基础设施监控系统对象系统开通系统…图3.2业务交付流程监控系统部署模式与接口关系示意图集团级：集团业务交付流程监控系统负责集团公司CRM域各应用系统的监控，集团业务交付流程的监控，以及全网业务运营过程中业务数据的稽核工作，为集团级全网业务运营提供支撑和保障。同时，集团业务交付流程监控系统接收省级业务监控交付系统的指标上报数据，由集团公司相应人员进行审阅。省级：省业务交付流程监控负责省内CRM域各应用系统，省内业务交付流程以及全网业务交付流程中涉及到省内处理的业务进行监控，负责省内业务运营过程中关键业务数据的稽核工作，为省级业务交付全流程提供充分的支撑和保障。同时，省级业务交付流程监控系统负责根据集团公司要求定期进行指标数据上报集成架构：集团公司系统与省公司系统通过广域网或专门的传输线路相联，以实现业务交付流程监控数据如管控指标上报、业务稽核数据上传、订单状态查询结果回传等。业务交付流程监控系统除了从被管对象系统采集被管对象的告警和性能数据之外，还需要从基础设施监控系统采集被管对象相关的基础设施的告警和部分性能数据；从IT服务管理平台中的CMDB中采集被管对象的配置数据；当确认被管对象发生故障时，通过接口在IT服务管理平台上启动事件管理流程。版权所有，注意保密12
详细接口方式与内容参见集成架构章节。3.3技术架构3.3.1技术原则业务交付流程监控系统实现中国电信CRM域应用系统与业务功能的实时监控，是端到端业务交付流程正常运营的保障，提供“以客户为导向”的运营管理机制，为改善客户感知和提升IT服务质量提供有利支撑。业务交付流程监控系统是中国电信的核心竞争力的体现，其技术架构主体上遵循CRM域技术架构规范要求，同时加入了监控系统统一的采集、控制、及告警处理等技术要求。系统在建设过程中应采用国际先进、成熟的科技成果，结合中国电信已有的经验和资产，保证系统在国内相应领域内具有领先的技术水平。系统实现过程中，应该遵循如下技术原则：1、先进性系统的实现应参考国际标杆并结合现状，采用先进可靠的设备和技术，确保系统的先进性和成熟性，保证投资的有效性和延续性。2、安全可靠性系统必须要达到电信级的安全标准，提供良好的安全可靠性策略，支持多种安全可靠性技术手段，制定严格的安全可靠性管理措施。3、开放性系统应基于国内外业界开放式标准，进行全国统一规划，为未来的业务发展奠定基础。4、可扩展性系统应具备灵活的可扩展性，具备方便地适应业务需求的变化、迅速地支持新业务的能力。5、可伸缩性系统应具备良好的可伸缩性，系统性能及并发处理能力对主机设备具备平滑的扩展能力，支持业务量快速发展的需要。版权所有，注意保密13
6、易使用性系统应易于使用与维护，具备良好的用户操作界面、人性化的管理工具和完备的帮助信息。3.3.2技术架构系统采用分层结构开发和设计，将采集、处理、存储、服务和界面层分离，实现系统内部的松耦合，以灵活、快速地响应业务变化对系统的需求。分层架构如下图所示：业务交付监控系统分层架构告警列表应用拓扑业务视图统计报表界面展现层界面组件(Jsp、Ajax、Flash、Portlet...)业务服务业务服务层业务组件业务组件数据存取数据转换数据封装数据存储层DB配置文件日志文件原始数据处理告警判断指标入库数据处理层数据数据预处理(格式转换、纠错)数据采集层接口协议(WebService、Socket、FTP、Agent...)监控对象(应用、功能、业务流程、基础设施接口、CMDB)图3.3业务交付流程监控系统技术架构各系统层次的职责和要求描述如下：数据采集层数据采集层从被管对象系统采集监控需要的配置信息、告警信息以及性能信息数据，并支持对数据的预处理：对采集来的原始数据进行格式转换、检错纠错、保证异构的原始数据能够按照监控系统内部的标准格式记录。版权所有，注意保密14
数据采集层主要负责为数据处理层提供原始数据，进行实时的数据处理和告警规则判断。同时也支持在数据预处理完毕后直接将原始采集数据入库，用于原始数据的二次加工和异步数据处理。如：原始数据为明细数据，而需要的指标数据为统计数据，就需要对数据进行周期性的汇总计算和处理。在系统设计时，数据采集层应尽量独立于数据处理层，可以单独部署和运行，减少系统内部耦合性，以避免当采集链路出现问题时对数据处理以及其它系统模块的影响。数据处理层数据处理层直接从数据采集层获取预处理完毕的标准格式原始数据，或者从数据存储层获取已保存的原始数据，进行数据加工处理、告警规则判断、并生成最终的指标数据。数据处理层主要负责指标数据、告警数据的生成。其直接调用数据存储层的数据存取、转换及封装功能，为业务服务层提供基础数据。随着被管对象数量的不断增加，数据采集、数据处理的压力也会越来越大。因此在系统设计时，应将数据处理层独立于其它层实现，并可以实现分布式地部署和运行，以保证整个系统架构的稳定性和扩展能力。数据存储层数据存储层的主要任务是实现对数据的封装，并把封装后的数据转换成有价值的业务与系统信息，向其上的业务服务层，其下的数据处理层以及其它相关外部系统提供一致的数据访问服务。数据存储层包括数据的物理存储以及数据的封装：在数据资源方面，支持对数据库、操作系统文件或其它形式存储的数据进行操作，保证数据的完整性、一致性和准确性。在数据封装方面，数据存储层要能完成业务对象的封装，以及业务对象到底层数据库结构之间的转换，并实现对物理数据的存取访问，从而帮助其它模块和系统对业务对象的处理，使得对数据的访问不受数据库物理设计、物理分布的影响。在设计上，可采用集群的构建方式，进行数据层的压力分担、负载均衡，以保证系统的高可用性。业务服务层版权所有，注意保密15
业务服务层实现人机界面无关的业务逻辑相关处理功能。业务服务层由业务服务和业务组件组成：业务服务业务服务以面向服务的方式对一个或者多个业务组件的功能进行封装，它具有明确的接口描述，可以被其它业务服务调用，也可以被界面展现层调用。业务服务的功能由业务组件来实现，某个服务也可调用其它服务来完成更复杂的业务功能。业务组件业务组件是提供业务服务的载体，负责实现具体的业务逻辑。业务组件使用数据存储层提供的功能，来实现对数据库、文件等的存取。业务组件的开发通常采用基于容器的技术，比如实现组件、负载均衡、高可用性和工作量管理的应用服务器。界面展现层界面展现层是业务交付流程监控系统与用户进行信息交互的平台，用户通过用户界面组件调用业务服务来实现业务功能：界面展现组件由一组基本并紧密相关的界面展现单元组成，并通过这些界面单元调用与之有较强内聚性的业务服务实现一个独立的、带有人机交互界面的业务功能。界面展现层设计时，建议采用业界成熟的技术标准体系来构建，通过Ajax、Flash、Portlet、Chart等多种技术手段，采用动画、图形、表格等多种展现方式，提供一套界面友好、操作灵活、运行高效的用户展示界面。3.4系统边界3.4.1集成接口边界业务交付流程监控系统与下列系统有接口交互：IT服务管理系统IT基础设施监控系统集团业务交付流程监控系统版权所有，注意保密16
被管对象系统其它系统主要的接口分类、接口功能概述如下：接口方向接口分类接口概述事件管理接口向IT服务管理系统上报告警事件并接收事件处理结果从IT服务管理系统接软件版本变更、进程启停、脚本执行等控制控制请求接口IT服务管理系请求，并反馈执行结果统IT服务管理系统中CMDB信息发生变更时，传递给业务交付流程监配置项同步接口控统进行同步(CMDB)从IT服务管理系统进行配置项和关联关系访问查询接收与应用软件和业务相关的基础设施如主机、网络、数据库的IT基础设施监告警与性能数据告警数据控系统同步接口接收与应用软件和业务相关的基础设施如主机、网络、数据库的性能数据管控指标上传接省级业务交付流程监控系统向集团级业务交付流程监控系统上报集团业务交付口性能、告警等指标数据流程监控系统全网订单查询接集团业务交付流程监控系统通过全网业务订单ID，调用省内接口口，查询全网业务订单在省内的实时状态、流转情况等信息实现系统对应用进程、接口、业务流程、业务功能的性能、告警数统一采集与控制据的采集接口实现对被管对象操作控制，如对被管应用进程的启停操作与ODS/EDW的接从ODS/EDW采集接收指标计算、业务稽核等结果数据被管对象系统口实时接收被管对象系统如CRM、服务开通等系统触发的告警信订单告警与状态息，转换后提供统一的告警列表展示查询接口从被管对象系统如CRM、服务开通、计费等系统查询订单状态及流转情况信息与短信平台的短信通知接口其它系统通知接口与邮件系统的邮件通知接口版权所有，注意保密17
以界面集成方式将业务交付流程监控系统界面集成到其它系统统一认证接口所有登入系统的用户都在统一权限控制中心进行认证详细接口内容、协议、接口方式定义参见集成架构章节。3.4.2数据处理边界对于业务交付流程监控系统中运算量较大，特别是需要对业务明细数据进行处理的功能进行分工说明：如业务类性能指标的计算、业务数据一致性稽核、业务数据准确性稽核。针对这些功能，要求监控系统提供统一的告警判断、结果展示功能。但运算过程，可以由生产系统本身处理、ODS系统处理或者业务交付流程监控系统来处理。本规范根据对业务交付流程监控范围内指标数据、业务稽核数据的分析，给出建议的处理方案，并提供分工方案选择说明。各省公司进行系统建设时可以根据自身情况择优选择。1)业务指标计算建议方案：指标生成功能部署在ODS系统中，ODS从生产系统中同步原始业务处理数据，按照业务交付流程监控系统的要求计算并生成指标数据，SFM通过统一采集功能将指标结果采集到系统中进行后续处理。如下图：SFM采集指标原始业务数据计算指标数据逻辑同ODSODS步生生产业务处理数据产系系统统业务处理版权所有，注意保密18
图2.6指标计算分工建议方案方案依据：指标计算是监控系统的重要组成部分，对于应用类指标或主动探测方式的业务类指标，通常由监控系统自行从被管对象获取。对于业务流程类的指标，往往需要根据指标要求和计算方法由原始生产数据汇总计算而来，因此涉及由哪个系统来计算的问题。考虑到对各系统的功能要求以及性能压力，如果业务指标计算方法较为复杂，或者ODS中已存有原始数据且ODS生成指标数据的及时性能够满足要求，建议由ODS进行指标计算处理；如果指标计算方法较为简单，或者生产系统数据中直接就可以取到指标数据，建议由生产系统生成后进行采集。其它情况下，也可以使用监控系统获取原始数据二次计算得到指标结果的方式。2)数据一致性稽核建议方案：业务数据一致性稽核功能部署在ODS系统中，ODS从生产系统中同步原始业务数据，按照业务交付流程监控系统的要求稽核业务数据的一致性，并将稽核结果、差异内容提供给业务交付流程监控系统统一告警与展示。如下图：SFM采ODS集数据业务数据一致性稽核结果稽核同步生产业务数据系统图2.7数据一致性稽核建议方案方案依据：数据一致性稽核主要分为数据量一致性稽核与数据内容一致性稽核两类：版权所有，注意保密19
数据量一致性稽核如订单数据平衡性、业务办理一致性等。主要关注各业务环节数据量的一致性，因此可采用简单的处理方法：业务交付流程监控系统直接从生产系统或ODS系统获取数据进行比对，对一致性比对结果进行告警与展示。数据内容一致性稽核如CRM与计费客户信息一致性的稽核，订单处理过程中各环节订单信息一致性的稽核等。除了关注数据量级的比对外，还关注数据内容的一致性，需要深入到字段级别的对比。这类稽核运算量巨大，数据涉及多个系统，但比对周期一般要求不高，分工方案的选择尤为重要。建议首选由ODS系统负责获取原始数据进行运算、其次选择由监控系统或者某个生产系统负责运算，将稽核结果传入监控系统进行统一跟踪告警与展现。3)数据准确性稽核建议方案：业务数据准确性稽核功能部署在生产系统中，将稽核结果、差异内容通过采集的方式提供给业务交付流程监控系统进行统一展示和告警。如下图：生产系统稽核结果采集SFM数据准确性稽核业务数据图2.8数据准确性稽核建议方案方案依据：数据准确性稽核是对数据稽核更高层面的要求，包括业务数据完整性、数据与系统配置符合情况、数据与业务规则符合情况等内容。准确性稽核除了需要获取大量的原始数据外，还与业务配置规则密切相关，因此首选由各生产系统自行处理，或者由专业的第三方数据核查工具来处理，如果涉及的数据和业版权所有，注意保密20
务规则较为明确也可由ODS系统处理，不建议由监控系统直接处理。业务交付流程监控系统可在稽核处理完成后采集处理结果进行统一展示。版权所有，注意保密21
4系统功能4.1统一采集与控制统一数据采集与控制是通过主动采集或被动接收等方式，从被管对象获取告警信息、性能信息、业务信息，并建立、维护及断开控制管理模块与被管设备之间的操作通道。为了实现业务、应用和基础设施三个层次支撑关系的建立与分析，还需要从IT服务管理系统的CMDB采集获取配置信息、从基础设施监控系统采集基础设施告警、性能数据。从被管对象采集数据包括原始数据采集、采集数据预处理等步骤。预处理是对采集来的原始数据进行格式转换、检错纠错，形成内部标准记录，可直接保存为原始数据。同时系统对原始数据进行计算、分析处理，并进行告警规则判断触发告警，并生成所需KPI指标。处理过程如下：从被管对象采集数据被管对象数据采集预处理数据处理告警判断监控DB图4.1采集处理流程示意图1从IT基础设施监控采集数据，是通过系统间集成接口，从IT基础设施监控系统获取处理完成的告警数据以及性能数据，通过接口的适配和转换直接保存为业务交付流程监控系统的告警指标及性能指标数据，处理过程如下：从IT基础设施监控系统采集数据基础设施数据采集数据适配监控DB监控系统图4.2采集处理流程示意图2从CMDB采集配置项数据，是通过与IT服务管理系统中CMDB的集成接口，获取被管对象的配置信息以及被管对象之间的关联关系信息，用于进行告警信息的内容丰富以及自动生成基础设施、应用之间的拓扑关系，处理过程如下：版权所有，注意保密22
从IT基础设施监控系统采集数据基础设施数据采集数据适配监控DB监控系统图4.3采集处理流程示意图34.1.1采集策略管理对统一采集功能所涉及的参数进行集中配置管理。如性能采集指标，告警采集指标,配置采集指标等采集点的参数配置进行集中管理。IT基础设施的告警、性能数据通过和基础设施监控系统的接口采集，应用、基础设施层被管对象的配置数据通过与CMDB的接口采集。【功能要求】4-1.系统支持通过统一的配置中心界面集中配置采集参数。4-2.支持按采集对象设定不同采集任务，支持采集任务参数的设定，比如采集任务名称、采集任务的类型(主动采集，被动采集等)、采集方式、指标采集周期、采集条件、数据文件存储目录、采集失败补采数据存储目录等参数设定。4.1.2配置采集4.1.2.1采集内容4-3.配置数据采集的内容包括但不限于：基础设施如主机、网络设备、数据库、中间件、存储、备份等设备的配置信息及配置项关联信息，详见ITSM规范中IT基础设施监控系统的配置信息采集要求；应用系统配置信息采集，主要指CRM域的应用软件、进程、进程池、接口、数据文件等逻辑单元的配置信息及配置项关联信息。版权所有，注意保密23
4.1.2.2采集方式4-4.配置数据采集的方式包括但不限于：从CMDB配置管理数据库提供的配置项(CI)同步接口采集4-5.应能够按照配置的采集周期和时间主动同步IT服务管理系统的配置项信息；4-6.当IT服务管理系统中的配置项发生变更时，应能够根据采集策略实时接收配置项变更信息；4.1.2.3采集要求<采集处理要求>4-7.应能够根据采集到的配置信息更新业务交付流程监控系统中的配置信息及配置项之间关联关系；<采集异常处理>4-8.支持对所需的资源配置数据采集失败后，能够产生配置数据采集失败告警，提示维护人员。告警内容要包括数据无法采集的对象标识和告警产生时间，告警级别等；4-9.如果由于网络或者其它原因，未能正确采集到资源配置数据，能够根据采集策略要求进行重新采集或补采；<采集日志要求>4-10.提供采集报告，采集情况写入系统日志，以便维护人员检查配置数据采集情况。4.1.3告警采集4.1.3.1采集内容4-11.告警采集的内容包括但不限于：来自基础设施监控系统的主机、数据库、中间件等基础设施的告警信息；来自应用系统的应用和业务告警信息。版权所有，注意保密24
4.1.3.2采集方式4-12.告警数据采集的方式包括但不限于日志方式：采集被管对象的日志文件，分析出日志文件中的告警信息，完成告警数据的采集任务；SNMPTrap方式：通过监听SNMPTrap端口，实时接收来自于应用、业务层面的Trap消息，经过消息预处理后，生成告警数据；Syslog方式：通过监听syslog端口，实时接收来自于应用、业务层面的syslog消息，经过消息预处理后，生成告警数据；SOCKET、文件（FTP）、API、数据库等方式：根据实际接口需要，通过SOCKET端口监听、文件传输、API传输、数据库访问等方式，被动接收或主动采集告警数据；安装代理方式：通过在被管服务器上安装Agent，实现被管设备的告警数据采集。4-13.对于实时采集接口，如：从被管对象发送的Socket、SNMPTrap告警信息以及基础设施监控系统接口传来的告警信息，统一采集应能够实时接收并处理；4-14.对于非实时的采集接口，如文件（FTP）、数据库等方式，统一采集应能够定制采集时间规则，并根据该规则进行告警采集；4.1.3.3采集要求<采集处理要求>4-15.应能通过对采集到的告警数据进行预处理，完成告警格式一致性处理；4-16.应能根据告警分类规则，实现告警的分类，如：应用告警、业务告警等；4-17.应能根据告警严重程度，实现告警级别的定义和判断；<采集异常处理>4-18.当采集系统自身出现故障时可以产生系统告警信息；版权所有，注意保密25
4-19.当采集系统恢复正常后，数据采集应能迅速自动恢复，能够根据采集策略要求进行重新采集或补采。<采集日志要求>4-20.提供采集报告，采集情况写入系统日志，以便维护人员检查告警数据采集情况。4.1.4性能采集4.1.4.1采集内容4-21.性能数据采集的内容包括但不限于：来自基础设施监控系统的主机系统、数据库、中间件等基础设施性能指标；来自应用系统的进程、进程池、接口、数据文件等性能信息；相关业务系统的监测指标数据，包括业务数据总量、比率性能指标等；相关业务系统的关键质量指标、管控指标数据，包括业务系统的服务质量评价指标等。4.1.4.2采集方式4-22.性能数据采集的方式包括但不限于：FTP/TFTP方式：针对业务系统的日志数据或者业务系统其它以文件方式保存的业务统计数据，数据采集层以FTP/TFT的方式从业务系统主机上进行采集；Syslog方式：业务系统主动通过Syslog方式上报的业务数据；数据库方式：从业务系统数据库表中，提取相应的业务统计数据；业务系统厂家提供的其它方式：如业务系统已经按照相关技术规范要求，定义了该业务系统MIB，其中定义了各种业务性能指标的Count值，要求能够通过SNMP轮询方式，从业务系统采集相应的业务性能数据；针对ODS系统已有的业务数据，系统应能支持通过接口直接从ODS系统采集。4-23.应能够周期性地自动采集性能数据，采集周期和采集时间可配置。应能根据不同的被管对象设置不同的采集周期和采集时间；版权所有，注意保密26
4.1.4.3采集要求<采集处理要求>4-24.应能够对采集来的原始数据进行检错纠错，形成内部标准记录，应支持比较灵活的检错纠错配置。应能够完成性能数据格式一致性处理；<采集异常处理>4-25.当采集系统自身出现故障时可以产生系统告警信息；4-26.基于被管对象支持的基础上，应提供补采机制，当性能数据采集出现问题时进行补采；<采集日志要求>4-27.提供采集报告，采集情况写入系统日志，以便维护人员检查性能数据采集情况。4.1.5操作控制操作控制数据传递主要在控制管理模块操作被管对象时提供命令传递和结果反馈通道，以便完成对被管对象的自动化控制。【功能要求】4-28.对被管对象的操作内容包括但不限于：对应用进程、应用服务器进程的启停操作；对应用接口的启停操作；对数据文件的增、删、改等处理操作；对业务系统的操作控制：比如对业务功能访问权限的控制、对系统的经常发生问题的数据进行变更控制，使得系统可以完成后续处理，保证系统连续性；基础设施如主机、数据库、中间件的启停等控制操作。4-29.操作方式包括但不限于：SNMP方式：支持SNMP接口的系统，可以此方式操作；telnet方式：通过telnet等方式对被管对象进行操作；版权所有，注意保密27
Agent方式：通过在服务器上安装Agent控制服务器的操作；ssh方式：大量操作控制采用安全的ssh执行；FTP/TFTP方式：FTP等文件方式传输配置文件；rlogin方式：远程登录后执行；Rsh、rexec方式：直接远程执行相应的操作；HTTPS方式：通过HTTPS对相应的被管对象执行操作；Webservice方式：对于支持webservice的应用系统采用本方式。4.2CRM应用监控模块CRM应用监控模块的主要目的是从CRM域各系统应用架构的视角，监控组成应用系统的应用软件运行情况，根据各部分的性能数据和异常数据生成各种告警，通过告警列表、应用拓扑图等方式展现给运维人员，及时发现应用系统存在的诸如服务不可用、性能下降等问题或隐患，帮助维护人员快速缩小、界定问题存在的最小范围，定位并解决问题，在最短时间内恢复系统的正常运行，为由被动服务向主动服务的转变提供有力的保障和支撑。【应用监控范围】目前的应用系统普遍采用分层结构开发和设计，特别是基于J2EE和SOA的系统架构，将界面、业务流程、服务、数据分离，实现了系统内部松耦合，以灵活、快速地响应业务变化对系统的需求。这样的分层架构对应用监控提出了更高的要求，相应的监控范围也扩充到应用系统各个层级，如下图所示：版权所有，注意保密28
外围展现层AJAX、Portlets、WEB2.0、Other系统BIL4L业务流程层ING3MS业务服务层EAISO2CSBSS业务组件层ED1A基础应用层应用服务器应用进程数据文件图4.4SOA架构下CRM域应用监控的范围(带有数字标识的内容为应用监控对象)应用层次结构划分为基础应用层、业务组件层、业务服务层、业务流程层、展现层，各层次间通过直接调用或者通过CSB进行调用，实现系统功能。其中CRM域的应用监控主要涉及基础应用层、业务组件层、业务服务层、CSB四部分：基础应用层：监控为上层组件和服务提供基础支撑的软件进程、应用服务器、数据文件等，在J2EE平台下，主要体现为运行在JVM容器中的WebApplicationServer。这里主要关注应用服务器的性能、故障、配置等信息的监控；业务组件层：业务组件是提供业务服务的载体，负责实现具体的业务逻辑，并且保证其对外提供的服务的质量要求。通常业务组件的开发采用基于容器的技术，比如实现组件、负载均衡、高可用性和工作量管理的应用服务器。对业务组件的监控主要基于对应用服务器的监控实现，提出了对J2EE架构下交易的跟踪功能(可选)；业务服务层：业务服务以面向服务的方式对一个或者多个业务组件的功能进行封装，它具有明确的接口描述，可以被其它业务服务调用，也可以被业务流程或展现层调用。对业务服务的监控主要体现为业务服务的可用性监控；版权所有，注意保密29
CSB：是CRM域内部的服务总线，CRM内部公用服务都需要在CSB上注册管理，可以提供给各个系统进行调用。提供给集团CRM或其它域相关系统的服务也需要通过CSB提供。对于CSB的监控主要指的是对注册在CSB上的服务的监控。4.2.1应用拓扑管理应用拓扑是以应用系统作为索引来组织应用软件所包含被管对象的拓扑结构，与普通告警列表相比，应用拓扑关注关键的应用监控对象及其关键指标信息，并能通过对支撑关系的分析协助运维人员进行问题预警和告警根源定位。应用拓扑图由节点、节点上的指标、节点间的关系、指标间的关系等元素构成。为体现应用软件与支撑应用软件的基础设施之间关联关系，拓扑图还要能展示与应用软件节点相关的基础设施节点以及告警、性能等指标数据内容。图4.5应用拓扑建模示意图应用拓扑建模步骤如下：1.确定应用拓扑监测范围：对需要监测的关键应用系统进行分类，如CRM域的，将相同类型应用系统监控对象配置在同一个应用拓扑模型中。系统要支持对应用拓扑模型的分类目录式展现；版权所有，注意保密30
2.确定应用关键节点：在明确了监测的应用系统范围后，对需要监测的应用程序、应用服务器、接口、数据文件以及支撑应用的基础设施如主机、存储、数据库等节点进行调研分析；3.建立关键节点，节点与监控对象、监控指标的关联关系，能通过指标库查询选择相应指标，可实现一次性的选中多个指标建立关联关系；4.建立节点间的关联支撑关系：应用拓扑管理具体包括拓扑模型模型管理、应用支撑关系管理和应用参数管理等，详述如下。4.2.1.1应用基本参数管理应用参数管理是指对应用拓扑管理中用到的各类基本参数进行管理，包括应用、基础设施类被管对象管理、指标管理、指标关联关系管理等。【功能要求】4-30.系统支持通过统一的配置中心界面，可视化方式集中配置应用建模相关参数。4-31.支持应用软件与支撑应用软件的基础设施监控对象管理、监控对象关联关系管理、指标管理、指标关联关系的统一配置管理；4-32.对于应用及基础设施的配置信息以及关联关系信息，获取方式除了手工录入，还支持从IT服务管理系统的CMDB接口导入；4-33.应用建模应支持自动发现功能，系统可根据自动发现规则配置自动发现被管对象、被管对象关联关系等信息；4.2.1.2拓扑模型管理能够提供图形化的方式，根据监控人员的要求配置一个或多个应用拓扑模型，以网络拓扑图的方式展示应用软件、基础设施监控对象以及他们的支撑关系。【功能要求】版权所有，注意保密31
4-34.应能支持拓扑模型中节点基本信息的维护，包括节点名称、节点与应用、基础设施类被管对象之间的对应关系等。系统应能够提供图形界面，灵活的定义业务监控视图，在定义过程中，应可以选择视图呈现的元素、背景颜色、父节点显示层次、子节点显示层次等；4-35.支持节点与节点之间的拓扑关系管理，如关键应用模块之间及关键应用模块内部的逻辑关系；4-36.应能够在拓扑模型中设置节点与被管对象的指标过滤规则，以便将与应用有关的指标信息在模型中呈现出来；4-37.应能够在拓扑模型中设置节点与被管对象的告警过滤规则，以便将影响应用状态的告警信息加载到拓扑模型中；4-38.应支持根据需要切换到不同的应用拓扑，支持多个拓扑模型管理；4.2.1.3应用支撑关系建模应用支撑关系建模主要指对应用软件与支撑应用的基础设施之间关系管理、应用软件自身之间的关系管理、告警影响规则管理、告警关联规则管理。应用软件、基础设施被管对象之间的关联关系包括但不限于：关联关系、依赖关系、从属关系等。通过关联关系可以对应用进行钻取，找到与告警的应用相关的其它应用以及支撑应用运行的基础设施，进而查看相关被管对象的告警数据和性能数据，进行告警问题的根源分析。告警影响规则管理指设置应用支撑关系模型中监控对象的影响规则，如设置某个应用出现告警，引起其父元素状态变化的规则。在应用拓扑图中体现为父节点状态的变化、颜色、文字的提示，以实现应用软件的及时预警。告警关联规则管理指设置不同应用之间、应用与基础设施之间告警关联关系，当多个告警同时出现时，系统会根据告警关联规则进行处理，自动定位出根源告警并突出显示。【功能要求】<应用支撑关系管理>版权所有，注意保密32
4-39.当具备了与IT服务管理系统的集成环境后，当在CMDB(配置管理数据库)中完成配置项关系建立或变更时，应能够将关联关系模型传递到应用支撑关系模型中，实现模型的自动生成；4-40.应能够提供可视化界面新建、编辑、删除构成应用支撑关系模型的各类监控对象，如应用进程、接口、主机、中间件、数据库等监控对象；4-41.应能够实现应用支撑关系模型的增加、删除、修改等基本管理功能，支撑关系包括但不限于关联关系、依赖关系、从属关系等；<告警影响规则管理>4-42.应支持根据监控对象的告警类型、告警程度、告警持续时长等信息对监控对象告警传递规则的配置功能；4-43.应支持根据告警影响规则，将被管对象的告警信息自下往上逐级传递的功能；4-44.告警影响规则方式包括但不限于：最大化：源节点发生任何级别的告警，目标节点将产生严重预警；升级：源节点发生告警，目标节点将产生更高一级的预警；标准：源节点发生告警，目标节点将产生相同的预警；减小：源节点发生告警，目标节点将产生更低一级的预警；最小化：源节点发生告警，目标节点将不产生预警；<告警关联规则管理>4-45.应能够提供可视化界面新建、编辑、删除构成应用支撑关系模型的各类监控对象的告警信息关联关系，告警关联关系包括但不限于：关联关系、从属关系等，以支持告警数据的关联过滤与分析。4.2.2应用运行监测应用运行监测是指根据应用参数管理功能中配置的应用、基础设施监控对象以及各监控对象的指标要求，实时采集、处理指标数据，进行数据预处理、纠错、转换并进行告警判断，通过告警列表、应用拓扑视图等方式予以展示，并通过短信、声音、邮件等方式将告警信息传递给运维人员，来实现对应用运行状态的实时监测。版权所有，注意保密33
应用运行指标监测按照功能可以划分为：应用运行指标检测、应用拓扑模型监测、应用支撑关系监测。4.2.2.1应用运行指标监测应用运行指标监测是指对系统中配置的应用、基础设施监控对象的性能、质量指标数据进行实时监控，如进程CPU利用率、进程内存占用率、接口可用性状态等，对这些数据进行预警分析并生成告警信息，将告警状态呈现在告警列表中，并可以根据配置执行告警前传，以短信、邮件等方式及时通知运维人员处理。【功能要求】4-46.应支持对应用进程的监测管理，如进程状态、进程CPU使用率、进程内存使用率等运行信息；4-47.应支持通过以模拟接口协议进行接口(业务服务)可用性测试，从而实现接口可用性状态、响应时间及其它指标进行实时监测；4-48.应支持数据文件监测，指对系统运行时重要的配置文件、系统文件等进行监测，这些文件的异常可能会导致应用软件的异常，能够针对配置数据文件的变化而产生告警，如数据文件内容的修改、数据文件的删除等；4-49.支持J2EE架构应用服务器的运行指标监测，如客户端请求数、Session数、数据库连接池使用率、Servlet情况、EJB情况等(可选项)；4-50.详细的应用监控内容要求见附录一：监控指标体系相关内容；4-51.基线分析：系统初上线时，因版本的不够稳定，通常告警阀值设定较高，系统进入稳定期后，相应告警阀值需要根据实际情况进行调整。系统应支持根据某个监控对象和指标一段时期内的指标运行情况进行汇总，作为阀值调整的基线，用户可参考汇总基线值方便地调整性能告警阀值。版权所有，注意保密34
4.2.2.2应用拓扑模型监测应用拓扑模型监测是根据拓扑模型，对在模型上定义的关键应用节点，节点关键性能、质量指标数据进行实时监控，将应用运行中出现的告警、预警信息直观呈现在应用拓扑模型中，来实现对应用系统运行状态的专题式监控，及时发现用户关注的异常。【功能要求】4-52.应用拓扑模型监测功能应以应用拓扑视图的方式展现；4-53.支持根据不同的应用系统构建不同的拓扑视图，并可以在监控时灵活切换进行监控；4-54.性能指标应具备预警机制，当某个指标的当前值超出了预警阀值，系统应能够自动生成应用告警信息，通过短信、声音、告警列表等方式主动通知业务人员或者相关维护人员及时解决问题。反映应用拓扑模型上，则该指标对应的节点应能够以不同的颜色展示不同级别的告警，当该告警事件被清除后，系统应能自动将该关键点恢复成正常颜色；4-55.支持通过应用拓扑图关联到应用节点详细信息页面，可根据时间段来查询该节点的告警信息列表，进而进行相关告警处理如告警确认、告警级别调整、告警清除等操作；4-56.支持通过应用拓扑图关联到应用节点详细信息页面，可根据时间段来查询该节点的历史指标数据，以表格或走势图的方式展现，应支持业务指标数据导出功能，导出格式包括但不限于文本、EXCEL等文件格式；4-57.应用拓扑视图应支持定时无闪烁刷新功能，刷新频率不宜过高，以不影响系统性能和展现效果为基准，也不宜过低，否则无法达到业务过程监测的实时性要求。4.2.2.3应用支撑关系监测应用支撑关系监测是指根据应用支撑关系模型对应用系统以及支撑应用的底层基础设施系统进行监测。对符合应用支撑关系、告警影响规则、告警关联规则的信息进行处理和展现，借此实现告警的根源分析、节点预警以及告警关联过滤，帮助运维人员提前发现应版权所有，注意保密35
用系统潜在问题、快速定位告警根源，以最短的时间解决系统问题，保证业务的正常运行。【功能要求】4-58.应支持根据应用模块之间的支撑关系以及应用与底层IT基础设施间支撑关系，以拓扑图的方式展示被管对象关联关系。在应用拓扑模型或者告警列表中，当某应用被管对象出现告警时，可以根据支撑关系钻取并展示相关被管对象，帮助维护人员进行告警问题根源分析。由上至下迅速定位影响应用系统正常运行的故障根源；4-59.应能够根据告警影响规则实现告警信息的传递。在应用拓扑模型中，当某节点发生告警时，系统可根据告警影响规则将告警信息传递到相关的其它节点中，并用特殊的颜色或信息予以展示。由下至上迅速了解节点故障对应用系统的影响；4-60.应能够根据告警关联规则实现告警的关联过滤。在应用拓扑模型或告警列表中，当多个被管对象均触发告警时，系统可根据告警关联规则，找到多个告警信息中的根源告警并突出显示，并能展示各告警信息之间的衍生关系；4.2.3应用交易跟踪（可选）【背景分析】随着J2EE框架及相关技术的迅速发展，J2EE已经成为大型企业创建以Web为中心的关键业务应用的首选平台，基于J2EE的应用服务器已经成为企业Web应用基础架构的核心。在J2EE应用管理过程中，迅速诊断和解决故障、性能问题是最关键，也最具挑战性的工作，特别是在生产环境下，问题将会更加复杂。常见的J2EE应用系统架构如下：版权所有，注意保密36
DBServletssnoiLtInternetWEB服务器EJBsQScaDBsna外部用户rT负载均衡防火墙中间件DBIntranetWEB服务器应用服务器内部用户图4.6J2EE应用架构示意图J2EE应用架构是一个复杂的、多层次的结构，其中包括客户机、防火墙、负载均衡器、Web服务器、应用服务器、交易服务器、数据库服务器以及这些组件之间的网络链接。同时，由于J2EE应用是建立在组件基础上的多层次结构，所以其本身也具有内部复杂性：应用服务器通过某个Web服务器接收到客户发出的HTTP要求，然后采用各种J2EE组件（Servlets、EJBs、helperclasses等）和各种外部实体（例如：数据库和交易服务器等）处理这些要求，再返回处理结果。可能造成J2EE应用服务器出现性能和可用性问题的因素有：不良的代码、设计和系统结构，造成例如内存泄漏、过多的远程调用、数据库SQL语句耗时、JDBC连接未释放等；错误的参数设定，例如数据库连接数不足、不合理的缓冲池大小、不正确的执行线程数、过小或过大的JVM内存量等；不合理的容量规划，低估了并发用户的数量造成资源紧缺，或者高估了所需容量导致资源浪费；不合适的集群，它将导致不正确的负载平衡，同样会造成节点的性能过载，削弱应用可用性；网络、硬件等其它问题。传统的分析策略，如基于服务器日志和参数的分析，在大型分布式、多层次的复杂J2EE应用中，往往不能提供足够的信息。J2EE诊断需要能够对运行中的生产系统，从版权所有，注意保密37
URL访问至数据库调用整个交易过程进行跟踪与分析，并能在定位到具体交易环节后深入应用系统组件和代码以定位问题的根源，以实现真实环境与负荷下的性能分析和诊断。由此提出了对应用交易跟踪功能的要求。【功能定义】交易实例跟踪：系统可以通过跟踪全程事务的方法，来获取每个应用交易实例各环节及整体性能数据，跟踪信息要能跨越Web应用架构的各个层面，如浏览器客户端到http服务器，再到应用服务器的网络时间；应用服务器内部各组件，如Servlet时间、SessionEJB时间、数据库时间等。系统可以通过设定性能阀值如交易时长来实现对整体交易或者某交易环节的监控，当应用交易出现超时等异常情况时，系统可以自动产生告警，并将交易实例详细流转情况记录入库，以支持问题现场的重现，方便运维人员先于系统用户发现问题并进行后续的交易深入分析，准确定位系统性能瓶颈所在。交易跟踪过程如下图：交易流转路径URL1JSP3ServletEJB3SQL21客户端HTTP服务器应用服务器数据库服务器URL1JSP1Servlet1EJB1SQL1URL2JSP2Servlet2EJB2SQL2URL3JSP3Servlet3EJB3SQL3图4.7交易跟踪流程示意图版权所有，注意保密38
交易深入分析：通过监控级别的进一步增强，当交易跟踪过程中监控到应用出现性能瓶颈后，可以自动开启应用交易的深入分析功能，实现事务处理中函数级别的时间捕捉，并将函数栈调用全过程，包括方法名、方法耗时信息等记录入库。可以通过被跟踪的交易实例关联到函数调用列表，支持运维人员与系统设计、开发人员协同工作，找出性能根源并及时解决。【功能要求】4-61.系统应能够根据应用交易实例流转情况自动生成交易拓扑，以图形化的方式展示交易实例流转过程，包括每个环节关联的组件对象，每个环节耗费的时间等；4-62.系统应支持针对不同的URL路径、Servlet对象名称等维度对交易的性能数据进行查询和统计分析，以期在生产过程中对系统性能进行评估，提前发现系统性能瓶颈；4-63.应支持交易跟踪的监控级别调整，分为两级基本的交易跟踪与监控。开启后，系统可以通过实时采集每个应用交易实例各环节流转的性能数据，进行性能数据的汇总，将均值信息记录入库，当设定了交易时长阀值后，如果交易超出阀值则会记录交易调用的详细信息，以备现场重现所用；深入的交易跟踪与分析，开启后，系统会在出现交易超时情况时，深入代码级别的数据采集，记录函数调用顺序以及函数执行时长等信息，以实现交易的深层次跟踪；4-64.应支持集群环境下的系统架构的交易跟踪功能，能够定位低性能应用服务器；4-65.要求系统实现时不修改生产系统源代码，不会对原有交易性能产生影响。同时，在开启了应用交易跟踪的两级监控功能时，分别对生产系统主机的额外压力应不大于10%和20%；4-66.要能支持主流J2EE应用服务器的交易跟踪功能，包括但不限于：WebLogic、WebSphere、Tomcat等。【说明】应用交易跟踪功能专业化程度较高，实现的技术难度较大，同时对生产系统也会带来较大的性能压力，作为可选功能项，各省可根据自身需求情况酌情参考。版权所有，注意保密39
4.3业务交付流程监控模块业务交易和信息处理通常在运行过程中是以业务流程的方式进行的，业务交付流程监控模块是将业务流程作为监测视角，对关键业务流程的处理过程进行深层次的信息整理和展现，深入业务过程内部，解析业务细节信息，通过监测业务过程中关键环节的指标数据以及整个业务过程的关键质量指标数据，来了解业务的运行状态和质量，找出业务流程瓶颈，发现业务存在或潜在的问题。这里监测对象主要指业务交付端到端流程涉及的各业务系统运行环节以及相应的业务指标数据。业务监测过程包括业务建模、运营监测、业务质量分析、可用性探测及业务稽核。4.3.1业务建模业务建模是以数据模型的方式在系统中建立起业务过程或者业务支撑关系的描述。主要包括：业务过程建模、业务支撑关系建模和业务参数管理。业务过程建模主要指业务活动过程中的模型建立；业务支撑关系建模是描述业务与模块、业务与底层IT基础设施以及应用之间的关系；业务参数管理指业务基本配置数据管理。4.3.1.1业务基本参数管理业务参数管理是指对业务建模过程中所包括的参数进行集中配置管理。【功能要求】4-67.系统支持通过统一的配置中心界面，集中配置业务建模参数。4-68.支持图形化界面灵活的配置业务建模参数。4-69.支持业务过程配置、关键点配置、指标管理、指标关联关系配置、指标分析方法配置、指标关联关系分析方法配置等功能。4.3.1.2业务过程建模业务过程建模首先通过对关键业务的流程梳理，确定业务处理过程中的监测关键点，版权所有，注意保密40
以业务处理过程的视角描述关键点之间的关系，形成业务处理过程模型。然后根据监测需要建立相应的监测指标体系，指标通过对业务基础数据的抽取和计算，来体现业务关键点的业务状态。业务过程建模的方法：图4.8业务建模方法示意图1.确定业务流程监测范围，选择重点需要监控的业务流程；2.确定流程的关键点，即业务过程中的关键处理环节。主要从监控需求出发，选择流程中容易出问题或者需要重点关注效率的环节作为关键点；3.梳理关键点的指标。抽取的关键业务指标能够对关键点的业务处理状态进行直观准确反映。指标的类型一般包括业务可用性、业务及时性、业务准确性、业务处理量、积压量等；4.通过关键点间的关联关系梳理指标之间的关联关系。关键点间的关联关系包含某几个关键点间的关联关系、具体的关键点与整个业务过程的关联关系；5.确定指标的分析方法，包括针对单个指标、以及多个指标之间关系的分析方法。例如新装机流程监控：版权所有，注意保密41
图4.9新装机流程示意图4.3.1.2.1业务过程模型管理过程模型管理是对所梳理的业务过程在系统中以模型化语言的方式进行存储，包括过程关键点梳理、业务关键点变迁流转路径梳理，并将整个业务过程以模型的方式存储，一个业务过程主要实体包括业务过程、环节、关键点、环节关联。【功能要求】业务过程关键点关键点关键点关键点图4.10业务过程建模示意图4-70.应能够根据对业务过程进行分类，支持对业务类型的增加、删除、修改的功能；4-71.应能够支持对业务过程基本信息进行增加、删除、修改的功能；4-72.应能够提供图形化界面新建、编辑、删除构成业务过程模型的各类监控对象，如业务关键点、指标等信息。版权所有，注意保密42
4.3.1.2.2关键点与指标的关系管理关键点与指标的关系管理，是对指标库中的指标与业务过程的关键环节的关系进行维护，通过这种关系的建立，将指标与业务过程关联起来，指标的量值能反应出监测对象的实际状态。关键点与指标的关系模型管理指的是将这种关系在系统中以模型的方式进行存储。【功能要求】建立关键点与指标的关系包含以下内容：4-73.应支持图形化的配置界面，配置关键点与指标的关联关系。包括关系的建立、修改与删除。如下图所示：图4.11关键点与指标关系示意图4-74.应支持从业务指标库中搜索需监测的指标，搜索条件包括指标类型、指标编码、指标名称等；4-75.应支持直接创建指标并与关键点关联的功能。指标需要明确定义采集周期、采集方式、起始采集时间等；4-76.应支持对指标进行归类整理的功能，如业务量类指标、业务处理效率类指标、业务积压类指标等；版权所有，注意保密43
4-77.应支持设置关键点上所对应的指标的告警过滤规则，以便将这些影响业务的告警信息加载到模型中，过滤规则应能够灵活的基于告警事件的不同字段进行设置，并能够基于多个字段组合设置过滤规则。4.3.1.2.3关键点间的关联关系模型管理业务关键点间的关联关系指确定业务过程中的关键点相互之间存在的关系，其关系通过关键点关联的指标的关系来具体体现。业务关键点间的关联关系管理指的是将这种关系在系统中以模型的方式进行存储。通过对不同关键点的多个同类业务指标的归并可以形成反映整个业务过程的关键质量指标。如下图所示的过程质量指标1是由业务指标1和业务指标10归并而成，归并算法根据具体业务应至少支持加、减、乘、除、定制等基本算法。图4.12业务关键点关联关系示意图关键点间的关联关系包含两种：某几个关键点间的关联关系；某一关键点与整个业务版权所有，注意保密44
过程的关联关系。某几个关键点间的关联关系，具体体现为多个不同关键点同类指标间的关系，通过对关键点指标进行分类及规整，形成相关指标类型，根据过程模型，并结合业务经验积累定义相关关键点同类指标的关联关系，进而建立关键点间的关联关系。关键点间的关联关系是业务监测的分析要点，如上图中关键点1的业务指标1和关键点3的业务指标12存在固定比值范围的关系，即业务指标1与业务指标12的比值在某一固定取值区间。关键点与业务过程的关联关系，具体体现为某一关键点业务指标与业务过程关键质量指标之间的关系。如上图所示：关键点3的业务指标10和反映该业务过程关键质量指标的过程质量指标1存在关联关系。【功能要求】建立关键点间的关系模型具备如下功能：4-78.应支持图形化的配置界面，配置关键点间的关联关系。包括关系的建立、修改与删除；4-79.应支持对关键业务指标进行归类整理，如业务处理效率类指标、业务积压类指标等；4-80.应支持对关键点相关业务指标进行归并，形成反映整个业务过程的关键质量指标的功能；4-81.应支持对不同关键点同类指标间建立关联关系，形成整个业务过程的监测分析要素，例如：构成关系、比值关系等；4-82.应支持对某个关键点与业务过程关键质量指标间建立关联关系，形成整个业务过程的监测分析要素，例如：占比关系等；4-83.应支持对关键点的单个指标或单个业务过程关键质量指标设置异动分析、趋势分析等多种分析方法；4-84.应支持对关键点间的关联关系设置多种分析方法，具体体现为对不同关键点间具有关联关系的同类指标设置对比分析、构成分析等多种分析方法，或者对多个关键版权所有，注意保密45
点间的同类指标以及某个业务过程关键质量指标之间设置对比分析、构成分析等多种分析方法。4.3.1.3业务支撑关系建模业务支撑关系建模主要是指对业务与模块、业务与底层的IT基础设施以及应用之间的关系进行梳理，建立业务的支撑关系模型，描述不同层次之间的物理和逻辑支撑关系，从而把业务的可用性和业务状态，与支撑业务的模块以及底层IT基础设施和应用的状态关联起来，构成业务与模块的支撑关系模型以及业务与应用、IT基础设施支撑关系的模型。业务支撑关系建模主要包括支撑关系模型管理、指标聚合规则管理、告警影响规则管理、告警关联规则管理等。4.3.1.3.1支撑关系模型管理关系模型管理是以数据模型的方式在系统中建立业务与应用及IT基础设施的关系模型，并在系统中以模型的方式进行存储。【功能要求】关系模型管理要能支持如下功能：4-85.当具备了与IT服务管理系统集成环境后，在配置数据库（CMDB）中完成配置项关系建立时，应能够将关联关系模型自动传递到业务支撑关系模型中，以便实现模型自动生成功能。4-86.应能够实现业务支撑关系模型的增加、删除、修改等基本管理功能。4-87.应能够提供图形化界面新建、编辑、删除构成业务支撑关系模型的各类监控对象，如服务器、中间件等监控对象。4-88.应能够在业务支撑关系模型中设置监控对象的指标过滤规则，以便将与业务有关的指标信息在模型中呈现出来。4-89.应能够在业务支撑关系模型中设置监控对象的指标告警过滤规则，以便将这些影版权所有，注意保密46
响业务状态的告警信息加载到模型中，过滤规则应能够灵活的基于告警事件的不同字段进行设置，并能够基于多个字段组合设置过滤规则。4.3.1.3.2指标聚合规则管理指标聚合规则管理指在业务与模块的业务支撑关系模型中设置基本监测指标向父元素聚合的规则管理功能。父元素根据聚合生成的新指标的数据取值以及该新指标设置的告警规则得到影响该元素可用性状态的告警数据，呈现在业务支撑关系模型展现视图中，直观的反映父元素的业务状态以及底层元素状态之间的支撑关系。【功能要求】4-90.系统应支持提供常用的指标聚合计算规则，主要包括如下：平均算法；最大算法；最小算法；合计算法；定制算法等；4-91.应支持指标逐级向上聚合的功能；4-92.系统应支持聚合指标值自动计算功能。4.3.1.3.3告警影响规则管理告警影响规则管理指设置业务支撑关系模型中监控对象的告警状态变化，引起其父元素状态发生变化的影响规则。如支撑业务的服务器或者应用出现影响业务的严重告警时，可直接或间接的影响到该业务的出现预警，在业务监控视图中体现出父关键点的状态变化，以颜色、文字等方式给以提示。【功能要求】版权所有，注意保密47
4-93.应支持根据监控对象的告警程度、告警持续时长等信息对监控对象告警影响规则的配置功能。4-94.应支持告警影响规则自下往上逐级传递的功能。4-95.直接传递规则应包括如下算法：最大化：源节点发生任何级别的告警，目标节点将产生严重预警；升级：源节点发生告警，目标节点将产生更高一级的预警；标准：源节点发生告警，目标节点将产生相同的预警；减小：源节点发生告警，目标节点将产生更低一级的预警；最小化：源节点发生告警，目标节点将不产生预警。4-96.系统应支持根据影响规则自动计算父元素状态的功能，父节点的告警信息能体现原节点的告警信息。4.3.1.3.4告警关联关系管理告警关联规则管理指设置不同业务之间、业务与应用以及底层基础设施被管对象之间的告警关联关系，当不同层面的多个告警同时出现时，系统会根据告警关联规则进行处理，自动定位出根源告警并突出显示。【功能要求】4-97.应支能够提供可视化界面新建、编辑、删除构成业务支撑关系模型的各类监控对象的告警信息关联关系，告警关联关系包括但不限于：关联关系、从属关系等，以支持告警数据的关联过滤与分析。4.3.2业务运营指标监测业务运营指标监测是通过业务监控视图将业务运行中的各个关键点的业务指标数据以及支撑业务的底层IT基础设施和应用的性能指标数据加载到业务模型上，并对这些指标数据进行预警分析生成告警数据，将告警状态呈现在业务模型中，来实现对业务运行状态的实时监测。版权所有，注意保密48
业务运营指标监测按照功能可以划分为：业务过程指标监测、业务支撑关系监测。4.3.2.1业务过程指标监测业务过程指标监测是指根据业务过程模型对各关键点上定义的关键业务指标以及整个业务过程的关键质量指标数据进行监控，如订单处理失败率、平均处理时长等数据，并对这些业务数据进行预警分析生成告警信息，将告警状态呈现在业务过程模型中，来实现对业务流程运行状态的实时监控，及时发现业务流程中出现的异常。【功能要求】4-98.业务过程指标监测功能应以业务监控视图的方式展现。4-99.业务监控视图应可以针对不同的业务构建出不同的视图。4-100.业务监控视图应能够提供拓扑图的方式来呈现具体的业务流程图，包括业务流程、关键点以及关键点间的关系等信息。4-101.业务关键点上应可以实时展现该关键点所关联指标的即时数据，包括基本监测指标数据以及根据基本监测指标运算出来的聚合指标数据。如：指标A为新装开户工单开机成功数，指标B为新装开户工单开机失败数，则聚合指标C新装开户开机工单失败比例=B/(A+B)。4-102.应能够实时展现反映该业务流程整个过程的关键业务质量指标数据。该指标数据一般由各个业务关键点同类指标聚合得到。比如整个业务过程的业务处理时长为各个关键点业务处理时长的加和。4-103.指标应具备预警机制，当某个指标的当前值超出了预警阀值，系统应能够自动生成业务告警信息，通过短信、声音、邮件、网站列表等方式主动通知业务人员或者相关维护人员及时解决问题。反映到业务过程模型上，则该指标所属的关键点应能够以不同的颜色展示不同级别的告警，当该告警事件被清除后，系统应能自动将该关键点恢复成正常颜色。4-104.业务过程指标监测应具备单实例监测以及总量监测的功能，单实例监测主要是指监测的业务指标对象为单个实体，如监测订单处理时长指标，则需要监控具体每一版权所有，注意保密49
个订单的处理时长；而总量监测是指监测的业务指标对象为多个实体的总量数据，并不需要细分到单个实体，如订单平均处理时长指标、订单受理失败量等。单实例监测和总量监测是通过监测指标采集数据的属性来区分的。4-105.业务关键点详细页面可根据时间段来查询该关键点的告警信息列表，系统应支持自动和手工进行告警确认、告警级别调整、告警清除等操作。4-106.业务关键点详细页面应支持根据时间段来查询各关键点业务指标在该段时间内的数据，以表格或走势图的方式展现，应支持业务指标数据导出功能，导出格式包括文本、EXCEL等文件格式。4-107.业务监控视图应支持定时无闪烁刷新功能，刷新频率不宜过高，否则影响系统性能和展现效果，也不宜过低，否则无法达到业务过程监测的实时性要求。4.3.2.2业务支撑关系监测业务支撑关系监测是指根据业务支撑关系模型对业务以及支撑该业务的业务模块、底层IT基础设施和应用的状态进行监控，并对这些业务数据进行预警分析生成告警信息，将告警状态呈现在业务支撑关系模型中，根据定义的业务影响规则来实现对业务的影响性分析。【功能要求】4-108.应支持以拓扑图的方式分别呈现业务与业务模块之间的支撑关系模型和业务与底层IT基础设施以及应用的支撑关系模型。4-109.业务支撑关系监测是通过业务监控视图来呈现的，系统应能够提供图形界面，灵活的定义业务监控视图，在定义过程中，应可以选择视图呈现的元素、背景颜色、父节点显示层次、子节点显示层次等。4-110.应能够将影响业务的性能指标信息加载到对应的监控对象中。4-111.应能够灵活的设置告警引起的监控对象可用性状态规则，可用性状态应至少包括可用、劣化、不可用等状态，并能针对不同的可用性状态设置不同的展现颜色。4-112.应能够将可用性状态加载到对应的监控对象中。版权所有，注意保密50
4-113.应能够根据告警关联规则实现告警的关联过滤。在业务监控视图或告警列表中，当多个被管对象均触发告警时，系统可根据告警关联规则，找到多个告警信息中的根源告警并突出显示，并能展示各告警信息之间的衍生关系以实现告警的根源发现。4-114.应能根据业务影响规则来判断当底层IT基础设施以及应用出现故障时将会对哪些业务产生什么级别的影响。4-115.监控对象详细页面可根据时间段来查询该元素的告警信息列表，系统应支持自动和手工进行告警确认、告警级别调整、告警清除等操作。4-116.业务监控视图应支持定时无闪烁刷新功能，刷新频率不宜过高，否则影响系统性能和展现效果，也不宜过低，否则无法达到业务监测的实时性要求。4.3.3业务运营质量分析业务运营质量分析是在业务建模和业务运营指标监测的基础上对业务过程的状态变化情况进行跟踪，对各关键点指标数据以及业务过程关键质量指标数据通过异动、趋势、对比、构成等分析方法来实时或准实时地发现业务异常，及时掌握业务运营质量，并对业务未来变化趋势进行预测，提前发现业务可能出现的问题并及早做出预防措施，找出影响业务的主要因素，解决问题。可以考虑的分析方法包括：异动分析：通过对当前业务指标数据与历史指标数据或业务指标预测数据的对比，发现业务活动的异常，作为业务问题进一步分析的出发点图4.13异动分析示意图版权所有，注意保密51
趋势分析：对关键业务指标的历史数据进行特定周期的趋势分析，反映关键业务环节业务活动质量的变化趋势8.00%7.00%6.00%5.00%4.00%3.00%2.00%1.00%0.00%1357911131517192123252729时间比例处理环节1失败处理比率处理环节2失败处理比率图4.14趋势分析示意图对比分析：业务流程中，有些关键点的指标之间有相似的变动趋势，可以通过比对指标之间的变化趋势，发现某个指标的异常变化业务量时间图4.15对比分析示意图构成分析：业务流程中，有些指标之间有构成关系，可以根据业务经验发现基本一致的构成比例，如构成比例曲线发生异常，则应及时展开分析100%60%50%80%40%60%30%比例比例40%20%10%20%0%0%9:0010:0011:0012:00时间9:0010:0011:0012:00时间业务环节1业务环节2业务环节3处理环节1占比处理环节2占比处理环节3占比图4.16构成分析示意图【功能要求】4-117.应能针对单个指标提供异动分析、趋势分析等图形分析方法，针对关键点间的关联关系（即不同关键点同类指标之间的关联关系、某一关键点与业务过程关键质量版权所有，注意保密52
指标之间的关联关系）则可以提供对比分析、构成分析等图形分析方法，这在业务建模时需要进行分析方法的配置。4-118.针对某些业务指标已确定的分析方法应可随着业务的变化而进行适当调整；4-119.应支持历史数据的对比功能，对于同一指标不同时期（如小时、天、月等）的对比（趋势分析），不同指标相同时期的对比（对比分析）。4.3.4可用性探测可用性探测是通过模拟客户端运行业务的过程以及模拟外部系统调用服务的过程，以界面、短信、服务调用等方式针对业务进行探测，从而对业务可用性状态、响应时间及其它指标进行实时监视。通过分析探测结果，发现关键业务流程潜在的性能及可用性问题，建立预警机制，生成业务活动监测告警事件通过模拟端到端的请求，替代传统的人工检查，弥补系统监控管理的缺陷，先于系统使用者找出业务流程的隐患。【主要探测方式】HTTP方式：通过模拟HTTP方式请求，探测网上营业厅请求、前台B/S结构的受理终端等系统；短信方式：通过模拟短信方式请求，探测短信营业厅系统；程序方式：通过模拟程序方式请求，探测自助受理设备、前台C/S结构的受理终端等系统；Socket接口方式：通过模拟Socket接口方式请求，探测CRM系统与外部系统之间的接口；WebService通过模拟WebService接口方式请求，探测诸如CRM系统与外部系统之间的查询，受理等功能。版权所有，注意保密53
4.3.4.1用例管理探测用例管理提供对探测用例和探测动作的定制、修改、删除。探测用例包含若干探测动作，每一个探测动作代表探测时执行的一次请求，系统针对每一探测动作记录其探测结果。探测用例管理需要提供探测用例与探测动作的关联关系、探测动作之间的关联关系的管理。例如缴费开机、客户订购产品、充值、停机等业务活动过程都可以作为探测用例。【功能要求】4-120.探测用例管理功能支持对用例属性（主要包括用例名称、探测对象、业务类型、部署位置等）的增删改查的管理。4-121.探测动作管理功能包括对动作属性（主要包括动作名称、所属用例、动作频率、探测方法等）管理。4.3.4.2探测处理探测处理功能包括业务活动模拟功能、手动探测与定时探测、探测点部署、探测告警、探测结果展现(通过综合展现层展示)。【主要业务分类】可用性探测可分为用户接触点探测、服务接口探测。用户接触点探测：通过模拟最终用户、营业员等系统最终用户的实际业务操作，采用仿真方式直接对被探测系统特定业务发起探测，通过对被探测业务办理结果及办理时延等探测结果的分析，发现被探测系统中存在问题的业务功能模块。服务接口探测：版权所有，注意保密54
主动模拟OSS订单接口、计费接口、欠费停机接口等CRM外部系统的实时业务过程，采用仿真socket、http数据交易等方式直接对CRM相关的业务接口发起模拟探测，模拟产生业务交易并分析交易最终结果，从而发现接口潜在的性能及可用性问题，建立预警机制，生成服务接口监测告警事件。在用户接触点探测和服务接口探测的基础上，可以使用业务建模中已经设置好的业务流程顺序，采用仿真交易的方式直接对业务过程发起模拟探测，模拟产生业务交易并分析交易最终结果，从而发现关键业务流程潜在的性能和可用性问题，建立预警机制，并通过系统监测生成告警事件。具体的业务功能和服务接口探测内容见附录一：监控指标体系章节。【功能要求】4-122.业务活动模拟功能业务活动模拟应能根据被探测业务系统的类型提供多种模拟功能。需要能够模拟用户打开业务系统页面，判断是否可以正常打开页面；再使用特定的测试帐号登录业务系统，判断是否可以正常登录；并模拟用户执行一个查询操作或功能操作（该操作需要通过相应中间件连接至数据库，然后返回操作结果），根据操作的返回结果判断操作是否成功，同时获取时延信息。4-123.手动探测与定时探测定时调度按照配置的探测频度和时间要求，发起探测交易；手动调度根据某类业务探测任务需要发起即时探测交易。增加手动调度功能可以补充定时调度探测的一些盲区，在某个时点可以进行业务运行状况抽查或者验证业务运行状况，并能按照现实情况增加某些时间点地探测密度。4-124.探测点部署模拟探测需要具备从不同地理位置（区域）发起业务探测的能力。这些业务探测发起地点通常部署在用户体验较差、性能问题多发地点，或者业务量较大的地点。所有探测点版权所有，注意保密55
采集的信息都需要发送到业务活动探测平台，按照小时、天、月和年等时间维度进行聚合。为查询分析和实时监测提供能够定位到地理位置（区域）的信息。4-125.探测告警探测告警是指在探测过程中由于探测模块本身出现故障或者探测结果数据出现异常导致系统生成警示信息的功能。探测告警包括两个方面的含义：一方面是指探测过程本身发生故障；另一方面是指探测到的业务活动信息有异常。4-126.按照主题的方式展示探测数据探测展示功能能够实时的按照用户类型和业务类型等维度来展示探测的数据。探测展示功能能够以业务为中心，按照模拟业务体验发起时间、发起地点、业务响应时间和业务体验结果等维度进行数据分析，找出体验较差的业务。本功能也可以以用户类型作为分类，展示不同类型用户的探测结果。探测的实时数据需要提供参考数据对比功能。参考值可以基于系统自行测算出来，也可以基于维护人员的历史经验输入。4-127.探测信息查询与分析探测信息查询与分析功能，需要根据探测信息的用户接触点、业务类型、探测指标等多种属性提供查询和分析的功能，属性范围如下：探测用例信息需要包括：探测时间、探测结果、探测时间总长、平均时长、探测失败率。探测动作信息需要包括：探测时间、反馈结果、时间长度。4.3.4.3探测回退探测回退是指在整个探测活动结束后，系统自动回退探测过程中对于生产环境造成的改动，确保生产环境恢复到探测之前的状态。【功能要求】版权所有，注意保密56
4-128.若自动回退失败，系统将发起回退失败告警，提示维护人员手动回退。4.3.5业务稽核为了保证系统处理全过程的顺畅，提前发现潜在的问题，应考虑对各系统的业务数据质量进行主动性监控及维护。业务数据稽核是指通过数据比对或配置审查的方式来发现业务处理过程以及各系统档案的数据问题，保证业务运行过程中业务处理流程数据及业务档案数据的一致性和准确性。业务数据的异常原因多种多样，主要可分为动态数据异常，如前后环节的订单流转数据；和基于档案的静态数据异常，如客户资料数据。动态数据异常一般是由于在业务办理过程中，由于接口通讯中断、数据配置错误、业务逻辑不完善等原因而导致。而静态数据异常一般是由于系统间同步不及时、数据存储异常、人为操作等原因而导致系统数据异常。从稽核方式上看，业务稽核可分为数据一致性稽核和数据准确性稽核两类，分别对应对比方式的数据稽核和数据审查方式的数据稽核。详细的业务稽核内容与指标要求见附录一：监控指标体系章节。4.3.5.1数据一致性稽核数据一致性稽核从稽核粒度上可分为基于数据统计值的平衡性稽核，如客户接触单派发总数等于接收处理各环节的单量总数，和基于数据明细的内容一致性稽核，如CRM系统中的客户信息应该与计费系统保持一致。根据本规范中系统处理边界的定义，数据平衡性稽核通常由业务交付流程监控系统实现，而内容一致性稽核由ODS或者生产系统实现，业务交付流程监控系统负责采集稽核结果、进行展示和告警判断。【功能要求】<数据平衡性稽核>版权所有，注意保密57
4-129.系统应支持业务数据平衡性稽核规则的配置化管理，要求配置灵活、简单；内容包括：核查所需KPI指标的选取，运算公式的配置，运算周期、运算开始时间的设定等。4-130.系统能根据配置好的采集策略自动获取稽核所需的KPI指标，并按设定的运算周期自动进行业务稽核。4-131.对于不满足规则的核查结果，支持产生告警并展现不满足规则的具体原因，包括告警内容、稽核时间等。4-132.提供按照核查时间、稽核类型、稽核规则名称等条件进行查询和统计。<内容一致性稽核>4-133.系统应支持设定内容一致性稽核结果的展示方式和告警判断规则。4-134.系统可接收来自ODS系统或者其它业务系统的内容稽核结果，根据设定的规则进行展示。提供图形化的展示方式，对于不满足稽核规则的记录可以用特别的颜色标明，并提供差异明细数据的关联展现。可对符合告警规则的稽核结果进行告警提示。4-135.可对历史稽核信息进行查询，可按稽核时间、稽核类型等条件进行查询与统计。4.3.5.2数据准确性稽核业务数据准确性稽核包括系统配置符合度稽核、业务逻辑符合度稽核两类。系统配置符合度稽核指系统档案中的数据与系统配置限定的要求是否匹配，是否存在不符合配置条件的数据：例如：系统配置数据限制了USIM卡号必须固定长度且为数字、客户档案的身份证信息不能为空等情况。业务逻辑符合度稽核指系统档案中的数据与业务规则的符合情况，是否有不符合业务场景的数据。例如：E家套餐下的产品的付费方式必须为后付费、办理的在途订单进行反向撤销前必须进行相关退款操作等。版权所有，注意保密58
根据本规范中系统处理边界的定义，数据准确性稽核一般由业务系统实现，业务交付流程监控系统负责采集稽核结果、进行展示和告警判断。【功能要求】4-136.系统应支持设定数据准确性稽核结果的展示方式和告警判断规则。4-137.系统可接收来自业务生产系统或者其它业务系统的准确性稽核结果，根据设定的规则进行展示。提供图形化的展示方式，对于不满足稽核规则的记录可以用特别的颜色标明，并提供差异明细数据的关联展现。可对符合告警规则的稽核结果进行告警提示。4-138.可对历史稽核信息进行查询，可按稽核时间、稽核类型等条件进行查询与统计。4.3.6订单监测订单监测是指对端到端的业务交付订单流程实例进行实时监测，与业务运营指标检测中监控流程性能指标不同，订单监测的对象的是订单实例。通过从CRM、服务开通、计费等系统中同步订单告警信息，及时发现订单流转过程中的异常，并通过主动的查询与分析帮助运维人员准确定位订单问题。4.3.6.1订单流程告警端到端的业务交付订单流转经过CRM、EAI、服务开通、计费等系统，在任何一个系统流转的过程中，如果流程环节执行异常、或者流程环节执行超时，业务系统在本系统生成告警的同时，也可以通过订单同步接口将订单告警同步到业务交付流程监控系统中，业务交付流程监控系统实时采集到这些告警信息，并统一以告警列表的方式展现给维护人员。【功能要求】4-139.应支持从业务生产系统实时接收订单告警数据，根据接口内容和格式要求将数据转换为格式化的内部数据，统一在告警列表进行展示；版权所有，注意保密59
4-140.为了生成业务交付流程监控系统的统一告警信息，各个被监控系统都必须按照业务交付流程监控系统的统一要求生成相应告警接口数据，告警信息内容包含但不限于：客户订单ID：出错的订单在各个系统中的的唯一标识，由CRM系统产生产品定单项ID：出错的定单项标识，由CRM系统产生告警标题：此次告警的标题告警描述：此次告警的详细描述告警生成时间：此次告警发生的时间告警环节：被监控系统中产生告警的具体节点告警类型：超时告警、异常告警产品信息（*可选）：产品名称、产品属性等告警级别（*可选）：产生告警的重要程度。各生产系统根据所产生告警的严重程度对告警进行分级。详细的接口内容与格式要求见集成架构章节相关内容。4.3.6.2订单状态查询订单状态查询是通过订单标识或用户关键号码等唯一查询条件对业务订单的运行情况进行实时查询和可视化视图展现，帮助运维人员了解该订单流程的实时的运行状态。因为端到端的订单流转过程涉及到多个系统的多个流程环节，因此系统应支持在输入统一的查询条件后顺序调用各系统订单查询接口，进行统一的展现。以欠费停开机和订单处理流程为例进行说明：欠费停开机处理根据唯一的事件ID，分别去查询CRM中的客户资料同步情况、服务开通中的开通情况，查询欠费停开机查询流程如图：版权所有，注意保密60
SFM计费系统服务开通系统CRM系统1.发送用户关键号码查询停开机事件ID返回查询结果2.发送停开机事件ID查询停开机是否成功返回查询结果3.发送停开机事件ID查询客户资料同步是否成功返回查询结果图4.17欠费停开机流程示意图系统支持以图形化方式展示订单实例在各系统的流转情况，流程从事件发起到结束过程中，在CRM、服务开通、计费等系统的实时状态。运维人员可以通过视图的颜色定义，区分查询用户的停开机流程是否正常：图4.18欠费停开机流程状态示意图点击图形中的流程节点，可以展现欠费停开机流程在该系统中处理情况的详细信息。如：流程进入时间、处理完成时间、故障详细信息等。订单处理流程版权所有，注意保密61
根据订单标识，分别去查询CRM中的订单流转情况、服务开通中的工单处理情况，以及计费中的资料同步情况等流程，如图：SFMCRM/计费/服开等发送订单编号查询流程在自身系统中是否完成流程完成：返回流程开始时间、结束时间；流程未完成：返回流程停留节点、实时状态；如果发生异常反馈详细故障信息返回查询结果图4.19订单处理流程示意图接收到各系统的反馈信息后，业务交付流程监控系统组合出一张客户订单在各个业务系统中的运行状态图。每个业务系统用一个节点表示，节点的不同颜色表现客户订单在该系统中的运行状态。例如：红色表示有订单行在该系统中发生异常或超时故障；蓝色表示有订单行正在该系统流转，且未发生异常或超时；绿色表示所有订单行在该系统中正常执行完毕；灰色表示订单尚未流转到该系统。如下图：版权所有，注意保密62
图4.20订单处理流程状态示意图点击图形中的流程节点，可以展现订单处理流程在该系统中处理情况的详细信息。【功能要求】4-141.应支持根据订单运行流程，顺序调用相关系统订单状态查询接口，接收反馈的订单流转详细信息，进行统一的展现；4-142.应支持以图形化的方式展示订单实例在各系统的流转情况，展示订单从发起到结束过程流经的节点。运维人员可以通过视图的颜色、文字等定义，区分各节点是否正常；4-143.应支持通过订单流转节点状态关联查询到订单状态详细信息，包括订单状态、系统内部环节列表、各内部环节流程进入时间、处理完成时间、故障详细信息等；4-144.订单状态查询对象应包括但不限于：欠费停开机流程订单处理流程全网订单处理流程：订单状态查询功能支持间接向集团业务交付流程监控系统提供查询接口，处理过程如下：版权所有，注意保密63
SFMCRM系统其他业务支撑系统1.集团订单编号查询省订单编号反馈查询结果2.省订单编号查询订单流转情况反馈查询结果2.集团订单编号查询订单流转情况反馈查询结果图4.21全网订单状态查询过程示意图4.4告警处理告警处理是针对来自应用及业务的性能、告警信息进行统一处理，以便快速确认故障，缩短排障时间，为及时恢复业务运行打下良好基础。主要包括告警判断、告警定位、告警信息丰富、告警过滤、重复告警压缩、告警操作(告警前转、告警确认、告警清除、告警级别调整)、告警流程定义等。【处理原则】实时性：保证关键告警信息及时得到处理。准确性：保证告警信息根据告警级别得到准确处理。参数化管理：提供灵活的参数配置功能，保证告警处理具有很强的适应性。4.4.1告警判断告警判断是对统一采集功能获取到的性能、告警数据进行处理、分析，根据设定的告警规则判断是否需要触发告警。如采集数据满足告警条件，则系统产生告警记录，在告警版权所有，注意保密64
列表及监控视图中进行呈现，并可以通过短信、邮件等方式及时通知运维人员。对于告警类原始数据，主要使用对告警发生频度、告警发生级别等属性进行分析的方式来实现告警的判断；对于性能类原始数据，主要使用阀值策略设定的方式实现告警的判断。【功能要求】4-145.系统应支持灵活的告警判断规则设定，可以根据告警规则准确触发系统告警；4-146.针对告警类数据，支持根据原始告警属性设置告警判断策略，包括告警发生次数、告警发生频度、告警级别等；4-147.针对性能类数据，应支持根据数据阀值设置告警判断策略，应支持静态阀值和动态阀值两种告警策略的设置功能：静态阀值：针对指标值相对固定的数据，特别是应用类性能数据，如进程CPU利用率，使用固定的阀值，将实际发生值与阀值对比生成告警。可以设定多个阀值对应于不同的告警级别；动态阀值：针对指标值不断变化的数据，特别是业务类性能数据，如订单受理量，一天中不同的时刻差异很大，可以使用动态阀值来实现数据比对：1）历史动态阀值：根据业务活动周期，动态选取一定周期内的历史指标数据，如过去一周的数据，通过不同的算法（如均值、加权均值等）计算得出历史动态阀值，通过将当前指标发生值与动态阀值进行对比，实现告警的判断；2）预测动态阀值(可选)：根据业务活动周期，动态选取一定周期内的历史指标数据，如过去一周的数据，选用不同的数据预测及拟和算法（如：回归模型、移动平均模型、混合模型等），计算得出预测动态阀值，通过将当前指标发生值域动态阀值进行对比，实现告警的判断。4.4.2告警定位告警定位是通过对告警信息的查看确定故障可能发生的位置。【功能要求】版权所有，注意保密65
4-148.告警故障定位应与被管对象和被管对象关联关系相结合，应能建立告警列表展示信息中相关元素和被管对象之间的关系。对于一个告警，可根据这个关系自动确认发生告警的被管对象，进而查看与被管对象关联的其它对象情况。4-149.可以对被管对象的最小粒度进行定位，如应用资源和关键业务点。4.4.3告警丰富告警丰富功能主要是对告警信息增加描述，使得告警信息更加详细和直白，方便系统维护人员更快的了解告警信息。【功能要求】4-150.应能够实现告警信息与告警对象的配置数据的关联，对告警信息进行丰富，增加对告警信息的描述，如对于主机告警，丰富相应的厂家，型号，设备描述信息等；对于数据库告警，丰富相应的数据库版本，字符集等信息；对于应用及业务关键点对象，应能够将其支撑的应用业务信息进行丰富，以便维护人员及时了解发生告警设备的全方位信息，针对不同情况分别处理。4.4.4告警过滤告警过滤是指对大量重复的告警信息和次要、无意义的告警信息进行过滤，以避免告警风暴和无效告警或非关心告警的干扰，以提高监控与处理的效率。【功能要求】4-151.按维护要求和管理部门的要求及实际管理情况，针对单位时间内发生大量告警或者已知告警，设置过滤规则，过滤从底层产生的告警信息中不重要的信息，减少轻微告警的干扰，以提高监控与处理的效率。4-152.告警过滤需要提供灵活的过滤规则，可按告警对象、告警级别、告警类别、告警标题、告警时间等设置过滤规则。4-153.被过滤的告警信息可以选择是否入告警数据库。4-154.对已设定的过滤规则需要提供保存和修改功能，便于维护人员灵活选择。版权所有，注意保密66
4-155.告警过滤应实现对以下告警的过滤：用户确认一段时间内可以忽略的告警周期产生的维护类告警已进入服务管理流程进行处理，一定时间内重复发送的告警特殊情况下，只需要记录不需要展现的特殊资源的相关告警4.4.5告警压缩告警压缩是对不同时间产生的相同告警，将其合并成一条告警信息，同时累计该告警的次数，更新最后发生时间等。【功能要求】4-156.在进行告警压缩时，应只在活动告警库中保留一条压缩后的告警信息。4-157.在进行告警压缩时，应更新告警记录的发生次数、最后发生时间等信息。4-158.在对告警进行压缩时，应能够灵活的定义压缩规则，应提供可视化的压缩规则编辑功能。4.4.6告警操作4.4.6.1告警操作内容4.4.6.1.1告警前转系统提供告警前转功能，将告警信息以各种方式（短信、声音、邮件等）转至指定的维护人员。【功能要求】4-159.告警前转的设置条件：告警级别、告警发生时间、告警标题、告警类型、告警地区、告警内容关键字模糊匹配、需要通知的相关系统和人员等。版权所有，注意保密67
4-160.一旦本系统接收到被管对象的告警信息，自动的根据告警前转过滤条件进行过滤匹配，并根据设置的前转方式，自动通过短信等形式发送给相应的管理人员或维护人员。4-161.可以根据告警数据的内容自由定义短信内容，在手动前传时，可以手工编辑短信内容，短信内容应该简单明了。4.4.6.1.2转事件单系统提供告警转事件单的功能，通过与IT服务管理系统的事件管理接口，可以手动或者自动将告警信息转换为告警事件单，进入IT服务管理流程。并可以接收IT服务管理系统返回的事件单处理状态，适时关闭告警。【功能要求】4-162.应支持根据告警对象、告警级别、告警类别、告警时间等属性设置自动转事件单的规则。应能提供可视化的转事件单规则编辑功能；4-163.应支持通过告警列表界面手动触发转事件单的功能，能够手动修改事件单信息，包括事件类型、事件标题、事件描述等；4-164.应支持接收IT服务管理系统反馈的事件单处理结果，自动关闭处理完成的告警记录。4.4.6.1.3告警确认告警确认主要是对告警承载的信息予以认可，以形成有效的告警，便于维护人员快速的优先处理告警信息。收到告警提示后，提供友好的界面供维护人员进行告警确认，系统产生确认时间等确认信息，且具备批量确认的功能。【功能要求】4-165.应能提供根据告警的属性字段设置自动确认规则的功能，并能根据自动确认规则对符合条件的告警进行自动确认，告警确认需要提供灵活的过滤规则，应能够通过组合不同的告警信息字段设置告警过滤规则。版权所有，注意保密68
4-166.可按告警对象、告警级别、告警类别、告警时间等设置过滤规则，应能提供图形化的自动确认规则编辑功能。4.4.6.1.4告警清除告警清除是对于系统中已经处理完毕，或者根据一定的条件判断，无需再提示的告警信息，能够设置清除的标识，标志告警处理完毕。例如：系统提供IT服务管理系统的接口，将告警事件传送给IT服务管理系统，在其实现事件管理流程，事件处理完成后返回本系统，将告警信息清除。【功能要求】4-167.应能提供根据告警的属性字段设置自动清除规则的功能，并能根据自动清除规则对符合条件的告警进行自动清除；应能提供可视化的自动清除规则编辑功能，并且能够对清除的告警设置告警清除标志。4-168.已清除的告警信息，在活动告警库中保留的时间应能设置，以便方便排障。清除后的告警信息，应能够自动转存到告警信息历史库中。4.4.6.1.5告警级别调整根据系统告警已发生时长、告警发生次数方面发生的变化，重新调整告警级别，保证根据正确的告警系统处理的正确性。【功能要求】4-169.应能提供根据告警的属性字段或属性字段的组合字段(如告警时长、告警发生次数)设置告警自动升降级的功能，并能根据告警级别自动调整规则对符合条件的告警进行级别升降级。应能提供可视化的自动升降级规则编辑功能。4.4.6.1.6控制操作为排除告警故障，借助监控系统的统一控制功能实现对被管对象进行的如执行命令、版权所有，注意保密69
主机重启、应用重启等控制操作。【功能要求】4-170.应能提供根据告警的属性信息(如告警对象、告警级别、告警类别、告警时间)设置自动控制操作规则的功能，并能根据规则实现被关对象的自动控制。应能提供可视化的控制操作规则编辑功能。4.4.6.2告警操作方式告警处理操作在默认情况下可以根据配置的规则自动执行，如果需要，可以人工干预手动执行。【功能要求】4-171.自动执行应支持根据配置的前传、转事件单、确认、清除、级别调整以及控制操作判断规则，自动执行告警操作的功能。4-172.手动执行应支持手动进行告警的前传、转事件单、确认、清除、级别调整以及控制操作功能，其中确认、清除操作应支持单条或者多条操作的功能。4.5控制管理控制管理功能向操作人员提供统一的被管对象控制界面，利用采集与控制接口将对被管对象的指令进行解析适配，发送至被管对象执行。管理员不需要直接登录到被管设备，可以通过控制管理远程登录到被管设备上执行操作命令。所有的操作过程、操作执行结果应当被记录下来提供查询。【功能要求】版权所有，注意保密70
4-173.管理员可以将常用的日常操作命令定义为控制管理中的标准操作，支持标准操作的增、删、修改，操作范围包括但不限于：添加、删除系统用户启动、停止应用进程部署升级软件包更新、备份配置文件关键数据备份4-174.支持操作过程的记录，对于执行的任意控制操作，都具有日志记录的功能，保证运维人员对历史操作记录的查询；4-175.支持操作结果的检查，对于执行的任意控制操作，可在执行异常或者成功后获取执行结果，并提供操作结果检查能力，能够明确查阅操作控制执行状态。4.6综合展现综合展现层是业务监控系统的统一展示和操作界面，各级管理人员和维护人员通过综合展现界面对业务交付流程监控系统进行运行状态监测。4.6.1告警展现告警展现是通过告警列表、告警监视视图的方式，对处理后的告警条目进行展现。在监控中，可以将告警分配给属于不同岗位（角色）的人员，当维护人员查看告警列表时，只是显示分配给他的告警消息。对管理人员显示对业务影响较为严重的告警和告警处理记录。4.6.1.1告警列表告警列表是以电子表格的方式对活动告警信息进行滚动呈现，是最简单也最实用的告警监视方式。在告警事件列表中，告警信息是以不同的颜色来代表不同的告警级别，运维人员可以根据其所关心内容的不同，灵活过滤其需要查看的字段，并可根据字段内容进行相应告警的排序。版权所有，注意保密71
【功能要求】4-176.告警列表的字段需支持用户自定义，系统默认的为告警级别、告警重复次数、发生时间、告警标题、告警内容、告警源。用户可以自定义告警列表显示字段，操作完成后可以立即生效；4-177.通过告警事件列表所提供的功能菜单，运维人员需能对某条具体的告警信息进行告警处理，如手工告警确认、告警清除、告警级别改变等操作，且所有上述工作均需通过日志的形式进行记录，保证运维人员对告警信息安全可靠的操作。4.6.1.2告警查询与统计告警查询与统计是对特定时间和范围的告警发生次数进行查询与汇总，以数据表和图形化方式进行多维度的展示，直观地反映运维人员关注的业务和应用的告警发生情况。【功能要求】4-178.告警查询与统计可以对不同监视对象、告警指标、告警类型、告警级别等条件进行查询和统计。展示结果可以根据运维人员关注的对象不同，进行个性化定制，满足不同运维人员的需要；4-179.支持以数据表和图形化方式如饼图、直方图、对比图等方式进行直观显示。4.6.1.3告警历史指标查询系统能够记录告警发生时被管对象的运行期指标信息，可以通过告警信息关联查询到被管对象发生告警时一定周期内的指标信息，以及与被管对象相关联的其它被管对象的当时的指标信息。同时提供查询、分析功能，尽可能展示故障发生时的情景，方便管理人员查找分析故障的原因。【功能要求】4-180.系统能够记录告警发生时被管对象指标信息、以及被管对象相关联的其它被管对象运行期信息；版权所有，注意保密72
4-181.系统应能够通过告警列表关联查询到告警对象当时的历史指标信息，并支持查询时间范围的修改。4.6.2综合视图综合视图即业务监测视图。提供一个以业务为中心，实时展现业务状态的视图。一方面，根据业务过程模型展现业务流程各关键点的可用性、性能、处理及时率等指标以及告警信息；另一方面，通过业务支撑关系模型及影响度规则配置，展现业务系统内部关系、业务与应用、业务与IT基础设施之间的关联关系，展示业务影响度和影响路径。可以通过不同的颜色来展现业务运行状态。应提供可视化的工具，以便管理业务监测视图。【功能要求】4-182.支持WEB展现方式，界面美观、信息清楚、操作简便，使用人员可以很快上手，查看自己关心的业务信息；4-183.可以在被授权访问的不同业务视图之间进行灵活切换；4-184.能够展现业务的内部关系和业务与IT系统构架之间的关联关系；4-185.通过业务节点可以查看相关的指标和业务数据；4-186.具备自上而下快速定位问题的能力；4-187.具备自下而上分析IT对业务的影响路径和影响程度的能力；4-188.具备展示各类告警情况的能力，如业务告警、应用告警和IT基础架构告警；4.6.3统计报表报表是业务交付流程监控系统重要的信息呈现方式，报表功能应具有报表生成的灵活性和呈现的多样性，以适应用户不断变化的需求。主要包括报表模板定义，报表生成等功能，报表是IT业务监控系统向使用者提供的主要信息。提供报表引擎，用户可以根据系统中的各个数据表，自由定义自己的报表，并存储成报表模板。支持报表自动生成，用户可以定义报表生成的计划，在计划的时间自动按照模板的定义生成报表。版权所有，注意保密73
【功能要求】4-189.用户可自定义模板报表，报表可以按照模板格式生成。报表模板包含数据的内容列表，格式的描述等信息。报表的内容列表可以由用户通过数据库中的数据生成，也可以由报表模板中已有的字段通过函数计算生成。报表模板支持分类管理。4-190.支持手动生成报表和自动根据模板生成报表，系统应支持报表自动生成任务的管理。任务的执行时间可以有周期性和非周期性方式，周期性的执行方式支持周、月、固定天数等，非周期性为一个确定的时间。4-191.可以方便查询、浏览、打印已经生成的历史报表。提供图形化展现界面，用户可以设置默认的显示格式、排序条目等信息，报表形式包括表格、图形，其中图形应当支持饼图、柱图、线条图等多种格式。4-192.报表导出支持HTML、PDF、EXCEL等格式。4-193.对于定义的报表，可以设置权限，只有通过授权的人员才能查看，其它人员无法看到报表内容。4.7系统管理4.7.1用户管理用户管理仅是对用户基本属性信息和权限信息的管理维护，不涉及用户认证信息的增删改等操作管理，用户认证信息由MSS集中进行管理维护。【功能要求】4-194.用户登录平台时，平台系统将用户认证要素转发给MSS集中进行身份认证，认证通过的为合法用户，平台根据事先配置的用户权限对合法用户进行授权管理。4.7.1.1用户管理用户管理功能指对业务交付流程监控系统中的用户信息、用户与角色等关联的管理。用户可以登录系统，由权限控制能够使用的系统功能。用户管理功能只能由授权的用户实版权所有，注意保密74
施，无此权限的用户，可以查询自身的用户属性，修改自身的用户密码、真实姓名和描述信息。【功能要求】4-195.增加用户：应能够增加系统用户。增加用户时应提供以下信息：用户名、用户密码、真实姓名、用户的描述信息(如用户的通信地址、用户单位、联系方法等)、用户角色。4-196.修改用户属性：应能够根据用户名称修改用户属性。可以修改的用户属性包括：用户密码、真实姓名、用户的描述信息(如用户的通信地址、用户单位、联系方法等)、用户角色。4-197.查询用户属性：应能够根据用户名称查询用户属性。应能查询到的用户属性包括：真实姓名、用户的描述信息(如用户的通信地址、用户单位、联系方法等)、用户角色、用户的操作权限。4-198.删除用户：应能够删除系统已存在的用户。4-199.用户密码管理。4.7.1.2角色管理角色是用来封装用户的权限的，一个角色就是一组权限的集合。可以按照在流程中的岗位设定角色，一个用户可以拥有一个或多个角色。角色管理功能只能由授权的用户实施。【功能要求】4-200.增加角色：应能够增加用户组。增加角色应提供以下信息：角色名、操作权限列表。4-201.删除角色：应能够删除系统已存在的用户组。4-202.查询角色属性：应能够根据用户组的名称查询用户组的权限信息。4-203.修改角色属性：应能够根据用户组的名称修改用户组的权限。版权所有，注意保密75
4.7.2权限管理系统能够对用户和角色进行权限分配，用户所具有的权限为用户所拥有的角色的权限或者角色权限的子集。用户、角色、权限的关系如下图：图4.22用户、角色、权限的关系4.7.3日志管理日志管理是对各个关键处理部位采用日志管理的方法，保证业务交付流程监控系统的安全、可靠和稳定运行，及时发现、及时预防故障隐患，避免系统运行事故的发生。【功能要求】4-204.用户操作日志：系统可记录每个操作员进入、退出系统的时间以及在系统中的一些重要操作的操作内容；4-205.故障日志：对人为和软、硬件故障及其解决过程进行详细的记录备案4-206.日志备份：对数据完整性要求较高的数据建立双副本日志，以保证意外发生时的数据恢复；版权所有，注意保密76
4-207.日志统计：系统支持对日志数据进行统计分析，帮助检查系统使用情况，对于系统的非正常使用和非正常状态及时发现、及时预防，避免系统运行事故4-208.日志查询：系统支持对用户操作日志的浏览、查询、删除和统计功能。当用户进入日志管理功能后，可以看到日志记录的列表显示；用户可以输入一定条件（比如时间段）查询统计相关的日志记录；用户还可以删除不需要的一条或者多条日志记录。4.7.3.1系统登录日志管理【功能要求】4-209.系统登录日志记录系统应能将用户的登录信息(包括成功与不成功的登录)记录下来，以供查询。用户登录信息包括用户名称、登录终端名称与IP地址、登录时间和退出时间等。4-210.系统登录日志查询系统应能够查询系统登录日志。查询条件包括用户名称、IP地址、登录日期时间、登录结果（成功或失败）等。查询内容包括用户名称、登录终端名称与IP地址、登录时间和退出时间。4-211.系统登录日志删除系统应能够删除过时的系统登录日志。系统应提供以下两种删除方式，一是按时间进行删除；二是按保留的记录条数进行删除。4-212.系统登录日志备份系统应具有手动保存系统登录日志到Excel文件的功能。系统应具有打印系统登录日志功能。4.7.3.2系统操作日志管理【功能要求】版权所有，注意保密77
4-213.系统操作日志记录系统应能将用户的操作信息记录下来，以供查询。操作信息包括实施操作的用户、操作时间、IP地址、操作名称、操作对象、操作结果。4-214.系统操作日志查询系统应能够查询系统操作日志。查询条件包括用户名称、IP地址、操作日期时间、操作结果（成功或失败）等。查询内容包括实施操作的用户、操作时间、IP地址、操作名称、操作对象、操作结果。系统应具备模糊查询方式。4-215.系统操作日志删除系统应能够删除过时的系统操作日志。系统应提供以下两种删除方式，一是按时间进行删除；二是按保留的记录条数进行删除。4-216.系统操作日志备份手动保存系统操作日志到Excel文件的功能。系统应具有打印系统操作日志功能。4.7.4自身管理对系统自身的各应用程序或服务进程进行监视和管理的功能，使管理员能够控制各类应用程序和服务进程的合法性和有效性。进程监控系统：当发现某个应用程序或服务进程出现问题或运行异常时，系统能自动重起或中止有问题的服务进程，或重新加载配置信息和功能模块告警：同时以系统自身告警的方式呈现到告警监视列表中，以确保系统始终处在正常运行状态【功能要求】4-217.能够查看被管进程的运行状态；4-218.对系统内各软件模块的进程进行统一管理，可对被管进程进行统一启动与关闭；4-219.自动维护被管进程的运行，当被管进程失效时，进程控制模块会自动的尝试重新启动该进程，并向系统报告进程的失效与启动信息；版权所有，注意保密78
4-220.提供与被采集系统网络链路的监视功能，当相关计算机网络链路出现问题时可以产生系统告警信息等；当采集链路恢复后，数据采集应能迅速自动恢复；（可以通过基础设施监控系统实现）4-221.应提供系统服务器运行状况监视功能（如主机CPU利用率、内存和磁盘运行状况等）。（可以通过基础设施监控系统实现）4-222.当用户非法登陆，日志异常等类似情况发生时，可以产生系统告警信息。版权所有，注意保密79
5集成架构5.1集成综述5.1.1集成接口视图短信、邮集团SFMMSS件平台指标订单统一消息上传查询认证通知被管对象系统订单CSB订单流程查询接口数据应用软件采集、省SFM控制业务事件控制配置告警、性能数据管理请求同步IT服务IT基础设施监控采集、基础设施管理系统系统控制图5.1系统集成架构业务交付流程监控系统的集成关系主要包括反映两级部署关系中的集团业务交付流程监控系统、为系统提供支撑的MSS（统一认证）和短信邮件平台、与业务交付流程监控系统同属ITSM范畴的IT服务管理系统和IT基础设施监控系统，以及各被管对象生产系统系统如CRM、计费、服务开通、ODS等。版权所有，注意保密80
根据CRM2.0集成接口规范的要求，与集团业务交付流程监控系统、MSS、短信邮件平台以及被管对象订单查询接口统一从CSB间接调用，或者封装为服务形式部署到CSB上提供第三方调用。与其它系统的接口，各省实现时视情况进行选择，可采用直连的方式。5.1.2集成接口方式从接口实现上看，一些接口是由第三方系统提供标准接口，业务交付流程监控系统根据接口调用方法和接口数据要求发起调用即可，如MSS认证接口、门户系统界面集成接口、短信邮件平台通知接口、被管对象提供的被动采集接口如Syslog、Socket侦听等。另外一些接口是新增接口，接口双方需要根据接口要求共同制定接口标准与要求，接口双方共同开发并实现接口。从接口类型上看，一些接口对及时性要求比较高、数据量中等或者较小，如数据实时采集接口、事件接口、控制请求接口等，适合采用WebService、Socket等实时性的接口方式；另有一些接口对及时性要求不高，数据传输量较大，如省级监控指标上传、大数据量采集、配置项同步等，适合采用FTP文件接口、临时数据库表等接口方式。同步和异步从接口数据格式上看，建议采用主流的XML格式统一进行接口数据的表示，这也利于基于XML技术的WebService协议实现。对于一些数据格式比较复杂，对数据解析效率要求较高的接口场合，也可以使用JSON等轻量级的数据格式。在本文档中以表格的形式表示XML等格式数据项。5.1.2.1消息类接口5.1.2.1.1数据协议业务交付流程监控系统采用主流的WebService接口协议或者自定义通讯包方式的Socket接口协议，各省在进行接口建设时可根据接口双方系统实际情况进行选择，优先选择WebService接口方式。下面就这两种协议分别进行说明。【WebService协议】WebService采用可扩展的标记语言(XML)来表示数据的基本格式，利用基于HTTP传输的SOAP访问协议实现接口方法的调用，并通过WebService描述语言(WSDL)将提版权所有，注意保密81
供的接口公布出去，让第三方系统了解接口提供哪些Webservice及其对应的函数、参数和返回值。WebService每个接口方法的请求和应答参数包括两个部分：MessageHeader(消息头)与MessageBody(消息体)。其中，MessageHeader用于存储交易请求以及应答的公共部分和消息的控制数据，MessageBody包含交易请求和应答的业务数据，以XML格式表示，例如：消息头元素一 消息头元素二 消息头元素三 消息体元素一 消息体元素二 消息体元素三 /itsm/upload/<省份代码>/<文件类型前缀>/<年份>/<月>。版权所有，注意保密85
上传目录示例：1)北京上发的告警文件，文件所在日为2009年6月8日，则上传的目录为：“/itsm/upload/bj/fault/2009/06/”2)福建上发的性能文件，文件所在日为2009年9月16日，则上传的目录为：“/itsm/upload/fj/perfm/2009/09”上传文件名示例：1)北京上发的告警文件，文件所在日为2009年6月8日，生成时间为上午10点，状态为正常上传的文件，则文件名称为FAULT_BJ_20090608_040_000.xml2)北京上发的性能文件，文件所在日为2009年6月8日，状态为正常上传的文件，则文件名称为PERFM_BJ_20090608_000_000.xml3)北京上发的性能文件，文件所在日为2009年6月8日，状态为重传的文件，则文件名称为PERFM_BJ_20090608_000_001.xml5.1.2.2.2.3发送文件内容文件接口数据格式均采用XML格式或者其它轻量级数据表达方式如JSON，所有文件都统一采用同样的文件头，而数据内容则放在文件头的最后一个元素Body中；以下是文件头各元素的具体定义：父元素名称元素名称类型描述file主标签文件类型；filetypeString其取值范围与发送文件定义中的TYPE一致。发送省代码；filesendprovinceString其取值范围参看附件中的省份码接收省代码；filerecprovinceString其取值范围参看附件中的省份码filecreatetimeTime文件创建时间版权所有，注意保密86
filesumInteger记录数filebegintimeTime统计起始时间fileendtimeTime统计截止时间filebody数据记录内容body„„详见集成接口一节中各文件接口内容定义5.1.2.2.3返回文件定义5.1.2.2.3.1返回文件命名文件名说明注释前缀（F_）+原文件名文件级检查结果文件名只有在出现文件级错误的上发文件才有前缀（E_）+原文件名记录级检查结果文件名每个无文件级错误的上发文件都有对应的记录级检查结果文件反馈5.1.2.2.3.2文件级检查结果定义【文件级检查错误类型定义】错误编码错误编码注释备注F001文件名重复F002文件名称错误F003文件格式错误F999其它【文件级检查格式定义】父元素名称元素名称约束类型描述VerifyError1StringErrorErrorCode1StringErrorErrorMessage1String版权所有，注意保密87
结果示例：F001 错误示例 R002 1 错误记录信息示例 1 --如果没有记录错误，此处为0
微信/支付宝扫码支付下载