背景

1.10号下午发现一个场景，在商品服务中没有进行库存判断，让商品同学加上了对应的判断。晚上进行了发布。发布过后，到了10点，突然收到了一个项目的http告警(Tomcat的活跃线程超过40会有告警)，发现一个很稳定的http接口，RT达到了500ms。

应对手段

收到该消息后，由于以前也处理过类似的问题，所以第一时间查看了RDS的CPU，结果显示RDS CPU被打满，已经是100%的情况了。

查看发布情况，6点多商品同学有过一次发布，要求先进行回滚，该同学响应速度较慢，以前未遇到过不知道该如何快速回滚，还得重新拉分支. 重新走流程. （未使用过公司提供的快速回滚功能），此时已经是10.30了。

10.10就开始影响到另外一个核心业务了。

10.30，我介入对服务进行了回滚，2分钟后，回滚完成，但是CPU迟迟下不来。

确定问题可能不是这里引起的，由于RDS CPU100，一时间也找不到源头在哪里。(如果第一时间联系DBA，当时可以避免这个问题)

随后用户反馈，很卡，他们正在李佳琦直播间搞活动。要求快速解决一下。

10.50，活动进入尾声，RDS CPU开始下降。

11.00 CPU平复到日常水位。

检讨

  • 日常问题
    • 流程激增的时候没有主动通知，不能主动感知流量激增。
    • 日常培训不足，发布系统功能不了解，遇到问题不能使用已有的手段去解决。
    • 开发同学响应不足，知道就知道，不知道就不知道，已读未回，5分钟后说不知道是不可以的。
    • SQL日常水位较高，平时的优化没有持续进行。
  • 应急情况响应机制不足
    • RDS 100的情况下，查看SQL并未发现慢SQL，此时应该呼叫DBA介入。
    • 项目缺乏限流机制，无法对多应用进行多维度限流。

如何应对

  • 日常问题
    • 新增流量监控，如果每秒超过3000条订单写入，进行预警。
    • 针对新同学做工具、技能培训，出现问题能够合理的利用已有工具解决。
    • 此处属于态度问题。
    • 日常SQL需要优化
      • 添加索引: 解决慢sql
      • 使用缓存: 降低SQL TPS
    • 索引优化
      • 解决慢sql后，需要对sql的索引进行管理优化，避免出现索引容量大于RDS表容量的情况
    • 引入限流机制，从多个方面维持应用的可用性
  • 应急响应
    • 建立应急响应机制。
    • 如果自己解决不了，应该及时呼叫相关同学介入。
    • 如果定位到问题，短时间内解决不了，应该联系同学回滚。

image.png