roy中国建设银行IT运维体系建设总体规划方案v4-1-IT运维方案

中国建设银行ITIT运维体系建设总体规划方案北京神州泰岳软件股份有限公司1IT运维规划总体设计思路 3 31.1.1在一体化全方位管理基础上充分考虑7层12P的新一代目标架构 31.1.2从“以IT为中心”上升到“以业务为中心” 51.1.3为大规模虚拟化集群及SOA组件服务提供必要管理手段 62IT运维管理体系总体设计 73建设功能描述 3.1监控管理体系 3.1.2应用监控 3.1.3跨系统交易监控 3.2综合分析体系 403.2.1总体分析平台设计 403.2.2统计分析分类 3.3自动化管理体系 543.4配置管理数据库(CMDB) 573.5服务管理体系 583.5.1ITIL核心流程 错误!未定义书签。3.5.2知识库管理 错误!未定义书签。3.5.3值班管理 错误!未定义书签。3.6统一展示体系 3.6.2大屏呈现 651IT运维规划1IT运维规划总体设计思路随着我行的IT系统不断建设与完善，在新一代业务系统统一规划与建设过程中，对系统的运行维护也需进行整体规划。我们将建立一套以客户为中心，以业务为导向的综合运维管理体系，对各类物理资源和虚拟资源实现全方位、一体化的集中管理模式，遵循IT运维相关规范，建立起包含集中监控管理、自动化运维管理、统一配置管理CMDB、统一流程平台、综合分析分析、综合展示为核心的一体化运维管理平台，从物理资源管理深入到虚拟资源管理，为大规模虚拟化集群以及SOA组件服务提供必要管理手段，同时不断提升用户感知和用户体验，以业务的视角关注系统健康状况，从IT管理上升到业务服务管理，逐步奠定我行新一代综合运维平台“国内领先、国际一流”的地位。批注[雨林木风1]:请补充相关文字一代目标架构一体化的全方位管理，将实现对新一代业务系统支撑的资源包括物理资源和虚拟资源进行一体化监控，同时结合7层（渠道整合层、客户服务整合层、应用集成层、外联集成层、产品服务层、数据集成层、管理分析层）12个域（渠道整合技术服务平台、客户服务应用整合服务平台、应用集成服务平台、外联集成控制服务平台、在线交易处理服务、支付服务平台、数据集成服务平台、管理分析服务平台、在线交易处理服务平台、事件控制服务平台）的新一代业务平台核心设计理念，建立一套完整的“集中管理、集中监控、集中运维、集中配置”的综合运维管理体系。综合展示平台综合展示平台大屏展示研发测试及系统部署综合评估自动化管理平台CMDB研发测试及系统部署综合评估自动化管理平台CMDB运维优化综合分析平台服务流程平台监控管理平台监控管理平台云基础架构统一管理云基础架构统一管理生产环境生产环境测试环境测试环境研发环境研发环境建立IT监控管理体系，通过前期的建设，目前CMP系统已经实现了对开放平台物理资源的监管，已经收到了良好的成效，从CMP系统对被管对象的故障发现率、故障发现及时性、准确性、有效性，告警信息通知到人的及时、准确性，监控覆盖面以及CMP系统的自身运行情况几个角度的实际使用效果来考量，CMP系统已经初步建设成为了稳定、准确、高效、全面的监控系统，为日常的运维工作提供了有力的保障，下一步将在该平台基础上进一步完善物理资源监控，继续深入监控的粒度、广度；同时通过TPMS系统逐步深入到关键业务交易内部，实现业务交易全路径展示和端到端的分析；从物理资源管理迈入到虚拟资源管理，逐步对各类虚拟资源的全面监控，最终实现监控全方位、立体化、智能化的全方位管理，构建一套先进的监控管理体系和平台。建立IT服务管理体系，实现“五个转变”：建立集中统一的IT服务组织管理模式，实现IT服务由分散管理向集中管理转变；建立体系化的管理制度和绩效考核指标，实现IT服务由粗放管理向精细管理转变；建立规范标准的IT服务管理流程，实现IT服务由职能管理向流程管理转变；建立统一的用户服务窗口，实现IT服务由无序管理向有序管理转变；建立先进、实用、高效的IT服务管理平台，实现IT服务管理水平和能力的提升。建立自动化管理体系，实现日常管理的自动化操作，如日常巡检、故障智能化处理、虚拟资源分配与变更处理、配置变更审计、软件自动装载等，将日常运维只是进行固化，以减轻复杂的日常运维带来的庞大工作量。建立统一配置管理数据库，随着IT基础架构越来越复杂，越来越庞大，IT资产已经成为运营过程中很重要的管理对象。为了统一管理、共享资源，我行需要建立集中、统一的配置管理数据库，实现各类配置资源集中化、规范化的管理。建立综合分析体系，经过前期的系统建设，各类系统已经采集并存储了海量数据，数据范围涉及到了告警、性能、配置项、业务、运营、运维等多领域，如何将这些数据进行有效的利用、分析为系统规范、系统分析、决策判断提供准确的依据成为系统发展的瓶颈。为更好的利用既有数据，服务于业务运营，提升业务运营质量，通过建设综合分析平台进行综合化的分析，分析中心主要面向管理人员、业务人员，维护人员，通过对既有数据进行多视角、多维度的分析，直观展示业务、应用及系统的运行状况、发展趋势，最终为系统扩容优化、业务质量提升提供运维数据支持。建立综合展示体系，通过建立IT运维部门统一的门户和大屏，为业务支撑部门内包括部门领导、业务管理人员、运维人员、值班监控人员在内的各层用户提供统一的展示平台，实现统一用户、统一认证，不断增强运维平台提升展示效果，积极提升用户体验。我们将以业务为中心进行IT运维管理，和传统的以IT为中心管理所关注的层面和建设的思路存在着本质的区别。以业务为中心需要站在业务层面进行系统的维护管理和深入剖析，传统的以IT为中心的管理则只关注设备运行情况、设备故障情况以及设备故障处理。可以说，以业务为中心不仅需要建设以IT为中心的日常运维管理，还要对业务过程、业务数据甚至交易过程等进行全方位的管理，并深入分析业务数据，从业务本身情况，对IT进行高层次的管理和应用。新一代运维管理平台我们将摒弃以往割裂的看到服务器、应用以及业务的监控和处理方式，以业务为主线，从底层资源到上层业务进行整体的监控和关联分析，以崭新的业务视角来进行管理，把业务服务的可用性和性能状态，与底层IT平台部件和业务部件关联起来，以便提供一个以业务为中心的IT服务平台，来支撑业务的运营。同时基于ARM规范逐步批注[雨林木风2]:批注[雨林木风2]:请调整实现对业务交易的监控，对交易线进行监控的意义在于交易线是面向业务逻辑的，而不是面向业务系统的。这就使得监控管理能够细化到各业务环节一级，监控每个业务环节在整个业务处理过程中的性能状况，使业务处理全过程对运维人员可见、可控，彻底改变目前业务管理长期处于被动局面的最直接和有效的技术手段。通过业务和交易监控，最终实现如下目标：通过对业务性能数据进行综合分析和业务系统优化分析，找出系统瓶颈，为系统升级及优化提供量化参考依据。对业务交易各处理环节进行监控，直观的展现业务交易流转路径，反映每个关键处理环节的性能状况，是运维人员具备对用户投诉做出快速响应的能力。对业务交易进行真正意义的实时监视，使运维部门具有主动性的监控能力，快速发现当前故障，同时做到尽早发现可能的故障隐患。理手段理手段随着云计算技术的逐渐成熟，其应用逐步进行扩展，在我行新一代业务系统的建设中，云计算将是一个重点建设平台，而如何以云平台作为基础，进行日常的运行维护管理，也将是新一代规划的一个重点。因此在运维平台建设中，需实现面向基础的云设施的一体化管理，并结合云服务的提供，建立自动化管理机制，为我行云计算管理奠定好根基，为后续云计算的拓展建设和运行维护打下基础，针对我行的实际情况，云管理主要包括以下主要内容：云资源监控：可以统一管理多种虚拟平台，包括VMwarevSphere(包括ESX版本)、CitrixXenServer，能够提供物理主机设备、以及部署在其上的虚拟机状态监控，并能够实现虚拟机部署的自动发现和自动监控；云资源分析：生产云的监控（包括基础物理平台监控、生产虚机监控及应用监控）纳入统一运维管理系统，能够提供云计算平台整体及各个子云的资源使用状况、资源使用趋势等指标进行监控并能给出直观的报告；云资源分配：对虚拟化平台的管理功能包括：新建、扩容、克隆、迁移、回收等。通过自动化的虚拟资源管理可以大大提高虚拟资源的分配效率，降低人为操作失误概率，从而实现减少人力成本。监控管理平台批注[雨林木风3]:请根据上图，补充相关文字，同时补充图中综合分析部分2评估治理研发测试及系统部署运维优化服务流程平台自动化管理平台CMDB12个P平台115个组件监控管理平台批注[雨林木风3]:请根据上图，补充相关文字，同时补充图中综合分析部分2评估治理研发测试及系统部署运维优化服务流程平台自动化管理平台CMDB12个P平台115个组件ITIT运维管理体系总体设计综合展现平台综合展现平台综合分析平台综合分析平台服务门户自助订购合规策略服务优化服务发布快速部署服务验证云基础架构统一管理服务门户自助订购合规策略服务优化服务发布快速部署服务验证服务服务目录附图1.总体架构设计经过多年建设，我行围绕着IT运维标准规范和最佳实践，初步建立起一套较为成熟的运维管理体系，涵盖了以监控、服务流程、CMDB、自动化运维为核心的IT总体运维框架。我行目前采用了神州泰岳Ultra-NMS和BMCAgent产品组合方式，实现对开放平台各类服务器、数据库、中间件的监控；采用了IBMNetCool产品实现了对整体网络环境的监控；采用了基于ARM的交易监控方式实现了对业务交易线的监控；采用了CAServiceDeskManager产品实现日常运维工作的流程化、规范化、电子化；采用了BMCAtriumCMDB产品实现了统一配置数据库管理；采用了HpOpsware基本实现了运维管理自动化。下一步我们将完善运维管理体系，将整体运维管理体系覆盖到综合分析、综合展示以及虚拟化资源监控等领域，不断提升我行整体运维管理水平，积极提升运维部门对外形象，保障核心生产系统的安全生产和业务的稳定发展。新一代运维管理规划将重点关注以下几个主要方面的内1.将管理范围从传统的基于物理平台拓展到基于物理+虚拟化平台，包括：物理平台：网络设备，服务器，存储，数据库，中间件，安全设备，动力环境等。虚拟平台：小机虚拟化（LPAR,VPAR,ZONEx86虚拟化（Vmware,Citrix,Hyper-V,RedHat）,桌面虚拟化（ICA-VDI）。虚拟化资源管理不等于虚拟机管理。虚拟化资源除虚拟机（VM）外，还包括虚拟化平台本身（如ESX,VC虚拟化资源池（ResourcePool虚拟化存储（DataStor）,虚拟化集群（Cluster）及动态负载分配（DRS）等内容，单一的虚拟机层面的监管不完整。虚拟化平台自身的稳定性会影响其上层承载应用的性能及稳定性，通常很难定位问题的根源，需要考虑一体化的综合分析手段。对虚拟化的池化资源及相关设施应该制定统一的管理标准及管理措施。2.将传统的针对应用自身的监管拓展到“应用管理+平台管理+SOA组件管理”三个维度。单纯从应用自身监管的维度来尝试将管理层次提升到“面向业务”的水平，在建行新一代系统中不可行。考虑到新一代的设计理念大量采用SOA架构，并将原有的300多个应用利用统一的ESB总线接口及12个P平台来完成整合，因此在管理平台的设计中，追加了SOA及P平台的管理维度。这三个维度的管理指标，作为基础数据，向上辅助交易层面的管理功能，真正实现“以IT为中心”上升到“以业务为中心”。缺乏这种支撑手段，单纯展现某种交易的性能及故障，对业务的辅助将极其有限。3.将传统的利用管理人员经验进行交易故障及性能的手动分析拓展到的基于业务层面各交易的端对端管理，辅助进行自动化分析，并建立专家系统。将各种业务交易过程进行细粒度的精细化分析，比如交易流转路径、交易时长等对业务交易实现真正意义的实时监控，运维部门主动发现业务当前的问题，而不是等待业务人员电话报送问题后进行响应。利用专家系统进行业务综合分析，快速定位业务环节中的故障范围，并利用“应用+P平台+SOA”的三维监控手段作为辅助，尽快制定业务问题的解决方案。利用专家系统进行业务收益业务风险资源占用（包括云资源）关联分析，帮助管理人员对整个新一代数据中心的业务运行状态是否合理做出判断，保障优质资源配备给重要的业务应用。4.将传统的综合分析由单一的历史数据统计报表，拓展到包括的虚拟架构优化、预测未来容量需求、历史工作负载和资源使用关联分析、服务等级管理、行为模式及使用趋势、组件容量管理（过度、不足）等内容的专业化的综合分析系统，辅助制定整个新一代系统的运行维护策略。传统管理平台中的综合分析只是对物理资源进行故障分布分析、性能趋势分析、资产统计分析，并依赖报表进行呈现，这种分析手段依然必要，但不能够完全满足建行新一代IT运维的要求。新一代系统建设的总体思路是利用SOA进行应用整合，并依托于虚拟化资源池进行承载，因此，必须综合考虑虚拟架构优化，业务质量分析（关键业务指标应用架构优化，SOA组件合并及请求流程，物理实体容量规划，资源池建设标准等相关同时，参考国际上一流的综合分析方案，引入历史工作负载和资源使用关联分析、服务等级管理、行为模式及使用趋势、组件容量管理（过度、不足）等相关内容。呈现手段也从单一报表方式而力求多样化，满足用户直观准确快速获取管理信息的要求。5.将传统的开放平台应用监控拓展到对开放平台+大机的整体数据采集及分析，去掉传统的大机管理“黑洞”，真实准确地展现交易的每个环节。6.配合后续的定制开发，提供多种贴近用户需求的展示方式，包括：大屏展示，统一门户（虚拟化+物理资源+云计算建设专家系统，业务接入，流程管理等内容。监控管理体系的建设，要求以我行新一代业务系统的规划作为基础，站在业务应用的高度进行整体系统的一体化监控管理。与传统的监控管理不同，一体化的监控管理将以业务应用为中心，从支撑业务系统运行的资源、应用，到业务交易，进行全方位的监控管理，以最终达到监控管理向新一代业务系统应用转型和高度建设的目标。因此在新一代规划方案中，将分别从资源监控、应用监控、交易监控三个层面来进行建设的功能要点阐述，以达到新一代业务系统整体运行的可视、可控的管理。附图2.监控管理架构资源维度：主要关注支撑业务系统运行的平台类监控，管理对象包括物理资源和虚拟资源等。通过标准或非标准协议获取这些被管对象的配置、性能、告警信息，而不涉及业务系统自身可用性及性能的监控。应用维度：从应用系统可用性角度出发，开始关注业务系统自身的一些关键监控点，包括核心业务系统（如网银、证劵）自身的一些关键监控点（如进程、日志、端口等）和部分业务指标。可以通过分析业务系统的日志或是执行业务系统提供的管理指令获取包括交易量、成功或失败笔数、无响应或超时笔数等相关指标。交易维度：以业务逻辑（交易线）为线索，在关键交易模块中嵌入监控探针，采集交易路径各个环节的交易状态。从而对用户真实的交易状况进行统计，生成单位时间内的交易量、交易模块单位时间内的执行失败率、交易模块的平均响应时间、交易的同异步信息、串联生成交易拓扑等等，从业务逻辑层展现交易运行情况，提供直观、快速、准确的定位手段。物理实体监控我行于2006年开始建设CMP项目，通过5年的逐步实施和不断努力，目前已形成面向我行开放系统的资源和应用的全方位监控管理体系，范围涉及我行开放系统的1600多台服务器（包括AIX、HP_UX、Windows、ScoUnix等操作系统）、300多套数据库（包括Oracle、DB2、Informix）、140多套中间件（包括WebLogic、Websphere、Tuxedo、WebsphereMQ、CICS、LotusDomino群件）、EMC和日立的存储备份设备及其承载的多种证券、信贷、人力资源、龙卡、网银、清算、OA业务应用系统。使用CMP的人员为我行负责开放系统维护的管理人员、工程人员和维护人员、厂商技术支持人员，共有用户1000余人，已经形成了规范化的运维管理体系。通过数据中心对CMP系统的实际使用，从CMP系统对被管对象的故障发现率、故障发现及时性、准确性、有效性，告警信息通知到人的及时、准确性，监控覆盖面以及CMP系统的自身运行情况几个角度的实际使用效果来考量，CMP系统已经初步建设成为了稳定、准确、高效、全面的监控系统。CMP系统为数据中心IT系统稳定运行提供了强有力的支撑与保障，每天晨会讨论的80%事件出自CMP监控系统，其中5%若不加处理会酿成生产事故。CMP系统已经成为我行安全生产的不可或缺的重要系统。在我行CMP项目的建设中，采用BMCPatrol进行数据信息的采集，采用Ultra-NMS作为集中监控管理平台进行数据的处理和展现，其监控管理效果已得到了充分的验证。虚拟实体监控随着虚拟化技术的逐渐成熟，其应用逐步进行扩展，在我行新一代业务系统的建设中，虚拟化将是一个重点建设平台，而如何实现虚拟化资源的管控，也将是新一代规划的一个重点。虚拟实体的监控具体来说应包含三个组成部分：对虚拟化平台自身的监控（如Vmware,Xen,IBMLPAR,Hyper-V,VBLOCK等）。对虚拟化平台上衍生出的虚拟化实体的监控（如：虚拟机，虚拟网卡，虚拟内存，虚拟CPU，虚拟存储，资源池，集群等动态资源）。对虚拟桌面架构（VDI云桌面）的监控。批注[雨林木风4]:批注[雨林木风4]:指标要列出来管理的需要。当前，先进的虚拟化健康度管理方法强调对整个虚拟化环境进行统一的管控。从用户体验的角度，自上而下的全面评估虚拟化环境的健康度，从而提高虚拟化环境的可用性和性能，扩大虚拟化环境的适用范围。通过提供一套统一的可管理多种虚拟化系统的管理平台，针对虚拟化建设及运维过程中所面临的困难，利用虚拟化健康度管理方法来逐步改进和完善虚拟化建设的不足：一方面，这种全新的虚拟化健康度管理方法覆盖了虚拟化环境所涉及到的软硬件的各个层面，统一运维，综合分析，从而全面保障了虚拟化环境的健康度。另一方面，企业通过引入先进的健康度管理方法，还可以使得业务人员和IT运维人员可以更好地明确自己的管理职责，更好地合作，提高了工作效率，同是也优化的虚拟化环境的可用性。运维人员可以从最终用户、交易、应用、主机、数据库、中间件和网络等各个方面，全面监控和分析虚拟化环境的性能和瓶颈。通过事件关联和SLA分析，快速发现虚拟化应用服务事件，定位事件根源，快速解决问题。针对此次需要监控的虚拟平台，主要实现以下指标的监控和管理：批注[雨林木风5]:说法有问题，统一监控实现跨小机（LPAR,VPAR）及x86（VMware等）批注[雨林木风5]:说法有问题，统一监控附图3.小机及X86虚拟化统一管理实现对VMWareESXSERVER等虚拟化平台自身健壮性的监管，防止虚拟化平台因自身故障导致上层的虚拟机出现问题。附图4.虚拟化平台自身监控实现对VMware管理控制台VirtualCenter的监管，包括VirtualCenter服务器状态（启动和停止）、VirtualCenter应用（进程、服务、日志等）信息的监控和管理。实现对虚拟交换机（vSwitch虚拟存储卷(DataStor)，虚拟化资源池及集群等动态资源的监管，使得部署在虚拟化平台上的各种应用不会因为动态计算资源的变换而导致性能不稳定。附图5.虚拟化各组件监控监控ICA协议，XENSERVER及ESX，实现对虚拟桌面架构（VDI）的统一管理。附图6.云桌面监控实现对虚拟机（VM）的监控，包括CPU、内存、硬盘、网络等资源信息的监控和管理。附图7.虚拟机自身监控参数实现对物理服务器虚拟化平台上层应用的关联分析，以确定最终影响性能或者发生故障的范围。围绕12个核心域组织应用监控管理应用监控一个主要目标就是是通过自动化、智能化的IT手段对业务系统进行实时监控以及历史数据分析，从而达到保障业务可用的目标。因此，在进行应用监控管理之前首先需要考虑管理对象是谁？管理哪些内容？如何发现管理的内容对管理对象产生的影响？要回答以上问题就需要拆解可能影响业务可用性的关键要素，判断这些因素在何种情况下可能对业务发生影响，并实施跟踪这些关键因素，保障业务免受这些因素的影响。根据建行新一代业务系统规划思路，将相关核心业务抽象为12个P平台，包括渠道整合技术服务平台（内部、外部各1个）、客户服务应用整合服务平台（内部、外部各1个）、应用集成服务平台、外联集成控制服务平台、在线交易处理服务、支付服务平台、数据集成服务平台、管理分析服务平台、在线交易处理服务平台、事件控制服务平台等平台。集中监控系统将统一规划、分步实施，围绕着12个P平台，逐步实现对于核心应用的监控和管理。我们将在项目实施过程中根据各个应用系统的不同特点以及业务使用人员的监控需求，通过业务建模、业务采集、业务处理、业务展现等技术手段，帮助运维人员快速梳理业务关联关系、定位业务故障根源、及时分析业务运行趋势，保证业务系统的正常运行。针对32个重要系统的应用监控通过前期的业务平台梳理，后续我们将对32个重要系统的120个核心指标进行集中监控管理，通过定义关键业务点（KBP）以及关键业务点的实例化原则，能够将各类被管业务对象纳入监控管理平台的管理范围，通过定义关键性能指标（KPI能够将任何的数据指标纳入监控管理平台的监控体系，下面着重说明监控管理平台如何实现业务性能、业务告警、业务关联影响分析等重要业务管理场景。.1业务性能管理应用系统监控通过性能数据接口，集成各类业务系统的实时业务性能数据，对业务性能的管理能够展现实时展示和历史性能数据分析统计，对于实时的性能数据可以采用曲线图的方式进行响应时间趋势分析。附图8.业务量实时分析附图9.交易时长趋势分析.2业务告警管理无论对平台类告警，还是业务类告警，在监控管理平台中处理方式、处理流程，如告警过滤、告警相关性分析、告警确认、告警清除等、告警通知、工单接口等都是一致的，对于业务类告警，唯一的区别体现在事件标准化规则方面，我们将采用统一的告警处理流程，将业务应用类告警在业务监控列表中实时分析和展示。附图10.业务告警.3业务影响性分析业务人员日常工作中面对着复杂、繁多的业务对象及其业务指标，指标数据归属于不同被管理的业务对象，同时业务对象之间又遵从于业务逻辑，如何能够把业务实体与业务指标有机的组织与呈现，便于业务管理人员快速、准确的查看系统状况将在很大程度的决定监控管理系统的价值。基于业务建模中对象与对象之间的关系，结合业务逻辑，实现业务影响分析功能，使得在业务人员能够发现某一故障对其它系统的影响程度。业务影响以业务影响拓扑的形式呈现。业务影响拓扑是展现故障和告警影响或者缘由的视图。业务对象之间、业务对象和平台对象之间存在着各种影响关系，即某个对象上发生的告警影响哪些业务系统、以及对业务系统产生的影响程度有多大，监控系统能够以业务影响分析的视角分析高层业务到底层技术之间的影响范围和程度的拓扑视图，它既可以正向展现影响路径，也可以反向展现缘由和根源。附图11.业务影响视图.4大机业务指标监控应用监控的管理范围不仅仅包含了开放平台，可以进一步扩大应用监控管理范围，将大机平台的关键业务指标纳入进来，可以和大机平台厂商梳理相关业务指标，通过定制规范的集成接口，将大机的监控指标集成到应用监控平台中进行统一处理和展现。大机应用性能管理：提供丰富的信息，提高对性能问题的响应能力，此前这些问题通常都需要人工干预。通过简洁、界面自定义的界面访问信息，它能够实现资源利用率监测、性能调整、问题分析和解决。监控实时和历史的主机系统信息。可定制的阀值报警，实现更加独立的系统关键数据监测。在指定时间段内采集数据，提高系统效率。大机应用的性能管理附图12.大机网络监控（TCP/大机应用的性能管理附图12.大机网络监控（TCP/IP及SNA提供了大型机内部全面的网络性能信息监控与分析功能，针对不同的网络协议TCP/IP或SNA提供了丰富的功能，以及SOA应用程序提供了全面的支持。包括：提供连接时长信息和ConnectionTrace。分析连接性能指标。DDF中的流量信息及应用程序信息。大机应用的网络管理附图13.批注[雨林木风6]:加一个图大机应用性能调优（MAT端到端性能管理是解决方案中非常重要的组件之一，大机应用监控平台实时监控发现业务应用的性能问题后，调用MAT对目标业务应用进行性能采样与分析，收集好这支应用程序在大型机中不同子系统(如：CICS,DB2，z/OS等)务应用的性能问题后，调用MAT对目标业务应用进行性能采样与分析，收集好这支应用程序在大型机中不同子系统(如：CICS,DB2，z/OS等)的性能开销信息，及时或事后对这些样本进行分析，可以：发现应用程序的CPU，I/O开销的性能信息。定位引起应用系统低效的编码在哪一行，数据库调用语句或系统服务。生成性能报告——一种详尽列出在应用系统执行期间，时间消耗等，为改善系统和系统资源调优提出报告依据。通过开放大机系统的相关接口，将大机的关键指标集成应用系统监控平台中统一分析，最终帮助用户实现分布式端到大型机端应用性能信息一览无余，并利用统一的“仪表盘”展示真实的业务现状，极大地提升解决问题的效率，并通过主动的预警机制及未来使用趋势分析进一步保障业务连续性和稳定性。批注[雨林木风7]:和P平台挂上钩基于ARM的交易监控传统的业务管理模式难以从根本上改变金融企业运维工作被动的局面，难以业务运维质量得到大幅度的提升。这对提升用户满意度和企业形象都十分不利，因此我行迫切需要建设一套全方位满足业务管理需求的业务交易监控管理平台，提升运维的质量，为广大客户提供更优质的服务。基于ARM标准的交易监控管理平台TPMS系统在继承和延续交易性能监控基础上，开展跨系统交易层面的监控管理，通过TPMS系统的建设不断完善我行IT生产环境的应用系统交易监控和管理体系，从根本上提高我行IT的监控和管理水平，为我行的业务发展提供有利保障。通过TPMS系统的建设，我们希望达到如下目标：令对跨系统的业务交易各处理环节进行监控，直观的展现业务交易流转路径，反映每个关键处理环节的性能状况，是运维人员具备对用户投诉做出快速响应的能力；令对业务交易进行真正意义的实时监控，使运维部门具有主动性的监控能力，快速发现当前故障，同时做到尽早发现可能的故障隐患；令实现统一的业务故障管理，并通过对告警信息的相关性分析，减少不必要的冗余告警，准确定位业务交易故障根源，具备故障精确定位的能力，有效提升故障排查效令通过对业务性能数据进行综合分析和业务系统优化分析，找出系统瓶颈，为系统升级及优化提供量化参考依据。.1关键技术分析对业务监控的方式有很多种，但业务逻辑监控有其特殊性，监控粒度需要深入到业务系统内部，实时反映业务系统内部各环节性能状况，目前，能够充分满足业务逻辑监控需求，业界广泛认可的技术标准为ARM，ARM标准是目前国际公认的也是业界遵循的唯一标准。所谓ApplicationResponseMeasurement(ARM)是一个应用程序接口(API)，它可以监控不同应用和系统下的业务事务的可用性和性能。ARM标准定义了事务何时开始和结束，因此这些事务就可以进行测量和监控。基本上，应用程序调用ARMAPI。这种方法使得开发人员可以把企业管理工具直接扩展到应用程序本身，这就可以创建全面的管理能力，包括可用性、性能和应用程序使用的监控，也包括对端对端事务相应时间的监控。ARM的优势主要体现在以下几个方面：口成熟的技术规范ARM标准由OpenGroup开发，从1996年开始开发ARM的首个版本ARMVersion1，通过ARM工作组及其合作伙伴历经10多年的完善和发展，截止2008年ARM标准的最后版本是ARM4.0version2。跨平台跨语言支持令ARM支持多种平台，这样有利于监控基于多个不同平台的应用程序；令ARM支持多种编程语言。目前最新的ARM4支持用JAVA和C/C++编写的应用程极低的性能消耗对性能进行详细的监控同时没有带来太多性能上的损失。当我们要对一个应用性能进行监控的时候，监控的细致程度往往和给应用程序带来的性能负载是成正比的。相较于其他监控方式，ARM是一个最佳选择，它可以让我们根据需要进行详细的监控，同时不会带来太多性能上的影响。带来业务监控领域的革命随着金融行业的电子化程度不断提高，除了功能方面的需求，人们也对系统的性能、可靠性等方面的要求也越来越高，会越发关心类似以下问题：令这些transaction成功了吗？令是什么原因导致某个transaction失败了？令客户体验到的系统响应时间是多少？令在整个交易过程中哪个部分耗时最长？令系统瓶颈在哪里？令如何能提高应用系统的性能？ARM正是用来回答这些问题的。通过在应用系统中引入ARMAPIs，可以让这些应用程序变得可管理、可监控，再配合相应的管理端系统，就可以捕获、分析运行时数据，回答以上这些问题。ARM规范经过多年的发展，现已成为业界公认的标准，尤其是金融业，对业务系统的稳定性、可靠性的要求相当高，越来越多的业务系统厂商开始遵循ARM规范进行系统开发，使得业务系统相关性能信息、属性信息对管理者可见。业务监控进入白盒监控时代。附图14.ARM管理系统的工作流程.2系统逻辑架构设计系统逻辑架构如下图所示，概括性的阐述了系统的逻辑架构。其中，不同的颜色表示不同的模块，方框表示软件内部的功能模块，通过此图可以直观地看到不同的功能模块在系统中的层次。附图15.ARM系统逻辑架构示意图系统分为应用接口层、数据采集层、数据处理层和数据展示层（用户接口层）。1、应用接口层提供客户应用调用接口，C实现的为基于标准的ARM4.1规范，它收集到的应用性能信息发送到消息队列中；针对J2EE系统，通过Java字节码注入的技术（Javaagent在系统运行时在需要监控的代码块前后插入探针，当这个代码块被调用时，就可以获得这次调用的性能数据；2、数据采集层负责收集由应用接口层发送过来的性能数据，进行一些简单的计算后发送给数据处理层；在C语言实现中，由单独的ARMAgent进程读取消息队列中的性能数据，计算处理后发送给ARMProbe；在Java实现中，由一个单独的线程接受性能数据，将相同交易模块的性能数据合并（统计并定时发送给数据处理层；对于每个交易模块单比的性能数据，使用采样率过滤（如果是有异常信息的则不被过滤然后发送给数据处理层。3、数据处理层接收到性能数据，将他们储存到数据库中，并进行一些计算分析，包括交易线统计分析、交易模块统计分析和应用统计分析，将分析结果储存在数据库中，供历史查询和报表使用；同时，当性能统计信息更新或告警发生时，数据处理层会通知数据展示层，数据展示层将负责协调刷新客户端，以达到实时监控的效果。4、用户通过浏览器请求数据展示层加载监控界面，ARMServer负责对登录的用户进行权限控制；用户使用基于flex技术的富客户端页面与后台的ARMServer交互，以拓扑图的方式观察业务系统之间以及系统内部交易模块之间的关系，诊断系统瓶颈。ARMServer实时刷新客户端界面，并负责处理用户的操作请求。.3实时交易监控对于收集到的交易性能信息，需要提供三种不同视角的实时监控方式。分别是应用视角、交易模块视角和交易线视角，以实现从总体到局部的较为全面的业务监控，每种视角均可以正确的展示异构系统之间的交易串联。附图16.异构系统交易线示意图基于C语言开发的应用系统之间：基于C语言开发的应用系统的交易监控是基于ARM4.1标准并改造应用代码后实现的，同时根据该标准，应用系统模块和模块之间、应用系统之间通过传递Correlator实现交易线自动串联；基于Java开发的应用系统之间以及系统内部的异步调用：通过ARM4.1ForJAVA标准，开发API产生并注入Correlator，以模拟上述基于C语言开发的应用系统交易监控实现方案；基于Java及C开发的应用系统间调用：异构系统之间的调用需要基于传递Correlator机制来实现自动串联交易线，Java端模拟产生Correlator，C系统接收它并调用ARMAPI注入，系统将自动生成调用关系的交易线；反之亦然。业务交易在进行流转的同时，会将交易相关性参数（Correlator）依次传递到交易线各个模块，系统通过获取这一参数，了解业务交易路径、交易的同步异步信息等，以此将各交易模块串联起来生成交易拓扑，并以图形方式展示出来。同时系统能够采集交易数据，并进行统计，生成单位时间内的交易量、交易模块单位时间内的执行失败率、交易模块的平均响应时间等，对于上述性能指标，系统还提供历史性能曲线，帮助管理员了解业务性能变化趋势，避免可能产生的故障。附图17.交易拓扑展示系统将从应用的视角将定期采集到的交易进行统计，计算一段时间内的交易量和错误的交易模块笔数，并以拓扑图的形式展现出来，应用之间如果有跨系统的调用关系则用箭头表附图18.交易指标展示.3.4交易状态实时排名如下图所示，系统将对每个应用内的首交易模块的交易量和平均响应时间（每个统计周期内的交易量）分别进行实时排序，以列表形式来显示；从应用实时监控面板可导航到实时排名面板，从实时排名页面可导航到交易模块实时监控面板。附图19.交易状态排名告警集成ARM产生的告警需发送给CMP系统，并通过告警模块来产生告警动作，监控人员看见告警后，可导航到ARM系统的拓扑图上，查看告警，进行告警的确认和清除。附图20.交易告警明细交易告警视图系统通过告警管理模块对错误和超时的交易模块产生告警。超时告警：当模块超时次数超过设定次数时，或是模块单位时间内超时次数与单位时间内总笔数的比值超过设定值时，系统会产生相应告警；错误告警：对错误码进行设置，系统将捕捉应用系统上报的错误码，并与设定值进行比较，当模块单位时间内错误次数与单位时间内总笔数的比值超过设定值时，系统将产生告警。不同颜色显示不同的告警级别，在交易拓扑中可以直观的展现故障点，精确定位故障环节，提高运维人员的排障效率。附图21.交易模块告警视图令历史告警如下图所示，对于ARM产生过的告警信息，用户可通过界面查询，查询条件包括告警发生时间、交易模块名称和应用名称。附图22.交易历史告警.4交易查询系统可根据交易相关信息包括主流水号、子流水号、发起系统、主交易码、子交易码、错误码等对错误的交易环节进行查询，以列表的方式显示所有负荷条件的交易模块，用户可以查看选中模块的详细信息，包括应用名称、应用实例、交易名称、交易实例、父交易实例、同步或异步调用、响应时间、错误码等。附图23.异常交易查询.4.2单笔交易实例查询当采样率设置为100%时，系统将记录每笔交易数据。根据交易相关信息用户可以对单笔交易进行查询，查询条件包括：主流水号、子流水号、发起系统、主交易码、子交易码、错误码和交易状态等，同时显示整条交易线的拓扑。附图24.单笔交易业务查询.5历史交易综合分析.5.1交易模块指标历史回溯对于每个交易模块的平均响应时间、交易量以及最大响应时间、最小响应时间，以曲线图的方式来反映指标的变化趋势，可通过选定时间范围来查看。用横向滚动条来调整横轴的精确度（精确度越低，横轴单位长度所表示的时间间隔越大，图中包含的数据就越多，反之，精确度越高，局部的变化趋势就越详细，精确度最高可以到每15秒一个性能数据）。如下图所示，面板上显示了交易模块PCHK_PRECHECK在一定时间内的交易量，横坐标是时间，纵坐标是交易量。附图25.交易模块指标历史回朔.5.2交易量相对业务系统比重计算系统计算出一段时间内交易模块的交易量占该交易所属业务系统的总交易量的百分比，用图表来显示（在一张图上显示交易模块交易量和应用交易量两条曲线，并标识出每个点上的百分比，或绘制百分比曲线）。如下图所示：面板上显示了交易模块0001_MAIN_ANS在一段时间内的交易量，以及这个交易模块所属业务系统pltserver的交易量，通过此图可直观的看到交易模块业务量占业务系统的比附图26.交易量相对业务系统比重分析对于一段历史时间的曲线分析图，提供同比和环比曲线作为对比。令同比图包括：按星期同比，例如将这个星期的星期一和上个星期的星期一来对比；按月同比，例如将这个月的15号和上个月的15号进行对比；按年同比，例如将今年5月1日和去年5月1日进行对比；令环比图包括：按天环比，例如将今天的和昨天的性能数据做对比；环比即给定一个统计周期，将这个统计周期和上一个周期进行对比，统计周期长短可配置。附图27.业务指标同比3.1.3.2基于无代理方式的业务交易监控一个全面的应用性能监控管理解决方案通常需要实时监控到所有的用户，所有的应用，并可以适应企业网络拓扑的改变或增长。通过安装代理程序可以实现端到端的性能检测或分析，但不可避免的是，无论采取在主机上安装代理，或安装被动式代理，主动式代理都有一定的局限性。当如果需要对所有服务器，应用，用户或网段进行监控就意味着需要安装大量的代理程序。因此，我们需要另一种方式，也就是无代理方式对整个系统进行监控。无代理业务交易监控的特点包括：1．无代理网络监控我们可以通过连接核心交换机上的镜像端口或监控端口，可收集并发现所有网络上的协议，服务器，端口以及用户。同时，对IP（TCP和UDP）流量进行分析，并可对其它IP或非IP流量进行统计。针对不同网络接口上采集到的相同的数据包，采用无重复数据包技术来保障数据采集的唯一性和无重复性，这一技术也用于多个探针采集到的同一IP数据流的处理，以此保障了对数据处理的准确性。2．识别真实的应用/网络用户自动通过IP地址，登陆名发现所有的网络用户。分别监控记录每一用户，应用，服务器的使用情况和性能。对于使用VPN登陆企业内网的用户，系统会自动识别出登陆名和用户真实的IP地址。在基于网站的无代理监控模式下，自动发现所有的访问网站的用户，监控每一位用户使用情况和性能表现，并对网站用户数进行统计。在真实网站用户统计中，往往使用不同的人工模拟代理的方式。3．通用TCP流量分析提供基于TCP交易的应用响应时间，错误率，可用率等性能指标。所有的这些指标适用于任何基于网络的应用和提供从链路层至会话层的应用控制。如需要应用层的进一步分析，可通过不同的协议解码器实现。4．HTTP深度分析提供基于HTTP页面的应用层至表现层性能指标，使用HTTPHit-to算法。可自动发现网站所有的Web服务；通过分析GET和POST请求来区分Web应用。对于每个Web应用（URL和相应的GET/POST参数）可监控其使用，性能，HTTP错误率等指标。HTTP性能指标包括，正常和较慢页面加载数量统计，页面加载时间，网络时间－服务器时间分别所占的时间，重定向时间,页面大小,页面吞吐。HTTP错误包括HTTP客户端错误（错误代码如未授权，未发现，其它）和HTTP服务器端错误。应用错误通常是经基于模式匹配的HTML内容检查后所得出。HTML分析包括支持Frame结构的页面分析（<IFRAME>/<FRAMESET>标签，并支持递归模式）。Frame结构的页面被看做一个页面而非一组页面，Frame结构的页面的监控模式可自动或手工配置进行监控。5．业务交易分析HTTP业务交易是指在网站上，通过一组顺序的URL页面去执行和业务相关的一系列操作。每一个业务交易都有自己的起始页面，终止页面和相关其它的一些页面组成。以实时方式监控所有网站用户的业务交易。对于每一个业务交易，其监控性能指标包括执行时间，实际步骤，以及各步骤，服务器处理时间，网络消耗时间，和空闲时间的关系或时间比重。交易期间的错误不仅会出现在HTTP页面报告也同样会反映到交易报告中。6．SMTP分析SMTP分析提供EMAIL流量数据，包括EMAIL字节数，附件数量，SMTP服务器性能，比如处理时间和错误数。SMTP报表的用户是EMAIL地址用户。7．防火墙和负载均衡检测监控设备本身的延迟和丢失率。提供设备延迟时间，计算防火墙上被丢失的SESSION数8．网络性能表现对被监控的应用的网络性能，提供延迟（roundtriptime）和丢包率（retransmissions）。网络性能往往作为应用服务水平下降的一个原因－也就是，应用服务是否受到网络性能的影网络性能表现可针对于单个用户，应用或服务器，并提供上传和下传两方面评估参数。网络延迟是TCPSESSION持续性的参数。9．应用监控对网络上的每个应用，服务器，用户，可以按client-server和server-client分开监测其流量（字节，包带宽使用，吞吐量等性能指标。.1无代理采集探针采集探针将部署在关键网段，通常依附于交换机上的镜像端口或监控端口。通过无代理技术，以被动方式从交换机的端口或分流器收集数据。以实时方式对采集信息按网络用户和应用程序等进行初步的元数据处理，对元数据进行进一步的分析和整理，以提供报表和告警触发信息。.2数据分析服务通过读取一个或多个探针收集的信息，在数据库中，为每一个网站用户，服务和URL建立相应的性能指标。数据的处理是以准实时的方式进行，因此可保证报表的准确性和及时性。并且，所有的报表都可以以WEB的方式进行访问。数据库不仅保存实时的各指标性能数据，还留有历史纪录，这样可以方便地进行趋势分析和自动计算性能基线。.3高级诊断服务Web应用通常采用复杂的多层(multi-tier)网站架构。基于HTTP的应用需要智能化的诊断，深入到Web用户以表格、向导或者遍历等各种形式动态交互的页面。在这种情形下，网站的用户故障诊断成为一项复杂的任务。网站的系统问题定位也变得非常具有挑战性，以至经常引起架构部门、内容设计部门和应用管理部门难以化解的争端。深入分析HTTP针对每个网站用户、每个HTTP点击、用户请求的每个页面分别收集数据，这些数据存入数据库，从而转化为用户-网站交互（Hit和Pages）的原子级别的诊断信息。由于这些详细信息是根据业务模块分别累积的，详细的HTTP分析可以专注于单个用户或者Web应用的故障诊断，包括业务应用、用户和位置信息。详细的分析是基于一系列可根据具体需求定制的报告进行的。即时可通的报告包括页面加载渐进视图、对请求时间、服务器时间、空闲时间、响应时间以及他们之间在一个页面加载内的关系的做详细评估。业务交易监测将探针收集的数据定制可扩展的报表，可以生成业务交易报表。即时可用的报表包括业务交易记分牌视图和渐进视图。业务交易报表包含的信息有事务性能、利用率和出错矩阵。渐进视图专注于事务执行，用来展示事务之间的时间关系。最终用户还可以深入至事务内部的每个页面。网站问题解决报表我们将构建一个网站性能分析模型，用于找出导致基于HTTP的应用性能下降的系统问题。系统问题的出现频率、原因以及影响都被量化并和网络、服务器、客户端时延、内容设计等关联起来。根据特定单元的失败导致的页面加载缓慢的数量来量化系统问题的影响范围和严重级别，然后将它们以一种便于理解的形式展示出来，以帮助IT人员重点解决那些最为严重的网站问题。业务模拟体验来自Google和Microsoft的研究证明，即使是一秒钟的延迟都会对用户体验、收入和品牌忠实度产生明显影响。用户一直渴望和要求更好的交互体验和更快的响应速度。当用户数和交易数量不断增加，现有的系统运维风险开始变大，而且越来越难以保证新版本发布后的扩展性和稳定性。用户体验的重要性不言而喻，那么通过怎样的手段来保障用户体验是最有效的呢？业务模拟体验管理，是衡量应用性能最直观的指标。基础架构的建设、应用系统的开发运维，最终目标是提供一个高效的业务运行平台，随着信息技术与业务的融合，用户对于业务的接触界面被虚拟化了。业务部门对于用户体验的掌控开始失效，而用户体验管理就是为了弥补这种状况。而信息技术部门对于应用运维的评价，已经不能单纯从单个网络、系统、数据库、应用来进行了，即使一切组件都运行正常，也难以确保用户体验良好，必须从真实用户的实际体验角度对运维进行评价，才不致于片面失察。业务模拟体验管理提供对于用户行为和用户体验的完全可视性，它捕获每一次用户点击，无论该点击来自何种设备，何种浏览器类型，都提供24*7的全时性能和错误分析，继而与动态生成的性能基线进行比对，为IT运维与业务管理层提供快速直观的故障诊断报告业务模拟体验管理作为业务服务管理的重要组成部分，完全以最终用户的角度，通过自动对系统的模拟操作，记录并分析模拟体验结果从而度量用户敏感度高的客户接触类业务，为运维人员提供体统可用性、系统质量的信息。业务模拟体验管理以7×24小时不间断的方式，主动地模拟用户使用业务的行为，发现关键业务流程潜在的性能和可用性问题，建立预警机制，通过系统监控管理生成业务体验告警事件。业务模拟体验管理目标是借助端到端的模拟请求，找出体验较差的业务流程，弥补系统监控管理发现不了的缺陷。模拟功能管理现代Web或企业应用的用户体验需要一个端到端、基于交易的方案。现代应用越来越多的调用第三方服务，例如内容分布式网络，广告服务等等。而且，越来越多的代码在浏览器端执行以增加与用户的互动性，虚拟化的基础设施和云服务被采用以降低风险和提供更大的灵活性。传统方案只能看见传输到服务器的网络数据以及其携带的有限信息。我们将提供完全基于交易的端到端的用户体验管理功能。第一次实现对真实用户体验、行为等信息的管理能力，能够全面了解使用任何设备的用户，从点击鼠标到最终数据库的整体性能。可视化实时交易流即使在最理想的状态下，隔离性能问题仍然是非常有挑战性的一件事，而对于今天复杂，分布式，动态的应用，仍然沿用老的性能监控工具去隔离性能问题几乎是不可能的。实时交易流拓扑图实时勾画出穿越你的应用环境中的每一个交易，包括全面的概览，或者是某个出现性能偏移的交易，或者是作为特定SLA一部分的交易。可以看到是哪一个应用组件被使用来处理这个交易，了解组件之间的互动关系以及层与层之间交互时的性能影响，展示一个交易在每层消耗的时间以及资源消耗比如CPU利用率。另外，交易流视图也可以展现每次交易执行时所调用的服务次数，高亮产生性能瓶颈的问题类别。附图28.可视化实时交易流端到端交易服务端到端的交易跟踪，可以跨越WEB/WebServer/Java/.Net/C边界，同时会记录和捕捉上下文环境，例如用户会话信息、方法参数、返回值，日志消息，异常详细信息等。采用可视化的技术快速定位性能瓶颈。附图29.端到端交易分析分析应用在浏览端的性能可以深入分析应用在浏览器端执行的性能，包括Javascript执行时间，页面渲染时间，解析时间，网络时间，服务器时间。附图30.浏览器端性能分析分布部署模拟体验点功能应具备从不同地理位置发起业务体验的能力。这些业务体验发起地点应部署在用户体验较差、性能问题多发地点，或者业务量较大的地点。所有体验点都会把采集到的用户体验数据发送到业务管理平台，按照小时、天、周、月、季度和年等时间周期进行逐层聚合，便于进行历史数据分析。模拟体验点历史性能数据分析功能以业务为中心，按照模拟业务体验发起时间、发起地点、业务响应时间和业务体验结果等维度进行历史数据分析，找出体验较差的业务。经过前期的系统建设，运维体系中各个管理系统已经采集并存储了海量数据，数据范围涉及到了告警、性能、配置项、业务、运营、运维等多领域，如何将这些数据进行有效的利用、分析，为系统分析、决策判断提供准确的依据成为系统发展的瓶颈。为更好的利用既有数据，服务于业务运营，提升业务运营质量，通过建设综合分析平台进行综合化的分析，分析中心主要面向管理人员、业务人员，维护人员，通过对既有数据进行多视角、多维度的分析，直观展示业务、应用及系统的运行状况、发展趋势，最终为系统扩容优化、业务质量提升提供运维数据支持。提供方便的查询功能，可以通过导航对各专业的维度和指标进行简单定制的查询；提供多种统计分析能力，围绕分析主题进行不同角度、不同层次的数据分析，用户能够在页面上快速实现指标的对比分析、分布分析、同比分析、环比分析、趋势分析等，从而形成一系列的指标分析内容；提供了灵活、易用的应用展现功能，包括：图、表、图表结合、文字、符号等多种可视化界面；提供灵活的多维浏览展现，用户可以对数据进行灵活的钻取分析、切片旋转分析，帮助发现数据之间潜在的、不易为人察觉的关系，洞悉业务发展规律；同时能够将分析结果自动生成所需要的报告；各种数据分析方法和操作方法——对比分析、分布分析、同比分析、环比分析、趋势分析、阈值分析和钻取分析、关联分析、切片分析、旋转分析、排序分析、数据导出，需根据主题分析内容可选实现。故障分布分析CMP系统每天会产生数量众多的告警信息，报表模块从告警类型、告警级别、告警源等多个角度分析这些告警信息。提供按照日、周、月等不同时间粒度的告警明细和统计报表，帮助维护人员定位故障频发点、故障多发时段，故障多发类型，分析故障发生原因，以采取有针对性的措施，尽量防止故障的发生。统计分析平台提供关于当前告警和历史告警的查询、统计和分析功能，并给出故障分析报告等信息，为透彻掌握系统运行情况提供分析数据。维护人员能够通过报表查看和处理告警和故障，对系统运行状况进行快速总结和汇报；管理人员也能够通过报表看到故障发生、处理、趋势等数据和图表，作为决策和考核的数据基础。告警管理报表能够提供以下信息：令当前告警：提供了多种维度的当前告警信息，方便查看各种需求的告警统计，为故障及时处理提供了告警和故障的有效展现工具，主要包括：告警列表查询：以最小粒度1分钟及时刷新当前告警，并提供按照设备、告警类型、告警标题、告警内容、告警级别、告警状态、发生时间、重复告警等条件的查询功能，当前告警可以钻取（DrillDown）到详细的告警信息。按照设备分布查询：将告警按照不同设备统计严重告警/主要告警/次要告警/警告告警等告警，可以按照设备钻取（DrillDown）到详细的告警信息。自定义查询：可以按照设备属性、告警属性、其它属性、告警发生时间等条件进行复合查询。设备状态图：按照系统、主机、网络、数据库等分别组织的设备状态的直观展现工具图表，可以将所有设备的主要属性（如主机的CPU/内存/Disk/Swap/磁盘/进程/文件系统/通断性等）的当前状态，按照不同颜色显示严重/主要/次要/警告/不确定/正常等不同状态，可以钻取访问到详细的告警信息。令历史告警：提供了多种维度的历史告警信息，方便查看多种方式的告警统计，为故障处理的考核提供了数据基础，主要包括：按照不同的系统统计历史告警按照不同的时长统计历史告警，包括告警时长、处理时长、响应时长等按照不同的告警类别统计历史告警按照不同的告警级别统计历史告警按照不同的设备统计历史告警自定义统一和自定义查询。附图31.故障分析报表性能综合分析系统运行情况性能报告是报表系统的重要内容。报表模块能够提供各种性能KPI指标报表，同时展现设定的性能指标的门限值，使维护人员能够通过报表系统了解IT系统、子系统的运转状况，分析运行趋势，定位性能瓶颈，为合理的容量规划和系统扩容提供量化依可以将多种数据来源的后台数据经过计算、加工、整理、组织，形成系统设备的历史性能数据，并按照最终展现的报表要求，进行各种时间粒度的聚合，从业务应用的角度，将经过聚合处理的数据按照各种维度进行重新组织，方便地展现各级不同用户需要的性能统计报令业务系统状态报表各个业务系统的维护人员在日常运维过程中需要了解自己负责维护设备的Overview情况。因此，报表模块提供了各业务系统的Overview报表，包括了该业务系统所属设备列表（可DrillDown察看明细资产数据）、当前设备告警情况（可DrillDown察看明细告警数据）、若干主要性能指标的TopN报表（可DrillDown察看性能明细数据）。性能查询报表对于服务器、数据库、中间件等的性能报表提供灵活的明细数据查询功能。能够对信息的内容条目设置查询条件，也能够对主要的条目进行复合条件的组合过滤查询。在用户设置如时间、日期等查询条件时，可以对输入内容的合法性进行检查。能够提供性能指标的横向比对和纵向比对的功能。横向比对即若干台设备的同一个或几个性能指标在同一时间段内的性能曲线比对，纵向比对即同一台设备的某几个性能指标的当前情况与昨日、上周、上月、往年同期的比对分析。对于通过折线图展现的多指标报表，可以区分到底哪条曲线代表哪个指标，能够对不同的指标加以不同的标记。同一张报表中展示多个指标，而这些指标的单位不同，可能是数量、时间、百分比等，报表模块提供同时展现多个坐标轴的功能。用户在查看性能指标数据的同时也可以查看到这些性能指标的告警门限，以直观的了解在一段时间内该指标的变化情况。如果用户需要了解某些指标对另外一个重要指标构成的压力情况，还提供在同一张报表中展示不同指标，指标状态和变化趋势可以分别用柱图、折线图表示。附图32.性能分析报表资产分析对于用户关心的IT系统的资源资产情况，可以通过资源资产分析报表获得。提供按照生产厂商、业务系统、设备型号、设备类型、联系部门、地理位置等多种维度组合查询功能，容量规划容量规划使维护人员能够清晰地了解IT系统中各种设备、软件、应用的资源配置情况。报表查询可以按照整体统计或设备明细进行，通过统计报表的向下钻取也可得到明细报表。资源资产报表为用户提供了翔实的数据，为维护人员、管理人员掌控系统资源信息，充分了解系统资源配置情况提供非常便利的工具。资源资产报表还提供在指定时间段内资产配置信息发生变化的配置变化报表。附图33.资产分析报表批注[雨林木风8]:加入虚拟化容量规划附图34.容量规划视图附图35.容量趋势报表.1.1主机容量规划主机容量规划是指依据对历史数据分析结果，形成评估模型，可以通过业务增涨量评估主机应具备的运算能力（TPC-C值与内存需求量从而为支撑部门按业务量进行主机扩容提供参考依据。.1.1.1规划要素规划要素包括：分析模型、分析变量、分析常量、分析结果。主机容量数据要素包括：主机型号、TPCC值、CPU主频与数量、内存容量、CPU利用率、内存利用率。主机容量按指定的忙时，提取单台采集主机容量指标，数据来源为性能数据或系统状态快照文件。业务数据的内容包括：业务指标名称、业务指标量、业务指标的统计周期、需要使用的系统资源名称，以及完成业务量处理所需要的运行时长。.1.1.2规划方法TPC-C评估方法TPC-C测试基准主要用于计算主机服务器每分钟能够处理的联机交易笔数，评估产生的单位结果是TPM值（TransactionPerMinute，即每分钟处理的交易比数）。TPC-C虽然客观的反映了各个计算机厂商的系统处理性能，并且测试基准也在不断完善以更加贴近现实应用的交易环境，但是仍然无法与纷繁多样的各类实际应用完全吻合；而且参加TPC测试的主机系统都做了适当程度的系统优化。因此，在实际业务应用系统选择主机服务器乘载体时，必须考虑到多方面的因素，以最大程度的做到适合应用系统的生产需内存量估计方法首先根据数据库容量算出所需的数据库缓存大小，再估计出操作系统、系统软件等所需内存，再根据按合理的利率计算出的值，即是所需的内存容量。公式如下：TOTAL_MEM=（OS_BASE_MEM+OS_HA_MEM+APP_MEM+DB_SYS_MEM+DB_CACHE_MEM）/Good_Rate其中：OS_BASE_MEM：操作系统所占的内存量OS_HA_MEM：双机热备等系统软件所占的内存量APP_MEM：应用程序所占的内存量DB_SYS_MEM：数据库管理系统所占的内存量DB_CACHE_MEM：数据库缓存内存量Good_Rate：合理的内存利用率，建议：75%.1.1.3规划结论以业务量预测值为基础，给出满足预测值的主机容量建议。.1.2数据库容量规划根据数据库容量评估得到的趋势图，形成DB容量要素指标和数据量的变化模型，通过数据增量评估数据库要素指标的增量，从而得到规划的数据量对应的的数据库要素指标，为支撑部门按业务量规划DB容量要素提供参考依据。批注[雨林木风批注[雨林木风9]:.1.2.1规划要素令数据库容量要素：硬件因素：包括表空间增量、内存增量；调整参数因素，包括游标增量、会话增量、进程增量、锁增量、任务队列增量；.1.2.2规划方法根据数据库容量评估得到的趋势图，形成DB容量要素与业务量的变化模型，根据评估模型，形成DB容量要素增量的关系。.1.2.3规划结论根据评估方法模型得到数据库的容量规划，为支撑部门按业务量规划DB容量提供参考依据。容量规划主要是建立未来系统扩容计划。通过容量评估已经可以得到系统支持的最大业务量，但是无法通过业务量趋势分析得到到达最大业务量的时间。容量规划可以通过对现有系统平台指标的趋势分析，获得平台指标到达阀值的时间。通过以上分析可以在业务量不明的情况下进行系统容量规划，获得扩容的时间点。同时，当获得业务部门预测未来的业务量是，可以通过系统交易模型反推出该业务量所需要的平台指标大小，进而分析要支撑未来业务量所需要扩容的项目和大小。.1.3虚拟化容量规划针对虚拟及物理实体的容量进行统一分析及预测由迅速增长和部署的虚拟服务器趋势所推动。首先容量管理解决方案需要监控并收集、过滤、归一并分析所有物理及虚拟实体的性能及配置数据，然后基于这些性能和配置数据以及可能的工作负载情况，预测未来的虚拟及物理实体对容量的需求状况。虚拟化增加了数据中心的灵活性。但同时也增加了复杂度。有些服务器实施了虚拟化，有些则没有。首先对虚拟及物理实体的性能及配置数据进行收集，整合来自多种异构性能数据源实例的性能数据，并将这些数据标准化，在整合过程中实现自动抓取、标准化、同步和验证来自多种普及供应商和自定义数据源的性能数据。首先需要确保数据之间不存在差别，保证准确性。如果需要，可以根据实际的业务和应用生命周期，重新定义数据采集周期和指标水平。企业肯定都拥有多个来源的性能和配置数据，因此要求容量数据收集能支持单一储存库支持和利用所有来源数据。例如应用一部分运行在VMware中，而另外一部分运行在HPMonitoring管理的UNIX/Linux服务器中，还有一部分则通过SAR或PerfMon进行监测，收集器可以提供集成的标准化数据集，从而实现报告和建模功能。即使独特的数据源也可以在收集器中加以利用，实现最终的灵活性。收集器还包括开放式报告框架，可以在容量储存库中提供所有内容的报告视图。用户能够利用立即可用的集成报告，支持简单的趋势分析和应用概要分析，或者他们能够采用自己的报告编写软件，创建自己的报告。如果需要理解当前应用的运行情况，收集器可以实现图形展示，无需额外的时间或部分精力。基于html的报告可以轻松实现与相关者的共享，以便促进讨论和决策支持。用户还拥有可选项，利用预先定义的报表模板用于报告。容量管理解决方案其目的就是在尽可能确保容量满足业务的服务水平的前提下节约成本。因此首先需要深入了解提供正确组合基础设施的洞察力，并且通过醒目的执行仪表板提批注[雨林木风10]:加上其他几条批注[雨林木风10]:加上其他几条供信息。再对比硬件供应商和配置，确定哪种基础设施组合可以采用最佳成本满足服务水平要求。最后规划并且定制传统的或虚拟的环境，包括应用环境。及早发现性能瓶颈，将风险保持在最低程度，通过预测提前纠正。虚拟实体综合分析通过分析虚拟实体的性能监测数据可以发现已经发生的问题，然而，当用于构建未来的绩效模型时，这种数据没有太大价值。已经采集的数据利用价值在于，可以迅速创建应用和基础设施的准确仿真模型，并且对它进行虚拟变更，不会给生产系统带来风险。凭借超过90%的精确度，可以获得所需的所有洞察力，从而做出明智的IT投资决策。一旦模型创建之后，可以应用“假设分析”("what-if")场景来加以实现。譬如不断更改的硬件供应商、整合服务器、不断增长的工作负载等等各种场景，有超过4000个硬件模型库的组件可以轻松挖掘出这些可能的趋势。在发生故障之前，便能识别出潜在的性能瓶颈，对需要投资领域的IT运行环境容量进行规划。一旦模型创建完成，可以采用内置的执行和运行报告，将基础设施和应用的详细信息以报表的方式对IT和业务部门进行展现，容量管理解决方案支持开放式报告框架，所有建模相关的成果都可以在开放式XML结构中提供，任何支持XML数据源的报告编写软件都可以获得包含报告在内的建模成果。容量管理解决方案还可以提供立即可用、与CrystalReports的额外集成，以实现执行和自定义报告功能。通过利用专利预测分析技术，结合真实世界的绩效数据、建模、仿真、财务信息和决策支持仪表板，综合分析解决方案可以提供对于虚拟和物理实体的容量信息的深入洞察能力和决策支持。运维管理综合分析运维分析主要是对DCM系统的数据进行分析，反映服务管理工作的质量和效率，从而评估流程管理的有效性和效率。运维分析的维度可以按照事件流程、问题流程、需求流程、配置流程、变更流程、发布流程、服务请求运维流程进行分类，分析指标应该涵盖数量、解决率、及时率、响应时长、中断时长、重复率、成功率等，详情请见下表：表格1.运维专题分析表维度主要指标数量解决率及时率解决时长中断时长重复率成功率事件管理√√√√√√√√√√√√统√√√√√√优先级√√√√√√√√√√√√