DevOps和SRE

  之前总是把SRE和DevOps混为一谈,总觉得这两个是同一种东西在不同公司的叫法,知道前两天google又放出了《The Site Reliability Workbook》 ,书中对比了SRE和DevOps的异同。今日重新看wikepedia上DevOps的的定义 ,发现两者虽有共同点,但本质上却不同。

DevOps(Development和Operations的组合词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。(via Wikipedia)

  DevOps不是一个实体,而是行业中运维和研发协作的一种理念、文化,SRE是什么?在《Site Reliability Engineering》中Google的工程师也给出了答案

SRE is what happens when you ask a software engineer to design an operations team.

  SRE是你让一个软件工程师组件一个运维团队的产物,它本质上是一个实体,是一个团队一个工种,是对DevOps的实践。说的形象一点,DevOps是一个Interface,SRE是实现这个interface的class,两者之间必然有异同,The Site Reliability Workbook 中给我们列出来一部分,我大概翻译一下。
– DevOps 和SRE建立在变革的基础上了,没有改变何谈提升。
– DevOps的核心是协作,SRE的核心是共享。但两者的主要价值都是贯穿整个组织把各个团队联结在一起。
– 维护变更和稳定性的平衡是SRE最重要的工作,小二频的变更、自动化测试和交付很重要。
– 工具很重要,用什么工具甚至能决定能做什么,但也不必太过分纠结于工具。其实API的设计好坏比在API之上任何工具的设计好坏更重要。
– 量化对SRE和DevOps来说都极为重要,对SRE来说SLOs是最主要的指标,当然没有衡量标准就没有SLO。 对DevOps而言,衡量通常用有些比如系统的输出,反馈循环的持续时间等等。无论是实践还是理论,SRE和DevOps都得用数据说话。
– 在管理生产服务的过程中总是免不了出问题,SRE和DevOps都实行不问责的事故处理方式。
– 归根到底,DevOps或SRE是一种全局工作,两者都希望通过某种特定的方式使得分散的部分组织协同的更好。 速度是SRE和DevOps都想要的结果。

  SRE和Devops有好多共同点,但也有有些明显的不同之处,DevOps是一种泛化的哲学和文化概念。 它能比SRE产生更多的变体,DevOps在实践中具体是什么还得看上下文环境。它不太关注系统运行的太多细节,而是专注于打破阻碍组织协同的壁垒。
  另一方面,SRE的职责相对狭窄,通常是面向服务(以最终用户为导向),而不是整体业务导向。 因此,它为了是系统运行更高效产生出一些武断的知识框架(比如错误预算……)。 虽然作为一个职业,SRE高度了解激励及其影响,但它反过来却相对于孤岛化和信息障碍等主题保持沉默。 它将支持CI和CD,不一定是因为业务案例,而是因为所涉及的操作实践得到了改进。 或者,换句话说,SRE相信与DevOps相同的东西,但原因略有不同。 作为一个具体的职业,SRE对他们产生的影响高度敏感,反而对信息壁垒不太关注。SRE支持持续集成和持续交付不是因为商业需求,而是因为持续集成和持续交付涉及到运维。 换句话说,SRE和DevOps相信同样的事,但不是因为同样的原因。

打赏

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.