SRE和DevOps的关系：把SRE看作是DevOps接口的实现

译者注：近几年，包括Oracle、微软在内的全球主要的软件企业都在其云服务研发和运营部门推行DevOps或SRE。我所在的系统架构和性能服务部门也在2017年初重组为Oracle SaaS服务的SRE部门，开发相关的统一工具链以改进SaaS服务的可靠性，并为SaaS生产环境（超过70万 VM 实例，超过25,000名客户）可靠性提供7x24的事件升级支持。2018年底，我们的SaaS工程运营事业群又发起了一次重大重组，这次重组是为了实现DevSecOps策略。那么SRE和DevOps之间是什么关系呢？Niall Murphy是谷歌爱尔兰的广告网站可靠性工程师团队负责人，本文他对这一问题的解读，并收录在2018年7月由O'Reilly Media出版的《The Site Reliability Workbook》一书中，作为第一章。

作者：Niall Richard Murphy, Liz Fong-Jones, and Betsy Beyer 翻译：王录华 原文：https://learning.oreilly.com/library/view/how-sre-relates/9781492030645/ch01.html

作为一门学科，运维是很难的（注1）。不仅是因为让系统很好地运行方面存存的普遍未解决的问题，而且是还发现很多有效的最佳实践方案往往高度依赖于环境，并且没有被广泛采用。同时在如何很好地运营运维团队方面还有很多未解决的问题。人们普遍认为，对这些主题的详细分析源于第二次世界大战期间致力于改善盟军军事过程和产出的运营研究，但实际上，我们近千年来一直在考虑如何将运营做得更好。

然而，尽管有这些努力和思考，生产环境的可靠性运维仍然是难以捉摸的 - 特别是在信息技术和软件的可操作性领域。例如，企业界通常将运营视为成本中心，（注2）这使得在结果上有意义的改进变得很困难，这不是不可能的。这种方法的巨大短视目前还没有被广泛认识，但是对它的不满已经引发了一场如何组织我们IT中所做的事情的变革。

这场变革源于试图解决一系列共同问题。针对这些问题的最新解决方案被命名为两个单独的名词-–开发运营（DevOps）和站点可靠性工程(SRE)。虽然我们单独谈论它们，好像它们是对刚刚描述的企业心态（注3）的完全独立的反应，但我们希望能说服你，实际上它们丰常相似，并且各自的实践都有比你想象的更多的共同点。

但首先，关于各自关键原则的一些背景知识。

1. DevOps的背景

