应对多种场景，运维人是如何做好业务活动保障的，

应对多种场景，运维人是如何做好业务活动保障的，

作为金融行业的领头羊，平安集团每年都要面向广大客户举办多场业务活动，如秒杀、赠险等。业务活动形式不同，对IT系统承载能力的要求也不同。

每一场大规模业务活动都是IT运维人员的“练兵场”，成功承担高并发访问的背后，都有集团科技IT团队专家们利用自己活动保障的丰富经验、专业的技术水平和夜以继的辛勤坚守。

那么，平安运维人是如何做好活动保障的呢？

01 梳理IT服务现状，寻找风险点

知己知彼，方能百战不殆。规划业务活动时，IT团队需对当前服务现状进行全面梳理，结合核心业务流程，制定有针对性的、有效的应急方案，寻找潜在风险点并优化。

活动场景梳理

了解活动场景是做任何活动支持方案的首要行动项。不同活动形式，如秒杀、免费赠险、办公签到等，均有不一样的用户表现。不同活动对系统性能的要求也不一样。

例如，秒杀的用户行为更多表现为集中时间点登陆，集中访问特定URL；免费赠险则为某段时间内的持续用户登陆，但广告推送、非工作等时间段访问量会有明显增量，但相对均衡；办公签到等有时效要求的活动，则是在某特定时间段区间内，存在集中峰值。

例如春节期间的直播活动，其带有办公签到的集中上线性质，在该类活动中，需重点保障高峰期间用户登陆、直播间进出、推拉流等场景。同时，直播间的个性化服务，如送礼物、IM等场景，则需分析其业务场景的核心程度，定义保障等级。

活动场景梳理完成后，需产出但不限于：业务活动形式、活动最高并发用户及请求量、活动核心业务场景、活动时间区间等内容。

应用架构梳理

活动场景及保障等级梳理完毕后，可以根据提供功能的系统组件逐步梳理出组件上下游调用关系，整理应用架构信息。

在整理应用架构信息时，一方面需关注组件的架构方案是否符合活动形态，如秒杀类活动，不适用对关系型DB进行高频次操作的架构，应以异步消息、高速缓存等轻架构应对前端高并发流量；

另一方面需关注业务场景实现过程中的调用关系及数据流，需区分业务场景数据流中的“关键”与“增值”。“关键”即为必须调用链，任何情况下均无法做降级服务；“增值”即为体验链，需考虑功能开关、服务降级等措施，可作为应急预案中的有损服务的保障措施考虑点。

需重点提及，很多团队在做应用架构梳理中，主要关注于应用，往往容易忽略网络层、机房等基础资源。网络层如出入口的流量、CDN服务等；机房架构如多活架构、云平台底层资源等，均是活动期间的评估维度。

应用架构梳理完成后，需产出但不限于：应用层面架构图、核心数据流、关键服务与非关键服务清单、组件集群清单等信息，基础架构层面如网络、云平台、多活策略等信息。

配置信息梳理

应用架构梳理完毕后，通过梳理配置信息，了解应用层各组件CI的配置环境。配置环境包含集群数量、集群上下游调用策略、集群在JVM的配置等（如线程数配置，内存配置等）。

同时需梳理基础架构领域的网络带宽、云主机的最大IO控制、甚至每个集群的对外防火墙策略。

A、应用的日志文件及日志输出级别是否合理。如常见的nginx日志、tomcat组件的out日志、acclog等，同时还需关注SDK日志。在与第三方服务合作中，常以SDK介质作为系统间的融合方案，SDK若涉及到PC客户端、移动客户端，需重点关注SDK的奔溃日志、接口请求日志等，需检查日志是否有回传机制，避免在生产发生异常时，无法获取SDK日志信息作为问题诊断的基础。

B、 各应用组件的核心URL请求及功能点描述。对于应用服务的核心URL，需有功能点的登记及描述，可作为请求分析的基础信息输入。

监控方案检视及部署

配置信息梳理完毕后，即可对涉及到的所有显性CI、隐形CI做监控配置的巡查检视。集团IT团队在用户体验（客户端/浏览器端/小程序端/用户感知）-服务链路-基础资源-业务趋势等层面，基于存在性-存活性-可用性-健康与效率等四个方面制定常规监控方案。除此以外，还有不限于以下范围的特殊监控：

A、应用异常标志性关键字监控；

B、 非标组件，需研发配合，实现可衡量服务运行状态正常的标记接口或日志；

C、 与第三方服务交互的应用场景，需考虑监控需覆盖第三方服务可用性、容量，甚至在异常现场需提供snapshot、崩溃日志、异常请求返回错误代码号等监控信息。

容量评估及扩容方案

基于业务活动重点场景的当前CI运行状态数据，预估系统当前可支持并发量，与业务预期并发量进行对比制定初步扩容方案（该评估为初步评估，因业务活动综合多类场景，无法准确评估容量比例，此评估可作为扩容参考）。其中扩容方案除常规的应用实例扩容外，还需考虑网络出入口带宽、CDN带宽、数据库容量、存储容量、信令容量，以及配置类容量（实例的最大连接数、主机的文件打开最大数）等。

在扩容方案中，需注意：

A、在多层架构中，下游系统组件的容量需大于上游系统容量，避免系统容量在上游进来后引起后端的崩溃式堵塞；

B、 扩容策略需与业务场景充分结合，业务场景的降级级别与服务的容量策略需定义关系表，如当某A组件达到CPU资源95%时，某低级别的业务场景的降级服务需可快速配置，避免影响A组件的整体容量异常。

生产压测及监控分析

