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

08|故障复盘:黄金三问与判定三原则

你好,我是赵成,欢迎回来。
前两讲,我们聚焦在 MTTR 阶段,我跟你分享了从故障发现到故障处理的一些经验。但是,即便我们身经百战,做足了准备,故障的发生依然是很难避免的。这时候,我们也没必要太沮丧,SRE 中有一条很重要的原则可以帮到我们,那就是“从故障中学习和提升”,也就是故障复盘。
那么,今天我会专门用一节课,来和你分享我在故障复盘过程总结的经验。

故障复盘的黄金三问

提起故障复盘,我自己的团队也是踩了很多坑,说出来都是血泪史。
最开始,我们坚信既然要复盘,那就一定要追根溯源,找到根因,最好是一次性解决所有问题,一次性把事情做对肯定是最高效的呀。
但是,在执行的过程中,我们发现,对于根因的理解和定义,每个人或每个角色都不一样。而且,一旦设定为找根因,那就只能有一个,还特别容易根据找到的根因来定责,导致把原本的寻求根因是什么,转变为“责任是谁”的问题。本来是想通过复盘来引导改进的,但是很容易画风一变,开始推诿扯皮,故障复盘会就开成了批斗会,每个参与的人都要承受很大的心理压力。
我这么说,不知道你是不是有同感。接下来我给你讲两个特别常见的情况,你也感受下。
比如,服务器故障导致上面业务也发生问题了,从业务开发同学的角度来看,这肯定是因为服务器不稳定造成的呀,根因就是服务器故障啊!但是从系统维护同学的角度来看,硬件故障属于不可控事件,所以这种情况下,根因应该是业务应用层没有做到高可用。你看,不同的角度,不同的分析判断。就这个情况来说,你觉得根因是什么?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

故障复盘是SRE中的重要原则,旨在从故障中学习和提升。文章提出了故障复盘的黄金三问:故障原因有哪些?我们做什么,怎么做才能确保下次不会再出现类似故障?当时如果我们做了什么,可以用更短的时间恢复业务?作者分享了团队在故障复盘过程中的经验,强调了故障根因不止一个的观点,提倡一起寻找引起故障的原因并制定改进措施。文章还介绍了在故障复盘时的具体做法,包括结合Timeline进行分类、针对耗时长的环节讨论改进措施、定责任人和时间点并持续跟进执行状况。最后,强调了在故障复盘会上紧扣着黄金三问进行讨论,不允许相互指责和埋怨的情况出现。整体而言,文章强调了故障复盘的重要性,提出了实用的方法和原则,对于SRE从业者具有一定的指导意义。 文章还介绍了故障判定的三原则,包括健壮性原则、第三方默认无责、分段判定原则,这些原则旨在帮助团队更开放地寻找不足,从自身找不足,找到更多可以改进的地方,不断从故障中学习和改进。作者强调了不纠结于故障根因,而是将更多的注意力放在提升故障处理的效率,缩短业务故障时长。最后,作者提出了一个思考题,邀请读者分享对于5W分析法的看法。 总的来说,本文通过介绍故障复盘的重要性、黄金三问和故障判定的三原则,为读者提供了实用的方法和原则,帮助他们更好地进行故障复盘和持续改进。

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