DevOps是一套松散的实践、指导方针和文化，旨在打破IT开发、运营、网络和安全方面的孤岛。由John Willis，Damon Edwards 和 Jez Humble 表达为 CA(L)MS——代表文化(Culture)，自动化(Automation)，精益(Lean)(用在精益管理中，也看到持续交付），测量(Measurement)和共享(Sharing)—— 是记住DevOps哲学要点的一个有用的缩略语。分享和合作是这一运动的重中之重。在DevOps方法中，您可以改进一些东西(通常是通过自动化)，测量相应结果，并与同事共享这些结果，以便整个组织都能改进。所有CALMS原则都得到一种支持性文化的推进。

DevOps、Agile和各种其他业务和软件重新设计技术都是关于如何在现代世界中最好地经营业务的普遍世界观的例子。DevOps理念中的任何元素都不容易相互分离，这基本上是通过设计来实现的。然而，有几个关键的想法可以在相对孤立的情况下讨论。

1.1. 不再是筒仓(Silos)

第一个关键想法是不再是筒仓（Silos）。这是对一些想法的反应：

• 历史上受欢迎的，但现在越来越老式的将运营团队和开发团队分隔开来
• 事实上，知识的极端孤立化，纯粹的局部优化的激励，以及协作的缺乏在许多情况下对业务来说是非常不利的（注4）

1.2. 事件是常态

第二个关键的想法是，事故不仅仅是个别孤立行为的结果，而是在事情不可避免地出错时缺乏安全保障的结果（注5）。例如，一个糟糕的界面无意中鼓励在压力下采取错误的行动; 如果出现（不明确的）糟糕情况，系统性能不足会使故障不可避免; 如果监测中断，人们不可能知道出现了什么问题，更不用说出了什么问题。一些传统意义上的企业拥有文化本能来铲除错误制造者并惩罚他们。但这样做有其自身的后果：最明显的是，它创造了混淆问题，隐瞒真相和指责他人的动机，而所有这些最终都是无益的干扰。因此，关注快速恢复比预防事故更有利可图。

1.3. 变更应该是渐进的

第三个关键想法是，当变更很小且频繁时，变更是最好的。在变更委员会每月召开会议的环境中，讨论对大型机配置进行更改的彻底记录的计划，是一个激进的想法。然而，这不是一个新想法。如果所有变更都必须由经验丰富的人员考虑，并且为了高效的考虑而进行分批，那么结果或多或少与最佳实践相反。变更是有风险的，但是正确的反应是在可能的情况下将变更改拆分为更小的子组件。然后，您可以根据产品，设计和基础架构变更的常规输出构建稳定的低风险变更管道（注6）。此策略，加上对较小变更的自动测试和对错误变更的可靠的回滚，可以实现变更管理的方法，如连续集成（CI）和持续交付或部署（CD）。

1.4. 工具和文化是相互关联的

工具是DevOps的一个重要组成部分，特别是考虑到强调正确管理变更——如今，变更管理依赖于高度特定的工具。但总的来说，DevOps的支持者强烈强调组织文化——而不是工具 ——是成功采用新工作方式的关键。一个好的文化可以解决破碎的工具，但相反的情况很少适用。俗话说，文化吃早餐策略（culture eats strategy for breakfast）。与运营一样，变革本身也很难。

1.5. 测量至关重要

最后，测量在整个业务环境中尤为重要，例如，打破孤岛（silos）和事件解决方案。在这些环境中，您通过客观测量来确定所发生事件的真实性，验证您是否正在按预期改变情况，并为不同职能部门达成一致的对话创建客观基础。（这适用于商业和其他环境，例如值班（on-call）。）

2. SRE的背景

站点可靠性工程（SRE）是由Google的工程副总裁Ben Treynor Sloss创造的术语（和相关的工作角色）（注7)。正如我们在上一节中所看到的，DevOps是关于整个生命周期协作的一系列广泛原则在运营和产品开发之间。SRE是一个工作角色，我们发现的一系列实践（下面描述），以及一些使这些实践具有动力的信念。如果您认为DevOps是一种哲学和工作方法，您可以认为SRE实现了DevOps所描述的一些理念，并且比“DevOps工程师”更接近于工作或角色的具体定义（注8）。因此，在某种程度上，把SRE看作是DevOps接口的实现。（译者注 - 原文是：So, in a way, class SRE implements interface DevOps.）

与DevOps运动不同，DevOps运动起源于多家公司的领导者和从业者之间的合作，在SRE在整个行业广泛普及之前，Google的SRE继承了围绕其公司的一些文化。考虑到这一轨迹，整个学科目前并没有像DevOps那样将默认文化变为前景。（当然，这并不意味着在任意组织中进行SRE没有必要进行文化重塑。）

SRE由以下具体原则定义。

2.1. 运维是一个关于软件的问题

SRE的基本原则是做好运维是一个关于软件的问题。因此，SRE应该使用软件工程方法来解决该问题。这涉及广泛的视野，包括从流程和业务变更到类似复杂但更传统的软件问题的所有内容，例如重构相应部分以消除业务逻辑中的单点故障。

2.2. 按服务水平目标（SLO）管理

SRE不会尝试提供100％的可用性。正如我们的第一本书《站点可靠性工程》中所讨论的，出于多种原因，那是错误的目标。相反，产品团队和SRE团队为服务选择适当的可用性目标，这些服务是基于用户的，并将这个服务管理设法和SLO对应（注9）。在此类目标进行管理需要来自业务部门的强有力的协作。SLO也具有文化含义：作为利益相关者之间的协作决策，SLO违规行为将所有相关团队无可奈何地带回到绘图白板前。

2.3. 尽量减少琐碎的杂活

对于SRE，任何手动的，结构化的命令行式操作任务都是令人憎恶的。（这并不意味着我们没有任何此类操作：我们有很多这样的操作。我们只是不喜欢它们。）我们相信，如果机器可以执行所需的运维操作，那么就应该机器做。如果琐碎的杂活就是一个工作岗位，这就是你要付钱给一个人做，这种区别（和价值）在其他组织中并不常见。对于谷歌环境中的的SRE，琐碎的杂活不是一个工作岗位——它不可能是。任何花在重复运维性任务上的时间都意味着这个时间没有花费在项目上——这里的项目工作是指如何使我们的服务更可靠和可扩展。有关如何在运营工作中取得平衡的更广泛的对话，请参阅“我们如何运营”。

