当线上发生故障时，除了查看日志和排查异常之外，还有一件重要的事 —— 通知。因公司业务形态和属性不同，业务方也不同。如果业务方是公司其它组的同事（对内），那么可以考虑直接通知他。如果业务方是用户/客户（对外），那么最好先通知公司的运营/商务，由他们处理对外的事。
如果没有基本流程，那么发生故障时一定会遇到这样的情况：
- 业务方：哎，访问不了/没有数据，你看看是出什么问题了吗？
- 业务方：你看看这个要多久才能恢复？
- 领导：看看怎么回事。
- 业务方：你们这故障大吗？
- 领导：通知一下各个业务方，然后再处理问题。
- 业务方：价格信息没有了，是这次故障引起的吗？
- 领导：哎，商务群那边你们通知了吗？
- ……
看出问题来了吗？
各方都在询问这件事的具体情况、影响范围、影响大小和故障级别，他们其实也没有准备，张口就问。你也没有什么准备，问了你就答，不清楚的支支吾吾就过去了。
建立通知流程
出现以上的对话是因为我们自己并没有对故障有完整认知，同时也并不重视对业务方的影响。单单依靠口头嘱咐、开会批评和事后诸葛亮对这件事其实并没有什么帮助，因为随着时间的推移，执行效果慢慢就会变差，尤其是当大家都很忙的时候。
这种情况，建立一个基本流程比批评和叮嘱更有效。根据上面的对话，我们大体可以推导出这些分类：
- [x] 影响的业务项；
- [x] 影响范围大小；
- [x] 影响的持续时间；
- [x] 影响的级别；
确定内容后通知上级负责人，并告知一些有用的信息。然后通知相关的业务方，把那些他们想问的一次性告诉他们。分析完毕，我们来建立一个基本的通知流程：
- 收集故障和影响信息，例如故障情况、影响的业务、影响范围大小、影响持续时间、影响级别；
- 信息收集完成之后稍加整理；
- 通知上级负责人，描述问题、场景、影响，有可能的话告知大体排查方向或者解决思路，最重要的是时间预估；
- 正式通知相关业务方，通过邮件或钉钉告知故障情况、影响和预期恢复时间；
- 故障登记；
- 恢复后告知相关业务方；
基本通知流程建立完成后，告知小组/部门各成员，要求严格遵守这个流程。
版权水印 微信公众号 Python 编程参考｜技术专栏 https://www.weishidong.com
落地实践为王
上面提到过，因为随着时间的推移，执行效果慢慢就会变差。虽然建立了基本通知流程，但实际上这是一个空洞的流程，什么是影响范围？持续时间怎么写？影响级别怎么算？
要是这些内容无法确定，那么通知的执行成功率和有效性就会不尽如人意。想要能够落地实施，必须在通知流程的基础上确定通知清单，一份有效的通知清单看起来像这样：
看上去已经很不错了，对吧。相信业务方或者上级领导看到这样的故障通知信息，也不会再耗费时间多问什么，以免耽误程序恢复。
单纯一个表格还不够，例如如何知晓这个项目关联的业务方是谁？这些级别怎么确定的？这些编号怎么生成呢？不慌，咱们一个个解决。我们可以把通知清单上的看作查询结果，这些没有直接体现的信息是可以通过关联查询得到，因此还需要几个表格：
- [x] 用于确定业务级别的表格；
- [x] 用于确定影响级别的表格；
- [x] 与业务方相关联的业务表；
这几个表需要小组/部门共同整理，整理完成后大家按照表格上的信息确定通知清单的几个关联项即可。下面给出几分参照表，各位在工作中使用时按照实际情况稍微调整即可。
影响级别定级参照表
业务级别定级参照表
关联编号命名参照表
示例中的编号 SPIDER-A-JOB-PRICE-01 就是这么推导出来的。
业务方关联参照表
有了这些表格和通知清单，这件事的落地实施就能够顺利进行了。
更多有用知识，请翻阅这本免费公开的 253 页全彩电子书《Python 编程参考》，可下载 PDF 原稿哦！关注微信公众号 【Python编程参考】即可获得下载地址。
有疑问加站长微信联系（非本文作者）
