SRE实战手册
赵成
蘑菇街技术总监
立即订阅
3438 人已学习
课程目录
已完结 13 讲
0/2登录后,你可以任选2讲全文学习。
开篇词 (1讲)
开篇词|SRE是解决系统稳定性问题的灵丹妙药吗?
免费
基础篇 (5讲)
01|SRE迷思:无所不能的角色?还是运维的升级?
02 | 系统可用性:没有故障,系统就一定是稳定的吗?
03 | SRE切入点:选择SLI,设定SLO
04 | 错误预算:达成稳定性目标的共识机制
05 | 案例:落地SLO时还需要考虑哪些因素?
实践篇 (5讲)
06 | 故障发现:如何建设On-Call机制?
07|故障处理:一切以恢复业务为最高优先级
08|故障复盘:黄金三问与判定三原则
09|案例:互联网典型的SRE组织架构是怎样的?
10 | 经验:都有哪些高效的SRE组织协作机制?
结束语 (2讲)
结束语|聊聊我的SRE落地心路历程
答疑|没什么能阻挡你拓展边界的渴望
SRE实战手册
15
15
1.0x
00:00/00:00
登录|注册

06 | 故障发现:如何建设On-Call机制?

赵成 2020-03-30
你好,我是赵成,从今天开始,我们进入课程实践篇的内容。
在上一部分,我们学习了 SRE 的基础,需要掌握的重点是 SLI 和 SLO 以及 Error Budget(错误预算)策略。SLI 是我们选择的衡量系统稳定性的指标,SLO 是每个指标对应的目标,而我们又经常把 SLO 转化为错误预算,因为错误预算的形式更加直观。转化后,我们要做的稳定性提升和保障工作,其实就是想办法不要把错误预算消耗完,或者不能把错误预算快速大量地消耗掉。
这么说,主要是针对两种情况:一种是我们制定的错误预算在周期还没有结束之前就消耗完了,这肯定就意味着稳定性目标达不成了;另一种情况是错误预算在单次问题中被消耗过多,这时候我们也要把这样的问题定性为故障。
今天,我们就来聊一聊,为了最大程度地避免错误预算被消耗,当我们定义一个问题为故障时,我们应该采取什么措施。

聚焦 MTTR,故障处理的关键环节

