2020年全球运维大会 全球最大呼叫平台监控实践课件.pptx

上传人:牧羊曲112 文档编号:1573864 上传时间:2022-12-07 格式:PPTX 页数:35 大小:3.08MB
返回 下载 相关 举报
2020年全球运维大会 全球最大呼叫平台监控实践课件.pptx_第1页
第1页 / 共35页
2020年全球运维大会 全球最大呼叫平台监控实践课件.pptx_第2页
第2页 / 共35页
2020年全球运维大会 全球最大呼叫平台监控实践课件.pptx_第3页
第3页 / 共35页
2020年全球运维大会 全球最大呼叫平台监控实践课件.pptx_第4页
第4页 / 共35页
2020年全球运维大会 全球最大呼叫平台监控实践课件.pptx_第5页
第5页 / 共35页
点击查看更多>>
资源描述

《2020年全球运维大会 全球最大呼叫平台监控实践课件.pptx》由会员分享,可在线阅读,更多相关《2020年全球运维大会 全球最大呼叫平台监控实践课件.pptx(35页珍藏版)》请在三一办公上搜索。

1、全球最大呼叫平台监控实践之路,目录,背景-全国集中维护、全球最大,1,出路-选择开源,2,转型-几个问题,3,蜕变-AIOPS在监控报警方面的尝试,4,中移在线公司,移动全网集中服务 提供者,移动全网业务,后台集中处理者,移动全网渠道运营 集中支撑者,2014,31省呼叫业务完 成划转奠定全网集中化 运营基础,2016,实现盈利业务发展和改革 创新初见成效,全集团首批入选国 资委国企改革“双 百行动”三家公司 之一,20182017,10月注册成立全集团集中化、专 业化运营试验田,发展历程,传统呼叫中心,传统呼叫中心是基于PBX、专用硬件排队机、硬件语音板卡等专用设备组成的客服系统。,软硬一体

2、,不够灵活建设成本高、周期长、维护升级困难无法满足多渠道多媒体互联网相 关增值业务的融合无法实现多客服中心坐席跨网协 同无法快速响应业务需求,缺点,排队机,CTI,IVR,应用,PSTN/ PLMN,PBX,坐席,坐席,新形态呼叫中心,语音坐席,视频坐席,互联网坐席,热 线,互 联 网,新形态下的呼叫中心,质量管控,大数据平台,支持客户 全渠道交 互,智能 质检,智能导航,智能应答,转人工,智能知识库,坐席助手,语音 客服,视频 客服,在线 客服,智能IVR,智能 运营运营管理,呼叫平台,统一排队 统一路由 统一监控,纯软件:全媒体CTI、IVR、互联 网接入网关、软交换、中继网关、媒体加速服

3、务、用户终端富媒体:支持传统语音、文本、 图片、视频、短语音、微信、微 博智能化:与人工智能(AI)、大 数据技术结合,应用于IVR、机 器人应答、质检、外呼等集中化:接续、CRM、分析、质 检、话务监控等集中化,特征,在线公司: 全球最大呼叫中心,河南,江苏,北京,我们面临的运维挑战,多,难,高,用户多, IT规模接近一线互联网企业9亿 用户, 超1亿微信粉丝,月服务超亿次,微博矩阵粉丝3038万(居行 业首位),10086APP超五千万用户 量20000+服务器50000+Tomcat,业务变化快,运维环境复杂支撑全国营销活动,总部/分公司/省公司多级协同日均上线 17 次,日处理 206

4、 例工单技术新:微服务/云计算/容器 ,要求高,提供电信级服务99.99% 的可靠性15秒接通要求7*24 小时保障,转变运维思路,适应新的时代挑战,为了支持业务快速上线和高效运维。在线公司监控系统需具备敏捷、集中、自动、智能的关键能力。,自动,敏捷,之 前,能力建设,智能,现 在,监控能力周粒度提供,监控能力分钟级提供,按专业划分的 “烟囱式监控”,混合集中化监控,手工添加,基于策略的自动化闭环,依赖专家经验,基于AI和大数据的自动识别,集中,目录,1,2,3,4,背景-全国集中维护、全球最大,出路-选择开源,转型-几个问题,蜕变-AIOPS在监控报警方面的尝试,统一监控平台:开源工具+二次

