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的工程师也给出了答案

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