作者:张毅
l 引言
近些年来,随着民航运输的快速发展,我国已经成为了全球最具发展潜力的航空市场。由于机场建设、机场设施部署和机场运营受到资金、技术和人力等资源的制约,加之机场运营各环节日渐复杂,旅客服务需求更加个性化,对机场的运营管理提出了更高的要求。为了更科学地提升机场的管理效能,使旅客的出行体验更加便捷、高效和个性化,搭建统一的大数据平台,进行航班、商业、运维的大数据分析就成了首都机场最迫切的要求。
作为大型国际枢纽机场,首都机场在大数据的探索中也走在了行业的最前沿,很早首都机场就提出了“让数据说话”的研究课题,也组成了专门的数据专家组。首都机场从2005年开始建设统一的数据中心系统,作为首都机场各类元数据的管理型数据仓库。直到2014年我们开始搭建民航业基于机场业务的大数据平台智能运营管理平台,再到最近的“大数据在大型机场运维管理中的应用研究”科技项目探索。首都机场一直致力于从企业的整体角度而非单个部门对数据进行统一管理,从而共享、分发、同步所有信息,创建可靠一致的企业视图,通过减轻对不一致、不完整或重复数据的依赖,促使整个企业的运营更加卓尔有效。本文提出的对于运维数据的大数据分析是首都机场大数据分析的一个分支,我们致力于通过对于运维数据的预测、搜索和优化使机场的IT运维管理更有效率,使机场的IT系统管理员从纷繁复杂并且重复性的运维工作中解脱出来,可以把更多的精力放在业务创新中去。
2 运维大数据
运维大数据顾名思义即系统运维产生的海量数据,一般广义上的运维数据是指公司的业务运营和生产运行中产生的所有数据的总和。而狭义上的运维数据则专指信息系统运行维护中产生的机器数据,在这里我们重点分析的是狭义运维数据。
信息系统的运维数据按照数据类型分类主要有以下分类:机器配置信息、告警信息、状态信息、性能信息、资产数据、变更及事件记录,机器日志数据。运维数据按照产生的来源主要有以下分类。
(1)硬件数据:服务器、存储、网络设备、强弱电设备、机房相关设备产生的信息数据。
(2)系统数据:操作系统、数据库、中间件的日志信息数据。
(3)应用数据:各种应用系统和业务系统产生的业务相关数据。
(4)服务管理系统数据:各种资产系统、变更管理系统、监控系统、决策支持系统等产生的数据。
运维大数据的特点除了具有大数据4大特点数量大、种类多、快速化(处理速度要求高)、价值化(需要从海量的不相关的数据中找到高价值)之外还具有以下特点:大量的非结构化数据、大量来自异构环境的数据以及流数据的特点(实时到达;次序独立,不受应用系统所控制;数据规模宏大且不能预知其最大值;数据一经处理,除非特意保存,否则不能被再次取出处理,或者再次提取数据代价昂贵)。
2.1首都机场的信息系统运维管理
首都机场的信息系统担负着公司主要运行业务譬如前端离港、安检、航显以及集成等机场业务应用的后台数据计算、交互、存储的技术支持。首都机场信息技术部负责该信息系统的运行维护工作。随着,随着机场业务量的与日俱增以及为旅客服务的不断精细化的需求。截止到2015年,由首都机场信息部负责管理的信息系统共有将近200套运行系统,300余台服务器,5000余台终端。
首都机场信息系统按照地域划分主要分为两个区域东区(T3航站楼)系统,西区(Tl/T2航站楼)系统。信息部的系统运行维护管理工作主要包括以下内容:主机监控、网络监控、运行资产管理、应用故障答疑及故障排除、运行分析、问题通报、运行制度的建立、服务商管理、投产版本控制、运行事务协调、机房、设备间管理、综合布线管理等。
基于对服务日益精细化的需求,首都机场的业务对于信息系统的业务连续性和高可用性的要求也越来越高,而首都机场现在的信息系统仍然面临着众多问题。
(1) IT系统架构仍为竖井式架构,系统之间流通不畅,数据不兼容。系统与数据库均具备双机或集群环境但是仍然频繁碰到单点假死,导致集群失效,业务中断的故障。大部分关键系统配置了第三备机,总体高可用性较好,但是在需要第三备机恢复业务的时候经常会遇到业务数据未与主备机同步的问题,该问题会影响到业务恢复时间。
(2)磁盘阵列基本均为单点,部分磁盘阵列为单控制器,部分应用服务器为单点,难以抵御失效的主机风险。大部分系统的本地恢复手段为手工方式,缺乏统一的数据备份平台及备份策略,部分备份数据保存在本地,缺乏恢复验证机制,将面临备份数据不一致,甚至不可用的风险。缺少容灾中心。
(3)东西区数据中心相对独立,但是之间的互联存在断联风险,在数据集中的现今亟待解决东西区系统整合,建立统一数据平台的问题。
(4)缺乏统一的基于信息系统全流程的监控系统,缺少详细的易于管理的配置变更管理系统。以至信息管理部门很难制订一套适合自身的资产管理系统和设备生命周期管理系统。
(5)对现有的数据管理不够精细化,甚至无法实现对所有信息系统历史数据的保存。缺少一个集存储、抽取、分析、统计、展现功能于一体的对结构化数据和非结构化数据进行统一管理的大数据平台。缺乏一套将业务数据和机器日志数据进行联动和可寻找关联关系的模型和方法论。
2.2机场的信息系统的运维数据
信息系统数据主要包括日志文件、报错信息、IT应用系统数据。其中日志文件主要包括各操作系统、数据库、应用软件的系统日志、事件日志。IT应用系统数据主要包括ITSM(IT系统管理系统)的变更管理、配置管理数据以及监控系统的服务器、存储、交换机的监控数据。
2.3 为什么要对机场IT运维数据进行分析
我们回顾一下机场信息系统运维管理的历史,早期的信息系统运维管理相当简单,运维基本都进行集中管理,即使部门也是按照业务系统来进行分界,譬如离港模块、航显模块,地面信息模块。每套信息系统从始至终作为功能完整的简单作业运行,很少与其他系统或者部门进行联动和交互。而现在的运维和业务则发生了很大变化,需求明显向着更复杂的业务关键型应用、复合式应用以及实时应用快速转变。同时系统之间的关联性也日益复杂,数据流纷繁复杂,譬如外网网站的航班信息数据需要从旅客自助平台传输过来,而旅客自助平台数据和航站楼广播系统的数据又是从航显系统得到。以上这种转变对业务各个方面都产生了影响,甚至用于访问这种新基础架构的技术也发生了根本性变化。这种现代化的运维环境有时更趋向“物联网”,包括各种移动设备以及先前并非互联互通的设备,而现在这些设备共同构成了机场运维的基础架构。所有这些要素都和物理基础架构有关,因此带来了额外的复杂性。另外在当今的市场条件下,业务系统是不允许宕机的,即使一个小的系统出现故障也可能导致其他一些关键生产业务发生意想不到的问题,同时系统运行缓慢或者崩溃对营业收入,公司业绩,客户满意度以及品牌信誉都有着直接的影响,具体到机场的业务,一套安检系统的应用服务器发生宕机,将直接导致机场的安检排队等候的旅客大量聚集,很容易造成群体性事件。同时还会导致大面积航班延误,造成机场的不安全事件。
为了对当今的设备及其复杂性有一个感性的认识,我们以首都机场数据中心为例,每天大概有10000个以上的机器事件被触发,产生大约200兆字节的相关运维数据,而如果包括业务数据,每天首都机场数据中心则会产生2G以上的数据。在这么大量的信息和事件中,隐藏着不少需要评估并解决的故障单。
另外目前机场的运维数据中超过50%的数据都是非结构化的。这些非结构化数据包含各种各样的数据类型,如航班信息、系统行为、应用性能、用户操作和视频音频等。大多数使用关系数据库或多维数据库的传统工具都没有能力应对目前的海量运维数据的复杂性和规模。这些工具也无法灵活地执行查询或获取答案。
2.4管理信息系统的日志
我们希望对于运维的实时和历史数据分析方面实现重大创新。采集大量结构化与半结构化的数据,通过分析机制将其改造成为可操作的数据,这首先要做到的就是日志的集中管理,包括系统中间件日志和应用日志,然后实现日志搜索和基于日志信息的统计分析以及日志数据归档和历史分析。接下来我们需要对运维日志进行数据分析即将客户应用系统中的交易流水、日志通过规则解析并完成索引,并通过设置查询规则来发现应用系统的问题,进行提前预警。
2.5如何对机场的运维数据进行分析
2.5.1 问题发展趋势分析
通过全维度的数据采集构建全样本数据仓库:以应用系统为主线,跨层面及维度的各类日志采集、归档、查询、分析、报警;7*24小时监控应用系统、中间件、Oracle数据库,及硬件产品的运行状态,同时可以生成完整的监控报告。通过统一的多维度报表展示故障时间、故障频次的全流程故障统计管理。通过模型构建分析并预测系统状态为管理提供决策依据:构建预测模型,提供预测分析并辅助运维管理者制定决策。
2.5.2 问题诊断分析
通过时间窗口和模式挖掘来检测潜在故障影响因子,挖掘历史相似问题加速问题解决。通过动态数据分析IT运维与业务数据规律与关联:采集网络报文、性能数据、报警消息、交易数据等动态数据采集,分析系统运维安全隐患、潜在故障、容量情况等,并对新上线的系统进行辅助测试。
性能问题快速精确定位。在应用系统碰到性能问题的时候,我们可以通过对代码级层面的深度钻取,并比照相应的知识库系统分辨性能问题由那条代码导致,从而快速精确定位系统性能问题与瓶颈。
性能趋势分析与潜在隐患排查。在我们的日常运维中,通过一定时间数据采集和积累,可以分析系统性能趋势,结合业务规划为升级或优化决策提供数据参考;同时根据业务发展,也能够获得整体应用系统在哪些层面可能成为瓶颈及是否存在系统隐患。
新应用上线前的性能辅助测试。我们首都机场新开发的应用系统上线前一般都会经历功能测试和性能测试以及压力测试,测试通过后才能正式上线。我们可以在性能测试过程中,将对新业务系统的测试结果以多维度抓取并展示,从另一个角度辅助测试系统性能。
2.5.3 实时预测分析
挖掘潜在导致重复问题出现的关联影响规则(比如相同类型的变更导致重复发生问题),提供预防性建议.用可视化的方法来展示过去曾发生的问题,并发现它们的共性:问题的症状,相关的服务器,中间件等,以及解决此类问题的专家信息。
2.5.4 系统生命周期规划预测分析
针对历史软硬件问题,提供优选升级策略及生命周期管理。利用时间序列分析方法来识别服务器负载的异常以及负载异常与应用故障的关联关系。通过对机场的ITSM系统的同类设备的事件管理日志历史数据进行不同时间段内的统计分析判断重要生产系统的硬件、系统是否达到了需要进行更换的地步。可以协助运维人员了解各应用系统的运维趋势,结合机场的业务发展和规划,将因系统即将到达生命周期而导致的宕机故障发生率减到最低。
2.5.5实现系统自主分析
随着全新自动化”基于分析”运维管理方案的发展,信息系统管理平台已经发生了巨大的变化。程序能够查看信息系统活动;学习信息系统行为模式;找到所采集的系统数据中的异常并基于分析运维数据时确定的模式和问题预测未来系统行为。其数据分析的速度比人为手工方式要快得多,从而加快了问题的解决,提高了准确性并且避免了更多的问题。通过运维大数据进行分析的运维管理方案见图1所示。
前几年运维管理者更专注于简化用户界面和集成管理组合,这提高了信息技术的管理效能,并且可以帮助降低数据中心的管理成本。但是现今的管理者更将注意力转向对运维分析数据进行自动分析上,以进一步减轻他们的工作量和人为失误,并且在运维问题发生之前进行预测。在此自动化分析工具产生之前,故障排除系统、存储、网络问题的负担一直落在以超负荷工作的信息系统管理员身上,这些专业人员必须制定系统性能指标和阀值,并且不得不使用时间监控工具并分析日志文件,才能解决问题。我们希望新的自动运维分析工具能够比人为操作更快的识别问题——从大型非结构化存储库中获得新的见解,通过对准相关结构化和非结构化数据,更快速地开始进行问题根源分析,从而帮助隔离问题;还能通过为管理员提供他们所需的信息使他们无需手动筛选大量日志文件和其他运维数据,从而有助于更快速地修复问题。信息系统管理员也可以从中腾出更多时间来关注价值更高的管理和调优工作。
3 对于运维大数据的分析使机场运维效能得到提升
3.1 日常故障管理分析和优化
我们从机场运维系统的故障发现和解决内容上看,对于故障的管理其实就是一次或者多次活动,因此我们对于单次的故障全流程绘制了活动图。
由图2可以看到我们运维部门在发现故障的时候
是极其被动的,在故障发生之后我们才能通过监控到的一些故障现象去发现问题,此时我们的应用系统很有可能已经受到了影响并导致业务中断。其次问题的处理过程较为复杂,具有明显的环节多、时间长、人力消耗大的特点。另外我们可以看到对于应用、数据库、操作系统、硬件和网络的故障定位是串行的,在实现故障定位之后,再进行日志收集和检查,并根据报错信息搜索厂商的知识库以及自己的经验进行故障处理。同时由于网络管理员、系统管理员、数据库管理员以及业务管理员各自负责不同的维护内容。各管理员职能相对孤立,只是将运维状态单向汇报给值班经理。也没有有效的途径使管理员之间进行问题修复的沟通。每个管理员只能掌握自己负责范围的运维状态,无法洞察到整体事件的运行状态,这对应急故障处理极其不利。同时随着机场业务体系的扩大,信息系统的规模呈几何级增长。在有限的时间里每个运维人员的工作量也随之增大。尤其是在一个系统管理员负责多个业务系统的时候,每天要负责的巡检、变更等运维工作纷繁复杂且重复性工作很多。
在对运维系统的大数据进行分析之后,故障的管理过程也得到了相应的优化,我们可以看到优化之后的故障管理活动图如图3。我们通过图3可以看到问题管理的整体过程在以下三个方面得到了提升。
3.1.1 故障发生前——预测
通过开放接口,我们利用运维大数据分析工具实时对所有机场负责的生产系统进行运维日志收集,将数据传送到应用程序,从而实现结构化和非结构化数据的实时读取。使用业界流行的流数据处理技术,无需对数据进行存储。经过系统仅捕获和分析异常的相关信息,(这意味着只会捕获相关数据并根据这些数据执行操作,因此在寻找异常时,宝贵的系统循环不浏览日志和其他数据源,这样还可以节省出存储空间)。通过比较一段时间的系统行为(分析时间序列数据)“学习”系统/应用程序行为模式。通过对比“好的”系统行为和“坏的”系统行为,在问题发生之前找出问题,为用户提供一个识别潜在问题并且在它们恶化之前修复这些问题的方法。
3.1.2 故障处理中——搜索
“搜索”可以被描述为采集大量模糊的非结构化数据并通过分析工具将其转化为洞察力,它具有以下5个作用。
(1)使用简单的查询语言在运维全日志数据中搜索,通过关联日志搜索结果与指标进行监控。
(2)基于从日志数据中发现到的趋势进行异常问题的检测和提醒。
(3)通过分析将性能问题进行隔离,通过搜索功能可搜索隔离问题的特定使用案例。
(4)使用拓扑结构和配置内容优化要搜索的知识库和已经发生的事件记录范围,从而找出问题的可能原因和问题关联和解决方案。
(5)搜索和分析ITSM(IT服务管理系统)中的服务工单或者对于工单内容的关键项进行统计、展示
3.1.3 故障解决后——优化
在问题解决之后,做事后诸葛亮,对问题进行总结、记录。自动对系统进行调优,调整系统资源分配和存储资源分配,并进行容量评估和工作负载和基础架构的最优化,从而大幅提高工作效率并降低人力成本。
4 结论
之前系统管理员确定系统故障和解决问题的时候,需要检查监控系统的报警日志和翻阅大量之前的故障案例和知识库中的相关文档才能确定异常,然后围绕可用性、响应时间等元素来分析系统性能,同时使用监控工具追踪问题,使用日志文件检查系统活动,并通过历史经验解决问题。而通过本文,我们希望借助对信息系统的运维大数据分析帮助用户预测可能的中断,并更快地搜索运维数据以便找到并解决问题,通过分析获得的洞察优化企业的IT和应用基础架构。我们的目标是从系统应用日志的监控方式对应用交易进行监控,实现更加符合系统管理者的用户习惯和更便捷有效的监控能力;提供实时的应用故障诊断辅助手段,快速解决问题;通过关键绩效指标的设计来反映应用及节点可用性和性能;并在问题产生之前提示应用维护人员采用措施阻止问题产生。这样首都机场的系统运维人员就能从重复性的运维工作中解脱出来,为机场减少不必要的人力和资源的浪费。
5【摘要】
本文介绍了运维大数据的概念、运维数据的特点以及运维数据的分析方法和机场业对运维大数据的需求。以首都机场信息系统运维现状为背景分析了如何通过对于运维大数据的预测、搜索、优化,为机场的信息系统运行维护管理提供更优化的方法、更便捷的流程、获得更多的洞察力,从而使机场信息系统的运行维护效率得到最大限度的提升。本文的目的是使IT运维人员认识到各种产生于我们日常信息系统的机器数据的重要性,并理解如何借助统一的大数据平台把不同类别、不同系统的运维数据收集、整合起来,通过统计和分析的方法,从杂乱无章的海量历史数据中精炼出对于运维人员更有价值的运维最佳实践。
上一篇:关于机场大数据平台构建的探索