案例七：8月26日 项目采购不可用

一、故障简述

二、故障处理过程

1.告警开始8月26日 9:05（-24）
09:05 prod-db_tendering实例告警消息发同步到运维群，运维并开始排查数据库的问题
09:07 运维收到告警电话
09:08 同步到运维群，运维并开始排查数据库的问题

待办问题处理过程，详见[P3][基础组件]8月26日 账号登陆后页面报错提示【服务器内部错误】

09:09 技术支持收到坑立平用户反馈政采云开评标页面报错以及后台报错
09:12 技术支持反馈用户中心处理，开发赵云定位到待办问题
09:14 测试居易打电话给运维重启new-backlog-center应用
09:21 重启结束后，待办恢复正常

09:27 运维发现web-bidding-open还是在告警，拉入项目采购同学进行处理

2.故障开始&故障响应 8月26日 9:29（+0）
09:29 运营群内反馈 项目管理-我的项目，一直无法加载，同时各地运营开始反馈开评标异常
09:30 运维发现pinpoint上web-bidding-open延迟很高，高延迟时间发生在数据库请求；看到db_tendering数据库CPU使用率100%，并询问项目采购开发处理进展
09:30 项目采购开发确认昨晚8点后没有发版，但对project表的status_no的索引进行过删除优化
09:35 项目采购开发把昨天删除的索引加回来，正则重启应用，问题仍未恢复
09:37 运维重启web-bidding-open
09:39 运维杀掉数据库上所有query的session, 依然没有效果
09:44 长空反馈给技术支持客服电话电话咨询量较大（5秒钟3个电话），技术支持告知是系统问题暂时无法确定修复时间
09:49 长空电话报备给远山客诉风险
09:57 技术支持报备给公司品牌部门故障影响及处理，同时开始梳理故障期间项目问题处理的话术
09:57 徐四（交易中心研发）提醒运维加SELECT fk_uuid FROM project_subproject WHERE provider_no = ?的索引，并让项目采购研发确认
09:57 因数据库CPU的使用率100%，项目采购加索引未成功
09:58 运维禁用接口/bidding-open/acquirePurFile/getAcqurePurFileList
09:59 运维杀掉数据库上所有query的session
10:05 运维关闭web-bidding-open服务，以降低数据库负载增加索引
10:05 项目采购开发第二次添加索引
10:06 运维禁用接口/api/bidding-open/eBidding/getBizFlowStat
10:07 运维杀掉数据库上所有query的session

