关于故障复盘的一些总结

原创
09/27 23:47
阅读数 70

这是学习笔记的第 2277篇文章


有句话说,常在河边走,哪有不湿鞋。我身边经常会看到不少数据故障。每每碰到这些问题,原因都是让人唏嘘不已。

而碰到故障的时候,除了通常都会说的后续改进,其实很多人对于问题的认识和理解还不够深入,这里主要包含几个方面:

1)害怕承担更多责任,会选择性的缩小问题影响范围和通知范围

2)如果问题不是出在自己身上,切身的感受不够深刻,觉得是在讨论别人的事情,持旁观态度

3)对于问题的改进方向错误,比如说因为手工误操作导致故障,如果反思是直接杜绝任何手工操作,就简单粗暴,而且很难落地了

4)关注的还是问题本身,没有从更高的角度来看待问题,通常故障都是和规范,标准,流程相关的


所以对于故障的复盘,我觉得可以从两个大的方向来进行思考和总结,也参考了很多资料,直接搬过来了。 

1)如果快速高效的处理故障,是直面故障时信息的快速上传下达

2)如何避免后续出现此类故障,潜台词就是可以规避,如果规避不了,参考第1条。


所以顺着故障的背景信息来展开,我们可以尝试用如下的两个表格来进行故障复盘和总结。

1)如何快速高效的处理故障


复盘项

问题点

总结改进

监控报警

监控是否足够完备?

流程监控

报警是否足够及时?

秒级监控、自动报障

故障响应

故障响应时间是否过长、能否缩短、如何缩短?

故障电话、主备负责人

故障定位

故障定位时间是否过长、能否缩短、如何缩短?

故障看板、调用网格

故障修复

故障修复时间是否过长、能否缩短、如何缩短?

故障紧急发布通道、大招系统

故障流程

故障信息同步是否及时?

故障信息流转系统

用户投诉反馈是否关注到?

投诉反馈自动聚合上报

客户端故障公告是否按预期周知到位?

联动客服,定期演习;及时弹公告安抚用户

是否还存在不符合流程规范的问题

引起二次故障的一些操作等




2)如何避免后续出现此类故障

复盘项

问题点

总结改进

防患于未然

有没有故障征兆?

系统缺陷的发现机制:运维系统风险工单

故障征兆为何没有及时扼杀?

系统缺陷的跟进与升级机制

不可抗力

挖断光纤

备用专线

机房断电

柴发续供

上联交换机故障

带状态服务打散,避免交换机聚集

外网故障

客户端容灾,自研解析

用户群体性行为

容量灵活伸缩能力

驱动因素

为什么要做这个变更操作?

必要性把关

变更方案和代码变动有没有审核review?

变更风险评估

影响面控制

是否先发布到测试环境和预发布环境验证效果?

增加变更测试和预发布验证的强制流程

测试环境和预发布环境,为什么没有感知和拦截异常?

预发布验证流程监控反馈建设

这个变更操作有没有灰度

强制灰度

这个变更操作是否支持回退?

变更前置的回退评估

回退是否足够及时快速?

升级加速渠道

系统架构

过载保护是否符合预期

review分析有效输出比例

环境耦合情况评估

顶层高扇出,底层高扇入

是否柔性可用

有损大招机制

变更管理

变更权限管理

按负责人收敛权限

变更计划性

严控紧急上线行为

变更时间窗口

非工作时间限制变更

变更质量反馈

变更监控建设


上面的这些问题感觉还是挺不错的,可以作为一个复盘总结时的切入点,把大大小小的故障和问题的处理过程都总结出来。


运维无小事,如果按照复盘的思维总结很多问题,那么你的知识集会越来越丰富。而相应的处理机制也会越来越健全。


我经常和团队成员说:你怎么证明你做的事情是正确的,如果能够按照这种自证的方式解决问题,那么完全就是一种自驱模式,前途不可限量。


QQ群号:763628645

QQ群二维码如下, 添加请注明:姓名+地区+职位,否则不予通过




在看,让更多人看到


本文分享自微信公众号 - 杨建荣的学习笔记(jianrong-notes)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部