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

01|SRE迷思:无所不能的角色?还是运维的升级?

你好,我是赵成。
作为这个课程的第一讲,我先从实践的角度,和你聊聊应该怎么理解 SRE。
为什么要强调是实践的角度呢?
开篇词里我们就提到过,有人认为 SRE 就是一个岗位,而且是一个具备全栈能力的岗位,只要有这么一个人,他就能解决所有稳定性问题。这还只是一种理解,而且这个理解多是站在管理者的角度。
也有人站在运维人员的角度,认为做好 SRE 主要是做好监控,做到快速发现问题、快速找到问题根因;还有人站在平台的角度,认为做好 SRE 要加强容量规划,学习 Google 做到完全自动化的弹性伸缩;甚至还有人认为,SRE 就是传统运维的升级版,把运维自动化做好就行了。
你看,其实不同的人站在不同的角度,对 SRE 的理解就会天差地别,但是好像又都有各自的道理。
所以,我特别强调实践的角度,我们不站队,就看真实的落地情况。我总结了一下从实践角度看 SRE 的关键点,就一个词:体系化SRE 是一套体系化的方法,我们也只有用全局视角才能更透彻地理解它。
好了,下面我们就一起来看怎么理解 SRE 这个体系化工程。

SRE,我们应该怎么来理解它?

我先给你分享一张图,这是结合我自己团队的日常工作,做出来的 SRE 稳定性保障规划图。
我们最初画这张图是为了提高故障处理效率,将每个阶段可以做的事情填了进去,并在实践中不断补充完善,最终形成了我们探索 SRE 的框架图。你应该也发现了,这里面很多事情都很常见,比如容量评估、故障演练、服务降级、服务限流、异常熔断、监控告警等等。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

SRE迷思:无所不能的角色?还是运维的升级? SRE(Site Reliability Engineering)作为一个体系化的方法,需要全局视角来理解。本文从实践的角度出发,强调SRE并非一个全能岗位,而是需要多个部门、多项技术的协同合作。作者分享了SRE稳定性保障规划图,强调SRE并不神秘,而是可以通过熟悉的抓手来学习。同时,SRE的建设需要高效的跨团队组织协作,而不是依赖单一岗位解决所有稳定性问题。 此外,文章还探讨了SRE的根本目的,即提升稳定性。通过衡量标准MTBF和MTTR,指出提升稳定性的方向是减少故障发生次数、提升故障处理效率。作者强调了SRE的目标是“提升MTBF、降低MTTR”,并解释了在不同阶段需要采取的措施,以实现这一目标。 总的来说,SRE不是一个全能岗位,而是需要多个部门、多项技术的协同合作。其根本目的是提升稳定性,通过减少故障发生次数、提升故障处理效率来实现。文章通过实践角度和以终为始的思路,深入探讨了SRE的理解和目标,为读者提供了全面的技术视角。 SRE需要从全局的角度去理解,需要整个技术和组织体系的配套支持,其目的是减少故障时间,增加系统正常运行时间。 SRE和DevOps都是优秀的方法论,但SRE更注重稳定性,而DevOps更注重快速交付。 SRE和DevOps都需要全局视角和跨团队协作,但在目标和重点上有所不同。

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

