刚刚经过双十一，作为一个电商的研发人员，在刚刚过去的双十一中系统受大促影响，峰值请求量翻了有100倍，在一定时间内系统还是出现了雪崩的情况，最近一直在反思，在优化系统，把最近思考的一些心得这里总结下。
图片来源网络
按照目前的经验，线上的事故绝大多数发生在3个场景下：发版，刷数据，大促。
下面针对这3个场景分别分析、讨论下预防策略。
发版相关
按照时间维度，可以将发版分为3个阶段；发版前，发版日，发版后。
发版前：一般不会直接导致线上事故，但是发版前转侧不及时，容易压缩测试时间，导致测试不充分，存在带bug上线的风险。所以发版前最重要的事情是如期转侧，留给测试充分的验证时间。
发版日：发版当天是最容易出现线上事故的节点，要慎重对待。针对发版日总结几点，研发同学一定要严格遵守。
要有详细的发布计划：研发leader在需求上线前要准备发布计划，包括跨领域的依赖关系，发布先后顺序，需要提前准备事项（更改表结构，新服务部署各种权限、环境准备），回退方案等。
发布后线上验证：
1.主流程验证：首先要验证发布功能点是否正常。其次要验证整个下单流程。线上出现过多次发布A模块，但是会影响B模块，如果只验证A模块会有遗漏。所以不管发布什么功能，都要把整个下单流程都验证一遍。这里最好有自动化回归测试用例，不然每次手工验证确实比较耗费人力。
2.监控观察：发布新功能后，研发要观察监控曲线至少30分钟，监控曲线、告警均无问题才可以离开，若有问题要迅速回滚版本，然后再定位问题。
3.灰度发布：所有0级系统版本发布都需要灰度。灰度时间至少半个小时以上，时间太短体现不出灰度的意义。
发版后：发版后出现线上事故，一般大多数情况是由于网络环境、机器负载过高、硬件问题导致发生，当出现这类问题时候首选要快速定位原因，拉相关运维同学进行处理。
刷数据相关
刷数据风险非常大，刷数据种类繁多，没有固定形式，每次都需要单独定制，一般刷数据都是时间紧、任务重、研发压力大。没有太充分的时间考虑全面的方案以及经过充分的测试，风险极大。所以针对刷数据问题讨论总结了几下几个策略。
1.拒绝；能拒绝的尽量拒绝，不是一定要通过刷数据解决的问题就不要通过刷数据的方式来解决。
2.double check；刷数据的脚本，sql要有两个研发相互检查下，并且要经过测试验证后才可以动手执行。
3.灰度刷；在执行刷数据的脚本的时候要采用灰度刷的策略，先刷一部分数据，待验证无问题后再执行全量刷数据操作。
大促相关
在大促的时候由于请求量是平时的若干倍，会触发平时发现不了的一些问题，针对大促这种情况，要提前做好如下几点准备。
1.压测，提前模拟线上流量对整个系统进行压测。
2.降级处理，各个领域都要有自己的降级方案，当依赖方出现问题时，要能够做到快速自动或者手动降级。
3.扩容，每个领域要具备快速扩容的能力，要不断演练扩容方案，当出现问题运维给到机器时能够做到10分钟内完成扩容处理。
网友评论