案例十:03月11日政采云首页无法访问

一、 故障简述

故障简要描述： 于3月11日14:21分收到用户大量反馈政采云首页访问出现502，14:32分运维重启应用后首页可以访问，但协议商品创建等还是出现报错，14:50分架构配置限流后影响消除。

二、 故障处理过程

14:03 致虑构建staging，误操作到真线。

14:20 若谷监控报警发现真线db_item cpu 100% 【监控发现】

14:20 奕铭开始排查定位问题。

14:21 收到大量用户反馈，首页返回502【故障发现】

14:23 致虑发现误操作后，回滚线上发布。（重启后缓存失效）

14:27 定位到慢sql

SELECT parana_front_categories.id AS id, parana_front_categories.pid AS pid, parana_front_categories.name AS name, parana_front_categories.level AS level, parana_front_categories.has_children AS has_children , parana_front_categories.logo AS logo, parana_front_categories.tag_id AS tag_id, parana_front_categories.status AS status, parana_front_categories.created_at AS created_at, parana_front_categories.updated_at AS updated_at FROM parana_front_categories parana_front_categories WHERE parana_front_categories.pid = ? AND parana_front_categories.status = ?

14:32 运维第一次重启item-center，item-microservice-center应用，首页可以访问，P1恢复。【故障恢复】

14:39 定位到下面接口qps最高到1.8k左右【定位原因】

io.terminus.parana.category.service.FrontCategoryReadService : findChildrenByPid

14:47 第一次重启没有效果，流量还是很高。运维第二次重启item-center，item-microservice-center应用

14:50 奕铭联系鹏飞操作限流，10次/s,，后改为20次/s，限流后影响消除。【影响消除】

三、 影响产品线及影响面

1.所有用户无法访问政采云首页。

2.部分协议商品创建等出现报错

四、 故障原因

1 致虑误操作线上的发版

1）重启之后缓存失效。

2）网超服务在启动的时候会加载前台类目树，每个区划的第一个用户请求，都会加载缓存，导致接口请求上升。

（接口：io.terminus.parana.category.service.FrontCategoryReadService 。）

理论计算请求量：7x3000x200（7台机器，3000多类目，200区划）。

实际qps: 1800 次/s

实际慢sql：14900次/h

2.商品中心的慢sql等性能问题

1).慢sql没有加索引；

2).接口io.terminus.parana.category.service.FrontCategoryReadService : findChildrenByPid 没有缓存，直接查DB。

亮点：

跟以往故障相比，本次故障中做的较好主要为以下亮点

1.监控报警提前发现。

2.限流工具产生效果。

其他关注点：

1.误操作发版的问题如何优化？

已联系运维修改线上预发环境的jenkins标签，区分staing环境和真线环境。

2.监控页面能否有基本的定位分析功能，报警出哪个应用，哪个接口，哪个慢SQL等出现异常，有聚合分析页面？

已在监控告警Q2规划中，后续会优先做商品中心相关的监控试点。若谷，预计6月30日。【ACTION1】

3.限流工具目前架构使用较多，还需要进一步推广到业务线在应急时使用。

已在应急响应和故障演练项目规划中（包括工具以及应急流程， 演练验证。）4月份优先试点商品中心的应急响应和故障演练。【ACTION2】

4.7台web-web的性能高于2台item-center，2台item-center的能力高于DRDS，导致最终数据库cpu100%。（容量规划）

4.1共享业务要根据历史的最大请求数评估来加限流。元芳 预计3月19日完成。【ACTION3】

4.2商品中心对上游的能力，对自己内部的能力不了解，需要后续去性能分析，并输出请求数等SLA。@奕铭 预计3月31日完成。【ACTION4】

5.慢sql没有加索引，需要持续优化。

商品中心已优化部分慢sql。后续要形成慢sql等持续处理与跟踪改进机制，并输出考核指标。@时升，预计3月31日完成。【ACTION5】

商品中心结合慢sql持续处理机制，不断优化慢sql并反馈优化结果。

6.重启网超的服务时，加载类目树的方式有大量请求产生的隐患如何根除？

采用多级缓存的技术方案，致虑与奕铭等协助优化。 青松 ，预计3月31日完成。【ACTION6】

7.首页上某个节点出现问题，如何不影响首页访问？

致虑牵头测试，并确认后续的解决方案。 致虑，预计3月31日完成。【ACTION7】

五、 故障评级
故障等级：P1&P3

故障类别：程序问题

六、 后续ACTION：