模型剖析 | 如何解决业务运维的四大难题？
前言作为业务运维，你是否经常会碰到这样的问题：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规划则主要解决了业务多地分布，持续保证业务高可用。业务多地分布，经历了天津机房爆炸，深圳光缆被挖断等大规模故障的检验。
业务画像随着业务的海量和多样化也在不断变化，同时也会根据运维需求沉淀出更多的业务画像。在处理日常的运维困难中，需要不断积累，多多关注业务的需求，善于总结。希望这些能够给大家带来一些启发。
·招 ·聘·广·告·
最后也希望更多优秀的同学加入到我们的社交平台业务运维团队，期待跃跃欲试的你简历砸来~
业务运维岗位职责：1）跟进社交业务从接入到上线全过程的技术运营解决方案，如部署方案规划、资源规划和平台组件接入等；2）解决业务上线过程及后续运维遇到的技术问题，发现运营风险；3）优化业务流程，优化业务架构，提升运维工作效率和服务质量，优化业务成本；4）监控业务相关的平台系统的运行状况，处理业务运行中出现的故障，保障业务可持续服务。5）负责运营系统的需求管理、规划设计及工程研发。任职要求：
1）计算机相关专业本科及以上学历，深入掌握计算机原理，操作系统，计算机网络等基础理论；2）熟练使用Linux/Unix操作系统，精通Shell，精通PHP或Python开发；3）了解WEB前端开发技术；4）熟悉数据库架构及维护；5）良好的沟通，表达能力，了解项目管理的基本知识；6）有海量运维工作经验，熟悉主流的业界监控软件及开源工具；7）良好的英文能力，能流畅使用英文进行口语交流的优先；8）良好的抗压能力，勇于接受有挑战的工作，良好的学习接受能力。
运营研发岗位职责：1） 负责监控告警/运营分析/自动化运维等运营平台的设计与开发，以及各类API的开发与维护工作；2）运营平台研发项目管理。任职要求：1）对运营开发工作有充分的热情，有强烈的成长欲望，愿意接受富有挑战的工作；2）良好的沟通表达和需求抽象能力，善于主动沟通了解业务需求；3）三年或以上的PHP、Python开发经验，有C/C++开发经验者优先；4）有互联网运营平台项目经验者优先。5）掌握Linux 操作系统和常用开源数据库；对SQL优化有丰富的经验；6）了解常用机器学习算法；7）关注互联网开发技术趋势，乐于尝试最新的技术，追求编写优雅的代码，在技术趋势和思路上能积极影响技术团队。
请将简历投至：
millerzhou@ tencent .comawaili@ tencent .com
页:
[1]