全部留言(45)

  • 最新
  • 精选
  • 无聊的上帝
    说下我的感受。 DevOps主要是以驱动价值交付为主,搭建企业内部的功效平台。 SRE主要需要协调多团队合作来提高稳定性。 例如: - 与开发和业务团队落实降级 - 在开发和测试团队内推动混沌工程落地 - 与开发团队定制可用性衡量标准 - 与开发,测试,devops,产品团队,共同解决代码质量和需求之间的平衡问题。

    作者回复: 分析地恰到好处,你找到了看待这个问题的正确角度。

    2020-03-18
    4
    49
  • 子杨
    听成哥这么一说,顿时有种豁然开朗的感觉。降低 MTTR,提升 MTBF。而 MTTR 里面,MTTI 一定要快。不过这里有一点不太理解,平常都是要以业务恢复为第一优先级的,这时候可能回滚变更操作就非常重要了,然后再去定位根因,先定位根因再去恢复业务,这个是有适用场景的吧。

    作者回复: 非常棒的问题,而且“业务恢复”永远都是第一优先级,你的理解非常正确。 这里提到是正常流程,但是实践中我们一定会根据实际情况来活学活用,所以,是不是要定位出根因,还是定位出根因范围就要看取舍了,有时我们大致定位出根因范围,然后就要开始执行响应的恢复和隔离措施了。 有点类似当前我们正在经历的疫情,虽然我们知道是新型病毒,但是根源来自哪里并不清楚,而且也没有预防和有效的治愈良药,这时最有效的办法就是提前发现,然后隔离,这种就不可能等着根因定位清楚,再采取措施。

    2020-03-19
    28
  • 云峰
    赵老师,好。SRE是否从项目开始就需要参与系统架构设计?如果只是在项目上线运行后才接触,遇到架构不合理的地方如何处理?

    作者回复: 肯定是越早参与越好,并不一定参与设计本身,但是要知道再哪里提出稳定性要求。比如一个促销场景,要知道可能流量是怎么样的,限流措施要设定在哪些接口上,限流量多大,通过什么方式验证等等,通过这种提要求的方式,倒逼业务开发和架构师思考设计和编码。

    2020-03-20
    10
  • 海峰
    看赵老师之前的书讲:SRE是 用软件工程的方法重新设计和定义运维。

    作者回复: SRE的一个理念,非常关键,一定要通过技术手段解决运维问题,而不是人肉投入。

    2020-03-18
    9
  • 海格
    SRE解决运维领域的故障目标,DevOps更偏向于为价值导向的效率目标,但是这个又是你中有我,我中有你,互相成就的一个过程,在实践SRE体系过程中,不可避免的要使用到一些DevOps中的一些技术,方法论,组织文化等,通过这些,达成一致目标。~~~

    作者回复: 理解地非常正确!

    2020-03-19
    7
  • 虹炎
    感觉要做好sre , 带头人至少是优秀架构师水准。普通开发只能做好分内事,慢慢学习经验。

    作者回复: 你说地对,优秀的SRE就是优秀架构师的水准,甚至比架构师要求更高,而且SRE的成长过程也会比一般开发和架构师更痛苦,要经过更多的磨炼才可以。

    2020-04-01
    3
    6
  • kaizen
    SRE 要求对公司业务架构要有一个宏观的了解

    作者回复: 你讲到一个非常重要的点,SRE要想做好,必须要对公司业务有全局的了解,甚至是非常深入的了解

    2020-03-18
    3
    6
  • null
    class SRE implements DevOps 可以简单理解为DevOps 是一种接口,但是没说怎么实现,SRE 提供了一种视角,这么做在Google 成功过,可以结合自己企业的特点去实现DevOps 这个接口,做有自己特色的‘SRE’ 即可。

    作者回复: SRE是DevOps的一项最佳实践。

    2020-03-18
    3
    5
  • soong
    个人认为:DevOps整体的表现倾向于价值交付,与敏捷的价值观贴合;而SRE的侧重点在于保障系统的稳定运行,通过系统稳定性实现价值最大化!两者有不同,也有交叉,他们不是非此即彼的选项。至于哪种更好,主要看团队的实际情况,产品本身所处的阶段,是另一个重要的考量依据!

    作者回复: 理解地很深入。

    2020-03-26
    3
  • 于加硕
    赵老师你好,听完本篇我又重新听了开篇。您接下来所讲的内容,应该都是基于团队已经在SRE实践的道路上。1.那么我们该如何判断某条业务线是否值的推行SRE体系呢?(业务的背景大致可以理解为:既追求稳定性,又不过分追求,且DevOps成熟度基本满足业务需求) 下面是自己对DevOps,SRE概念理解的方式,欢迎指正: a. 人们对SRE理解存在偏差,是因为局限个人经验与当下所处维度(IT环境)造成的;通常当我们对一个概念理解存在模糊状态时,通过追溯到它的历史起源,对于理解它会更加深刻,也更加能够看清它真正的意图。 b. 一个职位的兴起,绝不是凭空在当前维度出现的,兴许是上游出现了某种压力/变化,于是下游便出现某个职位来应对这种压力/变化。 文章结尾补充一个问题:DevOps与SRE矛盾点: c. devops解决全栈交付,全栈交付是非稳定性因素之一,而SRE关注稳定性

    作者回复: 某条业务线是否推行SRE,有个判断依据就是,是不是需要运维或SRE这样的团队介入,如果需要运维或SRE保障,那就要推行后面我们要讲的SRE体系,如果是开发自己维护,没有另外的团队参与,那就自行判断。 关于你的理解,我觉得很棒,特别是B,任何一个岗位或方法的出现,都是因为有问题解决不了被倒逼出来的,从我的角度,DevOps是如此,SRE也是如此。

    2020-03-21
    2
    3
收起评论
显示
设置
留言
45
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部