运营事故的处理及预防

一流的人生,就是看着别人犯错误,自己不犯错误,吸取经验教训;
二流的人生,是自己犯错误,自己吸取教训;
三流的人生,是自己犯错误,自己还不吸取教训。

互联网工程师,特别是后台工程师,经常遇到线上出问题,引起事故。事故有大有小,影响不一,有些能自动恢复,有些影响巨大刻骨铭心。今天就来聊聊运营事故的处理及预防。

如何处理运营事故

虽然发生运营事故是大家都不想看到的,但是真发生了,还是有处理的方法。

1、第一时间同步给leader

为什么要同步给leader呢?自己弄好,谁也不说行吗?肯定不行,纸包不住火。同步给leader只有好处,没有坏处。

同步后,你可以专心处理事故,leader会帮你决策处理方法,通知相关人,评估事情的严重性,寻找经验更丰富的人等。因为leader一般经验丰富,能够快速定位问题,帮你出主意,做决策。如果影响相关团队,还能帮你协调外部资源。如果自己一个人处理,处理不好会事情越来越严重,影响越来越大。处理好了,也违反了流程。按照流程办,就不会出大问题。处理流程也是在众多流血的事故中总结出来的。

2、快速恢复

工程师都有个习惯,遇到问题喜欢弄明白,有学习精神。但是在发生事故时,第一时间想的应该是如何快速恢复,而不是讨论技术和学习。只要能快速恢复和降低事故影响的办法,都是可行的。就像在战士受伤时,衣服也可以撕开当纱布止血用,这时衣服和流血比,还是止血重要。

例如:有的事故是发布新特性导致主流程出了问题,那么即时回滚,比查问题更重要,先回滚恢复,再查为什么。不要让用户的体验一直在流血。

不能快速恢复怎么办

评估影响

看下都哪些用户受影响,影响范围,和严重程度怎么样?如果恢复要多长时间,能恢复在什么程度?有没有替代的方案来处理,即使没有那么完美。

安民告示

通知相关人,整理话术,对外通知出了什么问题,多久会恢复。让外部有个准备,知道发生了什么事情,不会有人乱猜,而引起更严重的误会。

壮士断臂

有时要作出决策,要考虑柔性,舍弃一些正常的功能来保证主功能。决策要砍脖子,到底是手旁边的,还是脑袋旁边的脖子?

事后复盘

事故发生后,要进行详细的复盘,分析原因整改,要记录事故详细过程,事故的原因,造成的影响,改进措施和排期

如何预防事故

事故发生的原因

事故发生的原因有很多,本质都是一个“变更”

发布导致变更

用户行为变更

来的用户多了,热点事件导致用户对某种操作变多了。引起系统过载等问题。一般还是容量管理没有做好,不能应对大流量。
要对容量有个评估,能应对多少请求,当用户行为变更时,能够及时扩容,或柔性可用。

依赖变更导致

是另外一个系统变更所为,到底是自己的防御编程没做好,还是依赖方的程序没写到位?

bug触发

代码中写了“定时炸弹”,例如做系统初期分配的空间写的太小了,随着规模扩大,突破的分配。
有些代码没有用,却放到那里,阴差阳错又被调用了。

既然有这么多原因,如何预防呢?

对变更要保有敬畏之心

每一次代码变更,发布变更。都要谨慎,认真执行review和发布流程。要有柔性预案。要有防范事故的意识。例如:申请ip都是同一机房的,如果线路断了怎么办,机房停电呢?能不能备份了数据,能不能快速搭建一套新的服务,有没有备机?

但是事故发生的原因多种多样,有防范意识很好,但是也难应对所有情况。

吾生也有涯,而知也无涯 。以有涯随无涯,殆已!

为了不“殆已”,要抓住主要环节,最终的出口——监控。不管发生什么问题,都能即使发现,尽早预警。对SLA的指标监控。这是能够做到的。很多事故不是发生了处理不了,而是没发现。发现问题要比解决问题更难。

除此之外要能控制上限,例如发奖,总有个预算,万一多发了,也不至于把钱都发出去。给用户发短信,也不会一天发超过10条,如果超了就别发了。

总结

事故的减少,本质还是人的意识提高。
按照流程规范开发和运维,就不会出大问题。
不要两次被一块石头绊倒,从事故报告中吸取经验教训,减少事故。像圣斗士一样,不会被同一招打倒两次。


转载请注明来源:运营事故的处理及预防
欢迎收听公众号

发表评论

电子邮件地址不会被公开。 必填项已用*标注