模型剖析 | 如何解决业务运维的四大难题?

前言

作为业务运维,你是否经常会碰到这样的问题:

1. 新业务上线,开发同学会对服务做性能测试,但是换一种机型后的性能如何?服务版本更新后性能是否发生变化?

2. 节假日即将到来,某个业务预估用户活跃度提升2倍,但假日结束后只上升了0.5倍,提前扩容的资源白白浪费,如何解决?不同活动影响不同服务模块集群,如何分析?

3. 某个业务下挂靠的服务模块几百个,如何分析出核心模块和旁路模块?

4. 多地分布的业务,如何规划?

带着这些问题,我们来看一下腾讯SNG运维是如何通过业务画像来解决的。

通过分析模块性能数据(CPU,内存,IO等)、路由关系(上下游访问关系)、抓包关系(更底层的访问关系)、活动指标(节假日和压测演习带来的下游模块增长)得出业务画像。

业务画像类型

业务画像包含了几个模型,用来解决上面的四个问题:

1. 容量模型:通过自动化压测不同配置,不同版本的TPS和其他性能瓶颈。发现异常,推动性能优化,数据

2. 活动模型:分析业务历史活动和关联模块的变化趋势,评估未来活动的变化趋势,解放人力,优化成本。

3. 链路核心视图:根据不同业务场景过滤出核心链路访问关系图,可用于告警收敛,根因分析,架构优化。

4. SET规划:业务条带化,多地分布,快速调度能力。

新业务上线,开发同学会对服务做性能测试,但是换一种机型后的性能如何?服务版本更新后性能是否发生变化?

容量画像:通过自动化压测系统,压测出服务在不同机型、不同版本的TPS阈值。通过阈值基准来自动化管理容量。基于TPS的容量管理相比传统的基于单机性能(CPU、内存等)的容量管理更精细。

举个很常见的例子,基于运维经验,单机CPU使用率超过80%时,我们会认为这台机器的负载很高,服务已经有超时的风险了,所以我们一般会在单机CPU使用率达到70%左右就开始扩容。

但是,实际上有很多服务在CPU使用率30%左右就已经出现大量超时,具体原因此文不细说。如果还是按传统的CPU使用率来评估,业务早已受影响。

TPS容量模型则很好的避免了这个问题,不同机型承载的TPS都有一个压测阈值,只需要评估当前模块下的TPS总量(服务框架自动上报),超过TPS阈值才触发扩容。扩容的设备量也是基于不同机型的TPS标准来自动评估。

支持自动上报TPS数据的标准服务框架我们使用TPS模型,剩余非标准框架,也可通过压测找出性能瓶颈,只是瓶颈指标从TPS变成了CPU/流量/或服务主被调次数。

节假日即将到来,某个业务预估用户活跃度提升2倍,但假日结束后只上升了0.5倍,提前扩容的资源白白浪费,如何解决?不同活动影响不同服务模块集群,如何分析?

活动画像:每个核心链路视图在每个活动周期内的容量增长幅度,都会被记录在活动模型内,用于评估后续活动的增长服务。

可以看到,某次活动带来的活跃用户数增长,不同模块的流量和CPU增长幅度都是不一样的。

活动模型会将每一次活动用户增长幅度和下游模块的流量、CPU、TPS增长幅度都保存下来用于支撑后续活动关联模块的容量评估。

介绍一个基于活动模型评估活动容量的基础模型:

活动关联模块,通过活动过程中产品指标和模块流量变化幅度分析得出

历史增长幅度:模块过去12个月活动对应产品指标的变化趋势

容量指标增长幅度:TPS、流量、CPU绝对使用核心数三个指标在活动期间的增长幅度。

CPU的评估专门提一下,容量增长幅度需要计算某个指标的绝对值,所以CPU的维度我们把CPU的使用率量化成了CPU绝对核心数。比如一个模块包含了N种机型,每种机型的CPU使用率都不一样,我们会这样算:

CPU_total_core=n∑1=A1_core*A1_CPU_average+...+An_core*An_CPU_average

结合上述三个维度,可以预估出最近一次活动对应模块的容量增长幅度,容量托管后台可根据容量预估结果制定不同的扩缩容或调度方案。

每一次活动评估结束后,需要对比现网真实数据和评估结果。差异超过20%的模块会被要求做二次分析,增加更多高级维度优化评估模型。比如模块业务场景维度,某些离线场景,我们会单独打标,使用专门的算法进行评估。

某个业务下挂靠的服务模块几百个,如何分析出核心模块和旁路模块?

核心链路视图

业界流行的链路视图方案是google dapper模型。但是体量庞大的社平业务因为历史原因,短期内将所有业务都增加上报各种链路节点信息是不现实的。

于是我们采用另外一种方法来实现核心链路视图的绘制:根据路由、抓包、主被调关系梳理出接入->逻辑->存储三层的完整调用关系链路。结合不同的场景,在完整关系链的基础上根据服务主被调次数,出入包量等指标做进一步过滤。最终得出业务核心关系链。

未经处理过的业务链路视图看起来是这样的:

经过抓包数量、主被调次数过滤后的核心业务链路视图是这样的:

核心链路视图可以用于告警关联分析,根因分析,活动实时大盘视图等业务场景。

多地分布的业务,如何规划?

SET规划

对于一些要求高可用低延迟的业务就可以通过业务画像来实现业务多地分布了。

SET画像包含了:

1. 可视化视图:业务核心链路

