稳定性经验分享:如何应对生产事故

微信扫一扫,分享到朋友圈

稳定性经验分享:如何应对生产事故

1. 事故洞察

首先,你得对自己负责的系统了如指掌,同时有多种渠道来源,能够帮助你第一时间发现生产事故,比如实时监控预警系统、客诉部门、基础服务支撑部门、第三方服务依赖方等等。

如果核心业务交易量大、交易分布时间相对平均、业务面向 C 端用户多、业务重要程度高,需要特别安排 7*24 小时监控室 + 工程师轮值 on-call 机制,on-call 要求轮值工程师在一定时间内随叫随到,做好生产环境出现紧急情况的应对准备。

2. 事故分析

如果确保了第一时间能够发现生产问题,接下来最重要的事情不是去定位问题发生的根本原因,而是要 先去分析事故的影响范围和严重程度 ,比如是否会产生资损风险、资损的金额可能有多大、影响用户的范围有多大、是否非常严重等等。

因为研发人员的特点是发现问题会习惯性地排查问题的原因,而且一般都会觉得自己可以快速解决掉问题。可往往真实情况是,一个技术难点陷进去之后需要很长时间,就算这个难点解决了,却发现又出现了第二个问题。这就像电视剧里面通过线索排查案情一样,问题一环套一环,结果是时间可能已经过去了 30 分钟,问题也没有解决,这个时候生产事故已经扩大影响范围。

3. 事故升级

如果事故属于严重程度,需要立刻进行事故升级,通知相关业务方和上级领导。

及时向上级汇报有三大好处:

第一,领导会根据严重程度协调高层资源,进而加快解决问题的速度;

第二,没有完美的生产事故解决方案,很多时候需要领导在不同方案中做决策;

第三,就算这次事故没有处理好,第一时间告知领导之后,至少不失告知责任。

需要注意的是,在给领导汇报生产事故的同时,最好提供一些事先应对预案,并将不同预案的风险和优缺点如实告诉他,请他来决策和支持。

4. 事故应对

如果你在长期的应用运维过程中不断积累和沉淀,那么,对于 80% 的常见问题你是可以提前做出应对的。

比如,Java 系统产生 OOM 内存溢出,虽然不知道是什么原因导致的,但是可以通过立即重启来恢复服务;再比如数据库连接池占满,导致其他服务不可用,如果没有最好的方案,可以从数据库层面杀掉耗时最长的慢连接。

5. 事故复盘

事故解决之后,需要做的事情是复盘事故发生和解决的详细过程,包括发生时间、参与人员、详细处理过程、结束时间等环节。如果事故的应对方案是短期临时方案,还需要进一步针对此次事故制定长期解决方案,并且快速上线。

复盘最主要的目的不是问责,而是回顾解决事故的整个过程,总结经验,下一次遇到类似问题能够更加快速从容地应对。此外还能通过复盘分析事故的特点,寻找能够提前避免的预防方案,因为最重要的事情还是需要做到事前预防,而不是事后补救。

6. 故障预案

这里所说的方案池更像是历史生产事故记录表,也就是生产事故预案,你可以把经常发生的事故的应对方案放到应急方案池中,作为团队的共享资源。一旦发生这类问题,就算是新入职的同事也可以参考方案池快速解决问题。

如果再有新的事故发生,就再次把新的方案融入到方案池,这样方案池就越来越丰富,从而不断积累形成宝贵的经验。通过这种方式,生产系统的新问题一定会越来越少。

7. 故障演练

研发团队需要不定期做故障演练,包括数据库故障演练、应用故障演练、网络故障演练等一系列的极端情况下的故障模拟,确保真正出现问题的时候,能够沉着应对。

当你掌握了这些方法,就能从容地应对生产事故,避免或者减少生产事故所带来的影响。

图解|什么是蒙提霍尔问题

上一篇

消息队列与消息中间件概述:消息中间件核心概念与技术选型

下一篇

你也可能喜欢

稳定性经验分享:如何应对生产事故

长按储存图像,分享给朋友