又到双11，目前苏宁易购在多渠道融合、促销节奏变化等方面有着更多的技术挑战。如何保障系统高峰扛得住、长期平稳是每个大促人必须面对的问题。我们总结了一些大促的保障套路和经验，历经多次大促实战，取得了不错的成绩，也希望能给大家带来一些借鉴。

本文主要包括苏宁中台核心业务面临的挑战、保障工作的项目化运作、几个核心能力建设的经验。

1. 中台核心业务面临的挑战

苏宁中台是消费者平台和商家平台数据链接的中枢平台。中台主要负责会员、售前、交易、履约、数据分析相关的工作，涵盖会员、价格、库存、销售状态、订单、促销、数据分析等核心业务系统的管理和执行。中台面临的挑战主要来源于两大方面：一个是核心系统自身的职责，另一个压力是零售新模式的快速发展。

1.1 系统职责压力

中台业务的特点决定了我们的压力线。

浏览线的压力：高并发、低延迟，涉及实时价格查询、销售状态变更、促销活动展示、库存状态等等。

交易线的压力：高并发、高稳定、业务逻辑复杂，涉及购物车、订单、履约等核心业务。

1.2 零售新模式对技术的挑战

零售新模式对中台的压力主要集中在多渠道拓展带来的流量、业务的复杂度以及促销节奏的变化。

1.2.1 多渠道发展

从零售业态来讲，零售的核心竞争力是销售渠道的拓展能力和供应链的保障能力。一个负责开疆扩土、一个负责保障供给，中台恰是这两端的枢纽。中台需要应对渠道变化、输出供应链能力的要求，中台的核心职能“承载渠道、输出供应链”，更加凸显。

渠道的几个变化：

自建渠道的多元化拓展
a) 线上渠道：苏宁易购、苏宁拼购、苏宁小店、苏宁红孩子等
b) 线下渠道：苏宁门店、苏宁超市、苏鲜生、苏宁小店、苏宁红孩子、苏宁极物等
自建渠道的开放
上面介绍的苏宁自建渠道除了满足自身需要以外，也逐步把自己的渠道优势向外部商家开放，为商家赋能。
合作渠道的多元化拓展
合作渠道拓展是近几年来苏宁零售的重要变化。当前的外部形势是：线上大众化的渠道寡头化、小众化的垂直渠道在寻求机会；线下商圈依旧多元化。如何把握机会、合作共赢? 苏宁把外部形势转化为“强强联手、为渠道赋能”的内在要求。目前苏宁与外部渠道的合作正在迅猛发展。已经合作的渠道有：
a) 线上渠道：天猫、达令家、当当等
b) 线下渠道：大润发、欧尚、卜蜂莲花等

新渠道带来的流量非常明显，天猫、拼购、大润发表现突出。渠道的扩展能力依赖供应链的输出能力。在渠道大发展的背景下，中台需要更强的渠道承载能力和供应链输出能力为渠道赋能。

1.2.2 促销节奏的变化

单一集中式的促销活动的弊端越来越明显，用户不愿等，商家风险高。促销活动需要能够拥抱变化,来完成快速引流、锁定用户达成交易、满足用户高频的购买体验、使线上和线下充分互动的功能。今后，大型促销频度会越来越高、促销节日也会越来越多。中台需要一个更高水准的能力来保障多样式的促销活动。

2. 保障工作的项目化运作

2.1 为什么引入项目化运作

大促中我们经常遇到的问题和诉求：

中台系统繁多，大部分人都负责自己的系统，对完整链路不清楚。
从进度不一、粗放式、个人经验为主导的大促准备到流程化、标准化、不断迭代的工作模式转变。
能够注重数据的量化和标准化制定、能够让过程保存下来、能够长期稳定运行。
另外我们认为结果好过程差靠的是运气、过程好结果肯定不会差，所以我们希望大促保障注重过程，让各系统的责任人从意识上来积极准备。
简言之就是项目复杂，我们需要有个标准化、流程化、风险可控、可迭代的机制来保障我们的目标。项目化正好能帮助我们解决这些问题、满足我们的诉求。

2.2 项目化运作

2.2.1 流程迭代和阶段内容

大促保障的运作流程和一般项目的基本管理流程类似，分别为目标收集阶段、目标准备阶段、目标验证阶段、目标总结以及过程中的风险管控。每个阶段对应的工作内容见下表：

阶段	工作内容
系统目标收集	对整体的运营指标量化、根据系统模型和历史数据转化成到系统能力要求。
系统能力准备阶段	1. 各系统现状评估和性能数据收集 2. 系统扩容和性能优化 3. 降级和应急方案 4. 监控和告警梳理 5. 问题响应机制 6. 专项治理
系统能力验证阶段	1. 规划能力检查 2. 日常能力检查 3. 各系统的性能压测 4. 核心场景的全链路性能压测 5. 大促实战
大促总结阶段	总结相关的问题、制定改进计划
风险管控	1. 系统能力过程风险管控 2. 生产变更和发布风险管控

