DevOps和SRE

#DevOps和SRE 之前总是把SRE和DevOps混为一谈，总觉得这两个是同一
种东西在不同公司的叫法，知道前两天google又放出了，书中对比了SRE和DevOps的异同。

今日重新看wikepedia上，发现两者虽有共同点，但本质上却不同。

DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术
人员（Ops）”之间沟通合作的文化、运动或惯例。

透过自动化“软件交付”和“架构变更”的流程，来
使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

（via Wikipedia）
DevOps不是一个实体，而是行业中运维和研发协作的一种理念、文化，SRE
是什么？在中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相信同样的事，但不是因为同样的原因。