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

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

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

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

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

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

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

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

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

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

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

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

    共 3 条评论
    6
  • kaizen
    2020-03-18
    SRE 要求对公司业务架构要有一个宏观的了解

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

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

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

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

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

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

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

    共 2 条评论
    3