SRE 实战手册
15
15
1.0x
00:00/00:00
登录|注册

07|故障处理:一切以恢复业务为最高优先级

你好,我是赵成,欢迎回来。
上一讲我们讨论了 MTTR 的第一个环节,也就是 MTTI(故障发现)阶段的应对措施。今天我们继续来看 MTTR 的另外三个环节,也就是 MTTK、MTTF 和 MTTV 阶段,这三个对应的就是故障诊断、修复与确认,我们一起来看在这些环节应该做好哪些事情。
今天的内容,我会围绕一条基本原则展开,那就是:在故障处理过程中采取的所有手段和行动,一切以恢复业务为最高优先级。这也是我们故障处理过程中的唯一目标,没有第二个。
相信你一定理解这句话我想要表达的意思,但是在执行过程中,我们往往就是很难执行到位。原因是什么呢?
讲到这里,我先分享一个我自己团队的案例,因为这个案例非常典型,其中暴露出来的问题,你很有可能也遇到过。
我们先一起来看下。

一次应急操作导致的故障蔓延

在 2016 年的双十一前,我们蘑菇街策划了一场预热活动,各种优惠券非常诱人,当时确实吸引了大量的用户来参与。这个活动是秒杀类型,瞬时的并发量非常大,我们很乐观地以为做好了十足的准备。
然而真实情况是,一到时间点就出现了用户下单失败问题。当时,我们赶紧采取限流措施,但是发现下单请求仍然大量阻塞,用户访问超时失败。后来进一步排查,发现请求都阻塞在了价格计算的 SQL 语句上。这个信息很快传递到了 DBA 这里,DBA 就马上采取措施:既然有阻塞,那扩容就是最快的手段,先尝试一下再说,所以马上做了 Slave 节点扩容。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

故障处理原则:一切以恢复业务为最高优先级 本文讨论了故障处理过程中的重要原则和应对措施。作者强调了在故障处理过程中,一切行动都应以恢复业务为最高优先级。通过分享一个典型案例,作者指出了故障隔离手段缺失、关键角色和流程机制缺失以及缺乏演练等原因导致的故障蔓延。在此基础上,文章提出了建立有效的故障应急响应机制的方法,包括成立War Room、建立指挥体系和关键角色分工等。作者还介绍了Google的故障指挥体系,包括故障指挥官、沟通引导和运维指挥等核心角色。整体而言,本文强调了在故障处理过程中,技术方面和流程机制方面的重要性,为读者提供了建立有效故障应急响应机制的指导原则。 文章还提到了故障处理过程中的反馈机制,强调了团队间的及时沟通和信息反馈的重要性。此外,还强调了非技术团队在故障处理中的关键作用,包括客服、PR以及商家和合作伙伴代表等,他们的及时沟通和信息同步对于安抚用户情绪和减少外部干扰至关重要。最后,文章提到了故障处理效率的三个关键因素:技术层面的故障隔离手段、指挥体系和角色分工、故障处理机制的演练。 总的来说,本文强调了故障处理过程中的技术和流程机制的重要性,以及团队间的及时沟通和信息反馈的关键作用。同时,文章还提出了思考题,引发读者对于故障应急过程中指挥角色的思考和讨论。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《SRE 实战手册》
新⼈⾸单¥29
立即购买
登录 后留言

