Skip to content

Latest commit

 

History

History
242 lines (119 loc) · 26.9 KB

5_第1章-SRE和DevOps的关系.md

File metadata and controls

242 lines (119 loc) · 26.9 KB
Raw

第1章

SRE如何与DevOps相关

class SRE implements interface DevOps


By Niall Richard Murphy, Liz Fong-Jones, and Betsy Beyer, with Todd Underwood, Laura Nolan, and Dave Rensin



运维，作为一门学科，是“难”的。1不仅不存在如何很好地运行系统的这种普遍未解决的问题，而且，已经发现有效的最佳实践高度依赖于上下文，并且离被广泛采用还差很远。关于如何更好地运营团队，也存在一个很大程度上未解决的问题。一般认为，对这些主题的详细分析源自Operational Research, 致力于在第二次世界大战期间改善盟军的工艺流程和产出，但实际上，我们一直在考虑如何千年来更好地运作事物。

然而，尽管付出了所有这些努力和思想，但可靠的生产操作仍然难以捉摸-尤其是在信息技术和软件可操作性的领域中。例如，企业界经常将运维视为成本中心，2这使得即使不是不可能，也很难实现有意义的结果改善。这种方法的巨大的短视性尚未得到广泛的理解，但是对此方法的不满引发了一场如何组织我们在IT中所做的工作的革命。

这场革命源于试图解决一系列共同的问题。解决这些问题的最新方法有两个不同的名称-DevOps和站点可靠性工程(SRE)。尽管我们分别讨论它们，就像它们是对上述企业心态的完全独立反应一样，3我们希望说服您，实际上它们更相似，并且每个实践者的共同点都比您假设的要多。

但是首先，需要了解每个主题的主要背景。

DevOps的背景

DevOps是一组松散的实践，指南和文化，旨在打破IT开发，运维，网络和安全性中的孤岛。CA(L)MS---由约翰·威利斯(John Willis)，达蒙·爱德华兹(Damon Edwards)和杰兹·汉布尔(Jez Humble)共同阐述，它代表精益文化，自动化，精益(如精益管理，另请参阅持续交付)，度量和共享-是记住DevOps哲学要点的有用缩写。共享和协作是这项运动的重中之重。在DevOps方法中，您可以改进某些内容(通常通过使其自动化)，衡量结果并与同事共享这些结果，从而可以改善整个组织。支持文化有助于所有CALMS原则。DevOps，敏捷以及各种其他业务和软件再造技术都是关于如何在现代世界中最好地开展业务的一般世界观的例子。DevOps哲学中的任何元素都不容易彼此分离，这本质上是设计使然。但是，有一些关键思想可以相对隔离地进行讨论。

不再需要孤岛

第一个关键思想是“不再孤岛”。这是对以下两个想法的反应:

  • 历史悠久但现在越来越老套的独立运维和开发团队

  • 在许多情况下，极端的知识孤立化激励纯粹用于局部优化，并且缺乏协作对业务不利4

事故是正常的

第二个关键思想是，事故不仅是个人孤立行为的结果，而且是由于不可避免地在事情不可避免地出错时缺少保障措施而造成的。5例如，不良的界面会在无意中导致压力下的错误行为。如果出现(未明确说明的)错误情况，系统功能失误将不可避免地导致故障；中断的监控功能使您无法知道是否出了什么问题，不必担心“什么”是错误的。一些传统思维更强的企业具有根除犯错者并予以惩罚的文化本能。但是这样做有其自身的后果:最明显的是，它创造了诱使人们混淆问题，掩盖真相并责备他人的诱因，所有这些最终都是无利可图的干扰。因此，专注于加快恢复速度比预防事故更为有利。

变更应循序渐进