全部留言(15)

  • 最新
  • 精选
  • leslie
    其实这里提及到一个比较重要的点:备用措施。老师今天的课程又再次提及了原来课程推荐的《SRE Google 运维解密》中的经典名言“故障是常态,正常是特殊态”。 要想避免故障最关键的其实就是“是否有备用或应急处理方式以及如何均衡”。现在的系统越来越复杂,如何合理的稳定这个确实很难。 前几天听到一个例子:公司上了Docker,然后Docker的数目是实际服务器和人员的数倍;导致公司下架闲置设备时很困难。各个环节如何做到防患于未燃才是根本,故障的根本就是许多人以为“天下无贼”,然后被“贼”给光顾了。 谢谢老师的今天的分享,期待后续的课程。

    作者回复: 谢谢你的分享,还举了一个很现实的例子。

    2020-04-03
    14
  • EQLT
    故障复盘其实跟研发项目复盘会议很相似,本质上都是围绕怎么去让“项目”做得更好。 但是往往这种会议中,如果职位或地位比较高的人主导的观点或者方向错误时,底下的人员就会默默接受“挨骂”,比如提出前后端协作不顺畅问题导致项目延迟,最终根因变成单人积极性不足,这样打击了员工积极性的同事,也没有梳理痛点并改进,这样的氛围和项目接下来也是堪忧的。要形成这种“一起将事情做得更好的”文化氛围,个人觉得领头的必须有这个意识并时刻反思改进,从点到面的推广传播,不然都是空喊口号。

    作者回复: 感同身受。你说地非常对,往大了说这个是文化问题,往细了说,团队中有影响力的人要能够发挥作用,“鼓励改进,而不是处罚错误”,这一点是要落到实处的。 感谢你的分享。

    2020-04-05
    2
    13
  • Jxin
    1.针对健壮性定责有点个人见解。首先,防御式编程没有毛病,但是防御式编程有时成本是比较大的。比如b服务依赖a服务,a服务做好代码健全成本很低,而b服务要做好完善的防御式编程成本较高,这时候b服务与a服务间的交互采用契约编程并不为过。 2.所以,我觉得在发生故障时,定责应该以a服务和b服务,谁做好代码健全的成本较低,谁负责主要责任。(a犯了很低级的错误,但能快速修复就无责。b服务因为a服务的失误导致故障,但无法快速恢复就全责。这有点难受。)

    作者回复: 很好的分享。 针对最后提到的a犯了低级错误,这种其实我们定责时会要a承担对应的责任的,甚至是主要责任。 所以,具体case具体分析。

    2020-04-03
    2
    6
  • lyonger
    亚马逊的复盘就提倡ask 5why方法,我觉得无论哪种方法,其关键就是故障处理,故障复盘,故障改进需做到整体的闭环,这就需要跳出故障本身,站在更上层考虑整体的业务。比如某个团队的a业务出了故障,找到了问题,自身业务已经修复,那么该问题其他团队的b/c/d业务也可能会遇到,那么如何推动线上的业务全部fix? 我认为这需要一个良好的有效测试环境,毕竟对b/c/d...来讲是一次变更,要知道变更往往是故障的来源,所以变更之前的有效测试就很重要。

    作者回复: 很棒的分享!

    2020-04-06
    5
  • 霸波儿奔
    摒弃 “根因只有一个” 这个的观点,以更开放的心态去寻找不足,多从自身找不足,找到更多可以改进的地方,不断从“故障中学习和改进”

    作者回复: 你Get到了重点

    2020-05-29
    3
  • 天草二十六
    老师,除了《SRE Google 运维解密》,还请推荐其他学习资料一二

    作者回复: 我后面会统一推荐

    2020-04-06
    3
    1
  • 这里的应对故障的措施就是做好自己一切能做的,最大程度降低内部对外部的依赖

    作者回复: 对,要遵循健壮性原则。

    2020-04-04
    1
  • Helios
    经历过一次把case study变为批斗会的,研发、产品、质量的tl都在,全程质量部tl在骂人还是指名的骂人,还就骂一个人。 但是我就暗暗发誓,一定要听话,不再参加case study了。那时候是18年刚毕业时候参加的,后续看到开源社区的case study的文档,发现他们是为了项目的发展去复盘,而不是和我们当初一样是为了追究责任。今天听到老师讲了这一课,更加确信了我们当初的机制还是有个问题,至少却一个正真CL的身份,而不在会上让人想说啥说啥。

    作者回复: 除了CL这个角色,更重要的是故障复盘的文化和机制,复盘文化往往也体现了公司的文化,是大家齐心协力共改进,还是出现问题一定要撇清责任,这一点不是技术问题,一定要从文化和氛围层面去解决。

    2020-04-04
    1
  • 程子
    学习了老师的课程非常有收获。 在实际团队管理中,有些事故确实不可避免,但也经常会有些低级失误导致的事故。 能给介绍一下,在您的实际团队管理中,制度关于什么情况需要进行绩效处罚,这块是怎么规定的,不知能否给介绍一下?

    作者回复: 比如低级失误、重复错误以及触碰高压线,这样的情况是要跟绩效挂钩的。这部分可以参考我第一门课中的相关内容。

    2020-04-11
  • 蒋悦
    我印象里经常用5w做追问,问着问着就把对方问傻了

    作者回复: 是的,问着问着就不知道偏到什么地方去了,其实5w方法对提问者的要求也是非常高的。

    2020-04-08
收起评论
显示
设置
留言
15
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部