然而，执行运维任务确实是“生产环境的智慧”，为决策提供重要的参考。它通过提供给定系统的实时反馈从而使我们的工作保持稳打稳扎。琐碎的杂活来源需要是可以识别的，因此您可以最小化或消除它们。但是，如果您发现自己处于低负载运营状态，则可能需要更频繁地推送新功能和变更，以便工程师熟悉您支持的服务的运行情况。

生产环境的智慧

关于“生产的智慧”的注解：通过这个短语，我们指的是你从生产中运行的东西中获得的智慧——实际情况中复杂的细节，以及软件应该如何设计，而不是脱离了实际的服务相关的白板上的观点。您获得的所有文档，团队获得的服务号（tickets）等等都与现实直接相关，它们可以为更好的系统设计和行为提供依据。

2.4. 让今年的工作自动化

这方面的真正工作是确定什么可以自动化、在什么条件下以及如何自动化。

谷歌实行的SRE严格限制了团队成员花费多少时间用于琐碎的杂活，而不是用于工程设计产生持久价值：50％。许多人认为这个限制是一个上限。事实上，将它视为一种保证——一种明确的陈述和启用机制，对于采用基于工程的方法解决问题而不是一次又一次地仅作为琐碎的杂活处理。

当我们思考自动化与琐碎的杂活两者时，会发现这个基准和玩法不仅不直观而且相互交错。随着时间的推移，一个SRE团队最终会自动化一切服务，留下一些无法自动化的东西（Murphy-Beyer效应）。在其他条件相同的情况下，除非有其它行动方案，否则这将决定了SRE团队所做的事情。在Google环境中，您要么倾向于添加更多服务达到仍然支持50％的时间用于工程的某些限制，要么您在自动化方面非常成功从而您可以去做其他完全不同的事情。

2.5. 通过减少问题事件成本来快速迭代

参与SRE的主要好处之一不一定是提高可靠性，尽管显然确实发生了这种情况； 它实际上是改进了产品研发的输出。为什么？嗯，减少通用问题的平均故障修复时间（MTTR）会导致产品开发工程师效率提高，因为工程师在这些问题发生后不必浪费时间来清理。越在产品生命周期的后期发现问题，修复的成本越高，这是众所周知的事实。SRE专门负责改善并发现可能在后期发生的不期望的问题，从而为整个公司带来利益。

2.6. 与开发人员分享所有权

在“应用程序开发”和“生产”（有时称为程序员和运维操作员）之间的设定严格界限会适得其反。尤其是，如果将责任分离，并将运维归类为成本中心会导致权力不平衡或者尊重及薪酬方面的差异。

SRE往往倾向于关注生产环境问题而不是业务逻辑问题，但是当他们的方法带来软件工程工具来解决问题时，他们与产品开发团队分享技能。通常，SRE在他们所关注的服务可用性、延迟、性能、效率、变更管理、监控、紧急响应和容量规划方面具有特殊的专业知识。这些特定（通常是明确定义的）能力正是SRE为产品和相关产品开发团队所做的事情（注10）。理想情况下，产品开发和SRE团队应该对产品堆栈有一个整体的看法——前端、后端、库、存储、内核和物理机器——没有团队应当被羡慕地拥有单个组件。事实证明，如果你“模糊线条”（注11）并使用SRE工程师使用JavaScript，或者产品开发工程师对内核进行限定，那么你可以做得更多：如何进行变更管理的的知识、更广泛的权限、以及激励措施以小心翼翼地保护任何特别的功能，这些都可被删除。

在《网站可靠性工程》中，我们没有明确表明Google中的产品开发团队默认拥有自己的服务。SRE既没有也不能保证大部分服务，尽管SRE的原则仍然包括告知整个Google如何管理服务（注12）。SRE团队与产品开发团队合作的所有权模式最终其实是一个共享模型。

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

工具是表现行为的一个非常重要的决定因素，如果认为在Google环境中的SRE与如下这些无关，那未免太天真：广泛可用的统一代码库、广泛的软件和系统工具、高度优化和专有产品技术栈等等。然而，我们与DevOps共用这个绝对假设：团队服务（注13）应该使用相同的工具，无论他们在组织中的角色如何。如果SRE使用一种工具而和产品开发人员使用另一种工具，那么在不同情况下表现不同（并且可能是灾难性的），因而没有好的方法来管理这个服务。您拥有的分歧越多，您的企业从改进各个工具的每项努力中获益的就越少。