第三个关键思想是较小且频繁的变更是最好的。在主环境中提交那些变更委员会每月开会讨论详细记录在案的更改是一个激进的想法。但是，这不是一个新主意。事实证明，所有变更都必须由经验丰富的人员来考虑，并且要进行有效的考虑并分批处理，这一事实与最佳实践几乎相反。更改是冒险的，是正确的，但是正确的应对方法是将更改尽可能地拆分为较小的子组件。然后，您可以根据产品，设计和基础结构变更的常规输出构建稳定的低风险变更流水线。6此策略，再加上对较小变更的自动测试和对不良变更的可靠回滚，导致了变更方法管理，例如持续集成(CI)和持续交付或部署(CD)。

工具和文化相互关联

工具是DevOps的重要组成部分，特别是考虑到正确管理变更的重要性，如今，变更管理依赖于高度特定的工具。总体而言，DevOps的支持者强烈强调组织文化-而非工具-是成功采用新工作方式的关键。良好的文化可以解决残破的工具，但相反的情况很少成立。俗话说，文化能把战略当早餐吃。像操作一样，改变本身很难。

度量是至关重要的

最后，度量在整个业务环境中尤其重要，例如，打破孤岛和事件解决方案。在上述每种环境中，您都可以通过客观度量来确定正在发生的事情的真实性，验证您是否正在按预期方式更改情况，并为不同功能达成共识的对话创建客观基础。(这适用于业务和其他情况，例如On-Call。)

SRE背景

Site Reliability Engineering(SRE)是Google工程副总裁Ben Treynor Sloss创造的一个术语(及相关的工作角色)。7如上一节所述，

DevOps是有关运维和产品开发之间的全生命周期协作的广泛原则。SRE是一种工作角色，是我们发现行之有效的一系列实践(如下所述)，以及使这些实践具有生气勃勃的一些信念。如果您将DevOps视为一种工作原理和工作方法，则可以辩称SRE实施了DevOps所描述的一些哲学，并且比“ DevOps工程师”更接近于工作或角色的具体定义。 8因此，在某种程度上，class SRE implements interface DevOps。

与DevOps运动源于多家公司的领导者和从业者之间的合作不同，Google的SRE在SRE这个术语在整个行业广泛普及之前，就从周围的公司那里继承了许多文化。在这种情况下，默认情况下，该学科作为一个整体目前不会像DevOps那样将文化变革作为前景。(当然，这并不意味着在任意组织中进行SRE是否需要文化变革。)

SRE由以下具体原则定义。

运维是软件问题

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

按服务水平目标(SLO)管理

SRE不会尝试为所有内容提供100％的可用性。正如我们在第一本书Site Reliability Engineering中所讨论的，出于多种原因，这是错误的目标。取而代之的是，产品团队和SRE团队为服务及其用户群选择适当的可用性目标，然后将服务管理到该SLO。9确定此类目标需要业务部门的大力协作。SLO也具有文化含义:随着利益相关者之间的协作决策，违反SLO的行为无可厚非地将团队带回了项目白板阶段。

努力减少琐事

对于SRE而言，任何手动的，结构强制性的操作任务都是令人讨厌的。(这并不意味着我们没有任何此类操作:我们有很多这样的操作。我们只是不喜欢他们。)我们认为，如果机器可以执行所需的操作，则通常应该机器去做。这是一个区别(和价值所在)在其他组织中并不常见，琐事工作是工作，而这就是您付钱给人做的事情。对于Google环境中的SRE，“琐事”不能算是“工作”。花在运维任务上的任何时间都意味着是没有花在项目正常工作上的时间，而项目工作就是我们使服务更可靠和可扩展的方式。

但是，执行运维任务确实可以通过“真实生产环境的智慧”为决策提供重要的输入。这项工作通过提供给定系统的实时反馈使我们保持基础。需要确定琐事的来源，以便可以将其最小化或消除。但是，如果您发现自己对于运维操作不够多，则可能需要更频繁地推送新功能和更改，以便工程师对所支持服务的工作方式保持熟悉。

生产的智慧

关于“生产的智慧”的注释:用这个短语，我们的意思是您从生产中运行的某种事物中获得的智慧-杂乱的细节，如“实际生产情况”如何表现，以及软件应“实际生产情况”如何设计，而不是将服务与实际情况隔离开的白板视图。您获得的所有页面，团队获得的罚单等等，都是与现实的直接联系，应该可以更好地指导系统设计和行为。

