利用大数据分析重新定义企业服务质量（PPT45页)

利用大数据分析重新定义企业服务质量杨振宇[e-mail]软件部技术顾问我们的数据从哪里来？我们要处理什么样的数据？我们要如何处理这些数据？基于大数据的企业服务管理之道案例分享议程：问题：除了他，任何人都必须用数据来说话！我们的数据从哪里来？©IBMCorporationIBMSoftwareGroup6End-userexperiencemonitoring—捕捉应用或服务的终端用户体验Runtimeapplicationarchitecturemodeling—发现应用所依赖的软硬件基础设施，以及它们之间在运行时的通信关系。User-definedtransactionflowmonitoring—对指定交易，在执行的过程中，穿越的各逻辑节点，所占用的资源和响应时间能够跟踪Applicationcomponentdeepdive—单一领域，基于应用环境上下文的的深入分析，和问题诊断ITOperationAnalytics（ITOA）—将数据整合、格式化、分类后，通过关联和智能分析来提供更准确的业务管理能力摘自:GARTNERG00263442（28May2014）数据的来源：企业业务管理的五个维度©IBMCorporationIBMSoftwareGroup…需要分析很多数据并结合业务拓扑，才能识别问题©2014IBMCorporation8很少有公司是真正以预防为主的大多数企业只是在业务中断时被动应对企业的信息孤岛，分离的工具，以及数据的复杂性及如此浩瀚，加大了诊断故障的难度系统宕机与变坏将造成数以百万计美元的损失，伤害品牌、客户印象及忠诚度管理层从严要求其团队：事先预防，而不是事后补救IT环境爆炸性增长的数据（日志通常包含了最准确、最真实的关键信息）•拥有5000台服务器的企业每天产生超过1.3TB的数据宕机成本超过以往任何时候•关键性业务的宕机会给企业造成每小时数以百万计美元的损失：券商~$5-7百万/每小时，信用卡机构~$2-3百万/每小时，移动业务服务提供商~$66万/每小时，民航代理~$9万/每小时。相对于迅猛增长的要求而言，IT员工的水平则在下滑或没有起色预防性管理的时代已经到来©2014IBMCorporation9运维团队做不到预防性管理的主要障碍如果在宕机前没有预先诊断的话，运维团队则只能被动应对，眼睁睁看着宕机恶果蔓延有如烧钱一般...•海量数据，无法进行人工分析•现行分析技术如标准阈值分析法，无法实现预防目的•无法诊断到正在发生的问题（在造成业务损失之前）•阈值要么定得太高，在完全宕机之前没有足够的警告•阈值要么定得太低，噪音太多，所有一切都忽略掉了©2014IBMCorporation10传统业务管理与基于IT运维分析(ITOA)进行业务管理的区别状态考察客户业务系统的应用日志包含准确、详细的交易信息，真实、全面的体现了用户业务系统的状态望闻问切将非结构化的业务系统的应用日志，通过大数据技术进行高效收集、格式化、索引、分析，将业务系统的应用性能状态准确、及时的体现出来，并结合认知技术、逻辑算法，实现故障的提前预警静态研究需要了解被管理业务的逻辑拓扑，建立业务模型通过监控工具获得性能数据，获得KPI数据，更有效的性能管理需要结合动态性能基线来判断业务偏离先进仪器借助于各种先进的仪器，目的是弄清病因、发现病灶，找准病位：资源监控、模拟交易、用户真实交易体验等管理工具基于ITOA方案传统方案©2014IBMCorporation11我们要处理什么样的数据？IT运维是一种典型大数据挑战•典型的大型企业:5000服务器+网络+存储+中间件，每天产生大约1.3TB的可用性和性能管理数据•跨国公司及服务提供商则拥有超过20,000服务器,…每天产生大约4.5TB数据•Web及移动应用所要求的研发与敏捷开发，产生的数据量则大到难以统计•APM文摘2013：75%的高级IT总监对传统的管理方式感到不满意,30%表示他们无法预测潜在的宕机威胁智慧的基础设施带来大数据的机遇•典型的企业产生数以万计的工单和服务申请来管理他们核心的资产–约每天1TB非结构化数据•智能的网络资产自身就会产生大量数据:电源,温度,流量…•用户需要提供对资产性能,可用性及成本管理的洞察和趋势运维管理的需求与焦点转向敏捷与简洁可用性?性能?容量?使用率?构成?运维和业务线需要洞察…©2014IBMCorporation13•服务请求•故障通知单•社交媒体•库存与资产•用户文档与技术文档运维大数据的来源：包括结构化、非结构化数据搜索预测优化…取得洞察力…基于洞察力…提供洞察力•网络流量与事务处理•日志文件•警告/报警与事件•性能指标•核心文件与内存痕迹•配置文件©2014IBMCorporation14我们要如何处理这些数据？©2014IBMCorporation15应用性能管理（APM）事件管理Applications|Systems|Workloads|Wireless|Network|Voice|Security|Mainframe|Storage|Assets业务成果能力IBM大数据平台IBM或者第三方解决方案运维环境系统&日志监控OptimizeIT应用基础架构优化Search在海量的数据中进行快速搜索快速解决问题Predict问题发生之前进行预测主动规避宕机性能优化RaveSPSSInfoSphereBigInsightsWatsonStreamsCloudInsightsIBMSmartCloudAnalyticsIBM持续对分析领域进行投资，并在此基础上构建运维分析能力©2014IBMCorporation16使用全自动的学习算法来定义什么是“正常”。然后采用对现有条件的实时评估来预测和尽早发现异常，避免对业务产生实际影响。挑战:被动的对性能瓶颈进行反应是不够的–为了保证重要的业务系统24X7小时可用,必须在问题产生影响之前通过预测来进行规避预测©2014IBMCorporation17适应未来发展方案灵捷，支持动态的基础设施如云计算，变化不断支持异构方案灵活，易于支持多平台及多厂商的性能管理方案利用现有投资不用推倒重来或替换，利用好现有性能管理方案预测性解决方案的理想特征©2014IBMCorporation18SmartCloudAnalytics–PredictiveInsights提供预测分析和自学习为检测和避免服务中断，进行实时的分析采用先进的沃森多变量和单变量分析算法.关联跨多个域和异构数据源的指标©2014IBMCorporation19PredictiveInsights观察行为•单个KPI分析•对每个KPI学习其历史的行为•当KPI偏离其历史的行为时，认为是异常•多KPI分析•识别KPI之间的关系，并按照统计分析所了解的模式进行分组•了解正常的行为模式，并在识别到行为模式与正常的行为相异时，发送警告©CopyrightIBMCorporation2014©2014IBMCorporation20PredictiveInsights观察因果关系•使用统计的方法最可能确定哪些KPI有因果关系•识别大量的数据中，KPI之间的因果关系，并使用他们建立预测模型，并使用这些模型来持续的探测，预测和进行异常分析•基于GrangerCausalityTest（格兰杰因果关系检验）的方法进行实现•由诺贝尔奖获得者，经济学家CliveGranger提出•使用统计的测试来确定因果关系•对大量的时间序列的数据进行分析，发现存在于这些数据中的因果关系©2014IBMCorporation21观察KPI数据的模式•PredictiveInsights可以识别时间序列数据的模式•使用算法来确定数据是否是季节性的•PredictiveInsights观察数据每周的模式•Webservers在周一和周五会比较繁忙•对每个KPI进行自动的分析•KPI可以在季节性和非季节性中切换©2014IBMCorporation22异常显示(单个KPI)与异常行为相关的指标会被绘制成图形绿色的区域是正常的行为基线异常的区域以红色文字描述异常的行为©2014IBMCorporation23异常显示(多个KPI关系)自动绘制所有的关联指标数据异常领域红色显示文字描述异常的行为针对大量的时间序列数据，找出其中关键的因果关系并为时间序列数据建立预测模型利用该模型进行异常诊断和预测Application#2availabilityServer3NoofProcessorsServer#1AlertsServer#2MemoryFreeServer#1OutPacketsApplication#1availabilityTradevolume时间序列数据Granger因果逻辑算法因果/统计模型多KPI分析(Granger因果逻辑算法)对于KPI异常偏离的检测NetworkPerformanceServerMonitoringMiddlewareMonitoringApplicationMonitoringCustomerExperienceStorageMonitoringPacketsReceivedErrors20PingResponseTime100msCountdowntoServiceImpactSwap_Space_UsedMainframeMonitoringGC_Rate20MB/sTransactionResponseTime5secsCPUUsed90%JVMMemoryUsed10TotalTransactionLocksTotalCriticalAlertsFailed_RequestsAvgMQRespTimeAverageTransmitKB/SecCPU_usedContext_Switches/SecSwap_Space_UsedPage_Faults_per_secJVM_Memory_UsedMethod_Average_Response_TimeGC_RatePingresponsetimePacketsReceivedErrors%_Total_Privileged_Time%_Total_Processor_Time%_Total_User_TimeContext_Switches/SecFile_Control_Operations/SecFile_Data_Operations/SecFile_Read_Operations/SecFile_Write_Operations/SecProcessor_Queue_LengthSystem_Calls/SecProcessor_Queue_Length_ExcessFile_Control_Bytes/Sec_64File_Read_Bytes/Sec_64File_Write_Bytes/Sec_64Total_Wait_TimeConnection_RateQuery_RateAverage_Query_Processing_TimeAverage_Processing_TimePercent_FailedPercent_Slow,Percent_GoodPercent_AvailableAverage_Response_TimeFailed_RequestsTotal_RequestsSlow_RequestsGood_Requests需要花费很多时间来响应故障缩短MTTR提升运营效率如果没有针对故障的“提前感知”能力，运维团队只能被动响应故障，令企业遭受业务上的损失…基于认知技术对于关键业务系统异常进行预警的典型业务场景TX00101.RespTimeTX00108.TxCountTX00345.RespTimeTX00086.RespTimeTX00221.RespTimeTX00004.RespTimeTX00189.TxCountTX00143.FailRateTX00101.C