故障处理

故障定级

故障review前准备工作：

1、详细处理过程
2、导致故障的原因
3、故障影响范围、相关数据等
4、故障的后续改进计划（初步想法，具体计划在review时确认落实,但在会前要有相关改进项目）

5. 故障的金额损失，例如订单，和业务的赔付等

具体说明：

详细处理过程

从故障开始、到发现、到处理、到处理完成的详细过程，需要包含日期、时间、事件、人员；
目的：能够通过详细的过程描述，方便找出我们在发现故障和处理故障过程中暴露出的问题，做为后续改进计划的依据

示例：

1.yyyy-M-dd hh:mm 故障因xx开始
2.yyyy-M-dd hh:mm xx 发现故障 （或收到报警）
3.HH:mm xx 确认问题真实存在，通知xx上线处理，并通知NOC 报故障
4.HH:mm xx 查看监控及日志，确认影响范围及故障发生时间点
5.HH:mm xx 确认问题原因，通知xx开始回滚（或修bug）
6......... ....
7.HH:mm xx 确认线上功能已经恢复
8.HH:mm xx 开始修复数据
9.HH:mm xx 确认故障已经结束

导致故障的原因

故障中的问题发掘：问题在3个时间段中查找

A. 发生前导致故障的原因： Dev、QA、OPS、DBA等各角色存在哪些问题，导致故障

1. 代码bug？设计缺陷？需求缺陷？历史脏数据未考虑到？系统有后门被人错用？
2. 为什么上线前Dev 自测没发现？
   2.1是没有设计review么？没有code review 么？
   2.2是case 没有执行么？
3. 为什么上线前PM 测试未能发现？
   3.1是没按照case执行么？
   3.2是case 没写么？或者case 没有review？
   3.3是没有测试环境么？
4. 为什么上线前QA 没发现？
   4.1是流程/规范未执行？
   4.2是checklist写的不规范？
   4.3是没有进行codediff 或对codediff 不了解
5. 依赖第三方不受控？
6. 是误操作？

B. 发现前导致发现晚的原因：什么原因导致5分钟内我们不知道故障发生了

线上操作后没有检查 功能、监控、日志 的问题么？
监控不完整么？项目过程中我们没有写业务监控么？不了解如何加监控么？
报警阈值设置不合理么？
人员未响应报警么？线上日志大家每天没有人看么？
业务量太小没关注的问题？

C. 处理过程恢复过慢的原因：什么原因我们没能在10分钟内将故障处理完成

没带电脑回家？在外面么？
没有看监控定位故障时间？
定位问题过程合理么？
改代码比较耗时间么？没有测试环境验证么？

故障的后续改进计划

根据review 中发现出来的问题，我们需要制定出可实施的改进计划。

目的：同类型的错误我们自己及相关的同事都不应该在犯

改进计划的记录至少包含： 措施、跟进人、完成时间

改进计划可以包含但不限于下面几方面：

1.规则类的、流程类的、规范类的
2.人员经验总结类的
3.监控添加
4.系统或工具设计改造类的
5.流程类的、规则/规范类的、机制完善类的
6.人员经验总结类的、知识分享类的
7.报警设置
8.系统、业务需求改造类的

故障review提交后，将实时同步在JIRA上创建改进计划的任务。请务必在既定的时间内将任务完成并修改对应的状态，改进计划创建后只能在jira系统操作。