微信邦

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

返回列表 发新帖
查看: 4658|回复: 0

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

[复制链接]
发表于 2018-8-9 10:54:10 | 显示全部楼层 |阅读模式
生活圈制作
前言

作为业务运维,你是否经常会碰到这样的问题:
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模型。但是体量庞大的社平业务因为历史原因,短期内将所有业务都增加上报各种链路节点信息是不现实的。

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

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

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

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

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

回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

微信邦网联系QQ|Archiver|手机版|小黑屋|鲁公网安备 37082802000167号|微信邦 ( 鲁ICP备13013993号-5

GMT+8, 2019-5-20 16:35 , Processed in 0.172851 second(s), 26 queries .

Powered by Discuz! X3.2

© 2001-2013 Wxuse Inc. | Style by ytl QQ:1400069288

快速回复 返回顶部 返回列表