【问题描述】
12月21日下午5:14开始出现门店列表排序失效的问题，导致排序质量变差；
【影响范围】
首页门店列表排序、频道页门店列表排序
【事故级别】
根据处理时长，定级为P0
【处理过程】
- 17:14 工程同学重启服务的时候发现服务查询不到门店数据，算法同学排除后发现redis存储数据过期，生产数据脚本未启动；
- 17:30 算法重新启动生产数据脚本，门店ID恢复；
- 18:00 工程端重新启动服务，发现门店列表排序依赖的数据字段值为0，导致门店列表排序异常；
- 18:00～19:00 算法排查异常问题原因，发现生产数据的脚本所在目录整体被删除（删除时间为12.17）;
- 19:30 工程端降级为兜底策略，兜底策略为：按门店销量排序，并对特殊商家加权，保证优质销量高门店排在前面，但缺少个性化排序；
- 19:30～06:00 重新开放脚本，进行门店排序依赖重要数据重新生产；
- 22号10:00～19:00 工程和算法相关人员开始小流量验证数据和效果，中间发现特殊门店权重分、用户流览、加车、购买等数据缺失，算法同学做了恢复；
- 22号19:00～21:20 数据修复完成并上线，并给出问题之前的返回结果做了对比，结果基本一致；
- 23号 10:30～11:00 修复反馈badcase问题，线上效果恢复正常，业务方没有问题反馈；
【故障原因】
12.17日收到服务器磁盘空间使用率（>85%）报警提醒，相关同学由于对模块不熟悉，删除了门店列表数据挖掘模块所在目录，导致不能启动脚本重跑数据；
之前离职的同事并没有把门店列表挖掘模块的最新脚本上传到git，导致部分逻辑需要重写，进而使的完整恢复的时间加长；
【问题本质】
数据挖掘模块缺乏规范，包括部署方式，目录结构，任务调度和管理，代码和数据备份机制；
工作交接缺乏流程和规范，导致接手同学对模块不熟悉，问题处理起来手忙脚乱；
监控机制不完善，包括数据挖掘模块监控以及线上服务监控都有缺失，本次问题是17号就出现，监控完善可以提前发现问题，有充足时间处理；
【改进措施】
1. 制定数据挖掘模块规范
(1) 所有脚本都要上传git，并在每次替换之前对当前版本做备份，出现问题时及时替换为备份脚本；
(2) 数据挖掘模块工作目录定期备份，出现问题时候可以快速通过备份工作目录恢复；
(2) 制定部署方式和目录结构规范；
(3) 调研任务调度管理系统，对数据挖掘模块进行管理，解决目前使用crontab启动比较原始的方式；
2. 建立数据快速恢复机制
(1) 所有数据挖掘模块最终上线数据都需要写入到hive作为备份，以便线上数据出现问题时，能够快速从hive获取数据恢复；
(2) 在网关层建立数据兜底层面，保证在推荐服务出问题时，线上推荐结果不会出现大的异常；
3. 完善报警监控机制
(1) 数据挖掘模块需要对每个执行步骤，以及产生的数据进行对比监控，包括数据大小，数据字段个数，数据格式，数据异常值波动等；
(2) 服务端监控不仅覆盖接口，还要监控数据加载异常情况，对加载异常数据超过一定条数需要报警；
4. 制定工作交接流程
工作交接需要有checklist，包括书面的交接内容书，有代码、有文档、部署位置等；新接手同学需要安排时间严格按照checklist进行逐项完成；
思考
通过此次事故可以看出，完善的交接流程的重要性。以及数据备份的重要性。 整理了一些基本的交接流程如下：
1、基础文档
（1）中间件配置：redis、db等
（2）服务器配置
（3）zk、sentinel配置细节描述
（4）常见问题处理
（5）mq文档
（6）接口文档
（7）es文档
（8）监控umpkey文档
（9）表结构文档
（10）核心流程图
2、业务
（1）需求文档
-
近半年的需求文档
-
近几次业务需求的串讲 （2）业务流程核心文档
-
系统核心业务流程图
3、权限交接
- git权限
- 中间件权限 db、redis、es、mysql等
- 服务器操作权限
- 接口权限
- zk配置权限
- tb任务权限
- 功能菜单权限
- 账号权限
4、交接复盘
- 与产品沟通并且复盘线上功能
- 特殊逻辑、特殊配置、代码钩子着重备注
- 系统上下游交互逻辑确认
- 交接后的首次上线一定要谨慎，保存好回滚版本文件
