之前总是把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相信同样的事，但不是因为同样的原因。