5、开发,自主核心可控,监控管理,Grafana,统一门户,ITSM运维平台,自动化平台,CMDB,统一告警平台,统一事件分析告警,告警接口,性能看板,告 警,事件管理,短信,邮件,工单信息,故障定位或 修复场景,业务看板,根因分析,业务建模,业务模型和配置数据,被管环境,应用 系统,客服系统监控(I2000),应用性能监控(APM),告警信息,场景执行调用,性能看板,业务看板,业务数据,Prometheus,metric,ElasticSearch,数据库,数据库监控(Prometheus),基础架构监控(Zabbix),CTI/UAP系统,服务器、网络、存储、虚拟 化环境等,告警看板,Kafk

6、a,实时融合监控:引入业界开源工具, 进行二次开发与封装, 形成核心自主可控、 稳定高效、海量秒级 的监控能力。跨域/跨厂商/跨层的 IT/CT实时融合监控。 有丰富的管理对象。多样灵活的数据展现形式,可以灵活配置, 适应不同场景,快速 定制。,监控数据,统一监控平台:集中建设、统一管控、边缘节点标准化,为了更快速的建立监控能力、更全面的管控系统质量,在线服务公司统一监控平台采用了总部集中建设、统一管控,分公司标准化接入的建设模式。,全网集中:总部负责监控能力建设、 边缘节点的标准化,所有 监控数据的上收、分析、 展现与通知。分公司提供资源,遵照标 准化、封装后的监控模板 进行监控资源的维护与

7、管 理。,一些小总结:半年时间,一些小总结:广泛、丰富、多样、灵活,网络设备类型与厂家,存活/丢包/ 时延,CPU/内存占 用率,snmp状态,温度,端口状态,出/入口带宽 利用率,出/入口丢、 错包,接口类型,设备状态网卡状态设备信息,端口描述,软件版本,系统名称,光功率,光模块接收 功率,网络协议,光模块发送BGP对等体功率连接状态,ospf邻居 状态,vrrp虚拟 路由状态,网络监控指标,SNMP,一些小总结:广泛、丰富、多样、灵活,一些小总结:广泛、丰富、多样、灵活,看板可灵活制定,分钟级完成配置。图表多样化展现:折线图、柱状图、饼图、区域图、拓扑图等。,主机参数内核参数 TCP协议栈

8、参数信号量/IO(Zabbix启动失败不释放信号集),数据库CPU/内存/IO 连接(最大连接数、超时时长)数据一致性 强烈建议采用数据库SSD硬盘,WEBNginx参数 Php参数php.ini:max_input_vars(影响模板应用大批量主机失败),Zabbix视具体需求配置启动模块和进程数禁用自动发现,采用脚本调用api实现禁用housekeeper,启用数据库表分区 禁用server直连agent配置参数优化defines.inc.php:QUEUE_DETAIL_ITEM_COUNT(定义监控项队列检索限制,影响消息队列积压显示),一些小总结:zabbix系统优化,一些小总结:z

9、abbix系统优化,二、Preprocessing manager 负荷长期为100%,三、Zabbix server主机反复重启,却无法启动成功,问题现象与影响一、大量消息队列积压(超过20万),且呈现雪崩效应,问题定位与解决方案一、zabbix官网对于pre-process耗尽的说明:,二、解决方案:,1、在zabbix server所在主机再单独部署一个proxy节点。2、将之前由zabbix server直接监控的所有proxy所在主机的 agent节点,全部转到新增proxy管理。3、降低server的pollers、java pollers、pingers、trappers等 进程

10、数配置。4、增加zabbix server的自监控项配置项及告警( Pre-process 进程占用率及zabbix_server.log的异常关键字告警)。,Zabbix配置的同步机制,Zabbix的配置表比较多,大容量局点关联查询sql耗时很长,如数据库控制sql执行时间的max_execution_time配置不合理,会导致无法将 相应配置表数据同步到zabbix server以及proxy的cache,从而导致出现大量 监控项无法正常采集及消息队列积压现象。以下为zabbix_server.log相应日志:,数据库sql执行超时配置建议根据现网的数据库IO处理性能以及局点规模合理配置数

