该网络研讨会的音频质量很差，因此我们对其进行了转录。
我的名字是梅德韦杰夫·爱德华。 今天我会讲什么是SRE，SRE是怎么出现的，SRE工程师的工作标准是什么，一点关于可靠性标准，一点关于它的监控。 我们会在山顶上行走，因为一个小时内你看不到太多内容，但我会提供额外审查的材料，我们都在等你 。 一月底在莫斯科。
首先我们先来说一下什么是SRE——站点可靠性工程。 以及它是如何作为一个独立的立场、一个独立的方向出现的。 这一切都始于这样一个事实：在传统的开发圈中，Dev 和 Ops 是两个完全不同的团队，通常有两个完全不同的目标。 开发团队的目标是推出新功能并满足业务需求。 运营团队的目标是确保一切正常，没有任何问题。 显然，这些目标直接相互矛盾：为了让一切正常运行并且没有任何破坏，尽可能少地推出新功能。 正因为如此，现在被称为 DevOps 的方法论正试图解决许多内部冲突。
问题在于我们对DevOps没有一个明确的定义，也没有一个明确的DevOps实施。 两年前，我在叶卡捷琳堡的一次会议上发表了演讲，直到现在，DevOps 部分都是从“什么是 DevOps”报告开始的。 2年，DevOps已经快2017岁了，但我们仍在争论它到底是什么。 这是谷歌几年前试图解决的一个非常奇怪的情况。
2016年，谷歌发布了一本名为《站点可靠性工程》的书。 事实上，SRE 运动正是从这本书开始的。 SRE 是 DevOps 范式在特定公司的具体实现。 SRE 工程师致力于确保系统可靠运行。 他们大多来自开发人员，有时来自具有强大开发背景的管理员。 而且他们做的都是系统管理员过去做的事情，但是在代码方面强大的开发背景和对系统的了解导致这些人不倾向于日常管理工作，而是倾向于自动化。
事实证明，SRE 团队中的 DevOps 范式是通过解决结构性问题的 SRE 工程师来实现的。 这就是人们已经谈论了 8 年的 Dev 和 Ops 之间的联系。 SRE 的角色与架构师的角色类似，新人不会成为 SRE。 人们在职业生涯的初期还没有任何经验，也不具备必要的知识广度。 因为 SRE 需要非常微妙地了解到底什么时候会出现问题以及什么时候会出现问题。 因此，通常需要一些公司内部和外部的经验。
他们询问是否会描述 SRE 和 DevOps 之间的区别。 刚才已经描述过她了。 我们可以谈谈SRE在组织中的地位。 与经典的 DevOps 方法不同，Ops 仍然是一个独立的部门，而 SRE 是开发团队的一部分。 他们参与产品开发。 甚至有一种方法将 SRE 的角色从一个开发人员转移到另一个开发人员。 他们以与用户体验设计师、开发人员本身（有时甚至是产品经理）相同的方式参与代码审查。 SRE 在同一级别上工作。 我们需要批准它们，我们需要审查它们，这样对于每个部署，SRE 都会说：“好吧，这个部署，这个产品不会对可靠性产生负面影响。 如果确实如此，那么也在一些可接受的范围内。 我们也会谈论这个。
因此，SRE 拥有更改代码的否决权。 一般来说，如果 SRE 实施不正确，这也会导致某种小冲突。 在同一本关于站点可靠性工程的书中，许多部分（甚至没有一个）讲述了如何避免这些冲突。
他们询问 SRE 与信息安全有何关系。 SRE不直接参与信息安全。 基本上，在大公司中，这是由个人、测试人员、分析师完成的。 但 SRE 也与它们进行交互，因为某些影响安全性的操作、某些提交、某些部署也会影响产品的可用性。 所以SRE作为一个整体，和任何团队都有互动，包括安全团队，包括分析师。 因此，在尝试实施DevOps时，主要需要SRE，但同时，开发人员的负担也变得过大。 也就是说，开发团队本身已经无法应对现在他们还需要负责Ops的事实。 并且有一个单独的角色。 这个角色已在预算中计划。 有时这个角色是根据团队的规模来规定的，一个单独的人出现，有时一个开发人员成为它。 这就是团队中第一个SRE的出现。
受SRE影响的系统复杂度，影响运行可靠性的复杂度，有必然的，也有偶然的。 必要的复杂性是指产品的复杂性增加到新产品功能所需的程度。 随机复杂度是指系统的复杂度增加，但产品功能和业务需求对此没有直接影响。 事实证明，要么是开发人员在某个地方犯了错误，要么是算法不是最优的，或者是引入了一些额外的兴趣，在没有特殊需要的情况下增加了产品的复杂性。 一个好的 SRE 应该能够杜绝这种情况。 也就是说，任何由于随机添加而增加难度的提交、任何部署、任何拉取请求都应该被阻止。
问题是为什么不直接聘请一名工程师、一名拥有丰富知识的系统管理员进入团队。 我们被告知，扮演工程师角色的开发人员并不是最好的人员配置解决方案。 担任工程师角色的开发人员并不总是最好的人员配备解决方案，但这里的要点是，从事运维的开发人员对自动化有更多的渴望，拥有更多的知识和技能来实施这种自动化。 相应地，我们不仅减少了一些具体操作的时间，不仅减少了例行公事，还减少了MTTR（Mean Time To Recovery，恢复时间）这样的重要业务参数。 因此，我们稍后也会讨论这一点，我们为组织节省了资金。
现在我们来谈谈SRE的运行标准。 首先是关于可靠性。 在小公司、初创公司中，人们经常认为，如果服务写得好，如果产品写得好且正确，它就会工作，不会崩溃。 就是这样，我们编写了良好的代码，所以没有什么可以破坏的。 代码非常简单，没有什么可破坏的。 这些人都说我们不需要测试，因为，看，这些是三种 VPI 方法，为什么要在这里中断。
当然，这都是错误的。 这些人在实践中经常被这样的代码所困扰，因为事情会崩溃。 事情有时会以最不可预测的方式破裂。 有时人们会说不，这永远不会发生。 而且这种事一直在发生。 这种事经常发生。 这就是为什么没有人努力实现 100% 可用性，因为 100% 可用性永远不会发生。 这是常态。 因此，当我们谈论服务的可用性时，我们总是谈论九。 2个3，4个5，5个5，2个3,5。 如果我们将其转化为停机时间，那么，例如，XNUMX 个 XNUMX，则每年的停机时间略多于 XNUMX 分钟，XNUMX 个 XNUMX 则为 XNUMX 天的停机时间。
但很明显，在某个时刻，POI（投资回报率）会下降。 从两个 3 到三个 47 意味着停机时间减少超过 XNUMX 天。 从 XNUMX 个 XNUMX 减少到 XNUMX 个，每年可减少 XNUMX 分钟的停机时间。 事实证明，对于商业来说，这可能并不重要。 而且一般来说，所要求的可靠性不是技术问题，首先是业务问题，是产品问题。 产品的用户可以接受什么水平的停机时间，他们的期望是什么，他们支付多少钱，例如他们损失了多少钱，系统损失了多少钱。
这里的一个重要问题是其余组件的可靠性如何。 因为在具有 4 个 5 可靠性的智能手机上，2 个 10 和 8 个 XNUMX 之间的差异是不可见的。 粗略地说，如果您服务的智能手机每年出现 XNUMX 次故障，则很可能有 XNUMX 次故障发生在操作系统方面。 用户对此已经习惯了，一年也不会再关注一次。 有必要将增加可靠性和增加利润的价格联系起来。
就在关于 SRE 的书中，有一个从 4 个 3 增加到 0,1 个 1 的很好的例子。 事实证明，可用性的增幅略小于 900%。 而如果该服务的收入为每年 900 万美元，那么收入的增加就是 900 美元。 如果我们每年花费不到 3 美元就能将负担能力提高 XNUMX 倍，那么这种增加在经济上是有意义的。 如果一年花费超过XNUMX美元，就不再有意义了，因为收入的增加根本无法补偿劳动力成本、资源成本。 XNUMX 个 XNUMX 对我们来说就足够了。
这当然是一个简化的示例，其中所有请求都是平等的。 从 3 个 4 到 2 个 3 很容易，但同时，例如从 9 个 XNUMX 到 XNUMX 个，这已经节省了 XNUMX 美元，这在财务上是有意义的。 当然，在现实中，注册请求失败比页面显示失败更糟糕，请求具有不同的权重。 从业务角度来看，他们可能有完全不同的标准，但无论如何，通常，如果我们不谈论某些特定服务，那么这是一个相当可靠的近似值。
我们收到一个问题，在为服务选择架构解决方案时，SRE 是否是协调者之一。 比如说与现有基础设施的集成，这样就不会损失其稳定性。 是的，SRE，就像拉取请求、提交、发布影响架构、新服务、微服务的引入、新解决方案的实施一样。 为什么我之前说需要经验，需要资历。 事实上，SRE 是任何架构和软件解决方案中的阻碍声音之一。 因此，SRE作为工程师，首先不仅要了解，还要了解一些具体的决策将如何影响可靠性、稳定性，了解这与业务需求有何关系，从什么角度来看是可以接受和接受的。哪个不是。
因此，现在我们可以只讨论可靠性标准，传统上在 SRE 中将其定义为 SLA（服务级别协议）。 很可能是一个熟悉的术语。 SLI（服务水平指示器）。 SLO（服务级别目标）。 服务水平协议可能是一个象征性术语，特别是如果您与网络、提供商、托管合作过。 这是一份通用协议，描述了整个服务的性能、处罚、对错误的一些处罚、指标、标准。 SLI 本身就是可用性指标。 也就是说，SLI 可以是：服务的响应时间、错误数（以百分比表示）。 如果是某种文件托管，则可能是带宽。 例如，当涉及到识别算法时，指标甚至可以是答案的正确性。 SLO（服务级别目标）分别是 SLI 指标、其值和周期的组合。
假设 SLA 可能是这样的。 该服务全年 99,95% 的时间均可用。 或者每季度 99 小时内将关闭 3 个关键支持请求。 或者每月 85% 的查询会在 1,5 秒内得到响应。 也就是说，我们逐渐认识到错误和失败是很正常的。 这是一个可以接受的情况，我们正在计划它，我们甚至在某种程度上期待它。 也就是说，SRE 构建的系统可能会犯错误，必须对错误做出正常响应，并且必须将错误考虑在内。 只要有可能，他们就应该以用户不会注意到或注意到的方式处理错误，但有某种解决方法，这样一切都不会完全崩溃。
例如，如果你上传一个视频到YouTube，而YouTube无法立即转换，如果视频太大，如果格式不是最优的，那么请求自然不会超时失败，YouTube不会给出502错误，YouTube 会说：“我们已经创建了一切，您的视频正在处理中。 大约10分钟后就会准备好。” 这就是优雅降级的原则，如果你曾经这样做过的话，例如在前端开发中，你会很熟悉这种原则。
我们接下来要讨论的术语是 MTBF 和 MTTR，它们对于处理可靠性、错误和期望非常重要。 MTBF 是平均故障间隔时间。 MTTR Mean Time To Recovery，平均恢复时间。 即，从发现错误的那一刻起，从错误出现的那一刻起，到服务恢复到完全正常运行的那一刻起，已经过去了多少时间。 MTBF 主要通过代码质量工作来确定。 也就是说，SRE 可以说“不”。 你需要整个团队的理解，当 SRE 说“不”时，他这么说并不是因为他有害，不是因为他不好，而是因为否则每个人都会受苦。
再说一次，有很多文章、很多方法、很多方法，甚至在我经常参考的那本书中，也有很多关于如何确保其他开发人员不会开始讨厌 SRE 的内容。 另一方面，MTTR 是关于 SLO（服务级别目标）的工作。 而且主要是自动化。 例如，因为我们的 SLO 是每季度 4 个 3 的正常运行时间。 这意味着 13 个月内我们可以允许 13 分钟的停机时间。 结果发现MTTR不能超过13分钟。 如果我们在 1 分钟内响应至少 13 次停机，这意味着我们已经耗尽了该季度的全部预算。 我们正在打破 SLO。 7 分钟的反应和修复崩溃对于机器来说很长，但对于人类来说却很短。 因为直到一个人收到警报，直到他做出反应，直到他理解错误，已经过去了几分钟。 直到一个人明白如何修复它，到底修复什么，做什么，然后这就是几分钟。 事实上，即使您只需要重新启动服务器（事实证明），或者启动一个新节点，那么手动 MTTR 已经大约为 8-XNUMX 分钟。 当流程自动化时，MTTR 通常会达到一秒，有时甚至达到几毫秒。 谷歌通常谈论毫秒，但实际上，当然一切都不是那么好。
理想情况下，SRE 应该几乎完全自动化其工作，因为这直接影响 MTTR、其指标、整个服务的 SLO，以及相应的业务利润。 如果超过时间，系统会询问我们是否是 SRE 故障。 幸运的是，没有人应该受到责备。 这是一种独立的文化，称为无情的事后剖析，我们今天不讨论它，但我们会在 Slurm 上分析它。 这是一个非常有趣的话题，可以谈论很多。 粗略地说，如果超过了每季度分配的时间，那么每个人都有一点责任，这意味着责备每个人是没有成效的，让我们相反，也许不责怪任何人，而是纠正这种情况并利用我们所拥有的工作。 根据我的经验，这种方法对于大多数团队来说有点陌生，尤其是在俄罗斯，但它很有意义并且效果很好。 因此，我将在文章末尾推荐您可以阅读的有关该主题的文献和文献。 或者来 Slurm SRE。
让我解释。 如果超过每季度的 SLO 时间，如果停机时间不是 13 分钟，而是 15 分钟，谁应该为此负责？ 当然，SRE 可能是罪魁祸首，因为他显然做了某种错误的提交或部署。 数据中心的管理员可能应该为此负责，因为他可能进行了某种计划外的维护。 如果数据中心的管理员应该为此负责，那么运维人员也应该为此负责，他在协调 SLO 时没有计算维护费用。 经理、技术总监或签署数据中心合同的人没有注意到数据中心的 SLA 不是为所需的停机时间而设计的，这应该归咎于这一点。 因此，造成这种情况，都是一点一滴的错。 这意味着在这种情况下将责任归咎于任何人都是没有意义的。 但当然需要纠正。 这就是为什么会有尸检。 例如，如果你读过 GitHub 事后分析，发现在每种情况下这总是一个非常有趣、小而出乎意料的故事，你可以替换为没有人说这个特定的人应该受到责备。 责任总是归咎于特定的不完美流程。
让我们继续下一个问题。 自动化。 当我在其他情况下谈论自动化时，我经常提到一个表格，该表格告诉您可以在自动化任务上花费多长时间，而不会花费比您实际节省的时间更多的时间。 有一个障碍。 问题是，当 SRE 自动化任务时，它们不仅可以节省时间，还可以节省金钱，因为自动化直接影响 MTTR。 可以说，它们挽救了员工和开发人员的士气，而这也是一种取之不尽用之不竭的资源。 他们减少了常规。 所有这些都对工作以及业务产生积极影响，即使自动化在时间成本方面似乎没有意义。
事实上，几乎总是如此，而且在极少数情况下，SRE 的角色不应该自动化。 接下来我们就讲一下什么叫错误预算，错误的预算。 事实上，如果一切对你来说都比你为自己设定的 SLO 好得多，那么这也不是很好。 这是相当糟糕的，因为 SLO 不仅可以作为下限，还可以作为近似上限。 当你给自己设定一个 99% 可用性的 SLO 时，事实上你已经达到了 99,99%，那么事实证明你有一些实验的空间，而这些实验不会对业务造成任何损害，因为你自己已经确定了这一切，并且你是这个空间不使用。 你有一个错误预算，但在你的情况下，这个预算并没有用完。
我们用它做什么。 我们几乎将它用于所有事情。 用于在生产条件下进行测试、推出可能影响性能的新功能、发布、维护、计划停机。 相反的规则也适用：如果预算用完，我们就无法发布任何新内容，因为否则我们将超出 SLO。 预算已经用完，我们发布了一些东西，如果它对性能产生负面影响，也就是说，如果这不是某种本身直接增加 SLO 的修复，那么我们就超出了预算，这是一个糟糕的情况，需要对其进行分析、事后分析，可能还需要进行一些流程修复。
也就是说，事实证明，如果服务本身运行得不好，并且花费了 SLO，并且预算不是花在实验上，不是花在某些版本上，而是花在它本身上，那么就不是一些有趣的修复，而不是有趣的功能，而不是有趣的发布。 您将不得不处理愚蠢的修复以使预算恢复正常，或者编辑 SLO，而不是任何创造性的工作，这也是一个不应该经常发生的过程。
因此，事实证明，在我们有更多错误预算的情况下，每个人都会感兴趣：SRE 和开发人员。 对于开发人员来说，大量的错误预算意味着您可以处理发布、测试、实验。 对于 SRE 来说，制定错误预算并输入该预算意味着他们直接做好了自己的工作。 这会影响某种共同工作的动力。 如果您作为开发人员听取 SRE 的意见，您将有更多的空间进行良好的工作，并且减少例行公事。
事实证明，在大型团队中，生产中的实验非常重要，几乎是 SRE 不可或缺的一部分。 它通常被称为混沌工程，它来自 Netflix 团队，他们发布了一款名为 Chaos Monkey 的实用程序。
Chaos Monkey 连接到 CI/CD 管道并随机导致生产中的服务器崩溃。 同样，在 SRE 结构中，我们讨论的是这样一个事实：宕机的服务器本身并不坏，这是预料之中的。 而且如果在预算之内，也是可以接受的，不会损害业务。 当然，Netflix有足够的冗余服务器，足够的复制，因此这一切都可以修复，并且整个用户甚至不会注意到，更不用说任何人都会为任何预算留下一台服务器。
Netflix 有一段时间拥有一整套此类实用程序，其中一个 Chaos Gorilla 完全关闭了 Amazon 的一个可用区。 首先，当不完全清楚什么影响什么、什么依赖什么时，这些事情有助于揭示隐藏的依赖关系。 而这一点，如果您正在使用微服务，并且文档不太完善，那么您可能会熟悉这一点。 再说一遍，这有助于捕获代码中无法在分段中捕获的错误，因为任何分段都不完全是精确的模拟，因为负载规模不同，负载模式不同，设备不同。也很可能是其他。 峰值负载也可能是意外和不可预测的。 此类测试同样不会超出预算，有助于很好地捕获基础设施中的错误，而这些错误是分段、自动测试、CI / CD 管道永远无法捕获的。 虽然这一切都包含在你的预算中，但你的服务掉在那里并不重要，尽管看起来很可怕，服务器掉了，真是一场噩梦。 不，这很正常，这很好，有助于捕获错误。 如果你有预算，那么你就可以花掉它。
问：我可以推荐哪些文献？ 清单在最后。 有很多文献，我会建议一些报告。 它是如何工作的，SRE 在没有自己的软件产品或开发最少的公司中是否有效？ 例如，在一家主要业务不是软件的企业中。 在一个企业里，主要活动不是软件，SRE的工作原理和其他地方一模一样，因为在企业里你也需要使用，即使不是开发的软件产品，你需要推出更新，你需要改变基础设施，你需要成长，你需要扩展。 SRE 有助于识别和预测这些流程中可能出现的问题，并在一些增长开始和业务需求发生变化后控制这些问题。 因为如果您至少有一些服务器并且预计至少会有一些增长，那么绝对没有必要为了拥有 SRE 而参与软件开发。
小项目、小组织也是如此，因为大公司有预算和实验空间。 但同时，所有这些实验成果都可以在任何地方使用，那就是SRE，当然出现在Google、Netflix、Dropbox。 但与此同时，小公司和初创公司已经可以阅读浓缩材料、阅读书籍、观看报告。 他们开始更频繁地听到它，他们看具体的例子，我认为没关系，它真的很有用，我们也需要这个，这很棒。
也就是说，标准化这些流程的所有主要工作都已为您完成。 您仍然需要确定 SRE 在您公司中的具体角色，并开始实际实施所有这些实践，这些实践已经再次描述过。 也就是说，从对小公司有用的原则来看，这始终是 SLA、SLI、SLO 的定义。 如果您不涉及软件，那么这些将是内部 SLA 和内部 SLO，即错误的内部预算。 这几乎总是会在团队和业务内部引发一些有趣的讨论，因为事实可能是，您在基础设施、理想流程的某种组织、理想管道上的花费远远超出了必要的范围。 IT 部门拥有的这 4 个 XNUMX，您现在并不真正需要它们。 但与此同时，你可以把时间、预算花在其他事情上。
因此，监控和监控组织对于任何规模的公司都是有用的。 总的来说，这种思维方式，只要错误是可以接受的，只要有预算，只要有目标，对于任何规模的公司（从 3 人的初创公司开始）来说都是有用的。
最后要讨论的技术细微差别是监控。 因为如果我们谈论 SLA、SLI、SLO，如果不监控我们是否符合预算、是否符合我们的目标以及我们如何影响最终的 SLA，我们就无法理解。 我见过很多次监控是这样发生的：有一些值，例如向服务器发出请求的时间、平均时间或者向数据库发出的请求数。 他有一个由工程师确定的标准。 如果指标偏离标准，则会收到一封电子邮件。 一般来说，这绝对是无用的，因为它会导致警报过多，监控产生的消息过多，而人们首先必须每次都解释它们，即确定指标的值是否意味着需要采取一些行动。 其次，当基本上不需要他采取任何行动时，他只是不再注意到所有这些警报。 这是一个很好的监控规则，实施 SRE 时的第一条规则是只有在需要采取行动时才应发出通知。
在标准情况下，事件有 3 个级别。 有警报、有票证、有日志。 警报是任何需要您立即采取行动的事情。 也就是说，一切都坏了，你需要立即修复它。 门票是需要延迟行动的。 是的，你需要做一些事情，你需要手动做一些事情，自动化失败了，但是接下来的几分钟你不必做。 日志是任何不需要操作的东西，一般来说，如果一切顺利，没有人会阅读它们。 您只需要在回想起来时才需要阅读日志，结果发现某些东西已经损坏了一段时间，而我们并不知道。 或者你需要做一些研究。 但一般来说，不需要任何操作的所有内容都会记录到日志中。
作为所有这一切的副作用，如果我们定义了哪些事件需要采取行动，并很好地描述了这些行动应该是什么，这意味着该行动可以自动化。 也就是说，发生了什么。 我们从警戒状态出发。 让我们开始行动吧。 我们来看看这个动作的描述。 然后我们转向自动化。 也就是说，任何自动化都始于对事件的反应。
从监控，我们转向一个称为可观察性的术语。 在过去的几年里，这个词也受到了一些炒作。 很少有人断章取义地理解它的含义。 但要点是可观察性是系统透明度的一个指标。 如果出现问题，您能够多快地确定到底出了什么问题以及当时系统的状态。 就代码而言：哪个功能失败了，哪个服务失败了。 例如，内部变量、配置的状态如何。 就基础设施而言，这是在哪个可用区发生故障，如果有 Kubernetes，那么在哪个 Pod 中发生故障，Pod 的状态是什么。 因此，可观察性与 MTTR 有直接关系。 服务的可观察性越高，越容易识别错误、越容易修复错误、越容易自动化错误，MTTR 越低。
再次转向小公司，即使是现在，人们也很常见地问如何处理团队规模，以及小团队是否需要聘请单独的 SRE。 早些时候已经谈到过这一点。 在初创公司或团队发展的第一阶段，这完全没有必要，因为 SRE 可以充当过渡角色。 这将使团队稍微恢复活力，因为至少有一些多样性。 而且，它会让人们做好准备，随着增长，SRE 的职责总体上将会发生非常显着的变化。 如果你雇用一个人，那么他当然会有一些期望。 而且这些期望不会随着时间的推移而改变，但是需求会发生很大的变化。 因此，早期如何聘请SRE是相当困难的。 自己种植要容易得多。 但这值得思考。
也许唯一的例外是当存在非常严格且明确的增长要求时。 也就是说，对于初创公司来说，这可能是来自投资者的某种压力，某种对一次性增长数倍的预测。 那么聘请 SRE 基本上是合理的，因为它可以合理。 我们有成长的要求，我们需要一个对这样的成长负责的人，这样的成长不会破坏任何东西。
还有一个问题。 当开发人员多次削减通过测试的功能，但破坏生产、加载基础、破坏其他功能时该怎么办，要实施什么流程。 因此，在这种情况下，引入的是错误预算。 一些服务、一些功能已经在生产中进行测试。 它可以是金丝雀，当只有少量用户但已经在生产中时，部署了一项功能，但已经期望如果出现问题，例如，对于所有用户的 XNUMX%，它仍然会满足错误预算。 因此，是的，将会出现错误，对于某些用户来说，一切都会中断，但我们已经说过，这是正常的。
有一个关于 SRE 工具的问题。 也就是说，是否有一些特定的东西是 SRE 会使用而其他人不会使用的。 事实上，有一些高度专业化的实用程序，有某种软件，例如，模拟负载或从事金丝雀 A/B 测试。 但基本上，SRE 工具包是您的开发人员已经在使用的工具包。 因为SRE直接与开发团队交互。 如果您有不同的工具，那么同步就需要时间。 特别是如果 SRE 在大型团队中工作，在可能有多个团队的大公司中，公司范围内的标准化在这里会有很大帮助，因为如果 50 个团队使用 50 个不同的实用程序，这意味着 SRE 必须了解它们全部。 当然，这永远不会发生。 而且至少部分团队的工作质量、控制质量会大幅下降。
我们的网络研讨会即将结束。 我设法讲述了一些基本的事情。 当然，关于SRE的任何内容都不是一个小时就能讲完和理解的。 但我希望我能够传达这种思维方式和主要要点。 然后，如果有兴趣，就可以深入研究这个主题，自己学习，看看其他人、其他公司是如何实施它的。 因此，二月初，请来 Slurm SRE 与我们联系。
Slurm SRE 是一个为期三天的强化课程，会讲我现在讲的内容，但是深度要深得多，有真实案例，有实践，整个强化课程都是针对实际工作的。 人们将被分成小组。 你们都将从事真实案例的工作。 因此，我们有 Booking.com 的讲师 Ivan Kruglov 和 Ben Tyler。 我们有一位来自旧金山、来自 Google 的出色的尤金·巴拉巴斯 (Eugene Barabbas)。 我也会告诉你一些事情。 所以一定要来拜访我们。
所以，参考书目。 SRE 上有参考。 在同一本书上，或者更确切地说，在两本由 Google 编写的有关 SRE 的书上。 另一个 ，其中术语及其应用稍微详细一些。 接下来的3个是不同公司的SRE报告。 第一的 - ，这是来自 Google 的 Ben Trainer 的主题演讲。 第二 - 。 第三个又来了 。 第四次报告来自 ，该公司在 5 个国家/地区只有 190 名关键 SRE 员工。 看看这一切非常有趣，因为正如 DevOps 对于不同的公司甚至不同的团队意味着非常不同的事情一样，SRE 也有非常不同的职责，即使在规模相似的公司中也是如此。
关于混沌工程原理的另外 2 个链接： , 。 最后有 3 个来自《Awesome Lists》系列的列表 约 和关于 。 SRE 上的列表非常庞大，没有必要全部看完，大约有 200 篇文章。 我强烈推荐那里有关容量规划和无责备事后分析的文章。
有趣的文章：
谢谢你一直以来听我说话。 希望你学到了一些东西。 希望您有足够的材料来学习更多。 再见。 希望是二月。
该网络研讨会由爱德华·梅德韦杰夫主持。
PS：对于喜欢阅读的人，Eduard 给出了参考文献清单。 喜欢在实践中理解的人欢迎 .
来源： habr.com