王漫雪全球最大呼叫平台监控实践之路

1、全球最大呼叫平台实践之路中移在线服务王漫雪技术经理GOP S 全球运维大会 2019· 站目录1背景-全国集中维护、全球最大2出路-选择开源3转型-几个问题4蜕变-AIOPS在方面的尝试GOP S 全球运维大会 2019· 站中移在线公司简介 公司服务宗旨 发展历程 移动全网运营p 全集团首批入选国集中支撑者资委国企“双p 实现p 业务发展和创新初见成效百行动”三家公司之一p 31省呼叫业务完成划转p 奠定全网集中化运营基础p 10月成立移动全网集中服务提供者p 全集团集中化、专业化运营试验田20182017移动全网业务2016集中处理者2014GOP S 全球运维大会 2

2、019· 站传统呼叫中心传统呼叫中心是基于PBX、硬件排队机、硬件语音板卡等组成的系统。CTI软硬一体，不够灵活建设成本高、周期长、维护升级排队机PSTN/多多媒体互联网相PLMN关增值业务的融合无法实现多中心坐席跨网协PBX同无法快速响应业务需求IVR坐席坐席GOP S全球运维大会 2019· 站应用缺点新形态呼叫中心新形态下的呼叫中心质量管控智能IVR呼叫平台智能质检热线语音坐席智能导航支持客户全渠道交互转人工智能运营运营管理互联网视频坐席智能应答统一排队统一路由统一监控互联网坐席GOP S全球运维大会 2019· 深圳站 大数据平台智能知识库坐席助手在线客服

3、视频客服语音客服特征 纯软件：全媒体CTI、IVR、互联网接入网关、软交换、中继网关、媒体加速服务、用户终端 富媒体：支持传统语音、文本、图片、视频、短语音、微信、微博 智能化：与人工智能（AI）、大数据技术结合，应用于IVR、机器人应答、质检、外呼等 集中化：接续、CRM、分析、质检、话务监控等集中化我们的运维用户多, IT规模接近一线互联网企业 9亿 用户, 超1亿粉丝，月服务超在线公司: 全球最大呼叫中心多亿次，矩阵粉丝3038万（业首位），10086APP超五千万用户量 20000+服务器 50000+Tomcat业务变化快，运维环境复杂 支撑全国活动，总部/分公司/省公司多级协同难日

4、均上线 17 次，日处理 206 例工单技术新：微服务/云计算/容器 河南江苏要求高，提供电信级服务 99.99% 的可靠性高15秒接通要求7*24 小时保障GOP S全球运维大会 2019· 站转变运维思路，适应新的时代挑战为了支持业务快速上线和高效运维。在线公司监控系统需具备敏捷、集中、自动、智能的关键能力。敏捷集中自动智能能力建设之前按专业划分的“烟囱式监控”手工添加依赖专家经验监控能力周粒度提供现在监控能力分钟级提供混合集中化监控基于策略的自动化闭环基于AI和大数据的自动识别GOP S全球运维大会 2019· 深圳站 目录1背景-全国集中维护、全球最大2出路-选择开

5、源3转型-几个问题4蜕变-AIOPS在方面的尝试GOP S 全球运维大会 2019· 站统一监控平台：开源工具+二次开发，自主核心可控信CMDB被管环境metric服务器、网络、存储、虚拟化环境等CTI/UAP系统应用数据库业务数据系统GOP S 全球运维大会 2019· 深圳站 Java App.NET AppPHP, Python, NodeJS业务建模自动化平台故障定位或修复场景ITSM运维平台息事件管理统一门户告警看板业务看板性能看板监控管理告警监控数据工单ElasticSearch告警信息场景执行调用业务模型和配置数据数据库监控（Prometheus）客服系统监控

6、（I2000）应用性能监控（APM）基础架构监控（Zabbix）邮件Prometheus短信Kafka统一告警平台统一事件分析告警根因分析告警接口Grafana性能看板业务看板实时融合监控：u 引入业界开源工具， 进行二次开发与封装， 形成核心自主可控、 稳定高效、海量秒级 的监控能力。u 跨域/跨厂商/跨层的IT/CT实时融合监控。有丰富的管理对象。u 多样灵活的数据展现形式，可以灵活配置， 适应不同场景，快速 定制。统一监控平台：集中建设、统一管控、边缘节点标准化为了更快速的建立监控能力、更全面的管控系统质量，在线服务公司统一监控平台采用了总部集中建设、统一管控，分公司标准化接入的建设模式

7、。GOP S 全球运维大会 2019· 深圳站 全网集中：u 总部负责监控能力建设、边缘节点的标准化，所有监控数据的上收、分析、展现与通知。u 分公司提供资源，遵照标准化、封装后的监控模板进行监控资源的维护与管理。一些小总结：半年时间84ProxyGOP S 全球运维大会 2019· 站545用户数1.3K动作400+DashBoard30 万90 万触发器200 万项2 万主机一些小总结：广泛、丰富、多样、灵活GOP S 全球运维大会 2019· 站一些小总结：广泛、丰富、多样、灵活GOP S 全球运维大会 2019· 站网络指标状态网卡状态光功率网络

