从2012年毕业加入京东起，到现在已近8年。在这8年里，见证了太多的变化：从最初各业务各自维护中间件、缓存到今天的云上统一按需分配；从每逢上线就要求运维同学帮忙到现在研发可以自主一键上线；从用物理机线上部署业务到如今拥有全球最大的docker集群；从当初的.net、SQL Server、Oracle切换到Java、MySQL时代。在这个过程中京东基础设施系统从几乎零基础到如今涵盖人工智能、云计算、物联网、大数据等多种前沿技术的京东智联云，承载了包括京东零售、京东物流等在内的数千个业务系统。

在刚刚落幕的第 17 个京东 618 大促中，京东智联云作为京东 618 的技术基石，起到了极其重要的保障作用。618大促作为京东创立的的电商活动，经历过这些年的发展，已经变成整个电商领域的盛大节日。我们也在多次的大促备战工作中，积累了丰富的经验，本篇文章我就和大家聊一聊关于618大促备战的支持工作。

早些年时候，考虑到采购机器需要一定周期，通常每年第一个季度就会开始评估当年618大促的业务量，等到四五月份机器到位以后，才能及时把机器上架到位，确保6.1开门大促之前机器资源是充足的。

自从2016年开始，京东智联云逐步开始发力，京东集团的业务也开始不断迁移上云。如今零售、物流等核心业务都已经部署到京东智联云上，大促期间需要的资源全都可以在云上按需获取，全集团资源也都可以轻松实现弹性可伸缩。有了云的技术加持，大促备战可以做到事半功倍。

每年的618 大促备战都是全集团各个部门通力合作的结果，根据不同阶段，我们可以把大促备战分为8 个步骤，从资源评估到模拟压测、从预案整理到线上演练，直至最终的大促复盘。每一次备战都是一系列复杂的工作，大促成功的背后离不开一大群可爱的技术人员无数个日夜的辛勤付出。

Step 1 识别保障范围

所谓识别保障范围就是为大促活动确定大的边界范围，整个集团的业务线成千上万条，哪些业务是这次大促核心链路上的业务，哪些是核心0级系统，哪些是核心1级系统？在大促备战开始之前需要明确边界范围，明确要保障的业务优先级，才能更方便后面大促保障工作的展开。

Step 2 业务量预估及预检查

例如一个业务访问的网络流量预估是10 Gbps、访问QPS预估是100w/s或者订单数预估每秒有多少万单等，基于评估的业务量就可以去评估整个业务链路上需要的资源量。比如负载均衡器带宽是否足够，应用服务器部署的实例数是否足够，缓存大小是否满足需求，数据库空间以及性能是否满足需求等。如果不够需要扩容的就可以提前进行扩容，如果整个资源池资源紧张，还需要发起采购的就需要提前发起采购，确保大促之前资源能够到位。

Step 3 预案整理

各个上层业务团队以及基础系统团队都需要提前整理好预案，尤其是核心预案。所谓核心预案就是大促期间可以快速保命的预案，预案的处理原则要求尽量简单直接高效。如服务的高可用，在真正有异常时，预案可能就是主备切换。当然这种主备切换在很多系统中是自动的，如云数据库RDS。当系统检测到主库宕机时会在几秒钟时间内将从库提升为主库，从而确保整个线上业务几乎不受影响。除了这种自动切换外，我们还需要做好兜底方案，万一主库因为某些特殊情况表现异常，希望可以主动做一下主从切换时也可以人工在控制台一键切换。

在预案整理环节中，服务高可用是非常重要的部分。服务高可用可以分为几个级别：首先是Region级别的，如图2所示京东智联云上有提供华北-北京、华南-广州、华东-宿迁、华东-上海地域。Region级别指的就是一个地域，通常是城市级别的，Region下还会再分AZ(Availability Zone, 可用区)，可以简单理解为一个AZ约等于一个独立的机房，比如京东智联云华北-北京这个Region下有可用区A、可用区B、可用区C三个独立的可用区。

对于重要业务如果有需要可以把重要的数据从北京同步到上海。像物流很多库房是分布在全国各地的，资源部署上也会在就近的Region部署相应的服务。每个系统在同一个Region里部署的时候都需要考虑跨AZ的情况，比如应用实例部署到云主机的时候需要跨AZ部署，确保一个AZ异常时另一个AZ的应用可以正常对外服务。申请云数据库或者云缓存等其他资源时，选择跨AZ就可以直接创建出一个跨AZ的数据库或者缓存实例，当某个AZ异常时，可以平滑地切换到另一个AZ，确保业务尽量不受影响。服务高可用一般是靠主备或者无状态的服务部署多份(跨Region或者跨AZ)等来解决单点问题。根据场景不同，当出现异常时可以是自动切换的，也可以是人工在控制台进行切换。

