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