11、据库超时相关参数,将max_execution_time设置为超过目前zabbix server同步配置sql执行时长的2倍以上,并定期检查zabbix_server.log日志的相应执行时长,或者增加自监控告警。,一些小总结:zabbix系统优化,目录,1,2,3,4,背景-全国集中维护、全球最大,出路-选择开源,转型-几个问题,蜕变-AIOPS在监控告警方面的尝试,问题一:200w监控指标,业务出了问题仍然不知道,治理 范围,应用系统管理,业务质量管理,客户体验管理,能 力 扩 展,基础设施管理,基础设施性能管理(PM) 基础设施故障管理(FM),用户问题管理 用户感知管理业务问题管理 业

12、务质量管理,以业务质量和客户体验为核心,以可管控、可视化、可度量为目标。全网集中建设、集中管控、边缘节点标准化接入。软件监控+硬件监控一网打尽,运维数据统一、融合、流动,建立多层次度量体系。以用户体验出发,建立端到端全链路监控,告警+投诉预警+客服联动形成完整闭环管理。运维保障,应用性能管理(PM) 应用故障管理(FM),流 程 及 自 动 化 管 理,业务及应用质量可感知,是监控的核心,Ser ver,OS,DB,JVM,MQ,WEB,面向基础架构的监控 只能发现约30%的问题,从用户体验出发面向应用 的监控能发现约70%的问题,最终用户体验,应用程序,基础架构,梳理业务系统 核心功能模块,

13、梳理功能模块的 核心监控指标,评审监控指标的提取 方式及有效性,监控看板 制作,在强化基础设置监控的基础上,补充应用性能监控和业务质量监控能力,保障业务的稳定性和客户感知。应用性能监控业务质量监控,参考Google SRE五项黄金指标1:速率:请求速率,请每秒请求数量。2:错误: 错误率,即每秒错误数量。3:延迟: 响应时间,包括队列/ 等待时间,以毫秒为单位。4:饱和度:即过载程度,指标与资源利用率相关,也可通过队列深度进行 直接衡量。5:利用率: 资源或系统的繁忙程度,通常表示为 0% 至 100%。,应用性能监控将前台页面与后端服务以及用户网络环境真正串联,做到端到端 全链路、代码级监控

14、。用户体验评分 前端交互体验网络切片应用调用拓扑 代码定位追踪,问题二:海量的日志是否有利用价值?对于亚健康状态,异常日志比系统故障更早出现。由于海量日志存储在海量网元中,不同厂商日志标准不统一且可读性差,往往 很难鉴别真正触发异常的日志。,挑战,海量日志保存在海量网 元中,缺乏统一视图,不同厂商设备的日志缺 乏统一标准,可读性差,XXXX%#&(*( ¥%*XXXX#$%&*(%#$%C XXXX!#$*#$!%$*(*( XXXXERROR*&%$#$*()*,日志统一采集,统一呈现, 异厂商设备日志统一查询,针对异常日志进行统计,实 时推送异常日志告警,提升 亚健康网络问题定位效率,跨厂

15、商设备日志统一查询,异常日志统计,异常日志分析与告警推送,统一日志分析,Syslog网络设备( Huawei, HP, IBM,),Logstash,一体化 客服系统,精准扶贫,实名制语音管控,价值,Cloud OS,问题三:一个业务监控需要添加2480万个监控项?,监控 内容,接口平台类型( 4):接入接口,接入渠道,转接接口,转接渠道系统编码(31):为各省分公司的编码监控项类型(8):调用总数,成功率,平均耗时,失败率,失败数,大于1s比率,大于3s比率,大于5s比率监控项名称(500+):从业务数据库实时查询监控项名称错误码(50+):业务指标的错误码类型(4*31*8*500*50=

16、2480万),监控项类型大:千万级监控项组合,zabbix方案暂无法实现(包括监控配置和展示)图形展示筛选条件要求可配置,动态关联:zabbix解决方案暂无法实现(个性化tag无法关联查询)。,难点 说明,解决 方案,利用prometheus灵活的自定义babel功能实现数据采集和动态图形展示,监控平台架构的改进与优化,管控资源 对象,运维数据 分析平台,上层 运维场景应用,CMDB数据库企业资源数据,监控底层 能力平台,Prometheus,APM,Hadoop离线数据分析运维数据分析,内部用户,物理设 备,云平台网络,一体化客服业务 监控客服设备监控,。,容量管理,自动化扩缩容,。,故障决