自动化今年的工作

该领域的实际工作是确定要在什么条件下进行自动化以及如何对其进行自动化。

按照Google的惯例，SRE对于团队成员可以花多少时间在琐事上有一个硬性限制，相对于工程方案维持在:50％。许多人将此限制视为上限。实际上，将其视为保证-一种明确的声明和启用机制，对于采用基于工程的方法来解决问题，而不是一遍又一遍地解决问题，要有用得多。

当我们考虑自动化和琐事时，此基准与其如何发挥作用之间存在一种直观而有趣的互动。随着时间的流逝，SRE团队结束了对服务的所有可能的自动化工作，遗留下了无法自动化的事情(墨菲-拜尔效应)。在其他条件相同的情况下，除非采取其他措施，否则这将主导SRE团队的工作。在Google环境中，您倾向于添加更多的服务，直至达到仍支持50％工程时间的某些限制，或者您在自动化方面非常成功，因此可以去做其他完全不同的事情。

通过降低失败成本来快速行动

SRE参与的主要好处之一是不一定能提高可靠性，尽管显然确实如此。它实际上是提高了产品开发的产出。为什么？嗯，减少常见故障的平均维修时间(MTTR)可以提高产品开发人员的速度，因为工程师不必浪费时间并集中精力解决这些问题。这源于众所周知的事实，即在产品生命周期中发现问题的时间越晚，修复它的成本就越高。SRE专门负责改善不良问题的发现，从而为整个公司带来收益。

与开发者共享所有权

“应用程序开发”和“生产”(有时称为程序员和运维人员)之间的严格界限适得其反。如果将职责分开和运维作分类为成本中心会导致权力不平衡，尊重或报酬尤其存在差异。