2. 多地数据同步策略:这是SET画像的核心能力,对于多地分布的业务,难点就是如何实现多地数据一致。社交类业务形态主要是多读少些,我们使用单点写,多点读的策略规划多地分布架构。如图:所有的写请求都收归到深圳(因写入量相对少,跨地域访问的延时用户并无明显感知),深圳存储的数据通过同步中心同步到其他地域。所有的读请求都读本地存储。

3. 可度量指标:核心业务指标(比如承载多少用户,上传多少张图片等)、达到对应指标时各模块的容量等维度。

拿空间业务举例:

业务目前主要分布在深圳、上海、天津三地,每个地域可以承载各1/3的用户接入,每个地域的SET容量维持在50%,当一地故障时,另外两地可以分别承载25%的用户。

根据核心链路内模块的不同功能分类,划分不同子功能SET。

根据同地域不同机房分类,划分不同子机房SET。

下图是空间基于SET画像的业务架构示例:用户通过手Q接入,在空间上层接入获取用户的读写操作,将读请求路由到本地,写请求路由到深圳SET。底层数据通过同步中心通过到异地。进而实现了空间的多地分布。

随着后端服务的不断迭代,SET核心指标也会不断变化,我们通过定期的SET调度演习来保证SET画像的准确性。演习过程中我们可以找出SET内瓶颈模块,提前修正模块容量。

SET建调度的流量变化:

结语

业务画像的目的是将多年运维经验的沉淀成模型,自动化解决运维问题。

容量模型提供基础支撑数据到容量托管平台,上百个模块全自动扩缩容,容量稳定保持在45%左右。

活动模型智能预估业务活动期间各核心模块的容量变化趋势,提供预估结论到资源池,自动完成模块活动前扩容,活动后缩容,节约大量人力,预估准确率80%。

核心链路视图解决了社平业务复杂架构模型自动化梳理,目前统一告警ROOT平台使用核心链路视图做告警收敛以及根因分析。业务上云过程中,也会使用链路视图分析优化业务架构。

SET规划则主要解决了业务多地分布,持续保证业务高可用。业务多地分布,经历了天津机房爆炸,深圳光缆被挖断等大规模故障的检验。

业务画像随着业务的海量和多样化也在不断变化,同时也会根据运维需求沉淀出更多的业务画像。在处理日常的运维困难中,需要不断积累,多多关注业务的需求,善于总结。希望这些能够给大家带来一些启发。

原文发布于微信公众号 - 腾讯织云(TencentCOC)

原文发表时间:2018-08-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏养码场

《王者荣耀》技术总监复盘回炉历程:没跨过这三座大山,就是另一款MOBA霸占市场了

来听听邓君站在技术视角对《王者荣耀》内部的解读:《王者荣耀》如何从从立项之初经历的惨淡时期到华丽的翻盘;它实际原理、问题和优化的思路,和现在见到大部分不同的技术...

13920
来自专栏企鹅号快讯

新手如何学习java?一位十年开发经验的资深大牛给Java新手一些建议

这一部分其实也算是今天的重点,这一部分用来回答很多朋友所问过的问题,那就是我你是如何学习Java的,能不能给点建议? 今天我是打算来点干货,因此咱们就不说一些学...

23590
来自专栏web前端教室

没有哪个教程,是一点难度不带的,要以递归的方式来学习教程。

今天文章的标题的是在和一个新同学聊天沟通的时候,偶然提到的, ? 我觉得ta的心态特别好,对于学习的心态也特别的端正。很清楚的明白,目前还有许多不懂的地方,而这...

21570
来自专栏杨建荣的学习笔记

数据库工单系统的初步设计

对于数据库工单的设计一直以来是工作中的一个重点和难点,说是重点其实主要是很多DBA同学对于业务支持大家不够重视,但是从支持上希望及时响应业务,说是难点是因...

31340
来自专栏腾讯移动品质中心TMQ的专栏

腾讯TMQ在线沙龙回顾|测试过程管理

测试过程管理 活动时间:2017年10月26日 qq视频分享 活动介绍:TMQ在线沙龙第三十二期分享 本次分享的主题是:测试过程管理 共有83位测试小伙伴报名参...

26950
来自专栏CSDN技术头条

Lambda架构已死,去ETL化的IOTA才是未来

经过这么多年的发展,已经从大数据1.0的BI/Datawarehouse时代,经过大数据2.0的Web/APP过渡,进入到了IOT的大数据3.0时代,而随之而来...

33340
来自专栏数据科学与人工智能

【ETL工程】大数据技术核心之ETL

抛开大数据的概念与基本知识,进入核心。我们从:数据采集、数据存储、数据管理、数据分析与挖掘,四个方面讨论大数据在实际应用中涉及的技术与知识点。 核心技术 架构挑...

648100
来自专栏SAP最佳业务实践

从SAP最佳业务实践看企业管理(148)-MM-928供应商管理的库存

本文档的目的是为您详细介绍“供应商管理的库存(VMI)”业务情景中包含的所有步骤。本文解决最终客户的需求。 如果要在SAPBestPractices演示环境中测...

31760
来自专栏斑斓

剖析大数据平台的数据源

我在一次社区活动中做过一次分享,演讲题目为《大数据平台架构技术选型与场景运用》。在演讲中,我主要分析了大数据平台架构的生态环境,并主要以数据源、数据采集、数据存...

41970
来自专栏云计算D1net

混合云应用对于企业的意义

虽然为混合云部署开发应用并不是某种黑暗魔法,但是对于很多企业来说,这还是一项具有一定神秘性的工作。 可以想象,任何设想进行混合云开发的用户最终都需要完...

26630

扫码关注云+社区

领取腾讯云代金券