标签：降级 过程 问题 内存 引入 bsp 比较 最好 重启
618大促已过，618备战以及活动总结同步如下：
一、前期准备
1、 梳理上下游依赖，如上游接口不可用确认对上游是否相应预案，当我们接口不可用下游是否有相应预案。
2、 梳理降级预案、redis、数据库等，主要是使用的redis集群有哪些，核心redis集群和数据库是哪些，此次双11活动
前2个月各种问题频发，配合redis方做了集群扩容、集群构建独立分区，双11当前redis很稳定。
3、 摘机压测，主要为测试单机能承载的流量，理论上乘以容器数即为该服务可承载流量，实际上大促时整个
机房网络、容器所在物理机cpu、内存、网络等外部条件会发生变化，故单机压测是必要的，但还是需要上
下游联合压测
4、 性能优化，压测后会发现性能问题，需要进行优化，不然扩容后问题可能会被放大，进而影响系统稳定性。
5、 流量预估，根据618会议以及上下游沟通以及当前流量预估流量。
6、 上线游压测，降级预案演练，此时压测主要根据预估的流量上下游进行压测，压测时会进行多个回合，一般
第一回合压测到最大极限值，cpu、内存等90%或tp99 500以上，第二回合我方降级后压测看极限值，第三回
合压测我方恢复下游进行降级演练。压侧后记录相应压测量信息。
7、 扩容，根据流量预估单机压测、联合压测进行扩容，扩容需每个业务根据流量情况进行相应压测。
8、 联合压测，扩容后根据流量还要进行压测，并会根据压测对各个业务间进行调配。
9、 Redis稳定性、服务逻辑梳理、活动开始前上线业务review，活动前对redis、依赖服务以及邻近大促上线业务要进行
详尽review，确保不要在邻近上线时引入问题，此时引入修改风险大。
二、活动开始
1、6月1日凌晨跟进流量，线上服务性能、稳定性、可用性跟进。记录流量等指标。
2、6月17日集团值班，跟进9:00开始每个整点流量以及系统性能、稳定性指标。并根据当晚8:00 10:00流量对降级预案
进行调整，并同步相关人员知晓。
3、晚10点后可根据业务特点对相应业务进行重启以及关闭日志操作，以服务最好状态迎接0点大促。
4、一般降级在23:55进行，0:05通知上线游进行恢复，此次618未进行降级操作。
三、活动总结
1、总结备战、活动开始过程中的相应问题，按照优先级进行排期处理。
2、总结备战过程作为下次备战参考。
3、记录相应数据，已做后续大促，以及同步大家知晓。
四、此次618相应问题已构建事项列表，有些项已进行沟通，并开发中，有些已沟通，每件事进度会一直进行跟进。详见附件
五、大促重要的是前期准备梳理以及各项压测以及代码review等工作、重要的前期各项工作做细，因为大促时人会比较紧张，
指望临场去应急处理引起更大问题，出错风险很大。
标签：降级 过程 问题 内存 引入 bsp 比较 最好 重启
原文地址：http://www.cnblogs.com/freedommovie/p/7144154.html
