遇到P0级别事故如何项目复盘!

一、事件回顾
1、3月12号20:00点，运营人员在动态优惠系统配置14条AOI优惠策略，其中多条优惠策略是面向全网用户生效。
2、3月13号15:20分，研发突然收到系统大量接口告警，研发迅速开始查询日志排查问题。
3、3月13号15:25分，运维反馈有部分应用节点不可用，运维开始对应用cpu和节点数进行水平扩容并且串行重启动态优惠系统所有节点。
4、3月13号15:30分，支付系统反馈业务的用券量出现大量下滑，启动P0故障，同时支付系统关闭调用优惠系统，优惠系统恢复短暂正常。
5、3月13号15:32分，优惠系统部分节点又开始出现异常系统自动重启，研发和运维继续监控检查系统各项指标。
6、3月13号15:35分，通过监控发现redis出现一些大key，流量非常高，达到1.8G/s，经排查是新上的AOI策略报文太大导致redis出现大key。
7、3月13号15:40分，运营下架AOI相关优惠策略，系统恢复正常。
整个故障持续时间接近20分钟，间接影响收入*万，定级为P0故障

二、问题分析及解决办法
1、问题分析：
1）运营当天配置了14条AOI优惠策略，每条策略大概有300个AOI编码并且配置了AB分流规则。
2）优惠策略之前的策略数据都是存储在redis中，所以运营配置14条策略生效以后，redis接收到的报文瞬间变得非常大，
原来策略的key快速升级为大key，客户端频繁请求redis大key，流量高达1.8G/s，很快系统的http线程池被打满，
请求无法响应，系统进入假死状态。

2、解决办法：
1）优化redis大key：事发当晚，针对redis大key场景，引入本地缓存作为一级缓存，接口优先从本地缓存读取数据，减少对redis中间件的压力，优化后redis运行比较平稳。
2）增加系统异常预案处理：在配置中心增加动态关闭接口的开关，一旦出现系统即将不可用的情况，立即打开开关，进行人工降级，并返回兜底数据，等待系统资源正常后，
再打开开关。

三、总结与反思
1、研发侧：
1）对redis重度依赖，redis有细微的抖动，服务接口响应时间波动非常大，系统风险大。
2）redis使用不规范，没有提前对redis大key作出预判，导致面对突发流量，系统扛不住。
3）没有形成一套标准的高并发和高稳定性的架构设计评审方案，由于动态优惠系统属于核心系统，加上每天请求的QPS很大，
所以对于系统的稳定性设计要求极高，可能设计方案出现一点疏忽就会影响系统整体的稳定性。
4）性能压测没有真实模拟线上数据，导致压测结果有偏差，不能对研发同学优化性能做到精准支撑。

2、底盘运维侧：
目前我们所有的应用都已经上云，对集团底盘能力依赖较重，但集团提供的排查工具比较粗糙，没有顺手的工具可用，这里总结了几点如下：
JVM层面：
.获取dump线程文件：每次都需要找运维帮忙手工dump线程文件，人工介入比较慢。
.定位详细的性能瓶颈：目前实时在线分析应用指标的性能问题比较难，底盘提供的grafana指标监控，只能分析粗略的结果，不能准确定位是什么原因导致CPU飙高、
频繁full gc、http线程被打满，排查问题周期较长。
中间件层面：
.redis工具缺乏：目前底盘没有的redis慢查询、热key、大key等监控工具，导致redis线上排查问题很困难。
.运维没有开放底层中间件与数据库的监控告警给业务研发，导致业务研发不能及时收到告警作出合理的响应。

3、产品运营侧：
1）产品侧：负责系统的产品同学经常换人，系统缺乏沉淀，而且系统逻辑复杂度很高，新人熟悉底层逻辑的时间通常很久，
这样就会导致出需求的时候考虑不完善漏掉一些核心逻辑。
2）运营侧：运营同学上架策略节奏过快，策略上线后经常面向全网用户，如果出现问题，会引起大量客诉，风险高。


四、行动与结果
1、研发测
1）输出一套标准的redis使用规范，包括redis存储规范、redis热key解决方案、redis大key解决方案，并在部门内进行宣导，避免其他组踩坑（平台组长主导，3月底完成）
2）开发redis热key、大key监控与告警的工具并且集成到鹰眼监控平台，方便部门研发人员第一时间定位问题（平台组长主导，3月上线）
3）后续产品需求进入研发前，必须事先有严格的技术方案评审，研发同学必须输出架构方案设计图、接口详细设计、数据库设计、性能与安全设计、服务限流与降级配置、
监控告警配置、预案设计，文档沉淀到CF，由各组PM主导，相关的研发和测试人员必须参与（平台组长主导输出规范，3月底完成）
4）性能压测必须输出一套统一的标准，压测的测试场景与线上高度还原，接口如果达不到业务要求上线的标准，测试同学通过邮件报备，与PM商量后是否延期需求，
等研发优化完达到指定的性能标准后再上线（测试组长主导，3月底完成）

2、底盘运维侧
1）JVM层面
.建议获取dump线程文件自动化，底盘可以在集团云提供一个可视化页面，研发同学可以随时下载系统异常时刻dump线程文件。
.建议集团云在k8s容器集成Arthas性能分析工具，很多互联网大厂在使用，可实时在线分析应用相关指标，非常方便。
2）中间件层面
.建议运维开放中间件和数据库的监控给业务研发，确保研发第一时间接收到信息进行处理，及时消除潜在的系统风险。
.建议底盘开发redis慢查询和告警功能，可以串联skywalking分布式链路工具一起输出，这样排查性能问题非常有用。

3、产品运维侧
1）产品侧
.建议产品同学尽可能固定并且有备份同学，稳定的团队有利于系统长期、持续的规划和沉淀。
.系统还有不少前任产品留下来的业务债务，建议产品同学预留足够的时间优先处理这些债务，否则做的越多错的越多，我理解现在的慢是为了将来的快，欲速不达。
2）运营侧
.后期上策略建议邮件抄送，建议说明策略面向的用户量和生效时间，便于研发提前监控数据以及是否根据系统支撑的最大QPS对系统进行扩容处理，同时增加审批的流程，
比如运营负责人审批后才能上线策略。
.建议运维上线策略采用灰度发布的方式，发布当天，运营密切关注数据是否正常，确定没问题后第二天再推向全网用户。