SRE倾向于将重点放在生产问题上，而不是业务逻辑问题上，但是由于他们的方法带来了软件工程工具来解决该问题，因此它们与产品开发团队共享技能。通常，SRE在他们正在照看的服务的可用性，延迟，性能，效率，变更管理，监控，紧急响应和容量规划方面具有特殊的专业知识。那些特定的(通常是定义明确的)能力是SRE为产品以及相关产品开发团队所做的工作的基础。[理想情况下，产品开发和SRE团队都应该对以下方面有整体了解堆栈-前端，后端，库，存储，内核和物理机-且任何团队都不应嫉妒拥有单个组件。事实证明，如果您“模糊界限” 10并拥有SRE工具JavaScript，或者产品开发人员使内核合格，那么您将可以做更多的事情:关于如何进行更改的知识以及进行更改的权限将更加广泛。 ，并取消了嫉妒任何特定功能的奖励措施。

在Site Reliability Engineering中，我们没有清楚表明Google的产品开发团队默认持有其服务。尽管SRE原则仍然可以指导在整个Google范围内管理服务的方式，但SRE既不提供服务也不保证提供大量服务。11当SRE团队与产品开发团队合作时，所有权模型最终也是共享模型。

无论功能或职称如何，都使用相同的工具

工具是决定行为的极其重要的决定因素，并且假设SRE在Google上下文中的功效与可广泛使用的统一代码库无关各种各样的软件和系统工具，高度优化和专有生产堆栈，等等。然而，我们与DevOps共享这一绝对假设:关注服务12的团队应使用相同的工具，无论他们在组织中的角色如何。没有一种好的方法来管理一项具有一个针对SRE的工具以及一个针对产品开发人员不同的工具的服务，并且在不同情况下的行为不同(并且可能是灾难性的)。您的分歧越大，您的公司从每次改进每个工具的努力中获得的利益就越少。

比较和对比

回顾前面的原理，我们立即在概述的要点上看到很多共性:

  • DevOps和SRE都取决于必须接受变更才能改进。没有这些，就没有太多的操作空间。13

  • 协作是DevOps工作的重中之重。有效的共享所有权模型和合作伙伴团队关系对于SRE起作用是必不可少的。像DevOps一样，SRE在整个组织中也具有很强的共享价值，这可以使退出基于团队的孤岛变得更加容易。

  • 最好以小的，连续的动作来进行变更管理，理想情况下，大多数动作都是自动测试和应用的。变更与可靠性之间的关键相互作用使得这对于SRE尤其重要。

  • 正确的工具至关重要，而工具在一定程度上决定了行为的范围。但是，我们决不能太集中精力使用某些特定的工具来实现某些目标。归根结底，面向系统管理的API是一个更重要的理念，它比任何特定实现都更长久。

  • 度量是DevOps和SRE如何工作的绝对关键。对于SRE，SLO在确定为改善服务而采取的措施中占主导地位。当然，没有度量标准就不可能有SLO(以及跨团队辩论-理想情况是产品，基础架构/ SRE和业务之间)。对于DevOps，度量行为通常用于了解过程的输出是什么，反馈循环的持续时间是什么，等等。DevOps和SRE都是面向数据的事物，无论它们是专业还是哲学。

  • 管理生产服务的残酷现实意味着坏事偶尔会发生，您必须谈论原因。SRE和DevOps都实行对事不对人的事后检查，以抵消无助的，充满肾上腺素的反应。

  • 最终，实施DevOps 或 SRE是一项整体举措；双方都希望通过高度明确的合作方式使整个团队(或单位或组织)变得更好。对于DevOps和SRE，应该有更好的速度。14

如您所见，DevOps和SRE之间有很多共同点。

但是也存在重大差异。从某种意义上说，DevOps是更广泛的哲学和文化。因为与SRE相比，它带来的变化更大，所以DevOps对上下文更敏感。DevOps对如何详细运行操作相对保持沉默。例如，它不是关于服务的精确管理的规定。相反，它选择专注于打破更广泛组织中的障碍。这具有很大的价值。

另一方面，SRE的职责相对狭窄，其职责通常面向服务(和面向最终用户)，而不是面向整个业务。结果，它为如何有效运行系统的问题带来了一个固执己见的知识框架(包括错误预算等概念。尽管SRE作为一种专业非常了解激励措施及其影响，但它反而对孤岛化和信息障碍等话题相对沉默。它不一定会由于业务案例而支持CI和CD，而是因为所涉及的改进的操作实践会支持CI和CD。或者，换句话说，SRE 相信与DevOps相同，但原因略有不同。

组织环境与成功采用者的培养

DevOps和SRE在操作方式上有很大的概念重叠。正如您可能期望的那样，它们在组织中还必须具备一组相似的条件，才能使它们a)首先实现，并且b)从该实现中获得最大收益。正如Tolstoy马上但从来没有说过，有效的操作方法都是相似的，而破损的方法都是以自己的方式破损的。激励可以部分解释为什么会这样。

如果组织的文化重视DevOps方法的好处并愿意承担这些费用-通常表示为招聘困难，维持团队流动性和职责所需的精力以及专用于补偿技能的财务资源这种情况肯定更罕见了-然后，组织还必须确保奖励正确无误，才能充分利用此方法。

具体来说，在DevOps和SRE的上下文中，以下内容均应适用。

有限，严格的激励措施会使您的成功

许多公司意外地定义了破坏集体绩效的正式激励措施。为避免此错误，请不要将激励措施与发起相关或可靠性相关的结果紧密联系在一起。任何经济学家都可以告诉您，如果存在数字度量标准，人们会找到一种方法来对它产生不良影响，有时甚至是一种完全出于善意的方式。15相反，您应该让您的人民自由地找到正确的权衡。如前所述，DevOps或SRE总体上可以充当产品团队的促进剂，从而使其余的软件组织能够以持续可靠的方式向客户提供功能。这种动态变化还解决了传统的和分散的系统/软件组方法的一个持续存在的问题:在设计和生产之间缺乏反馈回路。具有早期SRE参与度(理想情况下是在设计时)的系统通常在部署后在生产中会更好地运行，而不管是谁负责管理服务。(没有任何事情会像丢失用户数据一样拖慢功能开发。)

