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

微信邦

前言

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

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模型。但是体量庞大的社平业务因为历史原因，短期内将所有业务都增加上报各种链路节点信息是不现实的。

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

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

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

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