8、协议存活/丢包/端口状态端口描述光模块发送BGP对等体时延功率连接状态CPU/内存占出/带宽版本光模块接收ospf邻居用率利用率功率状态snmp状态出/丢、系统名称vrrp虚拟错包路由状态温度接口类型网络类型与厂家SNMP一些小总结：广泛、丰富、多样、灵活看板可灵活制定，分钟级完成配置。图表多样化展现：折线图、柱状图、饼图、区域图、拓扑图等。GOP S 全球运维大会 2019· 站一些小总结：zabbix系统优化数据库CPU/内存/IO 连接（最大连接数、超时时长）数据一致性强烈建议采用数据库SSD硬盘WEBNginx参数Php参数php.ini：max_input_vars（影响模

9、板应用大批量主机失败） 不信号集） defines.inc.php：QUEUE_ITEM_COUNT （定义项队列检索限制，影响消息队列积压显示）GOP S 全球运维大会 2019· 站主机参数内核参数TCP协议栈参数信号量/IO（Zabbix启动失败Zabbix视具体需求配置启动模块和进程数禁用自动发现，采用脚本调用api实现禁用housekeeper，启用数据库表分区禁用server直连agent配置参数优化一些小总结：zabbix系统优化问题现象与影响一、大量消息队列积压（超过20万），且呈现雪崩效应问题定位与解决方案一、zabbix官网对于pre-process耗尽的说明：二

10、、解决方案：1、在zabbix server所在主机再单独部署一个proxy节点。二、Preprocessing manager 负荷长期为100%2、将之前由zabbix server直接的所有proxy所在主机的agent节点，全部转到新增proxy管理。3、降低server的pollers、java pollers、进程数配置。ers、trappers等4、增加zabbix server的自项配置项及告警（ Pre-process进程占用率及zabbix_server.log的异常关键字告警）。三、Zabbix server主机反复重启，却无法启动GOP S 全球运维大会 2019

11、83; 站一些小总结：zabbix系统优化l Zabbix配置的同步机制l Zabbix的配置表比较多，大容量局点关联sql耗时很长l 数据库sql执行超时配置建议GOP S 全球运维大会 2019· 站根据现网的数据库IO处理性能以及局点规模合理配置数据库超时相关参数，将max_execution_time设置为超过目前zabbix server同步配置sql执行时长的2倍以上，并定期检查zabbix_server.log日志的相应执行时长，或者增加自告警。如数据库sql执行时间的max_execution_time配置不合理，会导致无法将相应配置表数据同步到zabbix serv

12、er以及proxy的cache，从而导致出现大量项无法正常及消息队列积压现象。以下为zabbix_server.log相应日志：目录1背景-全国集中维护、全球最大2出路-选择开源3转型-几个问题4蜕变-AIOPS在告面的尝试GOP S 全球运维大会 2019· 站问题一：200w指标，业务出了问题仍然不知道q q q q以业务质量和客户体验为，以可管控、可视化、可度量为目标。全网集中建设、集中管控、边缘节点标准化接入。+硬件一网打尽，运维数据统一、融合、，建立多层次度量体系。，告警+投诉预警+以用户体验出发，建立端到端全链路联动形成完整闭环管理。运维保障用户问题管理用户感知管理业务问

13、题管理业务质量管理客户体验管理能力扩展业务质量管理治理范围应用性能管理(PM)应用故障管理(FM)流程及自动化管理应用系统管理基础设施性能管理(PM)基础设施故障管理(FM)基础设施管理GOP S 全球运维大会 2019· 站业务及应用质量可感知，是监控的核心在强化基础设置监控的基础上，补充应用性能监控和业务质量监控能力，保障业务的稳定性和客户感知。应用性能监控业务质量监控最终用户体验从用户体验出发面向应用的监控能发现约70%的问题应用程序基础架构面向基础架构的监控只能发现约30%的问题应用性能监控将前台页面与后端服务以及用户网络环境真正串联，做到端到端全链路、代码级监控。应用调用拓

14、扑用户体验评分网络切片代码定位追踪前端交互体验GOP S 全球运维大会 2019· 深圳站 WEBMQJVMDBOSSer ver参考Google SRE五项黄金指标1：速率：请求速率，请每秒请求数量。2：错误： 错误率，即每秒错误数量。3：延迟： 响应时间，包括队列/ 等待时间，以毫秒为单位。4：饱和度：即过载程度，指标与资源利用率相关，也可通过队列深度进行直接衡量。5：利用率： 资源或系统的繁忙程度，通常表示为 0% 至 100%。监控看板制作评审监控指标的提取方式及有效性梳理功能模块的核心监控指标梳理业务系统核心功能模块问题二：海量的日志是否有利用价值？对于亚健康状态，异常日志