使用压测手段验证扩容后的效果。结合活动场景、业务服务功能点，按逐步提升并发的方式制定压测方案。分析压测报告、监控信息的汇总报告，按照扩容策略分析存在容量资源瓶颈点，但需要警惕：

A、对瓶颈组件扩容后，同时需再做一次“回归压测”，观察其下游服务是否因此出现瓶颈；

B、 压测所发现的容量或性能瓶颈，并非所有现象均需要通过扩容方式提高保障，有时可通过服务拆解等架构优化、服务接口的代码优化等方式达成效果。

TOP缓慢SQL/接口分析

TOP缓慢SQL/接口的分析梳理，是提升当前容量及性能的非常有效的手段。缓慢SQL的优化，通过执行计划、高并发类的SQL转换为缓存计算等方式，可明显提升对应服务接口的效率。

每次业务峰值，缓慢SQL、缓慢接口很容易导致服务线程积压堵塞，甚至占用大量内存。对于缓慢接口可通过threaddump分析，缓慢SQL如ORACLE，则可WAIT_EVENT/longsession/lock/latch_free等维度做分析，并由DBA/研发提供优化方案。

应急预案整理

应急预案通常分为两大类型，一是业务层面的应急方案，二是IT组件异常应急方案：

A、业务层应急方案，可通过应用服务降级、服务中断、业务开关等方式进行，同时可以通过业务错峰等策略，实现高峰均匀；

B、 IT组件异常方案，一方面需以最窘迫情景分析，以每个组件为分析对象，当该组件异常时，是否可以以服务重启/环境切换/功能开关调整等方式恢复；

另一方面，对于大面积异常时的方案，是否可采用限流、多活切换、有损提供部分功能等方式继续提供服务，但该类策略需与事先与业务达成一致。

02 做好过程监视，不放过任何细节

不放过波峰细节，了解业务最前线

保留活动过程的现场是IT服务持续优化的最宝贵信息来源。在瞬间波峰时，基础资源的稳定性、服务层面的性能波动、服务层面的功能报错率、网络流量、网络建联的上限控制等，需充分分析及记录相关现象，运用监控时序数据、应用日志、甚至抓包等手段信息，逐步复原。

注意，我们通常会关注波峰时的系统容量、性能，但往往会忽略一点，即业务层面的用户行为分析。我们为了达到整体稳定目标，对业务核心功能进行重点保障，对非核心功能做有效隔离、错峰等措施，也能起到很好的效果。

比如在直播活动中，我们最常用到的功能点有直播间的进出、直播视频的推拉流、送礼物、IM聊天等，但对以上提及的内容，最核心的功能点是直播间的进出、直播视频的推拉流。在容量扛不住的情况下，可关闭送礼物、IM聊天功能；另外一种场景，直播间的创建与直播的现场是两个不同场景，但可能会占用同一组件资源。当直播高峰时，可以考虑直播间的创建功能临时错峰，避免资源竞争。

全面检查，寻找不合理的表现

在活动结束后，需安排对业务、应用、平台等方面进行全面检视。如对监控数据进行全面数据分析；对活动高峰期间的业务TOP URL/SQL进行分析；应用层面的服务链路性能及错误的变化现象；从平台层面检视带宽、连接数、云平台的超负荷状态等；寻找在资源上、业务行为上、代码健壮性等层面的异常现象，并逐个形成分析和跟踪措施，从架构优化、扩缩容、代码优化等方面安排改进。

03 良好的组织联动，是成功的关键

团结一心，分工明确，联动沟通

好的组织纪律，明确约定的工作沟通方式，团队间达成信息透明、主动协作，是保障活动工作有效、高效开展的条件。

业务活动保障，通常是由多个团队的多个角色临时组件的团队负责完成，有运维、业务、产品、架构、开发、测试、平台、基础架构等各个技术领域的人员，还可能涉及外部厂商。我们需要采取措施，妥善组织众多不同背景的人员，避免混乱，让大家拧成一股绳，共同朝向一个目标努力。

供应商沟通同样重要

在生产问题诊断中，供应商是常常被忽略的角色，如网络CDN、ORACLE厂商、网络设备厂商等。应用层面达到一定的优化程度后，供应商从底层出发协助提供优化方案，往往能够起到事半功倍的效果。当然，在业务保障过程中，对提供服务的厂商要信息透明，这也是一项基础要求。

生产变更操作必须评审、记录、透明

活动保障过程中，一切生产变更必须统一评审后再操作。生产变更历来属于风险极高的动作。在业务活动保障工作中，专业团队常会出现“我发现了某个参数貌似不对”，就默默地调整了参数。

这种做法没有在保障团队中做记录，当参数的调整引发生产问题时，无法回溯变更，无法快速定位异常导致点，常会导致问题定位效率低下。

因此，不管在架构检视、压测、扩容、业务峰值后的检视措施等过程中，涉及到的生产变更方案及计划，都需要进行评审，记录，形成有跟踪措施的变更计划，信息要透明。

写在最后

世上本没有什么岁月安好，只不过有人替你负重前行。疫情前线，医护人员的忘我奉献，谱写着一曲又一曲感人至深的赞歌。互联网时代，在一场轰轰烈烈，用户拍手叫好的大规模业务活动的背后，通常也是有无数IT技术专家们夜以继日的辛勤坚守。

业务活动的保障支持，是一项极高强度的IT事项，需要IT人员具备敏锐的信息收集、分析、应急能力，同时需要各技术领域专家集中贡献专业能力。只有在每场活动中积累经验，在技术上不断寻求创新，我们才能游刃有余，在每场业务活动中突破自己，缔造运维人员自己的传奇！

作者：黄伟星，平安科技运营工具平台团队监控规划及方案实施组，负责平安集团Wiseapm监控产品建设与实施工作。