常言道，常在河边走，鞋子永远不会湿。我经常看到周围有很多数据故障。每次遇到这些问题，原因都很尴尬。遇到故障时，除了通常提到的后续改进外，很多人对问题的认识并不深刻。这里有几个方面：1）害怕承担更多的责任，会选择性地降低问题的影响范围和通知范围2）如果问题不是自己造成的，个人感受不够深刻，感觉自己是议论别人的事，你在一旁。反思是直接杜绝任何人工操作，简单粗暴，实施起来难度大4）关注的是问题本身，没有站在更高的角度看问题。通常，故障与规范、标准和流程有关。所以，对于故障我觉得可以从两大方向去思考和总结，我也参考了很多资料，就直接搬过来了。1)快速高效地处理故障，就是直接面对故障快速上传和分发信息。2）以后怎么避免这样的故障，潜台词是可以避免的。如果无法避免，请参考第1条。因此，根据故障的背景信息，我们可以尝试使用以下两个表格进行故障回顾和总结。1）如何快速高效处理故障审核项目问题总结改进监控告警监控是否完善？过程监控报警是否及时？秒级监控，故障自动上报故障响应故障响应时间是否太长，能否缩短，如何缩短？故障呼叫，主备负责人故障定位故障定位时间是否太长，能否缩短，如何缩短？故障看板，调用网格故障修复故障修复时间是否太长，能否缩短，如何缩短？故障应急发布通道，大招系统故障流程故障信息是否及时同步？故障信息流通系统您是否关注过用户投诉和反馈？投诉和反馈会自动汇总和报告。客户端故障通知是否按预期到位？与客服联动，定期演练；如果还有一些操作不符合工艺规范，造成二次故障等，及时公告安抚用户。2）以后如何避免此类故障？失败的症状？系统缺陷发现机制：运维系统风险工单故障症状为何没有及时杀死？系统缺陷后续升级机制不可抗力挖出光纤备份专线机房停电柴油机持续供电上行交换机故障有状态服务分散，避免交换机聚合外网故障客户端容灾，自研分析用户群体行为容量灵活扩展驱动因素为什么要这个变更操作？必要性检查变更计划和代码变更是否有审计审查？变更风险评估影响面控制是否先发布到测试环境和预发布环境验证效果？增加变更测试和预发布验证的强制流程测试环境和预发布环境，为什么没有发现和拦截异常？发布前验证流程监控反馈建设这个更改操作有灰度吗？强制灰度这个变更操作支持回滚吗？变更前的回滚评估回滚是否足够快？通道系统架构升级提速过载保护是否达到预期审查有效输出比分析环境耦合评估顶层高扇出、底层高扇入灵活可用控制应急上线行为变更时间窗口、非工作时限、变更质量反馈、变更监控与建设。上面的问题感觉还不错。它们可以作为回顾和总结的切入点，总结大大小小的故障和问题的处理过程。无小事，如果你按照复习的思路去总结很多问题，那么你的知识储备就会越来越丰富。而相应的处理机制也会越来越完善。我经常对我的团队成员说：你如何证明你所做的是正确的？如果能够通过这种自我认证的方式解决问题，那么就完全是一种自我驱动的模式，前途不可限量。本文转载自微信公众号《杨建荣的学习笔记》，可通过以下二维码关注。转载本文请联系杨建荣学习笔记公众号。