好了,我们先回顾下在第 1 讲的时候,提到故障处理的环节就是 MTTR,它又细分为 4 个指标:MTTI、MTTK、MTTF 和 MTTV,之所以分组分块,也是为了更加有目的性地做到系统稳定性。
那么,这四个环节,在我们故障处理 MTTR 又各自占多长时间呢?下面这个 MTTR 的时长分布图,是 IBM 在做了大量的统计分析之后给出的。
我们可以看到,MTTK 部分,也就是故障定位部分的时长占比最大。这一点,我们应该都会有一些共鸣,就是绝大部分的故障,往往只要能定位出问题出在哪儿了,一般都可以快速地解决故障,慢就慢在不知道问题出在哪儿,所以说我们大部分时间都花在寻找问题上了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《SRE实战手册》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(13)

  • 美美 置顶
    谷歌SRE应急时间处理策略有一条是:由万(全)能工程师解决生产问题 向 手持“运维手册”的经过演练的on-call工程师 演进,核心思路是建设故障处理SOP,保证SRE可以处理大多数故障。这个思路是否和确保关键角色在线冲突!

    作者回复: “由万(全)能工程师解决生产问题 向 手持“运维手册”的经过演练的on-call工程师 演进,核心思路是建设故障处理SOP,保证SRE可以处理大多数故障”

    感谢你的分享,直接道出了我们oncall应该追求的目标,对于我们内容是非常好的补充。

    内容里我们提到的关键角色在线,就是指on-call工程师必须在值守过程中准实时在线,目的是为了及时响应,这个是机制上的保障,然后在处理问题时,需要有故障处理SOP,并且能按照SOP执行,这个是能力上的要求。

    所以,两者不矛盾。再次感谢你的补充,非常棒。

    2020-03-31
    4
  • soong
    监控体系解决的问题是给我们提供一个视角,更快发现或感知到问题发生。On-Call机制想要解决的在于真正去处理、解决问题的部分,关注点是有效性与机制建设本身。
    没有监控系统的支撑,感知到故障发生所需的时间就要很久;没有高效的On-Call机制,处理并解决故障问题的时间也会被拉长,老师文中也有举例!从重要性的层面来看,两者是相互促进、相互支撑的作用。
    从公司的发展过程来看,我个人认为,先建设一个能有效运行的监控系统,随后跟进On-Call机制的建设,是一个可行的路线!先建设On-Call机制,如果缺乏有效的监控系统,从提升系统的稳定性来看,针对性似显不足。希望看到老师的观点!

    作者回复: 前面两段讲清楚了,监控和on-call机制的关系,很赞。

    最后的问题,其实我的建议是,先要有on-call机制,因为问题反馈的渠道不一定只要监控,可能还有用户投诉、同事反馈等等,当遇到这些问题时,也需要有高效的响应机制。而且在早期,有可能监控并不准确,反而是其它渠道的反馈占比更高。

    2020-04-04
    3
  • moqi
    在某某公司的运维小伙和我提起过,他们那的系统出了问题,SRE的第一件事是写故障报告,第二件事是解决问题,坑爹的是解决问题的时候还得不停的回复boss们的询问,更坑爹的是其他的SRE没有任何的协作机制,看他一人在那忙死,没有丝毫的互备机制,老大们似乎也不觉着这是个巨大的问题。

    有再强大的监控体系,但没有协同作战的意识,这样团队里的成员哪来的团队荣誉感

    这套On-call响应机制很棒,应该是团队不停的磨合和共创出来的

    作者回复: 很好的关于感受的分享。

    特别是第一段,应该是我们要极力避免的状态和情况。

    2020-03-30
    1
    3
  • 旭东(Frank)
    熟悉某个系统的最快最好的方式就是参与 On-Call,而不是看架构图和代码。

    这块感觉应该是精通系统细节

    作者回复: 在炮火中磨炼,会成长的更快,对于细节的了解也会更深入。

    2020-04-03
    2
  • Go!SRE!
    ON-call机制重要,毕竟监控体系是持续优化进步的过程,而业务的故障是随时发生,优先恢复业务是最高优先级。良好的on-call机制既能保障业务,也能将处理过的故障快速反馈到监控体系,进一步优化监控体系,达到双赢。

    作者回复: 思考的很全面奥

    2020-03-30
    2
  • wholly
    看完老师的课程,很想从开发转岗到SRE,感觉很刺激😂

    作者回复: 不经历磨难,怎么见光明。不一定要转岗,但是开发过程中要多跟SRE交流学习,时间长了,你就是具备SRE意识和能力的开发。

    2020-03-30
    2
  • Helios
    on—call和监控,我感觉是鸡生蛋蛋生鸡的问题。首先oncall不能没有监控作为基础,要不然只能靠人工反馈了,单纯有监控没有oncall不能及时解决问题。

    监控对事故复盘有很好的作用,能完善oncall的指标,oncall反过来也能促进监控的发展,又是相辅相成的关系。

    但是如果这两个都没有的情况下,先建设哪一个。
    这个时候业务量不大,可以先建设监控,然后根据客服用户反馈解决事故,通过事故复盘增加oncall机制。

    作者回复: 非常好的分享,最终我们要学会两条腿走路,这才是最关键的。

    2020-04-04
    1
  • huadongjin
    MTTR的流程说的真好,在日常的稳定性工作中对这块有概念,但一直没有抽象出来,听赵老师你一讲,顿时豁然开朗。也给的工作规划起到了指导作用,那就是如何去缩短MTTI和MTTK的时长,提高故障修复效率,进而减少故障持续时长。我准备从告警和全网变更入手,这两项是故障的狼烟和故障的推手,在有疑似故障或故障定位中,拉取近一段时间的变更事件,包括安全、系统、网络、发布、数据库、中间件等变更类型,去协助定位故障。相信对他们的掌握有利于站在更高的角度看问题。请问这样的思路可行嘛,赵老师。

    作者回复: 变更日志的记录和检索,这个思路是没有问题的,但是因为每个系统和体系的日志不一定规范或者能够汇总全面,甚至是有些操作是业务层面的,所以,现实中不一定可行。

    更可行的方式是,针对一些关键部件的变更进行收集,比如软件发布、网络变更、数据库变更等等。

    2020-04-03
    1
    1
  • 一步
    关于On Call流程机制的建设说到了痛点,往往就是系统出问题了,不能迅速的联系对应的责任人

    作者回复: 这个是通病,也是非常容易被忽视掉的部分,而忽视的原因,是因为跟技术没有太大关系。

    2020-03-30
    1
  • leslie
    老师提及了错峰上班,可能我所经历的某些企业就是直接的翻班,这是国内IDC机房普遍使用的策略。必要时候这种翻班是从部门经理层一直到一线员工,集体翻班或者延长工作时间去保障其稳定性。
    监控的体系再怎么做其实都是后知后觉,就像SRE中说及"没有故障是特殊现象“,有问题有故障才是常态,故而On-call的机制是第一时间处理问题;二者又是相互的。只有在解决完处理完成后才能进一步去改善监控体系。
    谢谢老师今天的分享:期待后续的课程。

    作者回复: 很好的分享。

    因为IDC机房是基础设施,太关键了,很多银行和金融企业也是24小时现场值班,因为经不起半点疏忽。

    监控和on-call在一段时间内是要互补的,监控跟不上,on-call机制来补,随着业务体量的增大,监控的重要性会越来越大,也要同步建设起来。

    2020-03-30
    1
  • Christopher
    第一次听赵成老师的声音,还挺有磁性的,哈哈

    作者回复: 谢谢!

    其实内容也很有料,是吗?^_^

    2020-03-30
    1
  • 牧野静风
    对于中小型企业的我们来说,运维能做的就是做好各种监控体系,尽可能在用户反馈问题之前监控到故障,进行恢复。我们的做法是,每个项目有个Leader,出问题运维,开发,DBA协同处理,小团队这样配合解决问题还是挺快的。但是以前遇到过凌晨出现问题,各种人员Call不上,所以我们上线尽量放在周一到周四

    作者回复: 变更是“万恶之源”,所以人员不容易聚集的情况下,尽量避免变更是合理的策略。

    2020-05-07
  • daniel_yc
    从事一线运维工作6年了,最大的感受就是能力强的能被累死,我们行业比较特殊,基本上每个大的客户现场都有人驻守,加上客户自己的保障人员。有完整的on-call流程,奇葩的是,出现问题,第一反应是找能力强的人来解决,而当时当班的人只是用来传话的。。这就导致能力强的人被累死,基本上没周末没假期。。。。

    作者回复: 我遇到过很多这样的情况,其实这不是个人的问题了,这个是公司或机制的问题,应该要能轮转起来,并且一定周期内得对故障或问题的发生有容忍度才可以。另外,对于发生的问题或故障,要有分级才可以,不然啥问题过来都要立即马上处理,这种对oncall的同事来说,压力过大。

    2020-05-04
收起评论
13
返回
顶部