通过PDCA理论，我们来确保大促的质量可控、大促也能逐步迭代发展。项目化使得保障工作有了标准化的操作流程、标准化的验收指标、真正对各个系统的进度、整体质量管控起来。

2.2.2 三能一控的检查

大促的稳定主要看服务能力、监控能力和响应能力。因此我们的很多工作都是围绕着这三种能力的提升和检查的。三种能力加上风险管控简称三能一控。下面是三能一控对应的检查表：

三能一控	范围	检查表
服务能力	容量、流量的可扩展、高可用、高性能	业务系统容量和流量规划跟踪表、系统资源使用情况检查表、扩缩容申请表、接口性能检查表
监控能力	多维度告警、日常监控、活动监控、大促监控	监控项检查表、每日监控检查表、业务异常跟踪表、系统异常跟踪表、资源争抢迁移表、7*24小时问题跟踪单
响应能力	一般问题、降级、应急、特殊问题	常见问题处理手册、降级手册、应急手册、跨中心降级方案和应急预案、问题三级响应机制
风险管控	变更和发布、未解决问题	变更审核表、问题跟踪表

其实很多表格大家都有，但是我们要真正用起来、强化认知、避免流于形式。在实际操作上，经常也有流程和能力争吵。我觉得，流程的目的还是识别风险、能力是核心竞争力的体现。有流程无能力是山寨品，但是有能力无流程会导致我们没法确保能出来什么，可能好也可能是坏。

举个简单的例子，在系统服务能力接口性能检查表中，我们重点把控三个方面：设计峰值、历史峰值、实际峰值。

指标	意义	目的	时效
设计峰值	能水平扩展的最大能力支撑	提前做架构调整	明天
历史峰值	已经发生过的历史峰值流量	借鉴评估下次峰值	昨天
实际峰值	现在所能支撑的最大流量	风险安全值	今天

这个检查简单而言就是昨天、今天、明天三个时期的把握，能够借鉴昨天，把握今天，规划明天。它的核心目的就是让我们的系统负责人和架构师，站在时间轴上展望能力要求，为架构改进做好计划。

3. 几个核心能力建设的经验

前面是对核心能力的检查，检查是感知风险、解决风险是需要能力的。核心能力体现在服务能力、监控能力、问题响应能力这几个方面。但这是一个相当大的话题，我就谈下我们实践的一些经验。

3.1 水平扩展能力

高峰应对主要的途径是提升系统的服务能力，还有缓存数据减少穿透压力、还有冷热通道隔离、服务降级、流控等有损的系统防护。高峰应对需要在资源和服务能力之间需要做一个平衡。对于中台系统来说，我们要求更多的是扩展能力。对于扩展能力，不同的系统有不同的应对策略。从节约机器数量、硬件资源有较大的提升空间、临时快速地扩展的角度，系统尽可能使用垂直扩展能力；对于高并发的系统，我们都要求其具备水平扩展能力。水平扩容的能力有两个方面一个是架构层、另一个是工具层。在工具层面，我们现在支持应用的一键扩缩容、存储层redis、db的数据在线迁移能力。在架构层面，水平化扩展技术除了传统的应用无状态设计、存储层的分库分表、分布式存储系统等，对我们架构影响比较深远的是系统单元化以及数据库的预分表。

3.1.1 系统单元化

系统单元化类似微信红包的SET化，主要解决单一集群规模限制和如何快速扩展等问题。类似的，我们机房多活的单元化主要解决单一机房的规模限制、机房单点以及如何快速扩展等问题。

单元化系统的架构：

单元化：

系统单元化实际上是指集群化发展到集群分组化，系统根据规模划分成多个单元（集群），每个单元确定好自己的服务范围。系统单元化除了支撑单元级别扩展，还支撑单元分组级别扩展，就是说单元1和单元2隶属于服务单元组1。服务单元组可以应对一些更高维度的范围分组以及历史数据查询等场景。我们的系统经过单元化改造具备了很强的水平扩展能力。去年，我们对交易系统进行单元化改造，很快就使交易系统支撑了每秒万级以上的处理能力。在水平扩展的问题上，真正做到了加几台机器就可以解决。

3.1.2 数据库的预分表

一般来讲，接入服务和应用服务的无状态设计，很容易做到扩展，存储服务是最先出现瓶颈的。单数据库的CPU、IO、链接数等资源使用过高都是常见的瓶颈。

对于存储类的单机压力过大，我们一般的思路：首先向上扩展、再次垂直分库、然后水平分库。水平分库有个问题就是数据的复制和迁移，2分法能够最大程度避免数据重分布问题，但是还是需要行级别冗余数据删除。

预分表技术能够兼顾业务快速发展问题和数据迁移问题。预分表的过程：我们先预先划分一定数量的表。当规模不大的时候，就放在单库；随着规模增长可以分成多个库。在扩展过程中，只需要复制对应的表或者库就可以了，不需要对表内数据重新分片。如果业务增速度比较快，可以提前把预分表的数目弄得更大些,并且预分库。

3.2 监控能力

