论文部分内容阅读
“只有可见的，才是可运维的。”这是IT运维人员常说的一句话。
然而现实往往并不能如愿以偿，过去的很长一段时间内，企业IT团队的精力往往都放在应用系统的建设上，工作重心多是完成一个又一个项目，很少真正对所有的应用系统做详细的梳理、弄清楚其中的逻辑关系。再加上早期开发的一些应用系统并没有建立良好的开发和运维流程，应用系统之间的关联关系也往往没有规范的文档可以查询。这样久而久之，随着运维人员的交替，支撑企业业务的应用架构已经变得难以梳理，IT运维面临的压力也越来越大。
而在众多信息化建设开始较早的企业中，这种情形尤为明显，一方面是由于建设时资源紧张等特殊因素，某台服务器上可能运行着多个不同的应用程序，或者有一些边缘组件平时不太引人注意。这些问题伴随开发人员的更替，逐渐被人们淡忘，为后来的运维工作埋下了隐患，国内某大型商业银行便是这方面的典型案例。
应用可视化是关键
为此，该银行开展了相应的治理工作，以清除IT运维工作中存在的死角。该项目负责人姜岩在接受采访时表示，由于运维人员的不断交替，对整个应用系统缺乏清晰的认识是运维工作面临的最大难题。
显然，如果没有一种有效的梳理手段支撑，企业要解决应用梳理问题，无疑是一项充满挑战的工作。特别是在业务与IT系统越来越紧密关联的趋势下，业务运行会很依赖IT系统的支持，如果缺乏对IT架构的理解，每一个未知风险都可能导致业务的严重中断；另一方面，业务快速变化也对IT运维的敏捷性提出了前所未有的要求，运维人员只有对IT架构保持充分的了解，才能让IT跟得上业务变化的节奏。因此，如今的运维人员已经不能仅满足于知道有哪些应用和节点部署在企业中，更需要知道它们之间是如何连接和交互的。
为此，姜岩和他的团队尝试过多种方法，比如使用Agent模式、日志分析、代码植入等方式，不过效果并不尽如人意。由于这些方式直接与被管理系统、应用程序产生交互，也就是说其在监视数据产生的同时，本身也会消耗系统、应用程序资源，而这往往会导致资源紧张，进而导致业务处理性能下降，甚至有不少用户因此而遭受了严重的业务中断故障。
在经过多方考量后，最终他们采用了基于网络数据资源的应用性能管理方法，使用CrossFlow BPC（Business Performance Center）网络与应用性能管理产品进行应用梳理，并进行相关的监控管理。
而之所以采用这样的方式，也是因为在当前的应用架构下，应用服务层级划分已十分清晰，各层级间的交易全部通过网络传输来完成，基础设施和交付设施本身都以服务为中心向应用提供界限明确的服务功能，使得数据采集设备可以轻松获取关键交易环节的网络数据，这给网络数据源的获取带来了极大的便利和灵活性。
据姜岩介绍，整个项目的实施主要有五个关键步骤，包括应用整体监控的标准化制定；监控统一管理的必要性分析；明确监控统一管理的主要目标；掌握监控统一管理的关键技术及监控统一管理最终如何展现与运用。“整个项目的关键词就是整体、统一。”姜岩解释说，只有做到整体监控、统一管理，才能使IT系统可视化，运维工作才能得心应手。
整体监控 统一管理
在具体的实施过程中，姜岩首先对现有应用系统的整体构成做了全面了解、仔细排查，包括哪些应用是跨节点、跨层面的，哪些应用是多维度的；然后按照应用构成信息的不同（不同应用的基础层面构成信息、应用内部构成信息、应用外部关联信息等都不尽相同），设定不同的KPI监控指标，再根据相应的指标分发相应的监控策略。姜岩表示，这样做的好处就是可以全方位多维度地梳理应用监测点，并以体系化的监控指标作为分发策略的参考。在此基础上，构建起了三层架构的监控统一管理平台，其中包含监控对象及代理层、监控工具层及监控管理平台，进而对应用产生的数据进行采集、处理、监控及管理。
其中作为数据采集的关键，中间层的监控工具层起着至关重要的作用。因此，据姜岩介绍，他们前后部署了多个监控工具用以监视各个部件的情况，有针对惠普小型机监控的OVO、针对网络事件监控的SORLAWINDS、针对IBM小型机监控的TIOVLI、针对数据库监控的OMS、针对应用性能整体监控的CrossFlow BPC及针对存储环境监控的SOC等。
其中针对小型机、存储、网络的监控工具主要监控的是单一类型的系统，而针对应用性能监控的CrossFlow BPC则能在一定程度上起到全局监控的作用。因为当系统中的某一应用出现故障时，CrossFlow BPC能够及时发现，并追根溯源，进行自动故障定位，在呈现应用故障对用户体验影响的同时，指出导致问题发生的根源组件和原因。
CrossFlow BPC能够通过交易笔数、成功率、响应时间、响应率及返回码5个指标及交易时间、交易笔数2个维度对关键业务指标进行统计，并进行深入的分析。而其内置的SPV Discovery还能自动呈现被监控网络数据的IP连接性，快速梳理应用组件之间的逻辑访问关系。
也正是由于以上的种种特性，姜岩使用其对银行的核心业务进行监控，通过关键交易当前的状态分析、性能趋势对比、交易直接探测等措施，明确当前的各项交易处于什么状态、有无威胁，并通过CrossFlow BPC梳理各项应用之间的逻辑关系，降低人为出错的可能性。
在实际环境中，当其中某项业务出现故障时，CrossFlow BPC会以明显的颜色加以区分，并告知故障定位及告警数目，以方便用户做进一步的故障判断。
据姜岩介绍，通过上述一系列的应用梳理，数据采集、处理、分析工作，并在监控统一管理平台统一呈现，最终实现了应用整体监控的既定目标，即在应用整体结构管理方面，能够梳理应用整体结构，达到自动实时监测；在应用健康运行监视方面，做到实时采集并监测应用运行的状态；在应用运行故障预警方面，实时分析并监控应用运行的关键KPI；在应用运行故障报警方面，实时自动检查应用服务状态的异常情况；在应用故障原因分析方面，采集故障现场数据，并进行关联数据分析。
如今，通过新建立的监控统一管理平台，姜岩的运维工作已经变得得心应手。姜岩表示，现在通过总行的告警监控视图，运维人员可以轻松查看各个部分的运行情况。当某一部分出现故障时，通过整体报警消息，运维人员可以做到快速接管、准确检查、全程跟踪并及时通报。
然而现实往往并不能如愿以偿，过去的很长一段时间内，企业IT团队的精力往往都放在应用系统的建设上，工作重心多是完成一个又一个项目，很少真正对所有的应用系统做详细的梳理、弄清楚其中的逻辑关系。再加上早期开发的一些应用系统并没有建立良好的开发和运维流程，应用系统之间的关联关系也往往没有规范的文档可以查询。这样久而久之，随着运维人员的交替，支撑企业业务的应用架构已经变得难以梳理，IT运维面临的压力也越来越大。
而在众多信息化建设开始较早的企业中，这种情形尤为明显，一方面是由于建设时资源紧张等特殊因素，某台服务器上可能运行着多个不同的应用程序，或者有一些边缘组件平时不太引人注意。这些问题伴随开发人员的更替，逐渐被人们淡忘，为后来的运维工作埋下了隐患，国内某大型商业银行便是这方面的典型案例。
应用可视化是关键
为此，该银行开展了相应的治理工作，以清除IT运维工作中存在的死角。该项目负责人姜岩在接受采访时表示，由于运维人员的不断交替，对整个应用系统缺乏清晰的认识是运维工作面临的最大难题。
显然，如果没有一种有效的梳理手段支撑，企业要解决应用梳理问题，无疑是一项充满挑战的工作。特别是在业务与IT系统越来越紧密关联的趋势下，业务运行会很依赖IT系统的支持，如果缺乏对IT架构的理解，每一个未知风险都可能导致业务的严重中断；另一方面，业务快速变化也对IT运维的敏捷性提出了前所未有的要求，运维人员只有对IT架构保持充分的了解，才能让IT跟得上业务变化的节奏。因此，如今的运维人员已经不能仅满足于知道有哪些应用和节点部署在企业中，更需要知道它们之间是如何连接和交互的。
为此，姜岩和他的团队尝试过多种方法，比如使用Agent模式、日志分析、代码植入等方式，不过效果并不尽如人意。由于这些方式直接与被管理系统、应用程序产生交互，也就是说其在监视数据产生的同时，本身也会消耗系统、应用程序资源，而这往往会导致资源紧张，进而导致业务处理性能下降，甚至有不少用户因此而遭受了严重的业务中断故障。
在经过多方考量后，最终他们采用了基于网络数据资源的应用性能管理方法，使用CrossFlow BPC（Business Performance Center）网络与应用性能管理产品进行应用梳理，并进行相关的监控管理。
而之所以采用这样的方式，也是因为在当前的应用架构下，应用服务层级划分已十分清晰，各层级间的交易全部通过网络传输来完成，基础设施和交付设施本身都以服务为中心向应用提供界限明确的服务功能，使得数据采集设备可以轻松获取关键交易环节的网络数据，这给网络数据源的获取带来了极大的便利和灵活性。
据姜岩介绍，整个项目的实施主要有五个关键步骤，包括应用整体监控的标准化制定；监控统一管理的必要性分析；明确监控统一管理的主要目标；掌握监控统一管理的关键技术及监控统一管理最终如何展现与运用。“整个项目的关键词就是整体、统一。”姜岩解释说，只有做到整体监控、统一管理，才能使IT系统可视化，运维工作才能得心应手。
整体监控 统一管理
在具体的实施过程中，姜岩首先对现有应用系统的整体构成做了全面了解、仔细排查，包括哪些应用是跨节点、跨层面的，哪些应用是多维度的；然后按照应用构成信息的不同（不同应用的基础层面构成信息、应用内部构成信息、应用外部关联信息等都不尽相同），设定不同的KPI监控指标，再根据相应的指标分发相应的监控策略。姜岩表示，这样做的好处就是可以全方位多维度地梳理应用监测点，并以体系化的监控指标作为分发策略的参考。在此基础上，构建起了三层架构的监控统一管理平台，其中包含监控对象及代理层、监控工具层及监控管理平台，进而对应用产生的数据进行采集、处理、监控及管理。
其中作为数据采集的关键，中间层的监控工具层起着至关重要的作用。因此，据姜岩介绍，他们前后部署了多个监控工具用以监视各个部件的情况，有针对惠普小型机监控的OVO、针对网络事件监控的SORLAWINDS、针对IBM小型机监控的TIOVLI、针对数据库监控的OMS、针对应用性能整体监控的CrossFlow BPC及针对存储环境监控的SOC等。
其中针对小型机、存储、网络的监控工具主要监控的是单一类型的系统，而针对应用性能监控的CrossFlow BPC则能在一定程度上起到全局监控的作用。因为当系统中的某一应用出现故障时，CrossFlow BPC能够及时发现，并追根溯源，进行自动故障定位，在呈现应用故障对用户体验影响的同时，指出导致问题发生的根源组件和原因。
CrossFlow BPC能够通过交易笔数、成功率、响应时间、响应率及返回码5个指标及交易时间、交易笔数2个维度对关键业务指标进行统计，并进行深入的分析。而其内置的SPV Discovery还能自动呈现被监控网络数据的IP连接性，快速梳理应用组件之间的逻辑访问关系。
也正是由于以上的种种特性，姜岩使用其对银行的核心业务进行监控，通过关键交易当前的状态分析、性能趋势对比、交易直接探测等措施，明确当前的各项交易处于什么状态、有无威胁，并通过CrossFlow BPC梳理各项应用之间的逻辑关系，降低人为出错的可能性。
在实际环境中，当其中某项业务出现故障时，CrossFlow BPC会以明显的颜色加以区分，并告知故障定位及告警数目，以方便用户做进一步的故障判断。
据姜岩介绍，通过上述一系列的应用梳理，数据采集、处理、分析工作，并在监控统一管理平台统一呈现，最终实现了应用整体监控的既定目标，即在应用整体结构管理方面，能够梳理应用整体结构，达到自动实时监测；在应用健康运行监视方面，做到实时采集并监测应用运行的状态；在应用运行故障预警方面，实时分析并监控应用运行的关键KPI；在应用运行故障报警方面，实时自动检查应用服务状态的异常情况；在应用故障原因分析方面，采集故障现场数据，并进行关联数据分析。
如今，通过新建立的监控统一管理平台，姜岩的运维工作已经变得得心应手。姜岩表示，现在通过总行的告警监控视图，运维人员可以轻松查看各个部分的运行情况。当某一部分出现故障时，通过整体报警消息，运维人员可以做到快速接管、准确检查、全程跟踪并及时通报。