17、策系统,自动化切换,。,Zabbix,外部客户,日志容器云 业务监控 数据库应用中间件,日志平台,规则 数据机器学习数据,Flink实时数据处理运维数据分析,大型互联网公司基础资源多,业务广,线上变更频繁,监 控配置任务量大监控添加不是一蹴而就,需要反复调整,重复工作量大开源工具使用门槛高,大多没有好用的web界面,需要培 训才能灵活使用中移在线公司业务/工作人员遍布全国各省,基础资源达到 上万级别,业务变更频繁,统一管理难度系数高,痛点,应对方案,1,2,监控能力标准化、流 程化、模块化,二次开发、 3,自动化,配置界面化数据展示界面化,问题四:加不完的监控需求?,中移在线监控的历程(摸着石

18、头过河),1,需求分析 与功能验 证,2,3,全网推广性能调优典型问题与,4,软件bug处 理规范化制,定与整改5,运维界面 化与自动 化,欲速则不达 没有规范化 的交付,质 量无法保证,返工意味着效 率降低3倍以 上,1,2,需求分析 与功能验 证标准与规,范制定3,性能调优典型问题与软 件bug处理,4,批量推广,5,运维界面 化与自动 化,建议流程(标准先行,质量与效率并重),模板、主机 群组、主机 名,主机显 示名、动作 名称、展板 内容等等,需求交付/变更 流程,问题处 理流程,例行 会议与周报,一点感悟,现在的数字,2.4 万主机,99 万触发器,1.3K动作,614 万监控项,1

19、98 万,报警,Proxy,92,800+975DashBoard用户数,目录,1,2,3,4,背景-全国集中维护、全球最大,出路-选择开源,转型-几个问题,蜕变-AIOPS在监控告警方面的尝试,当前的主要矛盾是:海量的告警和有限的专家,告警要“少而精”, 不要重复和误报,监控要“多而全”, 一个问题都不能放过!,614万+ 监控指标,99万+ 报警阈值, 198万+ 告警/天, 2000+ 短信/每人每天,运维主管,工程师小明,VS.,经过分析,阈值正确设定是平衡“多而全”和“少而精”的关键手段之一,告警,正常告警,误报,漏报,缺少压缩&关 联,阈值不合理:80%监控能力不足:10%人员配置

20、失误:10%,无法设定阈值:70%无监控:30%,阈值设定从依靠专家经验向智能动态设定演进,专家依靠 经验设定规则阈值,通过大数据 分析设定固定阈值,通过智能分析 动态设定智能动态阈值,基于结构化的时序数据,通过AI预测拟合曲线,进行异常检测,历史数据分析历史数据读取和清洗数据抽取ETL断点修复数据间隔调整自相关性分析,毛刺检测统计异常检测,用于过滤毛刺型异常Moving Average移动平均滤波 (ARIMA)Exponential Smoothing指数平 滑滤波 (Holt-Winters)N*sigma统计检测,指标预测LSTM(长短期记忆) 预测算法孤立森林(Isolation F

21、orest)日同比(Day over Day method) 箱线图(Box-whisker plot),异常判定途径一:N-sigma方差 途径二:专家标记,智能化运维并不是我们想象的那样遥不可及,告警覆盖率 提升到95%,告警配置人 力下降60%,告警准确率 提升到80%,数据,算法,计算,海量数据源(性能指标、 日志、告警),可以迭代预测、迭代标 注,TensorFlow等成熟算法库针对不同场景,可选择不 同算法,如LSTM用于趋势 预测、ARIMA用于回归过 滤异常,轻量化虚拟机部署,4C32G 即可起步,未来,让智能化在更多运维领 域落地开花,智能故障发现,日志异常检测、 告警压缩&关联、 告警规则生成、容量管理、性能管理等,深度,广度,系统架构师、运维开发、应用运维、数据库运维、大数据运维、数据分析、容器云开发、 云计算开发、JAVA开发,享受互联网 般技术挑战,国企稳定待遇,郑州、北京、 上海、深圳研 发中心,31 省会城市,与客户交互产 生的海量数据,包括语音、 文本、图像等 数据,公司年轻、人 员年轻、扁平 化管理,谢谢,

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 生活休闲 > 在线阅读


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号