有句话说，常在河边走，哪有不湿鞋。我身边经常会看到不少数据故障。每每碰到这些问题，原因都是让人唏嘘不已。
而碰到故障的时候，除了通常都会说的后续改进，其实很多人对于问题的认识和理解还不够深入，这里主要包含几个方面：
1)害怕承担更多责任，会选择性的缩小问题影响范围和通知范围
2)如果问题不是出在自己身上，切身的感受不够深刻，觉得是在讨论别人的事情，持旁观态度
3)对于问题的改进方向错误，比如说因为手工误操作导致故障，如果反思是直接杜绝任何手工操作，就简单粗暴，而且很难落地了
4)关注的还是问题本身，没有从更高的角度来看待问题，通常故障都是和规范，标准，流程相关的
所以对于故障的复盘，我觉得可以从两个大的方向来进行思考和总结，也参考了很多资料，直接搬过来了。
1)如果快速高效的处理故障，是直面故障时信息的快速上传下达
2)如何避免后续出现此类故障，潜台词就是可以规避，如果规避不了，参考第1条。
所以顺着故障的背景信息来展开，我们可以尝试用如下的两个表格来进行故障复盘和总结。
1)如何快速高效的处理故障
|
复盘项 |
问题点 |
总结改进 |
|
监控报警 |
监控是否足够完备？ |
流程监控 |
|
报警是否足够及时？ |
秒级监控、自动报障 |
|
|
故障响应 |
故障响应时间是否过长、能否缩短、如何缩短？ |
故障电话、主备负责人 |
|
故障定位 |
故障定位时间是否过长、能否缩短、如何缩短？ |
故障看板、调用网格 |
|
故障修复 |
故障修复时间是否过长、能否缩短、如何缩短？ |
故障紧急发布通道、大招系统 |
|
故障流程 |
故障信息同步是否及时？ |
故障信息流转系统 |
|
用户投诉反馈是否关注到？ |
投诉反馈自动聚合上报 |
|
|
客户端故障公告是否按预期周知到位？ |
联动客服，定期演习；及时弹公告安抚用户 |
|
|
是否还存在不符合流程规范的问题 |
引起二次故障的一些操作等 |
2)如何避免后续出现此类故障
|
复盘项 |
问题点 |
总结改进 |
|
防患于未然 |
有没有故障征兆？ |
系统缺陷的发现机制：运维系统风险工单 |
|
故障征兆为何没有及时扼杀？ |
系统缺陷的跟进与升级机制 |
|
|
不可抗力 |
挖断光纤 |
备用专线 |
|
机房断电 |
柴发续供 |
|
|
上联交换机故障 |
带状态服务打散，避免交换机聚集 |
|
|
外网故障 |
客户端容灾，自研解析 |
|
|
用户群体性行为 |
容量灵活伸缩能力 |
|
|
驱动因素 |
为什么要做这个变更操作？ |
必要性把关 |
|
变更方案和代码变动有没有审核review？ |
变更风险评估 |
|
|
影响面控制 |
是否先发布到测试环境和预发布环境验证效果？ |
增加变更测试和预发布验证的强制流程 |
|
测试环境和预发布环境，为什么没有感知和拦截异常？ |
预发布验证流程监控反馈建设 |
|
|
这个变更操作有没有灰度 |
强制灰度 |
|
|
这个变更操作是否支持回退？ |
变更前置的回退评估 |
|
|
回退是否足够及时快速？ |
升级加速渠道 |
|
|
系统架构 |
过载保护是否符合预期 |
review分析有效输出比例 |
|
环境耦合情况评估 |
顶层高扇出，底层高扇入 |
|
|
是否柔性可用 |
有损大招机制 |
|
|
变更管理 |
变更权限管理 |
按负责人收敛权限 |
|
变更计划性 |
严控紧急上线行为 |
|
|
变更时间窗口 |
非工作时间限制变更 |
|
|
变更质量反馈 |
变更监控建设 |
上面的这些问题感觉还是挺不错的，可以作为一个复盘总结时的切入点，把大大小小的故障和问题的处理过程都总结出来。
运维无小事，如果按照复盘的思维总结很多问题，那么你的知识集会越来越丰富。而相应的处理机制也会越来越健全。
我经常和团队成员说：你怎么证明你做的事情是正确的，如果能够按照这种自证的方式解决问题，那么完全就是一种自驱模式，前途不可限量。
本文转载自微信公众号「杨建荣的学习笔记 」，可以通过以下二维码关注。转载本文请联系杨建荣的学习笔记公众号。
