故障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完成必需要产出改进计划，同时要确保改进计划细化，有截止日志，而且有监督人员。

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