每年 618 的大促都是一场技术团队大练兵的时候。作为技术研发人员，在这场战斗中，加深了对线上系统的敬畏之心，通过系统的备战，在技术上也得到了提升。大战在即，如何保障系统稳定，我们的备战思路是什么？

首先确定自己的备战思路，梳理核心流程、找出薄弱点，对薄弱点进行优化，针对业务进行资源隔离，同时协调压测对优化结果进行验证，并针对场景准备预案，比如降级开关在什么场景下开启，以及降级之后的影响有哪些等等，后面还要实际演练，防止实际情况发生时准备好的预案不可用。

我们知道，618 期间发生的问题都不是小问题，所以，如何做到更周密的筹备，我们可以秉承如下几个原则：

• 墨菲定律：任何事都没有表面看起来那么简单；所有的事都会比你预计的时间长；会出错的事总会出错；如果你担心某种情况发生，那么它就更有可能发生。
• 二八原则：19世纪末意大利经济学家巴莱多认为，在任何一组东西中，最重要的只占其中一小部分，约20%，其余80%尽管是多数，却是次要的，这就是二八法则。二八法则告诉我们，不要平均地分析、处理和看待问题，要把主要精力花在解决主要问题、抓主要项目上。

我们可以利用墨菲定律来梳理系统薄弱点，那些总是小问题不断的地方，一定会在某天酿成大的灾难，必须尽早解决。还可以利用二八原则梳理黄金流程，那些出了问题可能极大影响公司或影响用户的地方，就是不容有失的黄金流程。

我们以此为思路，从四个方面进行逐一介绍。

一、梳理薄弱点

1. 梳理系统架构

备战第一步，就是要对系统做一次全面的梳理诊断，其目的就是要甄别出系统的薄弱点。而梳理的第一步，就是要梳理出系统架构。通过梳理系统架构，梳理系统的层次结构和调用关系，由此排查系统调用的瓶颈和薄弱点。如是否有服务节点是热点或单点服务，是否有过长的调用链路，是否存在业务耦合相互影响等等。

以我现在负责的京东服务市场为例，服务市场采用 SOA 微服务化的架构设计理念，将服务市场设计为模块化和层次化的架构风格，高层次模块调用低层次模块，低层次模块通过接口向上提供服务。而复杂的调用链路，必然造成业务之间的相互影响，所以，通过对服务市场从部署、数据库访问、服务 PRC 调用、消息接收等进行了纵向垂直部署隔离，实现即使任一垂直域无论因为服务器还是数据库问题，影响不会扩散到其他业务上。这我会在后面详细讲述如何实现纵向垂直部署隔离。

2. 梳理系统薄弱点

无论系统架构是以哪种形式展示，我们都希望能够通过梳理把系统的薄弱点甄别出来。那系统薄弱点都有哪些特征呢？通过哪些手段能检查出系统薄弱点？

我们想一下，系统薄弱点可能引发哪些灾难，严重的有系统宕机，服务不可用，性能下降，404，CPU 100%，OOM 等等，所以，可能产生上述隐患的点就是我们要关注的系统薄弱点。对于系统薄弱点，我们可以通过以下几点进行排查：

• 检查没有脱库的功能：我们知道大促时的流量可能是平时的2～10倍，所以一些平时性能还好的查询接口，极有可能因调用量猛增，造成性能的极剧下降，如果其中的某些接口还是查询数据库的，那可能就会给数据库产生极大的压力，极端情况可能造成数据库 CPU 100%，出现服务不可用，因为数据库本身的架构设计就不是抗量的，所以对没有必要查库的功能进行脱库改造，以保证数据库的稳定，是非常重要的，尤其是那些严重依赖数据库的系统。
• 检查慢 sql：不是所有的功能都能实现脱库的，所以慢 sql 的检查就是为了保证数据库的稳定，因为一个慢 sql 就有可能把数据库的 CPU 打到100%，一是由于慢 sql 最容易出现的是没有索引，二是由于慢 sql 大多是关联查询、嵌套查询，以及使用聚合函数等造成的，还有就是慢 sql 大多需要回源查询，大量的请求会造成查询能力特别慢，还会造成其他请求无法获取连接，影响正常服务。所以，对于那些特别依赖数据库的系统，要每日订阅慢 sql，进行优化。优化就是优化数据库索引，将慢 sql 变成快 sql。
• 检查 ump 和 log：人常说，研发人员有两只眼睛，一只是监控报警，另一只就是日志，所以无论什么情况监控报警日志一定不能少。因为有了监控就能做到即时发现问题，有了日志就能做到迅速定位问题。否则，出了问题，就是两眼一抹黑，一通胡猜。我经常看到，当有些问题从客服那里投诉过来，才发现，要么该有的监控没有，要么有监控却没有报警，以及在解决问题时总是找不到关键的日志，只能干着急。
• 检查 jsf、mysql、jmq 等 timeout：设置 timeout 实际上是一种快速失败策略，使系统具备自我保护的能力。检查超时，一是检查该有的设置有没有，二是检查设置的时间是否过长。没有超时设置，则系统就没有自我保护的能力，这自不必说，当大量请求连接因为长时间运行而无法得到释放时，系统的资源很快就会被耗尽，从而造成了服务的不可用。而过长的设置，同样在访问量大的时候，就会导致请求连接积压，这也会导致系统的 CPU 快速飙升。那超时应该设置多少合适，这需要具体情况具体分析，但一个查询请求设置 10s 超时肯定是跟没设置一样的。
• 检查 redis 热 key、大 key、慢日志：热 key 和 大 key 是不同的，热 key 是某些 key 可能会被突然暴增的流量大量访问，这些 key 又碰巧集中存储在同一分片上，从而使得该分片的 IO、CPU 等资源吃紧，极端情况下迫使 redis 进行 failover 主从切换，但切换后的瞬时流量可能又一下子击穿 redis，迫使 redis 再次 failover，如此反复，服务几乎就是不可用的。而大 key 则是某些 key 存储的 value 很大，或者结果集很多，也是在可能暴增的流量下，大 key 不合理的查询，使得 value 在 IO 传输中阻塞，这情况和慢 sql 很像，又因为 redis 是单线程，所以大 key 查询造成 IO 问题就会很容易凸显出来。所以，如果检查出热 key 或大 key，就建议进行修改。
• 检查 master-slave 同步延迟：master-slave 同步延迟很大可能造成数据不一致性，这有可能影响业务正常运营，如创建订单写到 master，然后从 slaver 查询订单，但由于延迟太大，就可能影响用户查不到，你可能会说，这还好吧，慢1～2s不会有太大影响，但这个逻辑如果放在创建订单之后马上查询订单，根据查到的订单创建结算，在这个场景下，如何查询 slave 找不订单，就是不可接受的，这可能导致流程代码出错。所以，需要评估这种延迟是否对业务产生影响。