利用大数据分析重新定义企业服务质量（ppt45页)
利用大数据分析 重新定义企业服务质量,杨振宇 yangzy 软件部技术顾问,我们的数据从哪里来？ 我们要处理什么样的数据？ 我们要如何处理这些数据？ 基于大数据的企业服务管理之道 案例分享,议程：,问题：除了他，任何人都必须用数据来说话！,我们的数据从哪里来？,6,End-user experience monitoring 捕捉应用或服务的终端用户体验 Runtime application architecture modeling 发现应用所依赖的软硬件基础设施，以及它们之间在运行时的通信关系。 User-defined transaction flow monitoring 对指定交易，在执行的过程中，穿越的各逻辑节点，所占用的资源和响应时间能够跟踪 Application component deep dive 单一领域，基于应用环境上下文的的深入分析，和问题诊断 IT Operation Analytics（ITOA） 将数据整合、格式化、分类后，通过关联和智能分析来提供更准确的业务管理能力,摘自: GARTNER G00263442 （28 May 2014）,数据的来源：企业业务管理的五个维度,需要分析很多数据并结合业务拓扑，才能识别问题,很少有公司是真正以预防为主的 大多数企业只是在业务中断时被动应对 企业的信息孤岛，分离的工具，以及数据的复杂性及如此浩瀚，加大了诊断故障的难度 系统宕机与变坏将造成数以百万计美元的损失，伤害品牌、客户印象及忠诚度 管理层从严要求其团队：事先预防，而不是事后补救,IT环境爆炸性增长的数据（日志通常包含了最准确、最真实的关键信息） 拥有5000台服务器的企业每天产生超过1.3 TB 的数据 宕机成本超过以往任何时候 关键性业务的宕机会给企业造成每小时数以百万计美元的损失：券商 $5-7百万/每小时，信用卡机构 $2-3百万/每小时，移动业务服务提供商 $66万/每小时，民航代理 $9万/每小时。 相对于迅猛增长的要求而言，IT员工的水平则在下滑或没有起色,预防性管理的时代已经到来,运维团队做不到预防性管理的主要障碍,如果在宕机前没有“预先诊断“的话，运维团队则只能被动应对，眼睁睁 看着宕机恶果蔓延有如烧钱一般.,海量数据，无法进行人工分析 现行分析技术如标准阈值分析法，无法实现预防目的 无法诊断到正在发生的问题（在造成业务损失之前） 阈值要么定得太高，在完全宕机之前没有足够的警告 阈值要么定得太低，噪音太多，所有一切都忽略掉了,传统业务管理与基于IT运维分析(ITOA)进行业务管理的区别,状态考察 客户业务系统的应用日志包含准确、详细的交易信息，真实、全面的体现了用户业务系统的状态 望闻问切 将非结构化的业务系统的应用日志，通过大数据技术进行高效收集、格式化、索引、分析，将业务系统的应用性能状态准确、及时的体现出来，并结合认知技术、逻辑算法，实现故障的提前预警,静态研究 需要了解被管理业务的逻辑拓扑，建立业务模型 通过监控工具获得性能数据，获得KPI数据，更有效的性能管理需要结合动态性能基线来判断业务偏离 先进仪器 借助于各种先进的仪器，目的是弄清病因、发现病灶，找准病位： 资源监控、模拟交易、用户真实交易体验等管理工具,基于ITOA 方案,传统方案,我们要处理 什么样的数据？,IT运维是一种典型大数据挑战 典型的大型企业: 5000 服务器 + 网络 + 存储 + 中间件，每天产生大约1.3 TB 的可用性和性能管理数据 跨国公司及服务提供商则拥有超过20,000服务器, 每天产生大约4.5 TB数据 Web及移动应用所要求的研发与敏捷开发，产生的数据量则大到难以统计 APM文摘2013： 75%的高级IT总监对传统的管理方式感到不满意, 30%表示他们无法预测潜在的宕机威胁,智慧的基础设施带来大数据的机遇 典型的企业产生数以万计的工单和服务申请 来管理他们核心的资产 约每天 1 TB非结构化数据 智能的网络资产自身就会产生大量数据: 电源, 温度, 流量 用户需要提供对资产性能, 可用性及成本管理的洞察和趋势,运维管理的需求与焦点转向敏捷与简洁,可用性?,性能?,容量?,使用率?,构成?,运维和业务线需要洞察 ,服务请求 故障通知单 社交媒体,库存与资产 用户文档与技术文档,运维大数据的来源：包括结构化、非结构化数据,搜索,预测,优化,取得洞察力, 基于洞察力, 提供洞察力,网络流量与事务处理 日志文件 警告/报警与事件 性能指标 核心文件与内存痕迹 配置文件,我们要如何处理 这些数据？,应用性能管理（APM）,事件管理,Applications | Systems | Workloads | Wireless | Network | Voice | Security | Mainframe | Storage | Assets,业务成果,能力,IBM 大数据平台,IBM 或者第三方 解决方案,运维环境,系统 & 日志监控,Optimize,IT应用基础架构优化,性能优化,IBM SmartCloud Analytics,IBM持续对分析领域进行投资，并在此基础上构建运维分析能力,挑战: 被动的对性能瓶颈进行反应是不够的 为了保证重要的业务系统24X7小时可用, 必须在问题产生影响之前通过预测来进行规避,预测,适应未来发展 方案灵捷，支持动态的基础设施如云计算，变化不断,支持异构 方案灵活，易于支持多平台及多厂商的性能管理方案,利用现有投资 不用推倒重来或替换，利用好现有性能管理方案,预测性解决方案的理想特征,SmartCloud Analytics Predictive Insights 提供预测分析和自学习,为检测和避免服务中断，进行实时的分析 采用先进的沃森多变量和单变量分析算法. 关联跨多个域和异构数据源的指标,Predictive Insights 观察行为,单个 KPI 分析 对每个KPI学习其历史的行为 当KPI偏离其历史的行为时，认为是异常 多 KPI 分析 识别KPI之间的关系，并按照统计分析所了解的模式进行分组 了解正常的行为模式，并在识别到行为模式与正常的行为相异时，发送警告, Copyright IBM Corporation 2014,Predictive Insights 观察因果关系,使用统计的方法最可能确定哪些KPI有因果关系 识别大量的数据中，KPI之间的因果关系，并使用他们建立预测模型，并使用这些模型来持续的探测，预测和进行异常分析 基于 Granger Causality Test （格兰杰因果关系检验）的方法进行实现 由诺贝尔奖获得者，经济学家Clive Granger提出 使用统计的测试来确定因果关系 对大量的时间序列的数据进行分析，发现存在于这些数据中的因果关系,观察KPI数据的模式,Predictive Insights 可以识别时间序列数据的模式 使用算法来确定数据是否是季节性的 Predictive Insights 观察数据每周的模式 Web servers在周一和周五会比较繁忙 对每个KPI进行自动的分析 KPI可以在季节性和非季节性中切换,异常显示(单个 KPI),与异常行为相关的指标会被绘制成图形,绿色的区域是正常 的行为基线,异常的区域 以红色,文字描述异常的行为,异常显示(多个KPI关系),自动绘制所有的关联 指标数据,异常领域 红色显示,文字描述异常的行为,针对大量的时间序列数据，找出其中关键的因果关系并为时间序列数据建立预测模型 利用该模型进行异常诊断和预测,Application#2 availability,Server 3 No of Processors,Server#1 Alerts,Server#2 Memory Free,Server#1 Out Packets,Application#1 availability,Trade volume,时间序列数据,Granger因果逻辑算法,因果/统计模型,多KPI分析 (Granger 因果逻辑算法),对于KPI异常偏离的检测,Network Performance,Storage Monitoring,Packets Received Errors 20,Ping Response Time 100ms,Countdown to Service Impact,Swap_Space_Used,Mainframe Monitoring,GC_Rate 20MB/s,Transaction Response Time 5 secs,CPU Used 90%,JVM Memory Used 10,Total Transaction Locks Total Critical Alerts Failed_Requests Avg MQ Resp Time Average Transmit KB/Sec CPU_used Context_Switches/Sec Swap_Space_Used Page_Faults_per_sec JVM_Memory_Used,Method_Average_Response_Time GC_Rate Ping response time Packets Received Errors %_Total_Privileged_Time %_Total_Processor_Time %_Total_User_Time Context_Switches/Sec File_Control_Operations/Sec File_Data_Operations/Sec,File_Read_Operations/Sec File_Write_Operations/Sec Processor_Queue_Length System_Calls/Sec Processor_Queue_Length_Excess File_Control_Bytes/Sec_64 File_Read_Bytes/Sec_64 File_Write_Bytes/Sec_64 Total_Wait_Time Connection_Rate,Query_Rate Average_Query_Processing_Time Average_Processing_Time Percent_Failed Percent_Slow,Percent_Good Percent_Available Average_Response_Time Failed_Requests Total_RequestsSlow_Requests Good_Requests,需要花费很多时间来响应故障 缩短MTTR 提升运营效率,如果没有针对故障的“提前感知”能力，运维团队只能被动响应故障，令企业遭受业务上的损失,基于认知技术对于关键业务系统异常进行预警的典型业务场景,TX00101.RespTime,TX00108.TxCount,TX00345.RespTime,TX00086.RespTime,TX00221.RespTime,TX00004.RespTime,TX00189.TxCount,TX00143.FailRate,TX00101.Count,TX00004.TxCount,TX00350.TxCount,TX00078.RespTime,Busy Ratio,TX00200.FailRate,en01.InByte,en01.OutByte,hdisk001.read,hdisk002.write,hdisk001.write,db-A.db2lockCount,db-A.bufferpoolHitRatio,db-A.sortOverflow,sub-X.RespTime,sub-R.RespTim
