27 | 故障管理:谈谈我对故障的理解
赵成
该思维导图由 AI 生成,仅供参考
对于任何一个技术团队来说,最令人痛苦、最不愿面对的事情是什么?我想答案只有一个,那就是:故障。
无论是故障发生时的极度焦虑无助,还是故障处理过程中的煎熬痛苦,以及故障复盘之后的失落消沉,都是我们不愿提及的痛苦感受。在海外,故障复盘的英文单词是 Postmortem,它有另外一个意思就是验尸,想想就觉得痛苦不堪,同时还带有一丝恐怖的意味。
写故障相关的文章,也着实比较痛苦。一方面回顾各种故障场景,确实不是一件令人愉悦的体验;另一方面,故障管理这个事情,跟技术、管理、团队、人员息息相关,也是一套复杂的体系。
我们看 Google SRE 这本书(《SRE:Google 运维解密》),绝大部分章节就是在介绍故障相关的内容。其实看看这本书就能明白稳定性和故障管理这项系统工程的复杂度了,而且从本质上讲,SRE 的岗位职责在很大程度上就是应对故障。
所以,接下来的几期文章,我会谈谈我对故障管理的理解,以及一些实际经历的感受,也希望我们每一个人和团队都能够在故障管理中得到涅槃重生。
今天,先谈谈我们应该如何来看待故障这个事情。
系统正常,只是该系统无数异常情况下的一种特例
上面这句话,来自 Google SRE 这本书,我认为这是一个观点,但是更重要的,它更是一个事实。所以,正确理解故障,首先要接受这个现实。
故障,是一种常态,任何一个软件系统都避免不了,国内最牛的 BAT 避免不了,国外最牛的 Google、Amazon、Facebook、Twitter 等也避免不了。业务体量越大,系统越复杂,问题和故障就越多,出现故障是必然的。
可能你会有疑问,既然他们也存在各种故障,但是在我们的印象中,好像也没经常遇到这些大型网站整天出问题或不可访问的情况,这恰恰说明了这些公司的稳定性保障做得非常到位。
这里有一个非常重要的体现,就是 Design for Failure 的理念。我们的目标和注意力不应该放在消除故障,或者不允许故障发生上,因为我们无法杜绝故障。所以,我们更应该考虑的是,怎么让系统更健壮,在一般的问题面前,仍然可以岿然不动,甚至是出现了故障,也能够让业务更快恢复起来。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
故障管理的关键思考 故障管理对于技术团队来说是一项痛苦而必要的任务。本文从“系统正常,只是该系统无数异常情况下的一种特例”和“故障永远只是表面现象,其背后技术和管理上的问题才是根因”两个观点出发,探讨了故障管理的重要性和应对策略。 文章首先指出故障是系统运行的常态,任何软件系统都无法避免。因此,关注点应该放在如何让系统更健壮,能够在一般问题面前保持稳定,并在出现故障时快速恢复业务。其次,强调故障只是表面现象,真正的问题在于技术和管理层面。因此,在故障复盘过程中,应该聚焦于背后存在的技术和管理问题。 最后,作为管理者,需要思考如何更快地发现问题、更快地恢复业务,并不断改进故障应对的能力。这需要从全局角度思考,包括完善发布系统、稳定性平台建设、故障预案和演练等方面。 总的来说,本文强调了故障管理的重要性,提出了应对故障的思考方式和策略,对于技术团队和管理者都具有一定的指导意义。文章内容深入浅出,为读者提供了对故障管理的全面思考,对技术团队和管理者具有重要参考价值。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《赵成的运维体系管理课》,新⼈⾸单¥59
《赵成的运维体系管理课》,新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(4)
- 最新
- 精选
- Raymond吕出问题先自省
作者回复: 非常正确,首先要从自身找问题,看自己哪里做的不到位
2020-03-121 - yan十分认同此文章所说的话,现在有些部门或团队出了问题之后就紧紧抓住那个具体责任人不放,又或者是仅仅关注流程.2018-06-046
- 风飘,吾独思出问题不能光去追责,需要看清问题背后的问题。变更是故障之源,一般情况下变动最多的人出现故障的几率也就越高,如果一棒子打死,那以后还有谁去做事情。2020-06-231
- Star如果实在无法,建议分两个步骤:定责大会批斗,反省大会思进取。抓住每一次复盘,多角度改进。2022-11-21归属地:广东
收起评论