除了服务高可用，预案整理还有一个非常重要的部分是业务降级。所谓业务降级一般指当某个业务如果超过了其不能承受的范围时，可以进行限定保护，牺牲掉一部分业务流量从而保证至少有一部分是可以成功访问的。例如当某个用户访问请求非常大时，可以将用户做一定的限制，超过阈值时访问将会失败，从而确保在整体资源有限的情况下其他正常请求的用户可以访问成功。甚至当正常的流量大到一定程度以后也是需要有能力放弃一部分流量来保证其余大部分流量是正常的。降级思路实际是贯穿在整个业务链路中的，比如当应用实例部署很多时，每个应用实例的数据库连接池也是需要做好控制的。如果连接池过大很可能造成数据库压力太大，而站在数据库的角度自然也是需要做好最大链接数限制，确保即使应用实例的连接池配置得过大造成有数据库压力大的时候，数据库自身还是有能力保护自己不被打趴下。这种贯穿整个链路的降级保护思路也可以理解为系统间不信任原则的体现，即任意的A服务(模块)去调用B服务(模块)时，虽然在内部实际开发的过程中，A服务会尽量的去保护B服务，但B永远是不信任A的，B需要根据自身的情况做好自己的保护工作。

除了降级保护以外，还有一类是弹性扩容预案，一般资源扩容在大促之前就会全部扩容完毕，坐等流量洪峰的到来。但是也不排除在大促中会出现少量业务的流量超过了预想值，或者依赖的资源因为机器较老性能较差导致承接流量洪峰时压力较大的情况。尤其是当上游系统的生产流量已经往下游走的时候，下游压力比较大，此时除了降级保护以外还需要能快速在线上扩容来满足整个生产流量往下走。在大促业务压力高峰时间点进行扩容在工程实践上来讲实际是一把双刃剑，对各级系统的考验还是非常大的。618大促这种有明确的时间点预期以及压力预期的业务场景中，如果可以提前在业务低峰期做好合适的扩容准备才是最理想的。

Step 4&5 监控及报警梳理

监控是我们看系统的眼睛，是线上系统的感知体系。如果监控没有做到位的话，整个系统就是两眼一抹黑的状态，线上运行是否正常就全靠人品和运气了，整个系统的运行就变成了玄学，所以做好系统监控是至关重要的。

监控和报警总是相辅相成的，监控是通过各种方式不断去观测整个系统的各种指标，报警则是发现指标有异常时可以及时通知到对应的值班人员及时介入处理。

监控可以分很多类别，最基本的是存活监控，我把它们称为如何活下来，也就是优先要保证能否活下来这个底线，存活监控一般包括IP存活、端口存活、服务存活等，一个服务是死是活是需要可以明确感知的，如果服务宕机了，需要第一时间可以检测到并发出报警，除了这些机器及服务层面的存活，还有整个AZ(机房)的存活，如果整个AZ出问题了，对整个业务的影响是什么，能否监控到能否发出报警等。

在活下来这个底线保住的情况下，第二类监控是解决如何活得更好的问题，比如TP99到了几秒，CPU使用率是不是过高，内存占用比例是不是过大，磁盘IO压力是不是过高等。这类监控一般可以帮助你快速发现系统压力，在系统真正故障或者不可用前及时介入处理，确保整个系统运行平稳。除了CPU、内存、磁盘等通用指标的监控，实际上还会有很多带有较强业务属性的监控。比如某个任务如果长期处于中间状态，很可能是某个环节出现了没有考虑到的异常，这种就需要有专门的监控用于发现这种长期处于中间状态的任务。

Step 6 业务压测及预案演练

当业务评估、监控报警、预案整理都梳理完，下一步重要的事情就是将整个业务链路完整串起来。例如某个业务预估订单量是10w/s，那就需要采用压测机器人模拟相当的业务量从源头开始压测，观测整个链路在压测过程中的监控指标变化情况。如果有异常要能及时报警，并按预案进行处理。这种完整的业务链路压测代价其实是比较大的，各个上下游系统需要能够处理识别出模拟压测的订单，确保压测产生的订单不会影响到线上生产的订单。

除了业务全链路压测以外，各个系统还需要根据各自系统的特点进行演练，比如云数据库RDS，在618大促之前会对线上核心业务构造主库宕机等异常情况，观测系统自动切换时间以及线上业务的表现等，保证即使数据库发生异常也可以秒级自动切换，确保业务表现平稳。此外，数据库还会单独演练数据一键恢复等功能，云数据库除了每天会做一个全量备份外，还会实时将增量备份上传到云存储(oss)，确保即使有异常，在云上也是可以一键将数据还原，解除上层应用的后顾之忧。

Step 7 值班

京东618大促备战的绝大部分工作，不论是业务评估、预案整理、监控报警、业务压测还是预案演练都是前期准备工作，当这些前期准备工作做到位后，6.1开门大促开始时反倒是从容的，需要做的就是做好值班工作。值班同学24小时无缝衔接，确保线上报警可以第一时间响应，如有异常按预案处理即可。

Step 8 技术复盘

大促结束后，还有一个重要工作是大促复盘，团队一起回顾大促备战到大促结束的整个过程，审视哪些是后续需要改进完善的地方，哪些是未来需要进一步加强的，为下一次大促做更长远的准备。

以上就是京东618大促完整的技术备战工作流程，这个过程看起来并不算复杂，但备战是整个集团各个团队共同协作一起完成的，这个过程中会涉及到多个事业部多个团队非常多业务的很多细节，需要拉齐大家的信息以及认知，并确保动作的同步，在大规模工程上本身就是一件很有挑战的事情。大促不是一个人、一个团队或一个事业部就可以单独搞定的事情，需要大家一起同心协力，共同努力。