最好自己修复；别怪别人

此外，避免任何诱因将生产事件或系统故障归咎于其他群体。在很多方面，非常规的动因是工程运营传统模型的核心问题，因为将运维和软件团队分开可以产生单独的激励机制。相反，请考虑采用以下做法来打击组织级别中的责任过失

  • 不仅要允许工程师，而且要积极鼓励工程师在产品需要时更改代码和配置。还应允许这些团队在其任务范围内具有激进的权威，从而消除了进行得更慢的动机。

  • 支持对事不对人的事后检查。16这样做消除了淡化或掩盖问题的动机。这一步对于充分理解产品并实际优化其性能和功能至关重要，它依赖于前面提到的生产智慧。

允许支持从难以操作的产品上移开。威胁要撤消支持促使产品开发人员在启动支持过程中以及在产品本身获得支持时解决问题，从而节省了所有人的时间。取决于您的上下文，“难以克服的运维困难”的含义可能会有所不同-此处的动态应该是相互理解的职责之一。对其他组织的驳回应该要比较温和，比如“我们认为拥有这种技能的人会更有价值地使用时间，”或者“这些人如果承担太多的运维工作任务而没有机会使用他们的工程技能会辞职”在Google，完全从此类产品中撤回支持的做法已成为一种制度。

将可靠性工作视为专门角色

在Google，SRE和产品开发是独立的组织。每个小组都有自己的重点，优先级和管理，而不必互相竞标。但是，当产品成功时，产品开发团队将通过新员工有效地资助SRE的增长。这样，产品开发与SRE团队的成功息息相关，就像SRE与产品开发团队的成功息息相关。SRE还很幸运地获得了管理层的高层支持，这确保了工程团队对“SRE方式”支持服务的异议通常是短期的。不过，您无需拥有组织结构图即可以不同的方式进行操作-您只需要一个不同的实践社区涌现出来。

无论您分叉组织结构图还是使用更多非正式机制，认识到专业化会带来挑战非常重要。DevOps和SRE的从业者受益于拥有支持和职业发展的同龄人社区，而工作阶梯则奖励他们17他们带来的独特技能和观点。

请务必注意，Google所采用的组织结构以及上述某些激励措施在某种程度上依赖于规模较大的组织。例如，如果您的20人创业公司只有一种(相对较小的)产品，那么允许撤回运维支持就没有多大意义。仍然可以采用DevOps风格的方法，18但是，如果从字面上看，您能做的所有事情就是帮助它发展，那么改善可操作性差的产品的能力就会受到损害。不过，通常情况下，人们如何满足这些增长需求以及技术债务积累的速度比他们想象的要多。19

When Can Substitute for Whether

但是，当您的组织或产品规模增长到一定程度时，您可以在支持哪些产品或如何“优先”分配该支持方面行使更大的自由度。如果很明显，对系统X的支持比对系统Y的支持要早得多，则隐式条件的作用与在SRE世界中“不支持”服务的选择几乎相同。

在Google，事实证明，SRE与产品开发之间的牢固合作至关重要:如果您的组织中存在这种关系，则可以基于有关比较运营特征的客观数据来决定是否撤回(或提供)支持，从而避免产生非生产性的影响。

SRE与产品开发之间的有效关系还有助于避免组织上的反模式，在这种模式下，产品开发团队必须在产品或功能准备就绪之前就将其交付。相反，SRE可以与开发团队一起对产品进行改进，然后再将维护工作的负担转移到最不擅长修理的人员身上。

争取平等对待:职业与财务

最后，请确保采取正确行动的职业动机是:我们希望我们的DevOps / SRE组织与产品开发部门保持同样的自尊心。因此，每个团队的成员应采用大致相同的方法进行评级，并具有相同的经济动机。

结论

在实践和哲学上，DevOps和SRE在许多方面都在IT运营的总体环境中彼此非常接近。

