感谢您的反馈！
基础技术
商家系统大促保障解决方案
更新时间：2024/04/28
访问次数：1858
1. 前言
1.1 什么是大促保障
淘系电商以618、双十一为代表，在大促期间订单量往往会成倍增长，大促保障即商家/ISV通过业务预估、流量压测、链路梳理、限流配置、系统治理、预案演练等一系列技术及业务手段保障商家内部ERP系统在大促期间能够按照预期的正常提供服务；
1.2 为什么要做大促保障
对应公司经营来讲，大促销售额往往占据年度总销售的一大部分，提供稳定的服务对于公司自身的品牌声誉和年度业绩都至关重要。在考虑成本ROI的情况下，大促保障期望通过技术提升和可控人效达到受限成本下应对业务增长的目标，而非简单粗暴扩容，通过重点识别并解决关键技术点从而在面对大促流量的情况下系统可也稳定、正常的提供服务，从而也可更好的为消费者提供服务。
2. 大促保障过程化管理
不同行业不同商家对应的大促保障流程各不一样，按照阿里大促保障经验一般来说，基于大促的节奏，大促保障大致可以分为三个阶段：战前、战中和战后；
（1）战前阶段：聚焦大促玩法确认业务节奏、处理系统稳定性工作。
主要包括：业务和技术目标的确、大促保障关键时间点及时间节奏确认、大促保障组织保障确认、重点专项如关键链路梳理、容量评估及压测、预案保障、监控完善及值班和作战流程确认等；
（2）战中阶段：主要聚焦于系统的盯盘和问题的应急响应处理。
主要包括：限流、监控、降级、扩容，即所谓四板斧策略；
（3）战后阶段：主要聚焦于大促过程及问题的复盘；
主要包括：实际系统峰值表现复盘、异常问题复盘、后续系统改善和优化建议；
2.1 业务和技术目标&节奏确认
各行业各商家在大促期间的各业务玩法存在很大差异性，所以各商家自身系统的保障措施要根据自身具体业务情况来制定。例如对于预售业务, 流量峰值往往在大促正式前的半个月就出现了，那么对于限流&提前预案的时间节点就需相应的往前调整。所以在制定保障计划前需要与自身业务接口人确认大促的业务目标、预计单量以及提前了解平台具体大促时间节奏确认具体关键峰值时间段等；
2.2 大促组织保障确认
大促保障对于商家来讲不简单是系统/IT部门负责的事情，对于一场大促，保障系统稳定往往需要多方支持，一般需在组织层面确认各部门具体的负责及接口人，明确大促保障组织阵型，明确各角色职责，互相配合，共同保障大促业务稳定。
2.3 重点专项处理
2.3.1 流量分解&链路分析
在拿到业务口径的预估后，就需要将其拆解到各个核心链路上，构建整体流量模型，评估出各关键链路的QPS值，为后续大促压测以及扩容提供参考，所以链路分析在大促保障上是非常关键的一环。
而在聚石塔ERP场景中，从拉单到最终的出库发货回传，由于整条业务的复杂性，需要对自身系统核心链路进行细致梳理，所以一般不要指望一个人能够梳理清楚所有链路，在系统内可以通过指派各个模块接口人的方式去收集整理，对外就需要拉上各个子系统负责人去对齐上下游的流量情况。
以打单发货为例，假设日常的包裹数大概是10w-20w，假设大促期间增长3倍，那么首要考虑的是ERP系统拉单入口流量，需要评估系统接单压力，然后再将入口流量拆解到各个链路上，统计出各系统间交互的流量。对于系统间交互的情况，一方面可以通过技术文档或者代码梳理的方式，另外一方面还可以借助类似skywalking更直观的感受到系统间的调用情况。
2.3.2 容量评估&压测
在明确业务预估流量之后就需要进行系统自身的容量评估，需主动评估和盘点商家自身系统所涉及云资源产品，包含但不仅限于：ECS、RDS、短息&通信服务、网络带宽、消息中间件等；根据自身使用情况确认是否需要提前扩容以保障大促期间可正常使用。
主要包含但不限于：
- 高水位/低规格实例检查；
- 必要规格升级；
- RDS慢SQL优化；(DAS SQL审计)
- ECS水位检查；（ARMS）
- 其他云资源常规检查；
在容量评估及必要扩容结束后即可进入系统压测阶段，按照自身流量模型构建对应的压测模型，对商家自身系统进行压测摸底，聚石塔商家自研&ISV压测可借助聚石塔开放平台压测工具自行构建压测模型进行系统压测；（详见工具使用说明）
一般压测会进行两到三轮，第一轮确认系统当前最大水位，第二轮在针对上一次压测时异常的链路及系统修复或卡点链路扩容后重新摸高，重复压测只直至达到业务目标。
2.3.3 关键链路梳理及优化
在流量分解和链路分析的基础上，针对商家自研/ISV ERP使用场景，结合自身业务重点，进一步重点梳理商家ERP自身系统关键链路场景，如高风险链路识别、资损链路识别、强弱依赖梳理、外部依赖梳理等，并在关键节点针对性提升已达到最大ROI；
拉单推荐使用方式：数据推送服务 + MQ异步转单堆积方式；
一般对应ERP系统来讲，常见需要关注的关键链路主要有：
- 拉单延迟监控；
- 转单成功率监控；
- 审单吞吐监控；
- 库存占用/扣减/释放监控；
- 申请面单成功率监控；
- 发货回传平台成功率监控；
- 三方依赖系统相关监控；
- 基础云资源及系统中间件监控；
2.3.4 关键技改项优化
在关键链路梳理及压测过程中找到的问题要予以重点关注，建立对应技改专项进行必要系统优化，根据自身情况一般包含但不局限于：慢SQL治理、压测关键卡点优化、强弱依赖治理、监控预警治理、限流能力接入(AHAS/Sentinel)、预案开关梳理（Nacos配置管理）、系统及业务大盘建设等。
2.3.5 值班和作战流程确认
在大促前和各相关方接口人明确对应大促期间的值班表及问题处理流程规范，沉淀业务SOP，已做到过程中遇事不慌，可按提前准备的预案流程快速处理恢复。
2.4 大促过程中
在大促正式启动后，一方面我们要聚焦于系统的稳定性指标，另一方面就是要保障问题的应急响应处理。这个阶段的重点是利用好稳定性的四板斧。
- 通过限流或异步堆积控制过大的尖刺式流量对系统的冲击，防止系统奔溃。
- 通过监控报警及时发现系统问题，确定系统水位，做好止血对策。
- 通过降级进行系统保护，避免下游问题拖垮系统，对有问题业务止血。
- 通过紧急扩容避免系统崩溃，或助力核心业务超预期完成。
有了这些手段，可以避免出现一些预期之外的事情，导致系统不稳定。比如限流，如果预期之外出现了限流，我们可以先评估系统稳定性，没问题再放开。
2.5 业务结果及问题复盘
在大促结束后，根据系统实际表现，进行事后的问题复盘。通过复盘分析，团队能够深入理解导致问题的根本原因，从而制定有效的预防措施，避免未来发生类似问题。这有助于减少潜在的风险，保持后续业务的稳定性。从错误中学习，不断优化工作流程和系统质量，通过预防未来的问题，从而让系统稳定性为业务创造更大的价值。
3. 历史典型问题分享
3.1 云资源规格不合理
数据推送套餐选择大促版本速率，但是对应写入RDS实例规格未做对应升级，导致数据库崩溃，订单数据推送异常。
3.2 大促期间线上变更
在大促期间，尤其是流量峰值期间为解决问题临时操作线上应用发布，应用发布过程中未做优雅上下线，导致单机流量过大系统崩溃。
3.3 链路流量评估不合理
系统链路梳理过程中存在遗漏，未发现不合理系统流量链路，大促流量峰值期间导致该链路系统异常进而影响整体系统表现
3.4 三方/下游系统依赖异常
审单完成后下发三方/下游WMS系统出库，WMS没有经过压测验证，流量过大导致WMS崩溃从而影响整体业务表现；