对于监控能力，我们的做法：在时间上7x24小时异常监管、重点活动的监控、重点促销节的监控；在维度上，做到工具立体化监控；在机制上面，做到预警和告警自动化。因为内容比较多，主要讲下在监控内容上的把握。
对于系统层面的监控，我们主要把握异常、服务曲线和资源曲线这三个大的方面。

异常
异常包括系统异常和业务异常。
我们的经验是把异常监管起来、制定优化指标、把异常降到更低的水平。只有平时把异常消灭掉，大促的时候才能不是靠运气。

异常监管

服务曲线类
服务曲线主要看三个指标：调用量、响应时间、调用异常。

服务曲线的指标很好理解，不管是自己的应用还是nginx、varnish、redis、mq、db都是看服务的流量、服务的影响耗时、服务的错误率，只不过各种应用叫法不一样而已。对于流量，Redis叫命令数、db叫topsql，但是它们表达的含义是一致的。此外重点看下曲线的趋势、曲线的同比和环比。这个对我们识别风险、提前预测业务量是非常重要的。
系统有没有风险，在服务曲线上看时间趋势和异常。通过下图的时间曲线平滑，就可以判断该系统运行大致平稳。

资源曲线
资源曲线相对比较复杂，因为资源类型比较多。资源曲线主要有CPU曲线、内存曲线、磁盘IO、网络IO曲线。对于资源曲线，我们需要明确一个认识就是服务依赖于资源，资源来支撑服务。看资源曲线主要得到两个结论：一个是目前资源能支撑的服务量、另一个是目标服务量需要多少资源来支撑。这和USE理论的利用率和饱和度可能不谋而合。

3.3 问题响应能力

我们每天面对很多故障：有内部的、外部的；网络的、机器的、内核的、中间件的、应用程序的。实际上软硬件在功能、性能、安全上的故障无法避免（加密货币的程序好像可以避免），所以我们需要机制来解决而不单靠个人能力和经验。

我们对故障的几个核心认知：故障预警、故障隔离；能自动的坚决不手动，提高故障自动迁移的能力；应急方案多考虑流控、业务降级、故障迁移，要演练要丰富等。在实际中，我们遇到的故障很多、整体试错成本也很高。这个是由多方面原因造成的，导致救火也在所难免。救火需要速度，更需要分析的手段。

故障分析需要掌握一些分析方法。它主要有两个层面的分析：宏观分析和微观分析。宏观分析涉及跨网络的链路层面、机器资源等方面。微观分析通常限定在不容易诊断的系统内部的进程、线程、方法、底层依赖这几个层级。

宏观分析起到快速定位的作用、微观分析能够找到根本原因。微观分析成本很高，分析的维度太广，而且不容易入手。这个和高效的医疗诊断是类似的，要求我们首先能从宏观诊断的就先用宏观，避免上来就用微观诊断，导致漫无目的、无畏的消耗。

其实微观和宏观并不是对立和绝对的，更多是相对于检测手段难易而言。宏观是微观、微观是宏观。宏观现象如果没有工具支撑，也会变成微观现象，微观现象如果有工具支撑也会宏观起来。

常用的分析方法有链路分析法、最小环境法、排除法、加压法、问题复现法。

我们经常面对问题是响应慢问题和资源高问题。

响应慢问题的定位过程
A. 定位最快的是设置系统的耗时预警。
B. 如果没有预警，通过调用链监控，快速定位到所在系统的接口。
C. 查看客户端和服务端的慢日志情况，观察慢是局部现象还是整体现象。
D. 重点看下访问量、资源使用情况和异常信息。
E. 然后再去深入查看是不是有锁、gc、线程情况。
F. 方法级别的耗时、CPU使用情况。

2．宏观案例CPU高

这是个一台数据库CPU资源曲线，资源明显消耗太高。通过曲线形状分析，我们可以很容易发现它具备周期性，推断它应该是个定时任务。

通过数据库监控，发现执行的SQL语句有大量的读写、不走索引的现象。根据前面的分析，我们很容易定位到这个是数据迁移任务，然后临时暂停这个任务，以后做索引优化和控制迁移数据量的大小。

4. 总结

大促保障是一个非常大的话题、涉及的面很广、足可以写本书。但我希望通过这篇文章，大家能对大促的挑战、流程和核心能力有个明确的认识，然后在理论和技术上的各个方面有更多的发展。当我们有常态化的机制来保障、立体化的工具来支撑、救火越来越少的时候，我们的大促就又一次迭代成功了。

作者：
杨学增，目前在苏宁易购担任中台大促负责人，负责苏宁中台相关系统的稳定保障工作，先后在中兴通讯、通联支付工作过，在通讯、互联网金融、电商平台等领域积累了丰富的经验。
司孝波，苏宁易购IT总部中台研发中心技术负责人，负责苏宁易购中台核心交易系统的建设及大促稳定性保障大队长职责。拥有多年电子商务、企业应用领域开发及架构经验，主导了苏宁前台、中台、后台的架构分离，打造了高并发、高性能、高可用的电商交易系统，对电商分布式系统的建设具有丰富的实践经验。

创作场景

苏宁 11.11：苏宁双十一大促保障经验