PART1:李哥技术老师的参与双11年中大促作为技术负责人的一些经验复盘
将故事分为三大部分：事前、事中、事后。
- 事前：基本上就是相关人员聚在一起商量商量么
- 开会沟通：参加一个全局的，整体的KO会议(Kick Off Meeting，项目启动会)，商量目标啦、人员咋安排，工作如果分阶段进行呀等等。我们技术需要从中获取如下信息：
- 业务预期DAU、业务预期DAT、具体有哪些活动玩法、活动玩法的具体时间段、哪些商品参与大促，是否有第三方商品、这些商品的库存分别是多少【对于一些细节，下来我们需要与业务进行沟通，比如活动粒度是多少？宣传力度是多少？业务的预期DAU与DAT如何评估的？是否准确？】
- 流量评估：要清晰的知道，当前阶段每天的流量、DAU、DAT是多少，业务评估是多少，技术侧评估又是多少，
当前阶段的性能是否能支撑即将来临的大促，如果不能，需要做出什么调整。- 优化？怎么优化？优化哪些业务？现在优化还来得及吗？
- 扩容？扩容哪些服务？扩容到多少？为什么要扩容到这么多机器？
- 降级？什么业务降级？业务是否支持降级？什么时候降级？
- 业务梳理：
需要梳理出哪些业务是核心业务，哪些业务是非核心业务，哪些业务是可降级业务，这类数据大致可以从上一次大促获取。- 再加上上次大促到本次大促期间所产生的新项目(业务项目或技术项目)进行梳理，是否影响核心链路？是否进行了压测？压测结果如何？这些项目可能存在什么技术风险？
- 你的服务依赖哪些下游服务，这些下游服务又是如何依赖的，这是个很麻烦的事情，因为随着业务变大，依赖关系会变得非常复杂，很难判断与梳理。尽管很难，但是这个依赖关系仍然要梳理清楚，只有梳理清楚了，才有全链路。
- 压测：有了业务梳理和业务指标，那么就在技术上要能够支撑到这个业务级别，那就是压测了。
压测一定是针对生产！
- 到目前为止有两种压测方式：
- 不扩容压测：
不扩容压测一般不推荐，这种方式需要对业务指标打折作为目标来进行压测，最后在扩容的时候还是需要压测一次，因为局部压测不能完完全全代表整体压测，如果整体压测出现问题，那么所有的局部压测都是白费苦工。 - 扩容后压测：就是指
容量扩容到大促支撑位，然后进行压测。
- 不扩容压测：
- 压测一定是针对生产！
- 对开发环境、测试环境、预发环境、灰度环境、仿真环境进行压测，从而推断出生产环境的性能。
这是万万不可取的，因为环境不同，服务器的性能不一样，生产环境和其他环境的DB性能也不一样，还有一些中间件性能也不一样。所以，压测一定要在生产环境压测，但是有一个缺点，就是会对线上的正常流量产生影响，这也是不可避免的，所以压测的时候，一般都会选择流量不大的时候进行，尽量减少对正常流量的影响，一旦产生影响，请立即停止压测。
- 对开发环境、测试环境、预发环境、灰度环境、仿真环境进行压测，从而推断出生产环境的性能。
- 压测需要流量爬坡：切记不可一步到位，
按照一定比例逐渐施压，每一个坡度都观察几分钟，没问题继续施压，达到目标后观察几分钟没问题直接停止压测，不可恋战！因为大促的流量趋势就是那几分钟，长久的施压对服务器的性能有一定影响，比如CPU飙高啊，频繁GC啊等，所以在在压测过程中还需要不断观察系统整体性能，还有就是也会影响到正常的用户访问。举个例子，奥运会举重，明明只需要保证举起来三秒即可，你训练的时候难道要举起来三分钟吗？
- 到目前为止有两种压测方式：
- 限流：压测完了后，
我们需要输出一份压测报告，比如商详支持多少qps，下单页支持多少qps，下单支持多少tps等。这些数据说明了，我们的系统，有多少实例，哪个接口能承受的最大峰值是多少。那么我们就需要对这个接口或这些接口做限流【所以，我们需要拿着我们的压测报告，针对我们的服务做单机限流与集群限流。】。
- 单机限流与集群限流：
- 单机限流指的是每台机器自身的限流：机限流的目的是保护服务本身，保证自身服务不被流量击垮。
- 集群限流指的是整个服务集群的限流：集群限流的目的是保护下游服务，保证下游服务不被当前服务击垮。
- 比如A->B->C，每个服务三台实例，整个B集群最大能支持150qps，C集群最大能支持100qps，那也就是说B服务需要设置集群限流100qps用来保证C，B的三个实例需要设置单机限流50qps用来保证自身不被击垮。所以如果流量不倾斜的话，B服务每个实例会有33qps，如果倾斜的话，最大50qps。
- 单机限流与集群限流：
- 降级：限流后，我们能够保证服务本身不被击垮，保证下游不被击垮，但是，这不是我们的目标，
我们的目标是要保证大促期间商详没问题，下单支付没问题呀【所以，我们要降级，一些比较耗性能的业务降级，一些边缘业务降级，给核心业务让路。】！- 然后就需要梳理这些业务，有哪些需要降级的业务？什么时候降级？由谁来降级？什么时候恢复等。
- 应急预案与演练
- 咱们之前都听过一个老板让两个员工去买西瓜的故事，是一样的，事前能够考虑到的风险或者危险越多，然后做好准备，那咱们自身的损失就越少。当我们保证了核心链路的正常后，我们还需要考虑异常的情况。对于电商系统来说，要考虑到整个生命周期异常的可能性，比如：
打开商详页失败、打开订单渲染页失败、下单失败、履约失败等。说的都比较概括，我们当时准备了上千个预案！淘系双11大促，为了安全起见，是不会有任何依赖外部系统的，因为第三方系统都无法承受住淘系大促期间的流量波。- 如果你的电商系统有依赖外部系统的，那么你还要梳理出哪些渠道哪些商品会参与本次大促，这块也需要针对渠道做压测与限流，有可能渠道由于体系较小不支持压测，这时候你可能要考虑到在履约的时候做蓄洪与泄洪，使用真实流量来冲击渠道，用于检验渠道的性能。另外在有第三方参与的情况下一定
要有每个渠道的应急预案，对应给用户展示的文案是什么都是不一样的。
- 如果你的电商系统有依赖外部系统的，那么你还要梳理出哪些渠道哪些商品会参与本次大促，这块也需要针对渠道做压测与限流，有可能渠道由于体系较小不支持压测，这时候你可能要考虑到在履约的时候做蓄洪与泄洪，使用真实流量来冲击渠道，用于检验渠道的性能。另外在有第三方参与的情况下一定
- 最重要的是要与合作伙伴共同制定一份SLA(Service Level Agreement)：服务级别协议，服务提供商和客户之间的协议，用于确定所需的服务和预期的服务水平，对互联网公司来说是网站服务可用性的保证。
- 在这里SLA约定了客户对于合作伙伴的线上运维、计划运维、业务连续性以及故障处理能⼒的要求。做完预案后，要通过预案平台进行演练，或者人工演练，要当做到熟能生巧，大促出问题后才会显得临危不乱。
- 咱们之前都听过一个老板让两个员工去买西瓜的故事，是一样的，事前能够考虑到的风险或者危险越多，然后做好准备，那咱们自身的损失就越少。当我们保证了核心链路的正常后，我们还需要考虑异常的情况。对于电商系统来说，要考虑到整个生命周期异常的可能性，比如：
- 监控：大促出问题？你怎么知道这块出了问题？这时候需要监控，需要告警。
大促大盘监控、全链路监控、核心链路监控、压测监控、限流监控、资源监控、网关监控、渠道履约监控…
- 规范：大促期间是需要制定很多规矩，比如发布红线、红线问责、预案执行规范、紧急扩容规范、紧急发布规范…，我们这里统称大促变更规范吧。
无以规矩不成方圆，制定这些规范的目的是能让我们明确问题发生后我们应该按照什么流程去应急。还有很多其他的一些杂七杂八的，比如大促前每周周会、大促值班人员排班、大促作战室、问题的上升制度等。
- 开会沟通：参加一个全局的，整体的KO会议(Kick Off Meeting，项目启动会)，商量目标啦、人员咋安排，工作如果分阶段进行呀等等。我们技术需要从中获取如下信息：
- 事中：事中是整个环节最简单的，跨度最短的阶段，但是简单不代表不重要。主要是关注以下几件事情：
最重要的就是要持续关注告警与监控，一旦出现问题需要及时响应与止血，严格按照预案执行。另外就是关注大促每个场次的峰值情况，通过自动记录或人工记录的方式进行记录峰值，方便作为下次流量评估的依据。
- 事后：事后不就跟咱们博客文章复盘一样嘛，用以前的经验和东西为以后提供参考呗。
- 事后我们最重要的就是要做大促复盘，
盘点大促期间的一些好的点和不好的点，对于好的点如何延续到下次大促甚至更好，不好的点如何进行调整。- 业务上关注哪些商品在哪些区域更好卖一些，
哪些玩法更能让用户接受一些； - 产品侧需要关注
配合业务对于现有的产品模型做出一些调整与优化； 技术侧重点关注性能，本次大促是否存在性能瓶颈，瓶颈在哪里，如何优化，架构上是否需要调整，下次大促如何去支撑等。
- 业务上关注哪些商品在哪些区域更好卖一些，
- 其次是降级恢复，在大促前做的降级，在大促后需要对其恢复。不恢复可能有的功能就用不了了或者说不好用了或者说发挥不了原本的功能了
- 我们还需要
对于系统存在的性能问题进行持续优化改进，然后进行压测，得出结论，再优化，再压测，优化，压测，…。【每到大促，如何保障系统高峰扛得住、长期平稳是每个大促人必须面对的问题。大促期间发生的每一个问题都可能被无限放大，所以我们需要谨慎对待，这开不得玩笑。】
- 事后我们最重要的就是要做大促复盘，
PART2:JavaGuide老师的一个朋友分享自己在飞猪和美团基础架构组实习的经历【在飞猪的时候做业务，在美团的时候接触的是基础架构】
组 > 项目 > 部门 > 公司- 团队氛围还是相当和谐的组？有没有传说中的 PUA 和阿里味？
- 难处理的线上 BUG：
- 慢 SQL
- 本地缓存太大导致频繁 GC
- 例子来自Java基基老师的一次生产环境P0级事故解决过程与原因分析:某地区信息化系统，周末升级系统以后，后面连续一周，持续出现系统不稳定、宕机、服务假死、数据库锁表等事件。甚至星期五下午，出现三个多小时无法恢复系统，造成恶劣影响【你这出现的问题有可能把客户都吓跑了，还得一级一级的人去给你擦屁股，那你作为开发者你扣点啥能行？再搞不好被投诉要是出现啥欺骗行为…我的天呐】，问题逐条分析如下：
- 事件一之服务假死无法访问：
系统出现大面积服务假死，访问长时间没有响应。服务器网络延迟也非常严重。- 分析过程：一步一步排除之后，再查看数据库监控，发现数据库CPU和IO异常，
通过DBA查询数据库挂起的脚本，发现有个update请求把数据库资源全部占用了，导致其他数据库请求无法进来或者响应非常慢，从而导致服务都假死了
- 解决措施：系统优化，原来实例表是单表，数据量后续也会越来越大，就对程序做了改造，
针对这张表做了分表功能(按照时间点建立分表，程序自动处理数据，自动建立分表，相应的查询统计等都做了调整)。增加了权限控制，更新实例功能只允许管理员角色操作；强化现场实施人员培训，哪些操作是决不允许在上线期限操作的
- 分析过程：一步一步排除之后，再查看数据库监控，发现数据库CPU和IO异常，
- 事件一之服务假死无法访问：
巨人的肩膀：
macrozheng老师的文章
极客时间中的各位老师
bilibili中的各位老师
https://mp.weixin.qq.com/s/6KWdncFMKZL3-JiwHKpe6w
李哥技术老师
芋道源码老师关于订单系统的主体框架和主要业务模块的讲述
JavaGuide老师以及老师的朋友
https://juejin.cn/post/7154563048689106952
why 技术
K8S中文社区的阿里云云原生的十眠老师
程序猿DD老师关于千万级高并发秒杀系统设计思路，很详细，遇到相关需求时值得反复学习
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
