背景
今日公司进行面膜新品发布，新品分享有奖裂变活动，活动效果很好，异常火爆，可是系统很不争气挂了20分钟，作为系统支持的负责人觉得很惭愧，夜不能眠，在进行深深的自省。
过程回顾
作为系统支持负责人我是有一套系统稳定支持的理论：
- 活动方式/内容的理解
- 活动风险的评估
- 活动所需资源的评估
- 活动产品基础数据在系统核对
- redis扣库存
- 生产验证
- 活动核心链路压测
- 服务台的故障时的指引与术语
- 限流的制定
- 慢URL的梳理
- 应急措施的制定
- 集思广益的风险梳理
- 活动前24小时变更冻结
- 现场支持人力锁定
为什么还是挂掉？
为什么还是挂掉呢？是我的套路不行，还是我空有一身“内功”没有好的“武功”和“宝剑”发挥出来？
武功和宝剑
千里眼和顺风耳
- apm工具，可以助我实时掌握系统的流量、吞吐量和响应时间、系统错误的定位。
- aiops/grafana系统及应用组件资源使用实时监控
屠龙刀和倚天剑
- aiops的自动扩容助我快速完成节点的纵向和横向扩容
- 流控系统，助我完成全站和个别URL的流量塑形。
战队
我有一帮好兄弟，通力合作：
- 活动产品负责人尽心完成基础数据的录入，核对，生产测试。
- 有开发测试好兄弟完成功能开发，功能测试，压力测试打磨系统的处理能力。
- 有基础架构的伙伴们提供计算、网络、安全资源
- 有运维开发的小伙伴打造监控，自动化利器。
- 有稳定支持的伙伴们全程关注，随时准备系统救援。
- 还有服务台的小伙伴全程的前端体验和客户故障引导。
战况
- 开局：13：30 分，全部小伙伴就位。13：45观察到流量攀升，发出预警，13：50稳定性支持的伙伴发现后台出现大量报错，向开发测试发出预警评估是否影响活动，并得到及时响应。直到13：59，系统响应正常。
- 冲击：14：00，活动开启，结果14：01，apm利器显示系统响应变慢（访问量是历史峰值6xxx，是过往的2倍），活动前端使用体验官（服务台）警告前端白屏，请求超时。稳定支持的团队立刻检查各组件使用情况，资源飙升厉害，但未到临界线，**此时不确定问题所在 **，于是我立刻执行全站限流，确认后备方案APP端是可以使用，然后指引服务台的兄弟及时与市场沟通；紧接着奔赴开发测试身边确认问题是否与之前的报错是否有关。
- 变阵：14：15 确认问题所在，对问题URL（历史峰值每秒处理350rps，实质上平均响应时间8秒，估计次数请求处理占用大量应用线程）实施限流，流速240rps，全站限流打开以最大量满足用户需要；执行扩容。
- 初见成效：14：20 系统使用体验陆续恢复
- 收尾：受到到开闸冲击，部分组件出现假死状态，系统依然不太稳定，偶发出现超时，稳定支持团队有序重启组件重整资源。系统使用恢复。
复盘
- 有利器，有好伙伴，为什么开局失利呢？本次活动主要瓶颈于小程序调度微信公共接口code2session，在并发量超过150rps，返回时间在1s以上，当并发量达到350时，返回时间是8秒，此时我小程序自身timeout时间是3秒，自身选择退出，由于改接口强依赖，这个接口失败后，代码运行不下去，前端白屏。
- 为什么在慢URL没有检查出来，在apm工具中显示在接口在非活动时间并发量底，响应时间短，我们检查规则，按调度次数和95线响应时间，最大响应时间综合纬度评估是发现不了它的存在。
- 如何更有效安抚客户/业务代表，加强和服务台的紧密合作和信息共享，由服务台及时有序通告“战况”。
以后要怎么做
- 外部/跨平台调用一律不信任，采用限流方式控制住最佳吞吐和响应时间比。
- 完整梳理一次外部/跨平台调度接口。
- 接口最大能力的获知，全站URL/API按实质能力配置限流。
- 制定落实战况沟通机制，组建作战室，指挥中心。
- 完善故障根因智能分析工具/平台。
感概
其实我并不想讲每次活动的流量都是过往的几倍来解释/开脱故障，我更想说我们的系统平时就像一个懒人那样，不常做运动，很多指标看着正常，其实都是亚健康。我更希望多做活动，让系统天天跑步锻炼，而不是突然间让他跑马拉松或200米冲刺跑，如果活动变成日常化，常态化，系统天天得以锻炼，我们的武功不要生疏，宝剑利器不要生锈，我相信即使跑马拉松和打大战役，也是没有问题的
