故障review的一些总结

故障review的一些总结

故障review的目的

• 归纳出现故障产生的原因
  • 检查故障的产生是否具有普遍性，并尽可能的保证同类问题不在出现，
• 回顾故障的处理流程，并检查处理过程中所存在的问题。并确定此类问题的处理方法论。使得即便以后出现了同类的问题，也有明确的方法论来指导
• 标明后续改进措施及落实时间点
• 经验总结和分享

故障的级别定义

不同公司对于故障的级别有不同的定义，一般会有P1，P2，P3这几类故障，故障的严重级别依次降低。一个可能的定义如下：

• P1 公司主站提供的服务出现异常，广告展示出现问题等。比如对大量用户（3%）的正常使用产生影响，比如%3的下单失败
• P2 公司主站提供发服务缓慢，内部IT系统出现重大故障灯
• P3 公司内部系统出现故障，对外服务一切正常。

参与故障review的人员

不同的故障级别需要不同层级的人员参与review, 虽然不一定那么死板，但是一定要秉承着越严重的故障，越需要更高级别的人在场，并不是让他们来批评，而是让他们以示重视，并起到监督、督促改进的作用。

• P1 故障处理人员，系统负责人，相应的
  QA（DBA可选）受影响的团队的相关主要人员, 总监, VP
• P2 故障处理人员，系统负责人，相应的
  QA（DBA可选）受影响的团队的相关主要人员, 总监
• P3 故障处理人员，系统负责人，相应的
  QA（DBA可选）受影响的团队的相关主要人员

故障的升级和跟新时间

故障的级别并不是一成不变的。有可能故障刚刚发生的时候，观察影响可能觉的是P2，但是随着对故障的了解可能发现其实是一个P1级别的故障。当然也可能相反。

故障的升级或者降级的意义，并不仅仅是为了记录错误的严重性，或者说为了KPI的考核，它的最主要的左右在于影响故障处理人员一个可以动员人员的范围和获得的权限的大小 。比如一个P1故障出现了，故障处理人员可以为了处理故障，可以立即申请重要服务器的root权限，服务器管理员必须无条件审批通过，但是可能P3情况下服务器管理员就不会审批通过，而是让适合有root权限的人来完成操作。

从故障的发现，到故障的review完成，一直需要持续的跟新故障的进度。越是严重的故障越要更频繁的跟新故障的进度。这样好方便相关人员了解故障的处理情况。

故障review的时间点

考虑到人们总是懒惰的，因此为了保证流程和规范能够有效的执行下去，并确保具有「分享价值」的故障可以及时的被分享出去，公司从流程层面应该强制不同级别的故障必须在故障处理完成以后的多少个小时内review完成。
比如P1级别的故障必须在故障处理完成的12歌小时之内review完成。P3级别的故障必须在故障的36个小时之内review完成

故障review的准备工作

故障review的准备工作，主要是为了使得故障参与者提前准备好在review过程中所需要发表的内容。这样会使得review过程高效一些，也可以避免在review过程中可能会遗漏的东西。

故障review的详细步骤

故障review的详细步骤比如包含：从故障开始产生，到故障被发现、然后故障的具体处理过程、到故障处理完成的详细过程，需要包含日期、时间、事件、人员等其他有效信息。

主要是为了能够通过详细的过程描述，方便找出我们在发现故障和处理故障过程中暴露出的问题，做为后续改进计划的依据。一个可能的例子如下：

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

 故障的影响：xxx系统xxx服务受影响，大约影响3%的对外服务
 故障持续xxx时xxx分 

故障review的结论

故障review的结论，主要是明确故障下面的问题：

• 故障产生的原因
  • 代码bug？设计缺陷？需求缺陷？历史脏数据未考虑到？系统有后门被人错用？
  • 为什么上线前Dev 自测没发现？
  • 是没有设计review么？没有code review 么？
  • 是case 没有执行么？
  • 为什么上线前PM/QA测试未能发现？
  • 是没有测试环境么？
  • 是流程/规范未执行？
  • 是没有进行codediff？
  • 依赖第三方不受控？
  • 是误操作？
• 是否存在没有及时发现故障的问题，以及原因是什么
  • 线上操作后没有检查 功能、监控、日志 的问题么？
  • 监控不完整么？项目过程中我们没有写业务监控么？不了解如何加监控么？
  • 报警阈值设置不合理么？
  • 人员未响应报警么？线上日志大家每天没有人看么？
  • 业务量太小没关注的问题？
• 是否存在故障处理缓慢的问题，以及原因是什么
  • 没带电脑回家？在外面么？
  • 没有看监控定位故障时间？
  • 定位问题过程合理么？场景难复现？
  • 改代码比较耗时间么？没有测试环境验证么？

相应的改进计划

故障的review完成必须要产出改进计划，同时要确保改进计划细化，有截止日志，并且有监督人员。

- 改进计划是什么？
- 改进开始时间，改进截止日期？
- 监督人是谁？