3.故障降级(P1降至P3）8月26日 10:12（+43）
10:12 数据库CPU恢复正常后，运维启动web-bidding-open服务

10:15 除采购文件页面外，其他主流程都恢复
10:16 故障处理话术（涉及到故障期间影响的项目）反馈给长空，让他帮忙来做问题期间的项目问题回复处理

4.故障恢复（P3）8月26日 10:20（+51）
10:20 运维打开了上面采购文件两个接口访问
10:21 故障处理话术（涉及到故障期间影响的项目）反馈给运营
10:30 测试验证主流程没问题，所有业务恢复
10:35 古德查询受影响的解密供应商，排查到有53个供应商的开始解密时间在早上9点半，状态是未解密的，可能受到了影响，并通知运营

三、影响产品线及影响面

见下文 项目采购用户
四、故障原因

线上数据库索引变更，引发慢SQL，引发雪崩效应，影响开评标业务
4.1 8月25日晚，真线DB进行慢sql优化时，研发人员对project表的status_no字段进行了索引删除的操作。对删除的索引做进行当时慢SQL的校验，未对影响面进行排查。当天DB审核人过程未认真审查。

4.2 8月26日早，在收到数据库CPU 100%报警时，重新加入status_no索引，但因当时CPU过高且流量大量涌入已经无法恢复。最后通过关闭服务，再清除query进程逐步缓解数据库的CPU。

4.3 项目采购慢SQL跟踪 第8条“SELECT fk_uuid FROM project_subproject WHERE provider_no = ?”，登记时间：4月27日 ， 不优化原因：低频偶发，且平均时间在0.5秒左右

五、故障评级
故障等级P1
故障类别：性能问题-慢SQL-索引不合理
监控是否发现：是

六、后续ACTION：

七、预案：

故障教训
故障事前教训
1、变更线上数据库索引的原因？
项目采购因数据模型设计不合理、代码腐化。线上慢SQL非常多，200+。团队内正在推行慢SQL治理。

故障的起因是优化其中一条慢SQL,开发分析不走索引反而RT好。<<<< 黄裳分析此结论不稳定性，见下文

开发昨晚(8月25日)做了线上移除索引的操作。

2、线上变更的操作过程？
（变更发起人）始宁 找 北辰发起DMS变更流程 ， 流程由正则审批通过。线上变更成功。

3、事前为什么没拦住？过程是否有发声、有保障、有兜底？
有DMS审核流程，但没审出来。

4、DB线上变更的教训是什么？
开发者：线上变更影响分析不周全，只关注了慢SQL，未关注此索引所有相关的查询的影响评估。且，线上变更后没有及时的进行测试验证。

审核者：未审核到位，日常质疑/把控变更可行性和全面性。

主管：线上高危操作注意事项上欠宣贯和规范。开发者对线上的敬畏之心还不够。
故障事中应急教训
1、应急处理概述
9点05：项目采购数据库实例告警，同步到运维群。运维开始排查。

9点06 ~ 9点25：运维处理待办线上故障的问题。以为2者是一个问题。

9点27 ~ 9点30：运维发现web-bidding-open还在告警，同时数据库100%，开始拉项目采购开发处理。

9点35：项目采购开发把昨日删除的status_no索引加回来，并重启应用。 《《《 无效果

9点39：运维kill RDS里的query session（kill 慢SQL）。 《《《 依旧无效果

=== 期间继续查===

9点58：禁用主要慢SQL对应的web流量接口：获取采购文件。

9点59：运维重新kill RDS里的query session（kill 慢SQL）。《《《 依旧无效果

10点05：运维关闭所有web-bidding-open服务。并添加库中另一个subproject表的索引（期间某个查询暴增慢SQL 6000+，日常20左右）

10点07：运维重新kill RDS里的query session（kill 慢SQL）。《《《 此时生效了

10点12：RDS CPU 100%问题下降了，业务都恢复了。

2、故障原因分析
诱因：project表删除status_no索引后，造成目标SQL以外的SQL发生慢SQL，应早上业务高峰期，RDS CPU上涨。

恶化：因数据库处理性能下降严重，同数据库里的project_subproject的SQL也发生大量慢SQL。

3、故障恢复为什么耗时42分钟？
1、启动应急时间迟，9点05发现，9点25开始应急。《《《 实际处理42分钟恢复，此处可减少20分钟左右。

2、应急操作步骤上不精确。

实际操作顺序：加索引 ——》数据库 kill 慢sql ——》重启应用 ——》禁用web流量入口 ——》再重复尝试。

最佳操作顺序：加索引 ——》[禁用web入口流量或限流] / 关闭应用 ——》数据库 kill 慢sql

为什么：数据库入口流量未清空，即使kill 慢sql query session，原本等待的请求立马就执行，生成新的慢SQL。

《《《 按最佳操作顺序，应急恢复时间应在15分钟内。

4、应急的经验教训是什么？
数据库慢SQL问题的应急处理SOP。

其他教训
1、背景的额外说明
（墨菲定律）最头疼的project表。

项目采购代码最腐化的部分。无设计无约束，大量字段随意堆 200~300个字段。修改难，效率低。

大量慢SQL，线上200个慢SQL里，80%出自这张表。

基于此表的“获取采购文件”的查询QPS只有3，并发3时数据库CPU就100%了。随着业务量增大（即使没有本次删索引），此处爆发性能问题是下半年的必然。
已经在做的project表优化

慢SQL分工优化。其中，本次造成问题的慢SQL（获取采购文件），已代码优化完毕测试阶段中，31号发版。

project表的模型重新设计和拆分，8月、9月也在实施过程中。

2、故障事后外部跟进
客户影响：故障应急过程中，容成并行组织了外部话术的输出，品牌的告知等。

客户影响：一帆组织了受影响项目、代理机构、供应商清单的拉取，并组织事业部山丘、皓成进行询问和引导（省外乌海三家；省内40家；）。

Action：Review会议上收集。

Review会议讨论纪要

1. 接口 优化目的？

团队日常慢SQL治理

2.不走索引为什么反而快？

黄裳备注：标题有误导，其实是删索引后SQL走了另外的索引，特定条件下查询效率高一点。
黄裳分析：

3.加了第一个索引后，为何没恢复？

操作顺序不当：kill session的同时，因为是平滑逐个重启应用。仍有慢SQL对应的流量进到mysql，吃CPU。
应该：场景 索引效果不明显时，先切流量，加索引，再KILL session

4.项目采购监控添加指标【ACTION】

5.项目采购历史慢SQL，数量多

已有优化计划，推进中

6.榴莲 牵头产研数据库优化

7.待办 和 项目采购 判定一个问题？
串行处理，优先处理了待办，再处理项目采购
运维值班错峰通行

8.应急
P1/P2 运维/开发 停服务

数据库实例直接定位到应用，并发送对应告警到owner/值班人 【ACTION】

9.增删索引 组leader 审核

10.接口作用

供应商获取采购文件列表

投标客户端，供应商获取采购文件数量

11.基于P1/P2链路 优化措施

8月26日P1故障的复盘
8月28号晚上压测的结果

压测数据库的配置4C8G project表的数据量为10W 线上的数据量为18W。project_subproject的数据量为9W 线上为17W左右。压测数据量约为线上的一半左右。

现有的接口的在1秒10个并发的情况下，不加status_no索引的QPS是3.1 数据库cpu 100%。加了status_no索引QPS是2.7 数据库CPU 100% . 然后把并发降低到4 cpu依然在100%

其实这个接口早就发现为什么迟迟没有修改？

从慢SQL发现到定位到这个接口最早是7月16日，修复这个接口是在8月16日,提测是在8月21日。上线的版本定在8月31日。

中间赶着上海项目进度,并且从QPS和慢SQL执行的数据量上来说不是很大，虽然每个星期产生10个左右的慢sql。

后续的思考
现状如下

这是现在我们项目采购基本的架构，夜猫发现我们应用所有的SQL基本上都是打在写库RDS(写库配置为:4C8G)上，读库(读库的配置为:2C4G)只是开发人员用来查询一些真线数据使用。这个跟我原来的认知是有偏差的 我一直认为是读写分离的

所以如果任何一个开评标以外的慢sql造成数据库的雪崩，都会造成开评标的不可用。

开评标这块从年初就一直想着拆出来，目前按照进度在推进中。在开评标模块完全独立出来之前是否可以通过切流量的方式来确保开评标的业务

硬件成本： 1.增加一个web-biding-open的容器，现有的4个web-bidding-open应用改为5个，3个作为开评标以外的应用，2个作为开评标的应用通过nginx或者致虑的神笔来进行切流。

                2.增加两个4C8G的库

疑问点:1.为什么不通过限流,熔断来实现？QPS到达2.7 CPU就100%了， 限流1？最难的是不知道哪个请求还有类似的状况

         2.项目采购应用都进不去，菜单都加载不出来怎么办？是否可以创建一个新的应用 我们现在应用中心中的应用应该是一个菜单的集合我的理解

         3.标书解密的这块怎么办？迁移出去单独的服务？ 又增加成本啦。