3. 差异对比

从上述的原则看，我们可以立即看到这些同共点：

• DevOps和SRE两者都承认：为了改进变更是必须的。都取决于接受改变是必要的，以便改进。没有它，没有太多的运作的机动（注14）。
• 协作是DevOps工作的提题和中心。有效的共享所有权模型和合作伙伴团队关系是SRE运行所必需的。与DevOps一样，SRE也在整个组织中分享强大的价值，这可以使团队因素的孤岛更容易攀登。
• 变更管理最好是尽通过最小的持续的动作来实现，其中理想的状态是主要的测试和应用是自动化的。变化与可靠性两都之间的重要关联关系对SRE尤为重要。
• 正确的工具非常重要，工具在一定程度上决定了您的行动范围。然而，我们不能过分关注是否使用某些特定的工具来实现某些目标; 一天结束时，系统管理的API化是一个更重要的理念，它比任何具体的执行的影响会更长久。
• 量化对DevOps和SRE两者的工作方式都至关重要。对于SRE，SLO在确定改进服务所采取的行动方面占主导地位。当然，没有量化就不能拥有SLO（以及跨团队讨论 - 理想情况是产品，基础设施/SRE和业务）。对于DevOps，量化行为通常用于了解过程的输出是什么、反馈环的持续时间等等。无论是在专业技能上还是理念上，DevOps和SRE都是数据导向的东西。
• 采用野蛮而现实的方式管理生产服务就意味着偶尔会坏事，你必须分析原因。而SRE和DevOps都实行无可指责的事后分析（译者注：postmortemsin）以抵消无益的肾上腺素负荷的反应。
• 最终，实施DevOps或SRE是一种整体行为;两者都希望通过高度特定的方式共同合作，使整个团队（或单个或整个组织）更好。对于DevOps和SRE，结果就是更好的速度（注15）。

正如您所见，DevOps和SRE之间存在许多共同点。

然而，也存在显着差异。从某种意义上说，DevOps是一种更广泛的理念和文化。因为它会比SRE引起更广泛的变化，所以DevOps更具环境的敏感性。DevOps对如何在细节的级别运行哪些操作相对保持沉默。例如，它没有规定精确的服务管理。相反，它选择集中火力打破更广泛组织的障碍。这很有价值。

另一方面，SRE的职责定义相对狭窄，其职权范围通常是面向服务（以最终用户为导向）而非整体业务导向。因此，它为如何有效运行系统的问题带来了自以为是的知识框架（包括错误预算等概念）。虽然作为一个职业，SRE高度了解激励因素及其影响，但它反过来却相对于孤岛化和信息障碍等主题而言相对沉默。它愿意支持CI和CD，却不一定是因为业务案例，而是因为所涉及的操作实践得到了改进。或者，换句话说，SRE相信与DevOps相同的东西，但原因略有不同。

4. 组织背景与促进成功应用

DevOps和SRE在其运作方式上存在非常大的概念重叠。正如您所料，他们在组织内也有一组类似的必须为真的条件以便他们a）首先可以实现的，并且b）从该实现中获得最大的好处。正如托尔斯泰几乎但从未说过的那样，有效的运作方法都是相似的，而破碎的方法都以自己的方式被打破。激励因素可以部分解释为什么会这样。

如果一个组织的文化重视DevOps方法优点并且愿意承担这些成本——通常表现为招聘困难，维持流动性团队和责任所需的能量，以及增加的财务资源更为用于酬劳必要的罕见的技能能——那么该组织还必须确保正确的激励措施以实现这种方式的全部益处。

具体来说，以下内容应该在DevOps和SRE的环境中都适用。

4.1. 狭隘而僵化的激励措施会限制你的成功

许多公司不小心定义了破坏集体业绩的正式激励（惩罚）措施。为了避免这种错误，不要将激励措施与发行相关或可靠性相关的结果狭隘地联系起来。正如任何一们经济学家都可以告诉你的那样，如果有一个数字衡量标准，人们会找到一种方法来博弈其不良影响，有时甚至是以完全出于好意的方式（注16）。相反，你应该让你的人找到正确的方法的自由。如前所述，DevOps或SRE通常可以作为产品团队的促进剂，允许其他软件组织以连续可靠的方式向客户提供功能。这种动态也解决了传统和源于不同系统/软件组的方法的一个持久性问题：设计和生产之间缺乏反馈环。一个让SRE尽早参的系统（理想情况下，在设计时）通常在部署后的生产中会工作得更好，这和谁负责管理服务无关。 （没有什么会如同丢失用户数据一样会减缓功能开发进展）

