01｜SRE迷思：无所不能的角色？还是运维的升级？
SRE，我们应该怎么来理解它？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
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-18449
子杨听成哥这么一说，顿时有种豁然开朗的感觉。降低 MTTR，提升 MTBF。而 MTTR 里面，MTTI 一定要快。不过这里有一点不太理解，平常都是要以业务恢复为第一优先级的，这时候可能回滚变更操作就非常重要了，然后再去定位根因，先定位根因再去恢复业务，这个是有适用场景的吧。作者回复: 非常棒的问题，而且“业务恢复”永远都是第一优先级，你的理解非常正确。 这里提到是正常流程，但是实践中我们一定会根据实际情况来活学活用，所以，是不是要定位出根因，还是定位出根因范围就要看取舍了，有时我们大致定位出根因范围，然后就要开始执行响应的恢复和隔离措施了。 有点类似当前我们正在经历的疫情，虽然我们知道是新型病毒，但是根源来自哪里并不清楚，而且也没有预防和有效的治愈良药，这时最有效的办法就是提前发现，然后隔离，这种就不可能等着根因定位清楚，再采取措施。
2020-03-1928
云峰赵老师，好。SRE是否从项目开始就需要参与系统架构设计？如果只是在项目上线运行后才接触，遇到架构不合理的地方如何处理？作者回复: 肯定是越早参与越好，并不一定参与设计本身，但是要知道再哪里提出稳定性要求。比如一个促销场景，要知道可能流量是怎么样的，限流措施要设定在哪些接口上，限流量多大，通过什么方式验证等等，通过这种提要求的方式，倒逼业务开发和架构师思考设计和编码。
2020-03-2010
海峰看赵老师之前的书讲：SRE是 用软件工程的方法重新设计和定义运维。作者回复: SRE的一个理念，非常关键，一定要通过技术手段解决运维问题，而不是人肉投入。
2020-03-189- 海格SRE解决运维领域的故障目标，DevOps更偏向于为价值导向的效率目标，但是这个又是你中有我，我中有你，互相成就的一个过程，在实践SRE体系过程中，不可避免的要使用到一些DevOps中的一些技术，方法论，组织文化等，通过这些，达成一致目标。~~~
作者回复: 理解地非常正确！
2020-03-197 
虹炎感觉要做好sre , 带头人至少是优秀架构师水准。普通开发只能做好分内事，慢慢学习经验。作者回复: 你说地对，优秀的SRE就是优秀架构师的水准，甚至比架构师要求更高，而且SRE的成长过程也会比一般开发和架构师更痛苦，要经过更多的磨炼才可以。
2020-04-0136
kaizenSRE 要求对公司业务架构要有一个宏观的了解作者回复: 你讲到一个非常重要的点，SRE要想做好，必须要对公司业务有全局的了解，甚至是非常深入的了解
2020-03-1836
nullclass SRE implements DevOps 可以简单理解为DevOps 是一种接口，但是没说怎么实现，SRE 提供了一种视角，这么做在Google 成功过，可以结合自己企业的特点去实现DevOps 这个接口，做有自己特色的‘SRE’ 即可。作者回复: SRE是DevOps的一项最佳实践。
2020-03-1835
soong个人认为：DevOps整体的表现倾向于价值交付，与敏捷的价值观贴合；而SRE的侧重点在于保障系统的稳定运行，通过系统稳定性实现价值最大化！两者有不同，也有交叉，他们不是非此即彼的选项。至于哪种更好，主要看团队的实际情况，产品本身所处的阶段，是另一个重要的考量依据！作者回复: 理解地很深入。
2020-03-263
于加硕赵老师你好，听完本篇我又重新听了开篇。您接下来所讲的内容，应该都是基于团队已经在SRE实践的道路上。1.那么我们该如何判断某条业务线是否值的推行SRE体系呢？(业务的背景大致可以理解为:既追求稳定性，又不过分追求,且DevOps成熟度基本满足业务需求) 下面是自己对DevOps，SRE概念理解的方式，欢迎指正： a. 人们对SRE理解存在偏差，是因为局限个人经验与当下所处维度(IT环境)造成的；通常当我们对一个概念理解存在模糊状态时，通过追溯到它的历史起源，对于理解它会更加深刻，也更加能够看清它真正的意图。 b. 一个职位的兴起，绝不是凭空在当前维度出现的，兴许是上游出现了某种压力/变化，于是下游便出现某个职位来应对这种压力/变化。 文章结尾补充一个问题：DevOps与SRE矛盾点： c. devops解决全栈交付，全栈交付是非稳定性因素之一，而SRE关注稳定性作者回复: 某条业务线是否推行SRE，有个判断依据就是，是不是需要运维或SRE这样的团队介入，如果需要运维或SRE保障，那就要推行后面我们要讲的SRE体系，如果是开发自己维护，没有另外的团队参与，那就自行判断。 关于你的理解，我觉得很棒，特别是B，任何一个岗位或方法的出现，都是因为有问题解决不了被倒逼出来的，从我的角度，DevOps是如此，SRE也是如此。
2020-03-2123
