赵成的运维体系管理课
赵成
蘑菇街平台技术总监
立即订阅
5558 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 带给你不一样的运维思考
免费
应用运维体系建设 (11讲)
01 | 为什么Netflix没有运维岗位?
02 | 微服务架构时代,运维体系建设为什么要以“应用”为核心?
03 | 标准化体系建设(上):如何建立应用标准化体系和模型?
04 | 标准化体系建设(下):如何建立基础架构标准化及服务化体系?
05 | 如何从生命周期的视角看待应用运维体系建设?
06 | 聊聊CMDB的前世今生
07 | 有了CMDB,为什么还需要应用配置管理?
08 | 如何在CMDB中落地应用的概念?
09 | 如何打造运维组织架构?
10 | 谷歌SRE运维模式解读
11 | 从谷歌CRE谈起,运维如何培养服务意识?
效率和稳定性最佳实践 (20讲)
12 | 持续交付知易行难,想做成这事你要理解这几个关键点
13 | 持续交付的第一关键点:配置管理
14 | 如何做好持续交付中的多环境配置管理?
15 | 开发和测试争抢环境?是时候进行多环境建设了
16 | 线上环境建设,要扛得住真刀真枪的考验
17 | 人多力量大vs.两个披萨原则,聊聊持续交付中的流水线模式
18 | 持续交付流水线软件构建难吗?有哪些关键问题?
19 | 持续交付中流水线构建完成后就大功告成了吗?别忘了质量保障
20 | 做持续交付概念重要还是场景重要?看“笨办法”如何找到最佳方案
21 | 极端业务场景下,我们应该如何做好稳定性保障?
22 | 稳定性实践:容量规划之业务场景分析
23 | 稳定性实践:容量规划之压测系统建设
24 | 稳定性实践:限流降级
25 | 稳定性实践:开关和预案
26 | 稳定性实践:全链路跟踪系统,技术运营能力的体现
27 | 故障管理:谈谈我对故障的理解
28 | 故障管理:故障定级和定责
29 | 故障管理:鼓励做事,而不是处罚错误
30 | 故障管理:故障应急和故障复盘
31 | 唇亡齿寒,运维与安全
云计算时代的运维实践 (6讲)
32 | 为什么蘑菇街会选择上云?是被动选择还是主动出击?
33 | 为什么混合云是未来云计算的主流形态?
34 | Spring Cloud:面向应用层的云架构解决方案
35 | 以绝对优势立足:从CDN和云存储来聊聊云生态的崛起
36 | 量体裁衣方得最优解:聊聊页面静态化架构和二级CDN建设
37 | 云计算时代,我们所说的弹性伸缩,弹的到底是什么?
个人成长 (5讲)
38 | 我是如何走上运维岗位的?
39 | 云计算和AI时代,运维应该如何做好转型?
40 | 运维需要懂产品和运营吗?
41 | 冷静下来想想,员工离职这事真能“防得住”吗?
42 | 树立个人品牌意识:从背景调查谈谈职业口碑的重要性
加餐 (4讲)
划重点:赵成的运维体系管理课精华(一)
划重点:赵成的运维体系管理课精华(二)
划重点:赵成的运维体系管理课精华(三)
新书 |《进化:运维技术变革与实践探索》
结束语 (1讲)
结束语 | 学习的过程,多些耐心和脚踏实地
赵成的运维体系管理课
登录|注册

27 | 故障管理:谈谈我对故障的理解

赵成 2018-03-14
对于任何一个技术团队来说,最令人痛苦、最不愿面对的事情是什么?我想答案只有一个,那就是:故障。
无论是故障发生时的极度焦虑无助,还是故障处理过程中的煎熬痛苦,以及故障复盘之后的失落消沉,都是我们不愿提及的痛苦感受。在海外,故障复盘的英文单词是 Postmortem,它有另外一个意思就是验尸,想想就觉得痛苦不堪,同时还带有一丝恐怖的意味。
写故障相关的文章,也着实比较痛苦。一方面回顾各种故障场景,确实不是一件令人愉悦的体验;另一方面,故障管理这个事情,跟技术、管理、团队、人员息息相关,也是一套复杂的体系。
我们看 Google SRE 这本书(《SRE:Google 运维解密》),绝大部分章节就是在介绍故障相关的内容。其实看看这本书就能明白稳定性和故障管理这项系统工程的复杂度了,而且从本质上讲,SRE 的岗位职责在很大程度上就是应对故障。
所以,接下来的几期文章,我会谈谈我对故障管理的理解,以及一些实际经历的感受,也希望我们每一个人和团队都能够在故障管理中得到涅槃重生。
今天,先谈谈我们应该如何来看待故障这个事情。

系统正常,只是该系统无数异常情况下的一种特例

上面这句话,来自 Google SRE 这本书,我认为这是一个观点,但是更重要的,它更是一个事实。所以,正确理解故障,首先要接受这个现实。
故障,是一种常态,任何一个软件系统都避免不了,国内最牛的 BAT 避免不了,国外最牛的 Google、Amazon、Facebook、Twitter 等也避免不了。业务体量越大,系统越复杂,问题和故障就越多,出现故障是必然的。
可能你会有疑问,既然他们也存在各种故障,但是在我们的印象中,好像也没经常遇到这些大型网站整天出问题或不可访问的情况,这恰恰说明了这些公司的稳定性保障做得非常到位。
这里有一个非常重要的体现,就是 Design for Failure 的理念。我们的目标和注意力不应该放在消除故障,或者不允许故障发生上,因为我们无法杜绝故障。所以,我们更应该考虑的是,怎么让系统更健壮,在一般的问题面前,仍然可以岿然不动,甚至是出现了故障,也能够让业务更快恢复起来
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《赵成的运维体系管理课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(1)

  • yan
    十分认同此文章所说的话,现在有些部门或团队出了问题之后就紧紧抓住那个具体责任人不放,又或者是仅仅关注流程.
    2018-06-04
    2
收起评论
1
返回
顶部