【稳定性】浅谈11.11大促之预案演练 | 京东物流技术团队

一、预案演练

预案演练主要解决的问题是：根据单个系统的应急预案，模拟应用系统的一种或多种故障场景，验证系统的可靠性。

1.1、预案演练形式

预案演练根据应急预案组织相关的应急组织机构和人员，针对事先假设的异常应急场景，通过模拟实际决策、指挥和技术操作，完成应急响应及处置的过程，从而检验和提高相关人员的决策指挥、组织协调和应急处置能力。

1.2、预案演练原则

预案演练要遵循两个主要原则:

(1)确保业务能提供连续性服务

(2)演练范围和风险影响可控

1.3、预案演练目的

**检验预案。**通过演练进一步理顺应急处置流程，同时检验应急处置方案的完整性、有效性。

**锻炼队伍。**通过演练增强演练组织部门、参与人员等对预案的熟悉程度，提高应急处置人员的应急响应效率和应急处置能力。

**磨合机制。**通过演练进一步检验部门间的应急联动效率，完善相关部门间的工作联动机制。

1.4、预案演练实践

明确演练场景。明确要演练的故障场景及影响范围。

明确风险和应对措施。提前评估预判各场景演练过程中可能存在的风险，并针对各种风险给出应对措施。将风险和措施告知所有干系人。

明确演练人员。演练人员包括组织人员和参演人员，组织人员负责演练前的策划、文档准备、演练人员与演练环境的落实、演练实施过程中的综合协调及演练结束后的评估总结等工作，以保障应急演练能够顺利实施。 参演人员负责具体演练操作实施。

明确演练技术方案和业务验证方案。演练前检查与业务验证：包含系统检查：检查数据库、负载均衡、应用集群等状态是否正常；应用检查：检查服务是否可用、交易量、交易成功率等指标是否正常；网络检查：检查负载均衡、集群、数据库间网络环境是否正常；业务验证：根据案例进行演练前的业务验证。

切换阶段。明确演练切换的各操作步骤，建议通过工具实现作业编排，自动化执行切换操作。

切换后检查与业务验证。切换后进行技术和业务验证，检查数据库集群、负载均衡、应用集群、网络环境等状态是否正常，并根据案例进行业务验证。

回切前检查。同演练前检查操作，检查系统、应用、网络等状态是否正常。

回切阶段。通过工具编排操作指令，进行自动化切换。

回切后检查与验证。回切后进行技术和业务验证，检查数据库集群、负载均衡、应用集群、网络环境等状态是否正常，并根据案例进行业务验证。

1.5、演练实施流程

演练实施流程即演练切换前后每一步操作指令，一般建议三要素形式明确，主要包含：时间，操作，内容。如演练前的操作0:00关闭负载均衡，阻止交易进入。

二、预案梳理思路

预案梳理可以从三点入手：从问题开始，从目标切入，从风险着手。

每个人思考下：如何第一时间快速止血，如何缩短MTTR平均修复时长

下面会介绍我们做的一些预案的例子。

2.1、计划预案

以大促 11.11 来讲，我们会做全链路压测，还有限流、降级等操作，以及会梳理618上线后的需求，日常定时任务&DAP结转任务的错峰执行。因为有一些业务是非实时的，比如我们每天会有报表、数据统计、数据结转等业务，在业务的低峰期通过定时 Job 执行，这时会遇到一个问题，比如当11.11 零点，流量峰值最高的时候，如果有一个定时 Job 做扫表或做大量查询，遇到其他的业务高峰就可能会造成交叉影响，所以我们需要做定时任务的错峰执行预案，以及数据DAP结转任务错峰执行。

2.2、突发预案

比如线上突然某部分服务直接宕机或不可用了，第一优先级还是要业务止血，此时会通过JSF下线操作，让流量切换到其他的服务器上。附案例

2.2.1、应急场景：机器故障JSF下线

启动条件：ump告警可用率异常,或者MDC机器异常报警，或者运维通知机房故障

应急方案：jsf下线。

处理步骤

方案一:通过行云操作机器IP的JSF下线

1.通过UMP或者MDC告警定位到具体IP，选中IP，点击\[行云\]直达行云部署。

1.选择对应报警的实例，操作jsf下线操作。

1.故障修复后（先启动再上线）

方案二：定位到具体IP，也可以通过JSF平台操作下线 http://taishan.jd.com/jsf/instance

2.3、业务预案

在大促11.11**的20点流量峰值时，我们会提前降级关闭某些服务【**因为降级都会有损，需提前跟相关业务同事沟通认可】，比如根据用户的收货详细地址（没有经纬度的地址）获取GIS围栏信息用于计算Promise时效，由于该接口耗时较长，大促高峰期会通过DUCC开关关闭降级到四级地址时效。

针对大促某业务专项预案如下：

三、灾难演练

灾难演练与预案演练的区别首先体现在参与演练的应用范围上，灾难演练是针对整个地区的整个机房发生故障，该机房所有部署的系统全部切换到异地机房的演练（比如汇天机房断网演练），预案演练是针对单个系统的某个或某几个故障场景做的应急预案进行演练。其次是在组织形式上和影响范围上的差别，灾难演练波及的系统范围多，参与人员广，预案演练波及的系统范围少，参与人员少。

灾难演练主要解决的问题是：验证当数据中心整个园区发生灾难，如地震等引起大面积停电，导致整个机房系统不可用的情况下，应用系统如何平稳切换到异地机房启用灾备系统，继续对外提供服务的能力。

四、混沌实验

混沌实验有相对固定的模式，通常包括实验设计与准备、实施执行和实验结果分析等过程。混沌实验一般通过混沌工程平台实现各类混沌实验的统一管理和执行。

实验设计和准备阶段。主要包括故障场景、稳态指标、靶点管理和实验编排等内容。

实验执行阶段。主要包括故障注入、故障观测、实验防护和故障恢复等步骤。

实验结果分析阶段。主要包括实验报告、问题分析与跟进以及统计度量等。

五、风险巡检

风险巡检验证方案即可配合上述演练验证方案同步进行，也可独立实施。它是一种白盒化的可扩展风险管理和巡检能力。自动化能力，实现分布式系统稳定性日常巡检。

定时巡检。实现按指定时间周期，指定子域范围的自动进行风险巡检。触发式巡检。实现按照特定数据指标阈值自动触发风险巡检。

案例：比如Promise定时任务巡检，通过自动化巡检工具及UMP报警信息，实现按照特定数据指标阈值自动触发风险巡检。

本文所述仍有待进一步研究和探讨，希望能为相关领域的研究者提供一些启示。文章中难免会有不足之处，希望读者能给予宝贵的意见和建议。谢谢！

参考：信通院稳定性建设

作者：京东物流 冯志文

来源：京东云开发者社区 自猿其说 Tech 转载请注明来源