一文彻底读懂DevOps与SRE来龙去脉

本文主要是介绍一文彻底读懂DevOps与SRE来龙去脉，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

若是把运维当作一门学科来看，是有难度的.不仅因为如何很好的运行系统这种普遍问题未得到解决外，现存的最佳实战也因高度依赖环境，而未得到广泛使用；另外一个未解决的问题就是如何更好的管理运维团队。详细分析这些问题通常被认为起源于致力运筹学的研究，在第二次世界大战期间用于改善盟军的进程和产出，但事实上，几千年来，我们一直在思考如何更好的运营
然而，尽管有这么多的努力和想法，可靠的生产运维仍然难以保障,特别是在信息技术和软件可操作性领域例如:以企业的角度,通常将运维视为成本中心;如果可能，要做有意义的改进即使是困难的.因对这种方法的短视，尚未得到广泛理解，但是对它的不满已经引发了如何组织我们在IT中所有事情的一场革命，这场革命源于试图解决一系列共同问题，最新解决这些问题的方案有两个:DevOps和SRE(Site Reli‐ability Engineering)。事实上，它们有很多相似之处，要比我们想象的多

DevOps产生的背

DevOps是一套松散的实践、指南和文化，旨在打破IT开发、运维、网络和安全方面的孤岛。由JohnWillis，Damon Edwards和Jez Humble联合执笔，阐述:CA(L)MS-代表文化、自动化、精益(如精益管理，持续交付)、度量、分享，是DevOps关键思想的缩写。分享和协作是这场运动的最前线,在DevOps方法中,改进(通常通过自动化方式)、然后度量结果，并与同事分享这些成果，这样整个组织都可以得到改进。所有CALMS原则都是有这种支持性文化促成的

DevOps、敏捷以及各种其他商业和软件工程技术都是关于如何在现代商业中最好的做生意的普遍世界观的例子。DevOps思想中的任何元素都不容易彼此分离，这基本上是通过设计来实现的。然而，一些关键的想法可以相对独立的进行讨论

不再孤岛(谷仓效应)

第一个关键思想:不再有孤岛，针对这一思想有两个方面的反应:

历史上流行但现在越来越老式的独立运维和开发团队
事实上，知识的极端孤立,对纯粹的局部优化的激励，以及缺乏协作在很多情况下对于企业来说都是非常糟糕的

事故是正常的

第二个关键思想: 事故不仅仅是个人孤立行为的结果,而是因为当事情不可避免地出错时缺少保障措施。例如:一个糟糕的界面在压力环境下会促使采取错误操作。如果发生(未明确的)错误情况,系统错误会使失败不可避免;坏的监控使我们无法知道是有问题，更不用说出了什么问题。一切传统观念的企业具有根除犯错制造者和处罚他们的文化本能，但这样做有其自身的后果:最明显的是，它们创造了是问题混淆、掩盖真相、责怪他人的动机，所有这些最终都是无益的分心行为。因此，着眼于加速恢复故障比预防事故更有意义

变更应该循序渐进

第三个关键思想: 小而频繁的变更时最佳的。在变更委员会每月开会讨论彻底修改大型机配置的计划,这是一个激进的做法。然而这种做法并不鲜见，所有变更必须由经验丰富的人员考虑并且为了有效考虑而进行批量化的观点，结果或多或少与最佳实践相悖。变更是有风险的，没错，但是正确的做法是将变更尽可能拆分成晓得组件或单元。然后，根据产品、设计和基础设施的变更，建立一个稳定的低风险变更管道。这种策略，增加对小变更的自动化测试和可靠地回滚有问题的变更，就形成了变更管理的方法:持续集成(CI)和持续交付或部署(CD)

工具和文化是相互关联的

工具和文化是DevOps的重要组成部分,特别是在强调正确管理变更的今天，变更管理依赖于高度特定的工具。然而，DevOps支持者强烈强调组织文化而不是工具本身，作为新工作方式成功的关键。一个好的文化可以解决围绕破碎的工具工作，但相反的情况很少适用。俗话说的好，文化将策略当早餐吃了(意味着文化的影响力远胜过策略)，像运维，改变其自身是很难的事

度量至关重要

