线上故障处理——发布顺序错误引起的数据库异常
今天系统版本发布，多个因素凑到一起引发线上故障。这个排障过程做的不是很好，存在很多改进的地方，作为排障的反面教材，分享给大家。
先说下今日版本内容：User系统周版本含service应用和数据库脚本两部分，其中数据库有两个脚本：001-清理不合规则的设备登陆记录和设备记录；002 - 第三方账户绑定表新增表字段。
故障追溯
- 16:41 运维人员开始发布版本，开始执行脚本；
- 16:42 运维人员开始发布service；此时脚本001脚本还未执行完成；
- 16:50 产品经理找开发确认系统是否存在问题，导致管理端无法查询用户信息；开发开始介入查证；
- 16:59 开发人员接到同事电话反馈，用户登录功能也存在问题；
- 17:01 运维人员发现并反馈脚本001还未执行完成，执行时间过长；
- 17:03 开发人员怀疑001脚本清理数据时锁库，要求DBA kill掉001脚本执行进程；
- 17:07 DBA kill掉001脚本执行进程，但是服务未恢复；
- 17:08 开发人员怀疑service应用未能重新获取到数据库连接池，故要求运维人员重启service服务；
- 17:10 运维完成service重启，服务未恢复；
- 17:11 开发人员查看应用日志，发现大量报错“ORA-00904: "XXXXX": 标识符无效”，检视版本内容中，002脚本存在新增字段XXXX的脚本；
- 17:12 开发人员整理思路推断：001脚本未执行完成，进程kill后，部署平台不会继续002脚本，但由于运维先行发布了service，所以导致上述ORA-00904报错；
- 17:12 要求运维人员手动执行002脚本；
- 17:13 运维人员手动执行002脚本；
- 17:14 开发人员验证服务并监控日志，确认服务已经恢复。排障结束。
过程剖析
整个故障处理中，我们发现“故障发现”过程持续了近8分钟（16:42~16:50），“故障定位”花费了22分钟（16:50~17:12），“故障处理”花费了1分钟（17:12~17:13）。其中"故障发现","故障定位"两个阶段存在严重不足，下面一一剖析。
“故障发现”过程
最大的问题在于：服务缺乏告警，未能及时发现系统故障。从16:42 service开始发布，故障产生，到16:50 开发人员介入故障处理，期间没有任何告警出来，最后是由于用户反馈系统存在异常，才知晓系统故障。理论上，如果存在告警系统，1分钟之内便可以发现故障，可以节约7分钟，7分钟对于生产系统来讲是很宝贵的。
线上service服务有访问量、时延、错误率的监控，但是没有基于这些监控数据的告警，后续需要补上。
“故障定位”过程
最初开发人员接到产品经理的反馈只有用户管理端部分查询功能不可用，便没有提升优先级，让团队其他人一同介入处理；后接听到其他团队反馈用户登录存在问题时，才介入，并提升优先级；这反映出团队没有一个良好运作的故障排查协作机制，不能迅速地完成故障识别及故障升级，开发人员意识不足，需要加强培训。
在故障定位过程中，开发实践地比较好的技巧在于：
- 在得知运维同事给到的“数据库脚本执行时间过长”的信息后，第一时间要求DBA杀掉该执行脚本链接，此行为可能无法解决根本问题，但是对于此类异常现象的解除通常对故障恢复和系统运行有帮助，因此，在故障原因不太明朗的情况下，这个行为是有利于故障恢复的，值得肯定。
- 快速检视版本变更内容对故障带来的影响。
做的不好的地方：
- 开发人员在要求DBA杀掉脚本执行链接的同时，没有去查看应用日志，以最终确认问题点。
总结
根据此次排障过程中，后续再如下几个方面需要改进：
- 在团队内宣导线上排障的思路，制定故障排查的协作机制，提升开发人员的排障意识；
- 完善服务告警，在现有监控数据上，增加服务错误率的告警，以便迅速发现故障，为排障争取更多时间；
- 部署平台需要加入“版本依赖”强控制，确保依赖版本在被依赖版本之后发布；
- 服务优化，登录服务和非关键业务表解耦，提高登录等关键服务的稳定性。
