智慧并不产生于学历,而是来自对于知识的终生不懈的追求。这篇文章主要讲述高涨的用户热情如何成了压垮服务的流量相关的知识，希望能为你提供帮助。
- 事件描述
|
|
| 金九银十的销售旺季，在十一黄金周达到了顶峰！加上销售部门在全国门店的预热和促销战役的铺开，用户的购买热情空前高涨。而就在这速燃的火焰刚刚起头，如同空气被抽走般，所有的业务指标在上午9：10就出现停滞，并开始调头下坠。前方的销售团队如热锅上的蚂蚁，眼瞅着用户的业务办单无法继续，长时间的等待页面导致用户放弃，错失宝贵的销售机会！
从监控页面上，首先爆出问题的是一个叫BPC（Business Process Controller）的服务。具体问题是BPC的pod不断重启，无法问题提供对外服务。BPC是办单业务的核心调度服务，负责获取用户输入信息，以及和其他的服务进行通信，并将数据处理结果返回给前端页面。用户将图片信息上传给OSS 服务(Object Storage Service)来进行存储，大量的用户请求使得OSS需要完成大量的I/O操作，线程资源很快耗尽。由于Linux kernel的一个??bug??，导致pod 不能在fail了的情况下进行自重启，很快就失去对外响应；二者之间的同步调用模式又导致了BPC负责和OSS通信的线程数量不断上升，CPU开销急剧上升却得不到及时释放，对外部访问的响应中出现大量非HTTP 200的错误，根据pod健康策略，最终导致BPC所在pod重启。 技术团队经过一个多小时的问题分析和诊断，决定将BPC服务进行扩容，同时将OSS重新进行部署并扩容：从3个pod扩到6个。到10：50上述操作都完成后，业务有了恢复，但很缓慢，并没有达到预期水平，而另外一个业务—循环贷—出现了越来越多的500错误返回。此时的网络监控结果显示有大量的数据丢包现象，看来是办单业务的增长导致了循环贷业务的带宽被挤占。 网络团队实施了紧急预案，将办单业务从主宽带运营商切换到备份宽带运营商，并扩容带宽。随着业务带宽的隔离和扩容，办单业务得到了进一步增长，而且循环贷也恢复到了正常。此时已经是12：50了。 正当大家要松一口气的时候，办单业务中的用户身份审核组件UWS（UnderWriting Service）发出了警告！由于办单业务分为两个主要步骤，首先是用户信息的收集以及信息的存储（比如上述OSS存储的用户图片），然后是由UWS根据第一步的信息对用户进行评分。BPC在第一个步骤结束后，以RabbitMQ作为渠道通知UWS进行消息的消费，启动评分过程。此时的UWS在面临大量来临的队列消息时，撑不住了！在对pod数量进行扩容和增加连接池的容量后，在13：55左右，评分系统也可以正常处理评分请求了。 本次持续时间长达近5小时系统故障，恰逢一年中最黄金的销售时段，带来了巨大的业务影响，近千笔交易的损失，数百万的销售金额打了水漂！ |
- 时间线
| 时间
| 事件和行动
|
| 09:42
| 9:42，故障工单被触发，显示从9:30开始，自助办单
BPC
的K8S
pod
处于不断重启状态，OSS
服务健康状态出了问题（health接口无返回）。
|
| 10:00
| 3个事件管理员和3个高级指挥员同时上线，推动事件调查并统筹管理，迫切的进行根本原因定位和分析。
|
| 10:50
| 技术团队将自助办单
BPC的pod数量
从6个扩容到20个，将OSS服务迁移到新建pod上并成功启动。令人意外的是，自助办单
办单业务注册量只有缓慢增高，此时，支付交易的‘500’
报错量却增多
|
| 11:30
| 随后，技术支持团队发现外部网络有高带宽利用率和高丢包率的现象，并得到网络团队的证实。
|
| 【高涨的用户热情如何成了压垮服务的流量】12:50
| 权变措施被执行——把自助办单业务量从主宽带运营商切换到备份宽带运营商之后，网络丢包问题被成功修复。
支付的交易业务也开始逐步恢复，同时自助办单和支付的贷款合同注册量也开始回升。
|
| 12:50
| 伴随着自助办单业务恢复。大量评分请求快速流转到UWS，导致UWS负荷超载，开始返回大量报错信息，监控图显示12:50
到13:00之间，自助办单注册量大幅提升，但是合同审批量却下降了。
|
| 13:08
| 调查结果显示UWS的故障和此前网络的问题有一定区别，联系到UWS技术团队一同调查
|
| 13:38
| 发现在UWS
服务的数据库连接池打满（JDBC
Pool
usage
100%），于是将最大连接数扩大到50个。
|
| 13:40
| UWS服务的CPU和内存使用率也有超载现象，将
UWS
pod的数量扩展到6个。
|
| 13:55
| 随后，等待处理的请求开始被快速被消费处理掉，自助办单业务的注册和审批量都开始同步快速增加。
|
| 14:55
| 为了进一步提高UWS处理请求的生产效率，决定继续将
pod
扩容到20个，连接池的最大连接数扩大到140。
|
| 15:20
| 持续监控1小时，观测UWS性能，确认其可以高效处理请求，无异常报错信息。
|
- 根因分析
| #
| 为什么？
| 答案
|
| 1
| 十月一早晨，为什么自助办单的注册量降低了?
| 客户无法正常完成（KYC，
know
your
推荐阅读
|