最后，度量在总体业务环节中尤其重要，例如打破孤岛和事件解决方案。在每个环境中，通过客观的测量来确定正在发生的事情的真实性，验证是否按预期进行了改变。并为不同职能部门达成一致建立客观基础(适用于业务和其他环境，例如on-call)

SRE产生的背景

网站可靠性工程师(SRE)是Google工程副总裁BenTreynor Sloss创建的术语(和相关的工作角色)。正如我们在前一节中所讲，DevOps是关于运维和产品开发之间的全周期协作的一系列广泛原则。SRE是一个工作角色，一组实践。如果DevOps是一种哲学和一种工作方法，那么SRE实现了DevOps所描述的一些思想，而且更接近于工作或角色的定义，比如"DevOps工程师"。因此，从某种程度上来说，SRE是DevOps的实现。与DevOps运动不同，DevOps运动起源于多家公司的领导者和实践者之间的合作产生的,在SRE广泛普及之前，Google的SRE继承了周围公司的大部分文化，并没有像DevOps一样突出文化的变化

SRE有以下具体原则

运维是一个软件问题

SRE的基本原则是做好运维是一个软件问题。因此，SRE应该使用软件工程思想来解决该问题。这是一个广泛的领域，包括从流程和业务变化到类似复杂但更传统的软件问题，例如重写堆栈以消除业务逻辑中的单点故障。

通过SLOs(服务质量目标)进行管理

SRE不会试图提供100%的可用性，正如我们第一本书《Site Reliability Engineering》(网站可靠性工程)中所讨论的，这是个错误的目标，原因有很多。相反，产品团队和SRE团队为服务及其用户群选择适当的可用性目标，并将服务管理到该SLO。决定这样的目标需要业务部门强有力的合作。SLOs也有文化内涵:作为利益相关者之间的协作决定，SLO违规行为将团队无可指责的重新回到绘图板。

减少琐事

对于SRE来说，任何手动、重复性的的运维任务都是让人厌恶的。我们相信，如果一台机器可以执行期望的运维操作，我们就应该经常这样做。这种差别和价值在其他组织中并不常见，一些琐事就需要人力才能完成。对于在Google的SRE来说，琐事并不能作为工作来做。任何花费在操作任务上的时间意味着我们并没有真正的在为项目工作——我们如何使服务更可靠和可伸缩 a 然而，"生产智慧"为我们执行运维任务提供了非常重要的帮助。这种工作，可以通过指定系统的实时反馈来落地。需要甄别琐事的来源以便可以最小化这些工作甚至消除。但是，如果发现自己操作状态不佳，则可能需要更频繁的推送新功能和变更，以便其他工程师熟悉你所支持的服务

生产智慧关于"生产智慧"阐释: 使用这个词，意思是我们从运行的生产环境中获取到的智慧——关于它实际上是如何工作的、软件应该如何设计的细节而不是与实际相孤立的服务。获得所有事件及团队获工单等等都与现实直接相关，可以更好为系统设计和行为提供信息

工作自动化

这个领域的真正工作是决定什么条件下做什么自动化以及怎么自动化。 SRE在Google实践中:团队成员花费在琐事上而不是产生持久价值工程的时间为限制在50%。许多人把这个认为限制的上限。实际上,针对采用工程方法来解决问题，视为一种明确的声明和机制，要比一遍一遍的做琐事更加有用的多。

当我们考虑自动化和琐事时，基线和其如何发挥作用并不直观。随着时间的推移，一个SRE团队会将所有可以自动化的服务都自动化，剩下的都是无法实现自动化的(Murphy-Beyer效应)。这将主导SRE团队的工作，除非有其他要做。在Google环境中，你倾向添加更多的服务，直到达到某些限制，仍然有50%工程时间，或者你在自动化方面非常成功你可以去做一些其他完全不同的事情

通过降低失败成本来快速流转

SRE的主要优点之一就是不一定要提高可靠性,即使它已经发生,但实际上改进了产品开发的产出。为什么？降低常见故障的平均故障时间(MTTR)会增加产品开发人员的迭代速度，因为工程师不用将精力过多分散在处理故障问题上。这源于一个众所周知的事实，即在产品生命周期的后期，一个问题被修复的代价越高。SREs专门负责改善处理产品后期出现的问题，为整个公司带来收益。

