在IT行业总体来说,每个人写的代码都可能会遇到bug,有些故障我们在测试的过程中就发现了,并被解决掉,还有些故障在测试的过程中没有被发现,到了生产环境日积月累慢慢被暴露出来。那么我们在每一次解决线上故障的时候,都应该需要做一下故障总结,避免下次再遇到相同类似的问题。
在做故障总结的时候,我们需要注意以下几个非常重要的点:
一、看得懂
我们在编写故障总结报告的时候,尽量浅显易懂的去编写总结报告,如果是一个非专业人员也能看得懂这个故障的来龙去脉就是最好的了。
二、有数据
我们追究问题的时候,讲证据。那么故障总结的话,我们需要有数据做支撑,通过数据来展示清楚故障的真实原因,造成的损失等信息。
三、免指责
这个就主要考验我们的处事能力,情商等方面了,在总结报告里面,不要指责任何个人,要以团队的名义说清楚相关的解决方案和后续如何避免再次出现同样的问题。
备注:在工作中大多数研发人员比较单纯,很容易出现指责他人的情况,这是一种不好的体现,很容易让同事之间产生隔阂,对于后期的工作配合会造成很大的阻碍。
下面分享个故障总结报告模板:
事项 | 内容 | |
概述 | 一个到两个简短的句子,总结促成因素、时间线摘要和影响。例如:在 8 月 13 日早上,由于主数据库机器上的进程故障,遭受了 1 分钟的请求访问超时。 | |
影响 | 用数字说明影响范围。例如:0.01% 用户下单失败,预计造成损失 578w。 | |
开始和结束时间 | 故障发生时间和终止时间,永远试图减少故障发生间隔 | |
原因 | 故障导致的真实原因,例如:由于订单数据的缓存过期,所有请求打到数据库,进而导致数据库 CPU 升高,无法处理更多请求。 | |
解决方案 | 包括对解决问题的方法的描述。如果有临时解决方案与长期解决方案一起描述。 | |
临时方案:已经临时扩容 10 倍容量以减轻级联故障。 | ||
长期方案:问题解决方案、时间线和对应负责人。 | ||
时间线 | 事前、事中、事后的整个过程,要非常具体,并包括确切的数字。 | |
时间线 | 描述 | |
11:45 | 收到HTTP 500电话告警 | |
11:47 | 发现数据库CPU飙升 | |
….. | ….监控数据走势图 | |
12:00 | 10倍扩容,问题得到暂时解决 | |
专业术语 | 对于没有接触过该系统,但是故障中出现的专业术语描述 | |
事后学习 | 此次事故中哪些事情处理的值得称赞;什么事件做的不好,需要重点改进.... | |
撰写者 | xxx | |
撰写时间 | 20220813 |
最后总结下:
1、当出现故障的时候,很考验每个人对于为人处世的能力。
2、当出现故障的时候,正是集合团队成员凝聚力最佳的时间,要多充分沟通,充分新人。
3、一定要记录相关时间线的表现,这是增长工作经验最佳的机会。
4、一定要备注好解决方案,总结相关的经验教训,后续该避免的就避免掉。
还没有评论,来说两句吧...