作为金融行业的领头羊，平安集团每年都会为客户组织多项业务活动，如闪购、保险赠送等。不同形式的业务活动对IT系统的承载能力有着不同的要求。每一次大型业务活动都是IT运维人员的“练兵场”。成功承接高并发接入的背后，有来自集团技术和IT团队的专家，他们以丰富的经验、专业的技术水平和夜班经验为活动保驾护航。不断的努力和坚持。那么，平安运维人员是如何做好事件防护的呢？01梳理IT服务现状，寻找风险点，知己知彼，方能百战不殆。IT团队在规划业务活动时，需要全面梳理当前服务状态，结合核心业务流程，制定有针对性、有效的应急预案，发现潜在风险点并进行优化。整理活动场景了解活动场景是任何活动支持计划的第一个行动项目。不同形式的活动，如秒杀、免费保险、办公室签到等，用户表现不同。不同的活动对系统性能有不同的要求。例如，秒杀的用户行为更多表现为集中时间点登录和集中访问特定网址；免费保险是指一定时间内用户连续登录，但在广告推送和非工作时段的访问量会明显增加，但相对均衡；对于办公室签到等时间敏感的活动，在一定时间内存在集中高峰。例如，春节期间的直播活动具有办公室签到的集中在线性质。在此类活动中，需要重点保障高峰期的用户登录、直播间进出、推拉流等场景。同时，对于直播间的个性化服务，如赠送、IM等场景，需要分析业务场景的核心度，定义保障层级。梳理活动场景后，需要产生但不限于：业务活动形式、活动最高并发用户及请求量、活动核心业务场景、活动时间间隔activity等。梳理完应用架构的活动场景和保障级别后，可以根据提供功能的系统组件，逐步梳理组件的上下游调用关系，梳理应用架构信息。在整理应用架构信息时，一方面需要关注组件的架构方案是否符合活动形式，比如闪购活动，不适合高频操作的架构在关系数据库上，应该用异步消息和缓存等轻型架构来处理。前端并发量高；另一方面，在实现业务场景的过程中，需要关注调用关系和数据流向，区分业务场景数据流向中的“关键”和“增值”。“Key”表示必须调用链，任何情况下都不能做降级服务；“增值”是指体验链，需要考虑功能切换、服务降级等措施，在应急预案中可以考虑作为受损服务的保障措施。需要强调的是，很多团队在梳理应用架构的时候，都是以应用为中心，往往容易忽视网络层、机房等基础资源。网络层，例如入口和出口流量、CDN服务等；机房架构，如多活架构、云平台底层资源等，都是活动期间的评估维度。应用架构梳理后，需要产生但不限于：应用层架构图、核心数据流、关键服务和非关键服务列表、组件集群列表等信息，网络、云等基础设施层平台、多动策略等信息。配置信息整理应用架构整理好后，通过配置信息整理，可以了解应用层各个组件CI的配置环境。配置环境包括集群个数、集群上下游调用策略、集群在JVM中的配置等（如线程个数配置、内存配置等）。同时需要梳理基础设施领域的网络带宽，云主机的最大IO控制，甚至是各个集群的外部防火墙策略。A.应用日志文件和日志输出级别是否合理。比如常见的nginx日志、tomcat组件的out日志、acclog等，SDK日志也要注意。在与第三方服务的合作中，SDK媒介通常被用作系统之间的集成解决方案。如果SDK涉及PC客户端和移动客户端，重点关注SDK崩溃日志、接口请求日志等，检查是否有回调机制，防止出现异常时无法获取SDK日志信息作为问题诊断的依据在生产中。B、各应用组件的核心URL请求和功能点描述。对于应用服务的核心URL，需要进行功能点的注册和描述，可以作为请求分析的基础信息输入。监控计划检查和部署配置信息整理好后，就可以对所有涉及到的显式CI和不可见CI进行监控配置的检查和检查。集团IT团队在用户体验层面（客户端/浏览器/小程序/用户感知）-服务链路-基础资源-业务趋势，从存在-生存能力-可用性-健康效率四个方面，制定日常监控方案.此外，还有不限于以下范围的专项监控：A.应用异常符号关键字监控；B.非标准组件，需要开发合作实现能够衡量服务正常运行状态的标记接口或日志；C.在第三方服务交互的应用场景中，需要考虑监控需要覆盖第三方服务的可用性和容量，甚至提供快照、崩溃日志、返回的错误码数等监控信息通过异常站点的异常请求。容量评估及扩容方案根据当前业务活动关键场景的CI运行状态数据，预估系统当前可支持的并发量，并与业务预期并发量进行对比，制定初步扩容方案（本次评估为初步评估，由于业务活动场景繁多，无法准确评估容量比例，本次评估可作为扩容参考）。除了常规的应用实例扩容外，扩容方案还需要考虑网络出入口带宽、CDN带宽、数据库容量、存储容量、信令容量、配置容量（实例最大连接数、实例最大打开文件数）。主机）等。在扩容方案中需要注意：A.在多层架构中，下游系统组件的容量必须大于上游系统的容量，避免因扩容导致后端崩溃来自上游的系统容量；B.扩容策略必须与业务场景完全兼容结合业务场景的降级级别和服务的容量策略，需要定义一个关系表。例如，当A组件CPU资源达到95%时，需要快速配置低级别业务场景的降级服务，避免影响A组件的整体能力。异常。生产压力测试和监控分析采用压力测试的方法来验证产能扩张的效果。结合活动场景和业务服务功能点，以并发递增的方式制定压测方案。分析压测报告和监控信息汇总报告，根据扩容策略分析容量资源瓶颈点，但需要警惕：A.对瓶颈组件进行扩容后，需要做“回归压力测试”，同时观察其下游服务是否因此出现瓶颈；B.并非所有压力测试中发现的容量或性能瓶颈都需要通过扩容来保证。有时可以通过服务拆解、服务接口代码优化等结构优化来达到效果。TOP慢SQL/接口分析TOP慢SQL/接口分析是一种非常有效的提高当前容量和性能的手段。慢SQL的优化，可以通过执行计划，将高并发SQL转化为缓存计算，显着提升相应服务接口的效率。每逢业务高峰，SQL慢、接口慢，很容易导致服务线程积压、阻塞，甚至占用大量内存。慢接口可以通过threaddump进行分析，ORACLE等慢SQL可以在WAIT_EVENT/longsession/lock/latch_free等维度进行分析，DBA/R&D会给出优化方案。应急预案排序应急预案通常分为两种，一种是业务层面的应急预案，一种是IT组件异常的应急预案：A.业务层的应急预案可以通过应用服务降级来实现、业务中断、业务切换等。同时可以采用业务错峰等策略，实现均峰；B.IT组件异常解决方案，一方面需要分析最尴尬的场景，以各个组件为分析对象。组件异常时，是否可以通过服务/环境重启；另一方面，对于大规模异常的解决方案，是否可以通过限流、多活切换、有损等方式继续提供服务提供一些功能等，但此类策略需要事先与业务协议进行讨论。02做好过程监控，不放过任何一个细节，不放过高峰细节，了解业务一线。预订活动流程的站点是持续优化IT服务最有价值的信息来源。瞬时高峰期间，基础资源的稳定性、服务层的性能波动、服务层的功能错误率、网络流量、建网上限控制等，需要充分分析记录相关信息现象，通过监控时序数据和应用日志，甚至抓包等信息手段，逐步恢复。需要注意的是，我们通常关注的是系统容量和高峰期的性能，但往往忽略了一点，即业务层面对用户行为的分析。为了实现整体稳定的目标，我们重点保障业务的核心功能，对非核心功能采取有效隔离、错峰等措施，也能起到很好的作用。比如在直播活动中，最常用的功能点就是直播间的进出、直播视频的推拉流、礼物赠送、IM聊天等，但是对于上面提到的内容，核心功能点是直播间的进出，直播视频的推拉推流。如果容量无法支持，可以关闭赠送和IM聊天功能；另一种场景，直播间的创建和直播是两个不同的场景，但是可能占用相同的组件资源。在直播高峰时，可以考虑暂时错开直播间的创作功能，避免资源竞争。全面检查，寻找不合理表现活动结束后，需要对业务、应用、平台等方面进行全面检查。如对监测数据进行综合数据分析；高峰期业务TOPURL/SQL分析；应用层面的服务链路性能和错误变化；从平台层面检查云平台的带宽、连接数、过载情况等；从资源、业务行为、代码健壮性等方面寻找异常，并逐一形成分析和跟踪措施，并在架构优化、扩缩容、代码优化等方面安排改进。03良好的组织联动是成功的关键团结、分工明确、联动沟通中良好的组织纪律、明确约定的工作沟通方式、信息透明和团队间的积极协作是确保活动有效和高效的条件。业务活动保障通常由多个团队中具有多个角色的临时组件团队完成。有运维、业务、产品、架构、开发、测试、平台、基础设施等各个技术领域的人员，也可能涉及外部厂商。我们需要采取措施，把很多来自不同背景的人组织起来，避免混乱，让大家团结起来，朝着一个共同的目标共同努力。与供应商的沟通同样重要。在生产问题的诊断中，供应商是经常被忽视的角色，比如网络CDN、ORACLE厂商、网络设备厂商等。应用层面达到一定优化程度后，供应商从底层做起，协助提供优化方案，往往可以达到事半功倍的效果。当然，在业务保障的过程中，与服务商保持透明也是一个基本要求。生产变更操作必须经过审查、记录和透明化。在保障活动过程中，所有生产变更必须统一审核后方可操作。从历史上看，生产变更一直是一项风险极大的工作。在保障业务活动的工作中，专业团队往往在“发现某个参数好像不对”的时候默默调整参数。支持团队中未记录此方法。当参数调整导致生产出现问题时，无法追溯变更，无法快速定位异常原因，往往导致问题定位效率低下。因此，无论是架构检查、压力测试、扩容、业务高峰后的检查措施等流程，都需要对涉及的生产变更计划和计划进行审核、记录，并形成具有跟踪措施的变更计划。信息必须透明。写在上一世，世上没有美好的时光，却有人背负着你前行。在抗疫一线，医护人员的无私奉献谱写了一首首动人的赞歌。在互联网时代，一场轰轰烈烈、为用户喝彩的大型商业活动背后，往往有无数日夜奋战的IT技术专家。业务活动的保障和支撑是一项强度极高的IT事务，需要IT人员具备敏锐的信息收集、分析和应急响应能力，同时需要各个技术领域的专家贡献专业能力。只有在每一次活动中积累经验，不断寻求技术创新，才能在每一次业务活动中超越自我，突破自我，为运维人创造属于自己的传奇！作者：黄卫星，平安科技运营工具平台团队监控规划与方案实施组，负责平安集团Wiseapm监控产品的建设与实施。
