Go语言 - go语言杂谈

业务方还在钉钉群里问来问去吗?《线上故障通知流程指引与落地实施》

当线上发生故障时,除了查看日志和排查异常之外,还有一件重要的事 —— 通知。因公司业务形态和属性不同,业务方也不同。如果业务方是公司其它组的同事(对内),那么可以考虑直接通知他。如果业务方是用户/客户(对外),那么最好先通知公司的运营/商务,由他们处理对外的事。

如果没有基本流程,那么发生故障时一定会遇到这样的情况:

  1. 业务方:哎,访问不了/没有数据,你看看是出什么问题了吗?
  2. 业务方:你看看这个要多久才能恢复?
  3. 领导:看看怎么回事。
  4. 业务方:你们这故障大吗?
  5. 领导:通知一下各个业务方,然后再处理问题。
  6. 业务方:价格信息没有了,是这次故障引起的吗?
  7. 领导:哎,商务群那边你们通知了吗?
  8. ……

看出问题来了吗?

各方都在询问这件事的具体情况、影响范围、影响大小和故障级别,他们其实也没有准备,张口就问。你也没有什么准备,问了你就答,不清楚的支支吾吾就过去了。

建立通知流程

出现以上的对话是因为我们自己并没有对故障有完整认知,同时也并不重视对业务方的影响。单单依靠口头嘱咐、开会批评和事后诸葛亮对这件事其实并没有什么帮助,因为随着时间的推移,执行效果慢慢就会变差,尤其是当大家都很忙的时候。

这种情况,建立一个基本流程比批评和叮嘱更有效。根据上面的对话,我们大体可以推导出这些分类:

  • [x] 影响的业务项;
  • [x] 影响范围大小;
  • [x] 影响的持续时间;
  • [x] 影响的级别;

确定内容后通知上级负责人,并告知一些有用的信息。然后通知相关的业务方,把那些他们想问的一次性告诉他们。分析完毕,我们来建立一个基本的通知流程:

  1. 收集故障和影响信息,例如故障情况影响的业务影响范围大小影响持续时间影响级别
  2. 信息收集完成之后稍加整理
  3. 通知上级负责人,描述问题场景影响,有可能的话告知大体排查方向或者解决思路,最重要的是时间预估
  4. 正式通知相关业务方,通过邮件或钉钉告知故障情况影响预期恢复时间
  5. 故障登记
  6. 恢复后告知相关业务方

基本通知流程建立完成后,告知小组/部门各成员,要求严格遵守这个流程。

版权水印 微信公众号 Python 编程参考|技术专栏 https://www.weishidong.com

落地实践为王

上面提到过,因为随着时间的推移,执行效果慢慢就会变差。虽然建立了基本通知流程,但实际上这是一个空洞的流程,什么是影响范围?持续时间怎么写?影响级别怎么算?

要是这些内容无法确定,那么通知的执行成功率和有效性就会不尽如人意。想要能够落地实施,必须在通知流程的基础上确定通知清单,一份有效的通知清单看起来像这样:

看上去已经很不错了,对吧。相信业务方或者上级领导看到这样的故障通知信息,也不会再耗费时间多问什么,以免耽误程序恢复。

单纯一个表格还不够,例如如何知晓这个项目关联的业务方是谁?这些级别怎么确定的?这些编号怎么生成呢?不慌,咱们一个个解决。我们可以把通知清单上的看作查询结果,这些没有直接体现的信息是可以通过关联查询得到,因此还需要几个表格:

  • [x] 用于确定业务级别的表格;
  • [x] 用于确定影响级别的表格;
  • [x] 与业务方相关联的业务表;

这几个表需要小组/部门共同整理,整理完成后大家按照表格上的信息确定通知清单的几个关联项即可。下面给出几分参照表,各位在工作中使用时按照实际情况稍微调整即可。

影响级别定级参照表

业务级别定级参照表

关联编号命名参照表

示例中的编号 SPIDER-A-JOB-PRICE-01 就是这么推导出来的。

业务方关联参照表

有了这些表格和通知清单,这件事的落地实施就能够顺利进行了。

更多有用知识,请翻阅这本免费公开的 253 页全彩电子书《Python 编程参考》,可下载 PDF 原稿哦!关注微信公众号 【Python编程参考】即可获得下载地址。


有疑问加站长微信联系(非本文作者)

原文链接:https://studygolang.com/articles/32758

推荐图集: