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线响应时间,最大响应时间综合纬度评估是发现不了它的存在。
  • 如何更有效安抚客户/业务代表,加强和服务台的紧密合作和