618 电商搞促销，作为运维应该做什么？

[lavdemo]

帮我的朋友问下。我不太了解电商行业。

我的朋友他刚到电商公司做运维没多长时间，大家都在准备 618 大促销。结合过往各家的经验，他应该做哪些准备，有可能会遇见哪些问题，怎能预防？

[forvtwoex]

如果小公司就看看怎么提升带宽容量吧，大的就随大流了

[just4test]

先提升配置
然后等着挂。

[tftk]

准备好临时维护的文案和网页

[lavdemo]

@just4test 等着挂？那么夸张？需要做些准备才行吧

[lyh3222]

应对断网啊停电之类的吧，可以临时加下内存什么的

[b821025551b]

该加带宽加带宽，该升配置升配置，准备好随机 refuse 脚本和事后道歉文案。

[just4test]

@lavdemo
提升配置是最简单有效的方式。
更多的方式可以从业务、架构入手。
比如，使用队列下单代替立即下单。
比如，数据库拆分。

[kozora]

1.数据库主从分布
2.web 服务器负载均衡
3.CDN

[gamexg]

难道不是提前压测吗？

[ms2008]

617 要早点儿睡。。。

[lavdemo]

@gamexg 对哦，压测。谢谢

[zts1993]

压测
降级方案演练

[lumen]

看了之前的答案，基本上都做好了背锅的准备。
背锅的原因很简单，因为少做了一步工作，导致无限责任。
这里有个有限责任方案可供参考：

一、资源评估（重中之重，实力摔锅的重要依据）
　　 1.运维侧评估好当前资源，包括但不限于： IP 、带宽、存储、 DB 、服务器、网络设备
　　 2.运营及业务侧评估活动的人数、流量、包量峰值以及峰值出现的时间点（有可能是多个时间点）
　　 3.如果资源不足就要向公司要资源，如果公司也不能提供足够的资源，就反馈出来只能有损服务及具体的影响（意思是出了性能问题了这锅我们运维不背！）

二、部署扩容并测试
　　 1.不管资源够不够，该部署就部署，该扩容就扩容
　　 2.联合业务侧一起测试，功能测试、压力测试，输出结果（用于实力摔锅！）
　　 3.注意避免和别的业务混合部署，以免压力过大影响了别的功能

三、加强监控巡检
　　 1.Review 当前的监控，看是否有疏漏
　　 2.根据活动设置相应的监控，覆盖活动的所有关键路径

四、准备故障处理预案
　　 1.针对可能出现的故障场景做好处理方案

五、活动当天
　　 1.定时（比如每隔 30 分钟）查看监控视图
　　 2.团队成员轮流查看警报信息

以上，只要不是人为原因，运维都不用背锅。
至于其它什么随机 refues ，维护页面，道歉文案，那是业务和运营的事情了。

[WangYanjie]

@just4test 精辟

[julyclyde]

如果不是京东淘宝天猫的话， 618 基本上并不需要做什么
因为那几天流量会变少的

[cloudwise]

一定要压测，做活动服务器挂掉的不少呢。打个广告，可以试试我们家的压测宝（ yacebao.com ）:)

[lavdemo]

@julyclyde 真的吗？各家不是也有自己的活动吗？人群多少会不同吧？

[lavdemo]

@cloudwise 谢谢哈，好的话可以试试。

[julyclyde]

@lavdemo 人反正就那么多，钱反正就那么多，流向别处自然就不能流向这里