DevOps和SRE都需要讨论，管理支持和实际工作人员的支持，以取得重大进展。实施它们中的任何一个都是一个过程，而不是一个快速的解决方案:重命名和羞耻20的做法是一个空洞的，不太可能产生收益。鉴于它是如何执行操作的更自以为是的实现方式，尽管需要进行特定的调整，但SRE对于如何在此旅程的早期更改工作实践提出了更具体的建议。具有更广泛关注点的DevOps在某种程度上很难推理并转化为具体步骤，但是正是由于该关注点更广泛，它可能会遇到较弱的初始阻力。

但是，每个人的实践者都使用许多相同的工具，相同的变更管理方法以及相同的基于数据的决策思维方式。归根结底，无论我们叫什么名字，我们所有人都面临着同样的持续问题:生产,和使其变得更好。

对于那些有兴趣进一步阅读的人，以下建议应有助于您对当前发生的运维革命的文化，业务和技术基础有更广泛的了解:



Footnotes

  1. 请注意，此讨论出现在有关SRE的书中，其中一些讨论特定于软件服务操作，而不是IT操作。 ↩

  2. 玛丽·波彭迪克(Mary Poppendieck)在这方面有一篇出色的文章，名为"成本中心陷阱"。这种方法失败的另一种方式是，当一场非常大且不可能的灾难完全抵消了您采用低等级运营模式所节省的成本时(参见[2017年5月英国航空公司的停运](https: //ind.d pn/2LNQflE))。 ↩

  3. 当然，还有许多其他潜在的反应。例如，ITIL®是另一种IT管理方法，倡导更好的标准化。 ↩

  4. 还要注意，因为这是一个复杂的世界，所以也存在正效应到分区，孤岛等，但是在运营领域，不利因素似乎尤其严重。 ↩

  5. 请参阅https: //en.wikipedia.org/wiki/Normal_Accidents。 ↩

  6. 较高风险的更改或无法通过自动方式确认的更改，显然应该由人类审核，即使不是由他们实施的。 ↩

  7. Google的SRE历史来自前身的团队，该团队更注重运营，Ben从工程的角度提供了解决问题的动力。 ↩

  8. 这在很多方面都是用词不当，也许最根本的原因是您不能仅仅雇用一些人，称他们为"DevOps工程师"，并立即期望收益。您必须接受改变工作方式以受益的全部理念。正如Andrew Clay Shafer所说一样，"人们出售DevOps，但您买不到。"而且，正如Seth Vargo在"DevOps的十大神话"中指出的那样，您不能"雇用DevOp来修复您的组织"。 ↩

  9. 服务水平目标是特定指标性能的目标(例如，有99.9％的时间可用)。 ↩

  10. 如果您将其视为分层堆栈，请执行分层冲突。 ↩

  11. 实际上，有任何内容*的生产准备情况审查； SRE不仅会从一开始就提供车载服务。 ↩

  12. 服务通常被定义为运行以执行某些业务需求的软件，通常具有可用性约束。 ↩

  13. 在Google内部，这个问题已得到解决，服务始终会更改状态，配置，所有权，方向等。在一定程度上，Google的SRE曾是"抗争是必要的"论点的受益者，该论点过去曾被抗争并赢得过多次胜利。但是，正如威廉·吉布森(William Gibson)可能说的那样，并不是完全均匀分布。 ↩

  14. 请参阅https://devops-research.com/research.html上的相关研究。 ↩

  15. 请参阅http: //en.wikipedia.org/wiki/Goodhart%27s_law和https: //skybrary.aero/bookshelf/books/2336.pdf。 ↩

  16. 参见例如https: //codeascraft.com/2012/05/22/blameless-postmortems/。 ↩

  17. 在具有发达文化的组织中。早期公司可能没有建立奖励这些工作角色的方法。 ↩

  18. 确实，可以说，除非您外包操作，否则这是您的唯一选择。 ↩

  19. 有关如何在不同上下文中应用SRE原则的讨论，请参见第20章。 ↩

  20. 换句话说，简单地淘汰一组DevOps或SRE，而无需改变他们的组织位置，导致在无法实现预期的改进时不可避免地使团队蒙羞。 ↩