4.2. 最好自己解决相关问题;不要责怪别人

此外，要避免任何将生产环境事件或系统故障归咎于其他团队的动机。在许多方面，不断推卸责任是使用传统模型的工程运维中的核心问题，因为一旦将运维和开发团队分隔开就会允许出现孤立的激励因素。相反，从组织层面可考虑采用以下做法来打击的推卸责任：

• 不仅只是允许，而且是要积极鼓励工程师在产品需要时更改代码和配置。同时授权这些团队在其任务范围内具有激进的权力，从而消除那些使用工作进行得更慢的激励措施。
• 支持无指责性的事故后分析（postmortems）（注17）。这样做可以消除对问题轻描淡写或进行隐蔽的动机。这一步对于充分理解产品并实际优化其性能及功能至关重要，同时这也依赖于前面提到的生产智慧。

允许技术支持团队摆脱那些可运维性糟糕得不可救药的产品。撤销对产品的支持的威胁可以促使产品研发修复那些准备支持之前以及产品本身自我诊断支持方面的问题，从而节省每个人的时间。“可运维性糟糕得不可救药”的含义可能因您的环境而异——其中的动态变化应该是大家相互理解的责任之一。推回给其它团队可能会比较温和，“我们认为使用已有这种技能的人的时间具有更高的价值”，或者在体制的有限范围内，“如果不给他们机会利用他拉的软件工程技能，而是给他们分配太多的运维性的任务，那么这些人就会退出这个工作。” 在谷歌，直接撤销这类产品的技术支持的做法已成为制度。

4.3. 将可靠性工作视为一个专业的岗位

在谷歌，SRE和产品开发是相互独立的不同的组织。每个小组都有自己的工作重点、优先级和管理团队，而不必依赖对方。然而，当产品成功时，产品开发团队为SRE团队人员的扩充提供了高水平的人才库。通过这种方式，产品开发与SRE团队的成功息息相关，就像SRE的成功与产品开发团队密切相关一样。SRE也很幸运获得管理层的高层支持，这确保了工程团队反对以“SRE方式”来支持服务意见常常是短暂。你不需要有一个组织结构图来做不同的事情——你只需要不同的实践社区的出现。

无论您是组织结构图的分支还是使用更多非正式机制的方式，重要的是要认识到专业化带来挑战。DevOps和SRE的从业者可以从本行业的社区中获得支持和职业发展，以及职业阶梯为他们带来（注18）的独特技能和激励。

值得注意的是，Google采用的组织结构以及上述一些激励措施在某种程度上依赖于规模庞大的组织。例如，如果您的20人创业公司并只有一个（相对较小的）产品，那么在撤销运维支持方面没有多大意义。它虽仍然可以采用DevOps风格的方式（注19），但是如果您能做的就是帮助它成长，那么改善操作性差的产品的能力就会下降。但通常情况下，人们有更多的选择，而不仅是他们关于如何满足这些增长需求以对抗技术债务积累速度的想象。

4.4. 什么时候可以代替

但是，当您的组织或产品增长超过一定规模时，您可以在支持哪些产品方面行使更大的自由度，或者如何优先支持这些产品。很显然，如果对系统X的支持将比支持系统Y更快地发生，与选择不在SRE领域中支持这些服务一样，隐含条件可以发挥同样的作用。在谷歌，SRE与产品开发的强大合作关系已被证明是至关重要的：如果您的组织存在这种关系，那么撤回（或提供）支持的决定可以基于有关运营特征的可比较的客观数据，从而避免无效率的沟通。SRE与产品开发之间的富有成效的关系也有助于避免那种的反模式组织，即产品开发团队在产品或功能准备就绪之前而交付。相反，SRE可以与开发团队合作，在维护负担从具有最多专业知识的人员手出转移出之前改进产品。

4.5. 争取同等的尊重：职业和财务

最后，确保鼓励做正确事情的职业激励措施到位：我们希望我们的DevOps / SRE组织与其产品研发对应方保持同等的尊重。因此，每个团队的成员应该采用大致相同的方法进行评级，并具有相同的财务激励措施。

5. 结论

在许多方面，DevOps和SRE在实践和理念上都与IT运营的整体领域非常接近。

