2020年全球运维大会 全球最大呼叫平台监控实践课件.pptx
全球最大呼叫平台监控实践之路,目录,背景-全国集中维护、全球最大,1,出路-选择开源,2,转型-几个问题,3,蜕变-AIOPS在监控报警方面的尝试,4,中移在线公司,移动全网集中服务 提供者,移动全网业务,后台集中处理者,移动全网渠道运营 集中支撑者,2014,31省呼叫业务完 成划转奠定全网集中化 运营基础,2016,实现盈利业务发展和改革 创新初见成效,全集团首批入选国 资委国企改革“双 百行动”三家公司 之一,20182017,10月注册成立全集团集中化、专 业化运营试验田,发展历程,传统呼叫中心,传统呼叫中心是基于PBX、专用硬件排队机、硬件语音板卡等专用设备组成的客服系统。,软硬一体，不够灵活建设成本高、周期长、维护升级困难无法满足多渠道多媒体互联网相 关增值业务的融合无法实现多客服中心坐席跨网协 同无法快速响应业务需求,缺点,排队机,CTI,IVR,应用,PSTN/ PLMN,PBX,坐席,坐席,新形态呼叫中心,语音坐席,视频坐席,互联网坐席,热 线,互 联 网,新形态下的呼叫中心,质量管控,大数据平台,支持客户 全渠道交 互,智能 质检,智能导航,智能应答,转人工,智能知识库,坐席助手,语音 客服,视频 客服,在线 客服,智能IVR,智能 运营运营管理,呼叫平台,统一排队 统一路由 统一监控,纯软件：全媒体CTI、IVR、互联 网接入网关、软交换、中继网关、媒体加速服务、用户终端富媒体：支持传统语音、文本、 图片、视频、短语音、微信、微 博智能化：与人工智能（AI）、大 数据技术结合，应用于IVR、机 器人应答、质检、外呼等集中化：接续、CRM、分析、质 检、话务监控等集中化,特征,在线公司: 全球最大呼叫中心,河南,江苏,北京,我们面临的运维挑战,多,难,高,用户多, IT规模接近一线互联网企业9亿 用户, 超1亿微信粉丝，月服务超亿次，微博矩阵粉丝3038万（居行 业首位），10086APP超五千万用户 量20000+服务器50000+Tomcat,业务变化快，运维环境复杂支撑全国营销活动，总部/分公司/省公司多级协同日均上线 17 次，日处理 206 例工单技术新：微服务/云计算/容器 ,要求高，提供电信级服务99.99% 的可靠性15秒接通要求7*24 小时保障,转变运维思路，适应新的时代挑战,为了支持业务快速上线和高效运维。在线公司监控系统需具备敏捷、集中、自动、智能的关键能力。,自动,敏捷,之 前,能力建设,智能,现 在,监控能力周粒度提供,监控能力分钟级提供,按专业划分的 “烟囱式监控”,混合集中化监控,手工添加,基于策略的自动化闭环,依赖专家经验,基于AI和大数据的自动识别,集中,目录,1,2,3,4,背景-全国集中维护、全球最大,出路-选择开源,转型-几个问题,蜕变-AIOPS在监控报警方面的尝试,统一监控平台：开源工具+二次开发，自主核心可控,监控管理,Grafana,统一门户,ITSM运维平台,自动化平台,CMDB,统一告警平台,统一事件分析告警,告警接口,性能看板,告 警,事件管理,短信,邮件,工单信息,故障定位或 修复场景,业务看板,根因分析,业务建模,业务模型和配置数据,被管环境,应用 系统,客服系统监控（I2000）,应用性能监控（APM）,告警信息,场景执行调用,性能看板,业务看板,业务数据,Prometheus,metric,ElasticSearch,数据库,数据库监控（Prometheus）,基础架构监控（Zabbix）,CTI/UAP系统,服务器、网络、存储、虚拟 化环境等,告警看板,Kafka,实时融合监控：引入业界开源工具， 进行二次开发与封装， 形成核心自主可控、 稳定高效、海量秒级 的监控能力。跨域/跨厂商/跨层的 IT/CT实时融合监控。 有丰富的管理对象。多样灵活的数据展现形式，可以灵活配置， 适应不同场景，快速 定制。,监控数据,统一监控平台：集中建设、统一管控、边缘节点标准化,为了更快速的建立监控能力、更全面的管控系统质量，在线服务公司统一监控平台采用了总部集中建设、统一管控，分公司标准化接入的建设模式。,全网集中：总部负责监控能力建设、 边缘节点的标准化，所有 监控数据的上收、分析、 展现与通知。分公司提供资源，遵照标 准化、封装后的监控模板 进行监控资源的维护与管 理。,一些小总结：半年时间,一些小总结：广泛、丰富、多样、灵活,网络设备类型与厂家,存活/丢包/ 时延,CPU/内存占 用率,snmp状态,温度,端口状态,出/入口带宽 利用率,出/入口丢、 错包,接口类型,设备状态网卡状态设备信息,端口描述,软件版本,系统名称,光功率,光模块接收 功率,网络协议,光模块发送BGP对等体功率连接状态,ospf邻居 状态,vrrp虚拟 路由状态,网络监控指标,SNMP,一些小总结：广泛、丰富、多样、灵活,一些小总结：广泛、丰富、多样、灵活,看板可灵活制定，分钟级完成配置。图表多样化展现：折线图、柱状图、饼图、区域图、拓扑图等。,主机参数内核参数 TCP协议栈参数信号量/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系统优化,一些小总结：zabbix系统优化,二、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等 进程数配置。4、增加zabbix server的自监控项配置项及告警（ Pre-process 进程占用率及zabbix_server.log的异常关键字告警）。,Zabbix配置的同步机制,Zabbix的配置表比较多，大容量局点关联查询sql耗时很长,如数据库控制sql执行时间的max_execution_time配置不合理，会导致无法将 相应配置表数据同步到zabbix server以及proxy的cache，从而导致出现大量 监控项无法正常采集及消息队列积压现象。以下为zabbix_server.log相应日志：,数据库sql执行超时配置建议根据现网的数据库IO处理性能以及局点规模合理配置数据库超时相关参数，将max_execution_time设置为超过目前zabbix server同步配置sql执行时长的2倍以上，并定期检查zabbix_server.log日志的相应执行时长，或者增加自监控告警。,一些小总结：zabbix系统优化,目录,1,2,3,4,背景-全国集中维护、全球最大,出路-选择开源,转型-几个问题,蜕变-AIOPS在监控告警方面的尝试,问题一：200w监控指标，业务出了问题仍然不知道,治理 范围,应用系统管理,业务质量管理,客户体验管理,能 力 扩 展,基础设施管理,基础设施性能管理(PM) 基础设施故障管理(FM),用户问题管理 用户感知管理业务问题管理 业务质量管理,以业务质量和客户体验为核心，以可管控、可视化、可度量为目标。全网集中建设、集中管控、边缘节点标准化接入。软件监控+硬件监控一网打尽，运维数据统一、融合、流动，建立多层次度量体系。以用户体验出发，建立端到端全链路监控，告警+投诉预警+客服联动形成完整闭环管理。运维保障,应用性能管理(PM) 应用故障管理(FM),流 程 及 自 动 化 管 理,业务及应用质量可感知，是监控的核心,Ser ver,OS,DB,JVM,MQ,WEB,面向基础架构的监控 只能发现约30%的问题,从用户体验出发面向应用 的监控能发现约70%的问题,最终用户体验,应用程序,基础架构,梳理业务系统 核心功能模块,梳理功能模块的 核心监控指标,评审监控指标的提取 方式及有效性,监控看板 制作,在强化基础设置监控的基础上，补充应用性能监控和业务质量监控能力，保障业务的稳定性和客户感知。应用性能监控业务质量监控,参考Google SRE五项黄金指标1：速率：请求速率，请每秒请求数量。2：错误： 错误率，即每秒错误数量。3：延迟： 响应时间，包括队列/ 等待时间，以毫秒为单位。4：饱和度：即过载程度，指标与资源利用率相关，也可通过队列深度进行 直接衡量。5：利用率： 资源或系统的繁忙程度，通常表示为 0% 至 100%。,应用性能监控将前台页面与后端服务以及用户网络环境真正串联，做到端到端 全链路、代码级监控。用户体验评分 前端交互体验网络切片应用调用拓扑 代码定位追踪,问题二：海量的日志是否有利用价值？对于亚健康状态，异常日志比系统故障更早出现。由于海量日志存储在海量网元中，不同厂商日志标准不统一且可读性差，往往 很难鉴别真正触发异常的日志。,挑战,海量日志保存在海量网 元中，缺乏统一视图,不同厂商设备的日志缺 乏统一标准，可读性差,XXXX%#&(*( ￥%*XXXX#$%&*(%#$%C XXXX!#$*#$!%$*(*( XXXXERROR*&%$#$*()*,日志统一采集，统一呈现， 异厂商设备日志统一查询,针对异常日志进行统计，实 时推送异常日志告警，提升 亚健康网络问题定位效率,跨厂商设备日志统一查询,异常日志统计,异常日志分析与告警推送,统一日志分析,Syslog网络设备( Huawei, HP, IBM,),Logstash,一体化 客服系统,精准扶贫,实名制语音管控,价值,Cloud OS,问题三：一个业务监控需要添加2480万个监控项？,监控 内容,接口平台类型（ 4）：接入接口，接入渠道，转接接口，转接渠道系统编码（31）：为各省分公司的编码监控项类型(8）：调用总数，成功率，平均耗时，失败率，失败数，大于1s比率，大于3s比率，大于5s比率监控项名称（500+）：从业务数据库实时查询监控项名称错误码（50+）：业务指标的错误码类型（4*31*8*500*50=2480万）,监控项类型大：千万级监控项组合，zabbix方案暂无法实现（包括监控配置和展示）图形展示筛选条件要求可配置，动态关联：zabbix解决方案暂无法实现（个性化tag无法关联查询）。,难点 说明,解决 方案,利用prometheus灵活的自定义babel功能实现数据采集和动态图形展示,监控平台架构的改进与优化,管控资源 对象,运维数据 分析平台,上层 运维场景应用,CMDB数据库企业资源数据,监控底层 能力平台,Prometheus,APM,Hadoop离线数据分析运维数据分析,内部用户,物理设 备,云平台网络,一体化客服业务 监控客服设备监控,。,容量管理,自动化扩缩容,。,故障决策系统,自动化切换,。,Zabbix,外部客户,日志容器云 业务监控 数据库应用中间件,日志平台,规则 数据机器学习数据,Flink实时数据处理运维数据分析,大型互联网公司基础资源多，业务广，线上变更频繁，监 控配置任务量大监控添加不是一蹴而就，需要反复调整，重复工作量大开源工具使用门槛高，大多没有好用的web界面，需要培 训才能灵活使用中移在线公司业务/工作人员遍布全国各省，基础资源达到 上万级别，业务变更频繁，统一管理难度系数高,痛点,应对方案,1,2,监控能力标准化、流 程化、模块化,二次开发、 3,自动化,配置界面化数据展示界面化,问题四：加不完的监控需求？,中移在线监控的历程（摸着石头过河）,1,需求分析 与功能验 证,2,3,全网推广性能调优典型问题与,4,软件bug处 理规范化制,定与整改5,运维界面 化与自动 化,欲速则不达 没有规范化 的交付，质 量无法保证,返工意味着效 率降低3倍以 上,1,2,需求分析 与功能验 证标准与规,范制定3,性能调优典型问题与软 件bug处理,4,批量推广,5,运维界面 化与自动 化,建议流程（标准先行，质量与效率并重）,模板、主机 群组、主机 名，主机显 示名、动作 名称、展板 内容等等,需求交付/变更 流程，问题处 理流程，例行 会议与周报,一点感悟,现在的数字,2.4 万主机,99 万触发器,1.3K动作,614 万监控项,198 万,报警,Proxy,92,800+975DashBoard用户数,目录,1,2,3,4,背景-全国集中维护、全球最大,出路-选择开源,转型-几个问题,蜕变-AIOPS在监控告警方面的尝试,当前的主要矛盾是：海量的告警和有限的专家,告警要“少而精”， 不要重复和误报,监控要“多而全”， 一个问题都不能放过！,614万+ 监控指标，99万+ 报警阈值， 198万+ 告警/天， 2000+ 短信/每人每天,运维主管,工程师小明,VS.,经过分析，阈值正确设定是平衡“多而全”和“少而精”的关键手段之一,告警,正常告警,误报,漏报,缺少压缩&关 联,阈值不合理：80%监控能力不足：10%人员配置失误：10%,无法设定阈值：70%无监控：30%,阈值设定从依靠专家经验向智能动态设定演进,专家依靠 经验设定规则阈值,通过大数据 分析设定固定阈值,通过智能分析 动态设定智能动态阈值,基于结构化的时序数据，通过AI预测拟合曲线，进行异常检测,历史数据分析历史数据读取和清洗数据抽取ETL断点修复数据间隔调整自相关性分析,毛刺检测统计异常检测，用于过滤毛刺型异常Moving Average移动平均滤波 (ARIMA)Exponential Smoothing指数平 滑滤波 (Holt-Winters)N*sigma统计检测,指标预测LSTM（长短期记忆） 预测算法孤立森林（Isolation Forest）日同比（Day over Day method） 箱线图（Box-whisker plot）,异常判定途径一：N-sigma方差 途径二：专家标记,智能化运维并不是我们想象的那样遥不可及,告警覆盖率 提升到95%,告警配置人 力下降60%,告警准确率 提升到80%,数据,算法,计算,海量数据源（性能指标、 日志、告警）,可以迭代预测、迭代标 注,TensorFlow等成熟算法库针对不同场景，可选择不 同算法，如LSTM用于趋势 预测、ARIMA用于回归过 滤异常,轻量化虚拟机部署，4C32G 即可起步,未来,让智能化在更多运维领 域落地开花,智能故障发现,日志异常检测、 告警压缩&关联、 告警规则生成、容量管理、性能管理等,深度,广度,系统架构师、运维开发、应用运维、数据库运维、大数据运维、数据分析、容器云开发、 云计算开发、JAVA开发,享受互联网 般技术挑战,国企稳定待遇,郑州、北京、 上海、深圳研 发中心，31 省会城市,与客户交互产 生的海量数据，包括语音、 文本、图像等 数据,公司年轻、人 员年轻、扁平 化管理,谢谢,
