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

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

故障review的一些总结的更多相关文章

  1. 一个磁盘I/O故障导致的AlwaysOn FailOver 过程梳理和分析

    下面是我们在使用AlwaysOn过程中遇到的一个切换案例.这个案例发生在2014年8月,虽然时间相对久远了,但是对我们学习理解AlwaysOn的FailOver原理和过程还是很有帮助的.本次FailO ...

  2. 从一次线上故障思考Java问题定位思路

    问题出现:现网CPU飙高,Full GC告警 CGI 服务发布到现网后,现网机器出现了Full GC告警,同时CPU飙高99%.在优先恢复现网服务正常后,开始着手定位Full GC的问题.在现场只能够 ...

  3. Code Review最佳实践

    我一直认为Code Review(代码审查)是软件开发中的最佳实践之一,可以有效提高整体代码质量,及时发现代码中可能存在的问题.包括像Google.微软这些公司,Code Review都是基本要求,代 ...

  4. Code Review最佳实践(转)

    我一直认为Code Review(代码审查)是软件开发中的最佳实践之一,可以有效提高整体代码质量,及时发现代码中可能存在的问题.包括像Google.微软这些公司,Code Review都是基本要求,代 ...

  5. Java进程故障排查思路及步骤

    故障场景 Java进程出现问题,通常表现出如下现象: Web应用响应时间长/超时,甚至不响应 CPU使用率极高/低,频繁出现Full GC,甚至OutOfMemoryError 响应时间长.超时,甚至 ...

  6. 放弃等待,故障到来:少一个 await 引发的 tcp 连接泄漏故障

    更新:后来升级至 .NET Core 2.2 Preview 3 ,并将 System.Net.Http 升级至 4.3.4 之后没出现这个问题,问题与 https://github.com/dotn ...

  7. Code Review怎样做好

    一.背景 最近随着交易业务快速扩展,研发组内新项目及新成员越来越多,如何做好Code Review,把控研发人员开发代码质量很是关键. 对于大部分业务团队,谈到Code Review就会面露哀状:   ...

  8. 从一次故障聊聊前端 UI 自动化测试

    背景 事件的起因在于老板最近的两次"故障",一次去年的,一次最近.共同原因都是脚手架在发布平台发布打包时出错,导致线上应用白屏不可用. 最神奇的是,事后多次 Code Review ...

  9. 从0开始搭建SQL Server AlwaysOn 第二篇(配置故障转移集群)

    从0开始搭建SQL Server AlwaysOn 第二篇(配置故障转移集群) 第一篇http://www.cnblogs.com/lyhabc/p/4678330.html第二篇http://www ...

随机推荐

  1. Css3新特性应用之形状

    一.自适应椭圆 * border-radius特性:    * 可以单独指定水平和垂直半径,并且值可以是百分比,用/(斜杠)分隔这两个值即可(可以实现自适应宽度椭圆).    * 还可以单独指定四个角 ...

  2. 你必须收藏的Github技巧

    一秒钟把Github项目变成前端网站 GitHub Pages大家可能都知道,常用的做法,是建立一个gh-pages的分支,通过setting里的设置的GitHub Pages模块可以自动创建该项目的 ...

  3. jQuery flickity 滑动触屏

    flickity是一款自适应手机触屏滑动插件,它的API参数很丰富,包括对齐方式.循环滚动.自动播放.是否支持拖动.是否开启分页.是否自适应窗口等. 在线实例 实例演示 使用方法 <div cl ...

  4. iOS 生成二维码

    首先先下载生成二维码的支持文件 libqrencode 添加依赖库 CoreGraphics.framework. QuartzCore.framework.AVFoundation.framewor ...

  5. 11g新特性:Health Monitor Checks

    一.什么是Health Monitor ChecksHealth Monitor Checks能够发现文件损坏,物理.逻辑块损坏,undo.redo损坏,数据字典损坏等等.Health Monitor ...

  6. java、easyui-combotree树形下拉选择框

    最近一直在研究这个树形的下拉选择框,感觉非常的有用,现在整理下来供大家使用: 首先数据库的表架构设计和三级菜单联动的表结构是一样,(父子关系) 1.下面我们用hibernate建一下对应的额实体类: ...

  7. NFS网络共享服务部署

    10.3 NFS服务端部署环境准备 10.3.1 NFS服务部署服务器准备 服务器系统 角色 IP Centos6.7 x86_64 NFS服务器端(NFS-server) 192.168.1.14 ...

  8. nth-of-type在选择class的时候需要注意的一个小问题

    查了下w3和MDN的手册,没发现有这个说明,写篇随笔记下. 1..class:nth-of-type(n)在选择class的时候,如果在class前面插入x个同类型标签,n需要加上x <!DOC ...

  9. Lambert(朗伯)光照模型 和Half Lambert的区别

    Lambert-它不包括任何任何镜面属性,对粗糙物体来说,这项属性是非常有用的,它不会反射出周围的环境.Lambert材质可以是透明的,在光线追踪渲染中发生折射,但是如果没有镜面属性,该类型就不会发生 ...

  10. codevs 1228 苹果树 树链剖分讲解

    题目:codevs 1228 苹果树 链接:http://codevs.cn/problem/1228/ 看了这么多树链剖分的解释,几个小时后总算把树链剖分弄懂了. 树链剖分的功能:快速修改,查询树上 ...