DevOps和SRE都要求实际工作的人员进行讨论、管理层支持和接受，以取得重大进展。实施其中任何一个都是一个过程，而不是一个快速解决方案：仅仅是羞涩地重命名（注20）的做法是空洞的，不太可能带来好处。鉴于它是如何执行运维的更具见解性的实现方式，尽管需要特定的适应性，SRE在如何尽早地在过程中如何改进您的工作实践有更具体的建议。DevOps，具有更广泛关注点，有点儿更难以推理并转化为具体步骤，但恰恰是因为更广泛的关注，可能会遇到较弱的初始阻力。

但每个实践者都使用许多相同的工具，相同的方法来改变管理，以及相同的基于数据的决策思维。在一天结束时，我们都面临着同样的问题：生产环境，使其变得更好——无论我们被称为什么。

对于那些对进一步阅读感兴趣的人，以下一些建议可以帮助您更广泛地了解目前正在进行的运营大变革相关的文化、业务和基础技术：

• 《Site Reliability Engineering》by Jennifer Petoff 等，O'Reilly，April 2016
• 《Effective DevOps》by Ryn Daniels 等，O'Reilly，June 2016
• 《The Phoenix Project》by George Spafford等，IT Revolution Press，January 2013
• 《The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services, Volume 2》by Christina J. Hogan 等， Addison-Wesley Professional，September 2014
• 《Accelerate: The Science of Lean Software and DevOps》by Nicole Forsgren PhD 等，IT Revolution Press; March 27, 2018

注解：

• 注1 - 请注意，由于此讨论出现在有关SRE的课程中，因此本讨论中的某些内容特定于软件服务运维，而不是IT运维。
• 注2 - Mary Poppendieck有一篇关于此问题的优秀文章中称之为“成本中心陷阱”。这种方法失败的另一种方式是，当一场非常大且罕见的灾难会完全抵消之前通过转向低级操作模型所节省的成本（c.f. the British Airways outage in May 2017）。
• 注3 - 当然，还有许多其他潜在的反应。例如，ITIL®是另一种改进标准化的IT管理方法。
• 注4 - 另请注意，由于这是一个复杂的世界，因此对分区，孤岛等具有同等的影响，但缺点似乎在运维领域特别不利。
• 注5 - 参见 https://en.wikipedia.org/wiki/Normal_Accidents。
• 注6 - 如果不是由人类制定的，那么高风险变更，或那些通过自动手段无法实现的变更，显然仍应由人类审查。
• 注7 - 谷歌SRE的历史就是它发源于一个更具运维性质的先驱团队，Ben从工程角度提供了解决问题的动力。
• 注8 - 这在许多方面都是用词不当，也许最基本的是你不能雇用一些人，称他们为“DevOps工程师”，并期望立即获益。您必须引进改变工作方式以获益的整体理念。正如Andrew Clay Shafer所说，“人们出售DevOps，但你不能买它。”而且，正如Seth Vargo在“DevOps的10个神话”中指出的那样，你不能“雇用DevOp来修复你的组织”。
• 注9 - 一个服务级别（SLO）目标是一个执行特定度量的目标（例如，99.9％的可用时间）。
• 注10 - 当然，并非每个团队都能做到，但这些是SRE最常见的论题。
• 注11 - 如果您将此视为分层堆栈，请执行分层违例。
• 注12 - 事实上，有一个“生产环境准备情况审查”可以用来进行任何事情; SRE不仅仅是从一开始就提供服务。
• 注13 - 服务被宽泛地定义为运行以执行某些业务需求的软件，通常具有可用性限制。
• 注14 - 在谷歌内部，这个问题基本得到解决，服务一直在改变状态，配置，所有权，方向等。在某种程度上，谷歌的SRE是“变更是必要的”论据的受益者，过去曾经多次争吵过。但威廉吉布森可能会说，但并非完全分散开。
• 注15 - 参见相关研究报告：http：//devops-research.com/research.html。
• 注16 - 参见 http://en.wikipedia.org/wiki/Goodhart%27s_lawandhttps://skybrary.aero/bookshelf/books/2336.pdf.
• 注17 - 例如，见https://codeascraft.com/2012/05/22/blameless-postmortems/。
• 注18 - 在具有良好发展文化的组织中。早期公司可能没有确定的方式来奖励这些工作角色。
• 注19 - 的确，可以说，除非你外包业务，否则这只是你的选择。
• 注20 - 换句话说，简单地重新命名一个组织为DevOps或SRE，而其组织定位没有其他变化，当承诺改进不到时，导致团队不可避免的丢脸。