全部留言(18)

  • 最新
  • 精选
  • lyonger
    置顶
    能快速处理好故障的团队,内部文化应该也很优秀。这和军队作战类似,经常打胜仗的部队,其内部作风肯定非常严谨细致。而要提高自身作战能力,肯定是要付出代价的,军人可能会流血。相比业务肯定会存在一些因故障演练带来的损失,但随着你业务规模的扩大,这个代价其实省不了。提前向业务方沟通好的故障演练,往往比事后出故障被动处理要好。整个沟通过程,都应尽量化被动为主动,主动发现,主动汇报,主动安抚,尽量降低客户的负面情绪。而且故障过程中汇报用词也很关键,多站在对方的角度思考。另外,故障的处理应对方式,往往你和团队leader(如果这个leader干过运维,那你是幸运的)的认可度有特别大的关系,不然开展起来会很麻烦,毕竟调用的资源不少,牵扯的人又多,还可能有背锅的风险。

    作者回复: 我发现这位读者的分享总是这么优秀,我会置顶你的留言,让更多同行看到。

    2020-04-06
    37
  • Helios
    我们公司因为是b端业务,不要求快速修复。 交付工程师会把软件包在客户内部署,我们称为L1,然后无论是部署问题还是业务问题都会找到对应的开发或者devops,这个过程交付工程师就全靠认识谁就问谁了。 后来公司一看不行,两端的效率都太低了,对于开发效率低的原因是因为一个客户出的问题可能其他客户也会出,要经常回答同样的问题,这时候在交付工程师和开发之间多了一层技术支持我们称为L2,最后开发和devops称为L3。L1解决不来的就问L2他们遇到的问题比较多,最后才是L3 这个时候问题解决的效率全靠L2了,因为他们要两端协调,他们就负责了指挥的角色。我觉得我们在文中讲到的角色定位做还算可以,但是技术方面的故障隔离,还有故障演练因为业务原因没有建立,老师觉得呢我们这种业务又没有必要建立呢

    作者回复: 首先,感谢你前面的分享,很好的实践。 关于你提到的问题,其实这里提到的L2确实是非常关键的角色,他是承上启下的作用。是不是有必要进行故障演练,看业务、场景和客户需求,如果产品稳定,客户诉求不大,可以降低优先级,但是如果经常出问题,客户反馈比较多,建议还是跟客户一起做必要的演练。

    2020-04-04
    7
  • 蒋悦
    故障处理过程的管理和软件开发的管理其实是一样的,只不过周期短得多。我经常和团队的人说,即使没有进展也要反馈。我带的都是小项目,一般我也要管故障处理。 不过我提一点,决策应该是“权责利”相匹配的,别决策做对了啥奖励也没有,决策做错了就直接被开了。 另外,

    作者回复: 你说的对,下一篇我们就会讲到“鼓励改进,而不是处罚错误”。 好像你的问题没有说完,可以补上继续提问哈。

    2020-04-01
    3
    6
  • wholly
    受益匪浅,特别是那句:没有进展也是进展!很多从事故障处理或维护人员没有这个意识,确实很关键!我们团队的指挥官一般是负责整个系统的SE来承担,拉通的同时,也做技术决策,还是比较高效的。

    作者回复: 找对人和关键角色,效率自然就会大大提升。

    2020-04-07
    4
  • Zachary
    问题到最后不再是简单的技术问题, 还要有管理(流程)和沟通

    作者回复: 技术只是问题的一个维度,要尝试从更多的角度去看问题,解决问题。

    2020-10-14
    1
  • 宋子龙
    太棒了👏非常受用

    作者回复: 对你有帮助,很开心。

    2020-04-01
    1
  • leslie
    这个问题应当是不同公司不同情况吧:有些企业或是技术总监,有些会是部门主管;这其实涉及到的最关键问题就是权限-足够的沟通和协调权限,这种可能涉及跨部门操作的事情只能是公司的中高层。 甚至当直接协调人不在时会有相关业务部门的同级别人员去承担相应的事情。

    作者回复: 不同企业情况不同,这里最重要的是要有足够的授权给到。

    2020-04-01
    2
    1
  • 小炭
    至少总监级别的人物作为指挥和协调者。

    作者回复: 对,一定要有资源调动能力

    2020-11-08
  • Quinn
    为什么没有提前做出准确的评估?技术问题还是管理问题?再次发生的组织手段是什么?这里讲到当故障发生时的对应。理想情况是尽可能避免故障发生。如果没有总结出防止问题出现的手段。仍会导致混乱。

    作者回复: 改进措施最终一定要落地,而且可验证。不然,如你所说,问题不解决,仍然会导致相同的混乱。

    2020-05-05
  • xierongfei
    这个故障处理流程 和 google SRE 那本书讲的类似。我们公司在处理故障中也慢慢引入,之前出问题全是运维排查,看日志重启服务,后面确定了责任,运维只对基础设施负责,重启和业务异常排查,全部开发来做。
    2022-01-24
    1
收起评论
显示
设置
留言
18
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部