与开发人员分享所有权

"应用程序开发"和"生产"之间的严格界限(有时被称为Dev和Ops)会产生相反的效果。将责任分工、运维分类作为成本中心，则会导致权力失衡或薪酬差异这一点尤为正确

SREs倾向于关注生产问题而不是业务逻辑问题，但是随着他们用软件工程工具的方法来解决问题以及与产品开发团队分享技能。一般而言，SRE在他们关注的服务可用性、延迟、性能、效率、变更管理、监控、紧急响应和容量规划方面具有特殊的专业知识。这些特殊技能(通常明确定义的)是SRE为产品和开发团队技术服务的基础。理想情况下，产品开发和SRE团队对技术栈有一个整体的了解——前端、后端、库、存储、内核和物理机——任何团队都不应该嫉妒拥有单一组件

在《Site Reliability Engineering》(网站可靠性工程)一书中，我们并没有明确指出：在Google，产品开发团队就默认拥有他们的服务，虽然SRE原则仍然告知整个Google如何管理服务，但是SRE原则既不可用也不保证。SRE团队的所有权模式与产品开发团队合作最终也是一个共享模型

使用相同的工具，无论功能或职位

工具是一个非常重要的行为决定因素。在Google的环境中，SRE如果没有统一的代码库、软件和系统的各种工具、高度优化和专有的生产堆栈等是非常天真的。我们与DevOps分享这个绝对假设:负责服务的团队应该使用相同的服务工具，不管它们在组织中的角色是什么。如果没有好的方法去管理服务,一个工具给SREs使用，另外一个工具给产品开发者使用，在不同的情况下，操作不同，可能会是灾难性的。彼此分歧越多，公司从改进每个工具的努力中获益就越少

DevOps与SRE对比

从上面聊的原则中，我们可以看到它们之间有很多共性:

DevOps和SRE都取决于为了持续改进，必须接受变化
协作是DevOps工作的前沿和中心，有效共享所有权模式和合作伙伴关系是SRE发挥作用的必要条件。与DevOps一样，SRE也具有跨组织共享的强大价值，这样更容易打破团队之间的壁垒
变更的最佳实践是: 持续小而频繁的变更，大部分情况下，都需要自动化测试和应用。关键是变更对可用性影响对于SRE来说尤为重要
使用正确的工具至关重要，工具在一定程度上决定了行动范围。然而，我们不能过于关注使用某种特定工具来实现一些操作。面向系统管理的API是一个更重要方法
度量对于DevOps和SRE来说都至关重要。对于SRE来说，SLOs(服务质量目标)决定着是否改善优化服务。当然，如果没有衡量标准(以及在产品、基础设施/SRE和业务之间的跨团队合作)，就不会有SLO。对于DevOps来说，度量行为常用来了解过程的产出、一个反馈周期持续的时间等等。无论从专业角度还是从哲学角度，DevOps和SRE都是面向数据的
管理生产服务器残酷的事实就是偶尔发发生了故障，并且你要说出为什么。SRE和DevOps都是无可指责的，目的是为了消除无意义的争论
最终，实施DevOps或SRE是一种整体行为，两者都希望使用一种特定的工作方式共同协作，促使整个团队运营的更好。对于DevOps和SRE来说,更好的速度就是产出。

正如你说看到的，DevOps和SRE有很多共同点。然而，也存在着显著的差异，DevOps在某种意义上是一种更广泛的哲学和文化。DevOps对于如何在一个具体层面上运行相对沉默，例如，它并没有明确规定如何对服务进行精细化管理，而更多的专注如何打破更广泛的组织中的障碍。这就很有价值。

另一方面，SRE的指责范围相对狭窄，其职权范围通常是面向服务的(以终端用户为导向),而非整体业务。因此，它解决如何高效运行系统有自己的知识框架(包括错误预算等概念)。尽管SRE作为一种职业，高度关注激励错误和效率，但在诸如“组织孤岛”和“信息壁垒”等话题上，却相对沉默。它将支持CI/CD，不一定是因为业务需要，而是改进操作的实践。或者，换句话说，SRE相信和DevOps相同的东西，但原因可能有所不同

但原因可能有所不同