• 记一次刻骨铭心的值班失误


     

     我们公司有个值班制度,每人值班一周,非上班时间系统出现问题的时候,会有人给值班的人打电话。

     

    本人值班这么久,从来没接到过电话。今天凌晨3点的时候接到了个电话,特别兴奋,盼星星盼月亮,终于“盼出”问题了!赶紧打开电脑,进入值班群,看看聊天记录里有什么有用的信息。原来是上线出了问题,代码上了,但数据库字段更改没有上。导致了代码里查询的字段在DB的表里没有,就报异常了。

     

    紧急措施是运维组同事来回滚代码。

     

    整个过程中,我没说一句话(插不进嘴)。看了一下我们组相关的影响,发现我们组的一个表也受到了影响,报了一些异常信息。因为查DB有问题,所以业务数据无法插入,于是我判断,不会有脏数据出现,重启一下就OK了。

     

    关电脑,睡觉。第二天正常上班,干活儿。

     

    下午却发现我们的数据受到了影响。原因是有一些定时任务调度(Quartz),在任务调度里调用了我们的业务代码,业务代码查询DB、插入DB有问题,抛异常。但是调度任务已经执行完了(虽然业务上失败了),就不会再重新执行了。这就会造成本来应该被执行一次的业务代码,永远不会被执行了。

     

    领导赶紧找相关人员(虽然我值班,但没有我,恰巧我平时的工作内容跟这块业务相关性不大),查询数据,找到受影响的业务数据,敲定恢复方案,执行。

     

    虽然这周我值班,虽然我昨晚被叫醒了,但是整个故障排查与恢复我一点都没有参与。让我心中特别的失落,一是感觉自己值班有失职,二是我一个最应该处理故障的人恰恰没有参与故障处理。

     

    事情已经发生了,心里不好受是没有用的。总结一下自己的一些错误吧,希望下回不要再出现了。

    1. 进入聊天群之后没有发言。这样别人可能就不知道我已经上线了。很有可能自己被折腾了半天,最终却没人知道自己参与了第一轮排查错误这件事儿。其实当时应该在群里吼一声,“我是XXX组的XXX,有什么需要我帮忙的吗?”。这样不仅能有效的知道自己应该干什么事儿,还能引起别人的注意。
    2. 对于故障的影响过于乐观,没有按部就班地分析故障所造成的影响。虽然这部分的业务逻辑不是我主要负责,但是作为值班人员,把这个问题给漏掉了,这就是我的失职。正确的做法是要研究一下,重启系统之后,这些失败掉的业务逻辑会被重新触发吗?虽然以我对这部分业务的了解程度,凌晨3点是无法很快得出结论的。但当时可以有两种选择可以把这件事儿处理的更好
      1. 可以直接给相关的同事打电话问一下,也可以给直接上司打电话汇报一下这件事,让上司找一下相关的人员。
      2. 如果紧急程度不是很高,凌晨暂时不骚扰其他同事了,但是第二天上班之后,要第一时间找一下上司或是相关同事。
    3. 第二天上班之后,没有把这件事汇报给领导。这是最严重的问题!我以为这件事已经没有问题了,但以领导的经验也层次,也许是可以发现问题的。如果这件事我不汇报给领导,那么出了问题所有的责任就都在我身上了。而汇报给领导了,不仅能从更高的一个层次来看这个问题,能调动更多资源,而且还拉上领导来一起背锅。还好领导发现了这个问题,并且及时找了相关同事解决。给领导点赞的同时,要深刻反思一下自己的做事方法了。

     

    自己出现以上问题,原因如下:

    1 主观上不乐于交流

    2 凌晨不好意思打扰别人

    3 第一次处理这样的问题,没经验

     

    至于技术上怎么排查问题,就不说了。这次值班里,暴露最严重的问题是自己做事方法上的问题。

     

    以后遇到类似问题,

    1 要勇于、乐于交流。多沟通。

    2 不要不好意思打扰别人。尤其是领导。如果不愿打扰领导,可以打扰相关业务人员,大不了第二天请他吃顿饭。

    3 遇到故障时,要按部就班,一步步排查。不要想当然,不要怕花时间。

    4 一定要及时向领导汇报!

     

    最后,虽然自身暴露了问题,但改了就好,能让自己进步也未必是坏事,及时丢掉坏心情。

     

  • 相关阅读:
    232. Implement Queue using Stacks
    231. Power of Two
    n&(n-1)位运算的妙用
    230. Kth Smallest Element in a BST
    关于UNIX的exec函数
    Go语言的各种Print函数
    Go语言的接口interface、struct和组合、继承
    Go语言知识点笔记
    Ubuntu自定义终端窗口位置
    Python的类变量和成员变量、类静态方法和类成员方法
  • 原文地址:https://www.cnblogs.com/james6176/p/8277482.html
Copyright © 2020-2023  润新知