2021-04-15 kk日记，415系统支持战况总结

背景

今日公司进行面膜新品发布，新品分享有奖裂变活动，活动效果很好，异常火爆，可是系统很不争气挂了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米冲刺跑，如果活动变成日常化，常态化，系统天天得以锻炼，我们的武功不要生疏，宝剑利器不要生锈，我相信即使跑马拉松和打大战役，也是没有问题的