15、比系统故障更早出现。由于海量日志存储在海量网元中，不同厂商日志标准不统一且可读性差，往往很难鉴别真正触发异常的日志。跨厂商设备日志统一查询异常日志统计异常日志分析与告警推送价值挑战海量日志保存在海量网元中，缺乏统一视图日志统一采集，统一呈现， 异厂商设备日志统一查询针对异常日志进行统计，实时推送异常日志告警，提升亚健康网络问题定位效率不同厂商设备的日志缺乏统一标准，可读性差XXXX%#&(*( ￥%*XXXX#$%&*(%#$%C XXXX!#$*#$!%$*(*( XXXXERROR*&%$#$*()*LogstashSyslog网络设备( Huawei, HP, I

16、BM,)一体化客服系统精准扶贫实名制语音管控Cloud OSGOP S 全球运维大会 2019· 深圳站 统一日志分析问题三：一个业务需要添加2480万个项？内容难点说明解决方案GOP S 全球运维大会 2019· 站n 利用prometheus灵活的自定义babel功能实现和动态图形展示n项类型大：千万级项组合，zabbix方案暂无法实现（配置和展示）n图形展示筛选条件要求可配置，动态关联：zabbix解决方案暂无法实现（个性化tag无法关联）。n接口平台类型（ 4）：接入接口，接入，转接接口，转接n系统编码（31）：为各省分公司的编码n项类型(8）：调用总数，率，平均耗

17、时，失败率，失败数，大于1s比率，大于3s比率，大于5s比率n项名称（500+）：从业务数据库实时项名称n错误码（50+）：业务指标的错误码类型（4*31*8*500*50=2480万）平台架构的改进与优化外部客户内部用户业务容量管理故障决策系统上层 运维场景应用自动化扩缩容自动化切换。Flink实时数据处理运维数据分析CMDB数据库企业资源数据规则数据机器学习数据Hadoop离线数据分析运维数据分析运维数据分析平台底层能力平台ZabbixPrometheusAPM日志平台物理设备管控资源对象容器云业务数据库应用中间件云平台网络日志GOP S 全球运维大会 2019· 站问题四：加的

18、需求？l应对方案l痛点GOP S 全球运维大会 2019· 站1能力标准化、流 2二次开发、 3配置界面化、模块化自动化数据展示界面化 大型互联网公司基础资源多，业务广，线上变更频繁，监控配置任务量大 添加不是一蹴而就，需要反复调整，重复工作量大 开源工具使用门槛高，大多没有好用的web界面，需要培训才能灵活使用 中移在线公司业务/遍布全国各省，基础资源达到上万级别，业务变更频繁，统一管理难度系数高一点感悟 中移在线的历程（摸着石头过河） 建议流程（标准先行，质量与效率并重） GOP S 全球运维大会 2019· 站 需求分析1与功能验证2 标准与规范制定 性能调优3 典型

19、问题与软件bug处理4 批量推广 运维界面5化与自动化需求交付/变更流程，问题处理流程，例行会议与周报模板、主机群组、主机名，主机显示名、动作名称、展板 需求分析1与功能验证2 全网推广 性能调优3 典型问题与bug处理4 规范化制定与 运维界面5化与自动化返工意味着效率降低3倍以上欲速则不达没有规范化的交付，质量无法保证现在的数字92ProxyGOP S 全球运维大会 2019· 站975用户数1.3K动作800+DashBoard198 万99 万触发器614 万项2.4 万主机目录1背景-全国集中维护、全球最大2出路-选择开源3转型-几个问题4蜕变-AIOPS在告面的尝试GOP

20、 S 全球运维大会 2019· 站当前的主要是：海量的告警和有限的工程师小明运维主管告警要“少而精”， 不要重复和误报要“多而全”， 一个问题都不能放过！VS.614万+指标，99万+阈值， 198万+ 告警/天， 2000+/每人每天GOP S 全球运维大会 2019· 站经过分析，阈值正确设定是平衡“多而全”和“少而精”的关键之一正常告警 缺少压缩&关联 阈值不合理：80%告警误报能力不足：10% 配置失误：10% 无法设定阈值：70%漏报 无：30%GOP S 全球运维大会 2019· 站阈值设定从依靠经验向智能动态设定演进通过智能分析动态设定智能动态阈值依靠经验设定规则阈值通过大数据分析设定固定阈值GOP S 全球运维大会 2019· 站GOP S 全球运维大会 2019· 站基于结构化的时序数据，通过AI拟合曲线，进行异常检测历史数据分析毛刺检测统计异常检测，用于过滤毛刺型异常异常判定途径一：N-sigma方差指标LSTM（长短期记忆） 算法孤立森林（Isolation Forest）日同比（Day over Day method） 箱线