网络研讨会的声音不好，因此我们将其解密。
我叫爱德华·梅德韦杰夫。 今天，我将讨论什么是SRE，SRE的外观，SRE工程师的工作标准，可靠性标准，监控情况。 我们将上楼，因为您在一小时内不会告诉您太多信息，但是我会提供进一步熟悉的材料，我们都在Slerm SRE等着您。 一月底在莫斯科。
首先，让我们谈谈SRE-网站可靠性工程的全部意义。 以及它如何作为一个单独的位置，一个单独的方向出现。 一切始于以下事实：在传统开发圈中，Dev和Ops是两个完全不同的团队，通常具有两个完全不同的目标。 开发团队的目标是推出新功能并满足业务需求。 Ops团队的目标是一切正常，不间断。 显然，这些目标彼此直接矛盾：为了一切正常工作，没有什么坏事，尽可能少地推出新功能。 因此，该方法（现在称为DevOps）正试图解决许多内部冲突。
问题在于我们对DevOps的定义不明确，对DevOps的实现也不明确。 我在2年前在叶卡捷琳堡举行的一次会议上发表讲话，到目前为止，DevOps部分的开头是“什么是DevOps”。 在2017年，dev诞生了将近10年，但我们仍然争论它是什么。 这是Google几年前试图解决的非常奇怪的情况。
2016年，Google发行了名为《网站可靠性工程》的书。 实际上，SRE运动就是从这本书开始的。 SRE是在特定公司中实施DevOps范例的特定选项。 SRE工程师为自己设定了确保可靠系统性能的目标。 它们主要来自开发人员，有时还来自具有强大开发背景的管理员。 他们正在做系统管理员以前做过的事情，但是在代码方面对系统的开发和知识的丰富了解导致这些人不倾向于日常管理工作，而是倾向于自动化。
事实证明，SRE团队中的DevOps范例是通过解决结构问题的SRE工程师来实现的。 这就是人们已经讨论了8年的Dev与Ops之间的紧密联系。 SRE的角色在某种意义上类似于架构师的角色，而SRE的新手则没有。 人们在职业生涯的开始还没有任何经验，没有必要的知识广度。 因为SRE需要非常准确的知识，确切地知道什么时候出错。 因此，这里通常需要公司内部和外部的一些经验。
他们询问是否将描述SRE和devop之间的区别。 她刚刚被描述。 我们可以谈谈SRE在组织中的位置。 与传统的DevOps方法不同，SRE是开发团队的一部分，在经典的DevOps方法中，Ops仍然是一个独立的部门。 他们参与产品开发。 甚至有一种方法，其中SRE是从一个开发人员转移到另一个开发人员的角色。 他们以与UX设计人员，开发人员本身以及有时与产品经理相同的方式参与代码审查。 SRE在同一级别上工作。 我们需要他们的更新，我们需要他们的审查，因此对于每个SRE部署来说，它都说：“嗯，这个部署不会对该产品的可靠性产生负面影响。 如果确实如此，那么在某种程度上。” 我们还将讨论这一点。
因此，SRE拥有否决更改代码的权利。 通常，如果SRE实施不正确，这也会导致某种小冲突。 在有关站点可靠性工程的同一本书中，许多部分，甚至没有一部分，讲述了如何避免这些冲突。
他们询问SRE与信息安全之间的关系。 SRE不直接参与信息安全。 基本上，在大型公司中，个人，测试人员和分析师都可以这样做。 但是SRE在某种意义上也与它们交互，因为某些影响安全性的操作，某些提交，某些部署也可能影响产品的可用性。 因此，SRE总体上可以与任何团队（包括安全团队，包括分析师）进行交互。 因此，大多数SRE在尝试实现DevOps时都是必需的，但与此同时，开发人员的负担却太大了。 也就是说，开发团队本身已无法应对现在他们也需要对Ops负责的事实。 并且出现一个单独的角色。 此角色已在预算中计划。 有时，此角色取决于团队的规模，出现一个单独的人，有时成为开发人员之一。 因此，第一个SRE出现在团队中。
受SRE影响的系统复杂性，影响工作可靠性的复杂性是必要且随机的。 必要的复杂性是当产品的复杂性增加到新产品功能所需的程度时。 随机复杂度是指系统的复杂度增加时，但是产品功能和业务需求不会直接影响这一点。 事实证明，开发人员在某个地方犯了一个错误，或者算法不是最佳的，或者引入了一些额外的兴趣，这些兴趣增加了产品的复杂性而没有特殊需要。 一个好的SRE应该总是切断这种情况。 也就是说，应该阻止由于随机添加而导致复杂性增加的任何提交，任何部署，任何拉取请求。
问题是，为什么不只聘请工程师，团队中有很多知识的系统管理员。 有人告诉我们，作为工程师的开发人员并不是最佳的人员配备解决方案。 担任工程师角色的开发人员并不一定总是最佳的人员配备解决方案，但这里的要点是，与Ops打交道的开发人员对自动化有更多的渴望，为实现这种自动化需要更多的知识和技能。 因此，我们不仅减少了任何特定操作的时间，不仅减少了例行工作，还减少了重要的业务参数，例如MTTR（平均恢复时间，恢复时间）。 因此，不久以后，我们将为组织节省资金。
现在让我们谈谈SRE工作的标准。 首先是可靠性。 在小型公司（初创公司）中，人们经常会认为，如果服务编写得当，产品编写得当且正确，那么它将起作用，并且不会损坏。 就是这样，我们编写了不错的代码，所以没有什么可打破的。 代码很简单，没有什么坏处。 这些人都是说我们不需要测试的人，因为，看，这是三种VPI方法，为什么要破坏它。
当然，这都是错误的。 这些人在实践中经常会咬这样的代码，因为事情会中断。 事情有时会以最不可预测的方式崩溃。 有时人们会说不，这永远不会发生。 这一切都发生了。 它经常发生。 因此，没有人为实现100％的可用性而奋斗，因为从未发生过100％的可用性。 这是常态。 因此，当我们谈论服务的可用性时，我们总是谈论“九”。 2个9、3个9、4个9、5个9。 如果将其转换为停机时间，例如5个9，则每年停机时间超过5分钟，而2 9个停机时间为3.5天。
但是很明显，在某些时候，POI（投资回报率）会下降。 从两个9减少到三个9，这意味着将停机时间减少了3天以上。 从四个9减少到五个，每年可将停机时间减少47分钟。 事实证明，对于企业而言，这可能并不重要。 通常，所需的可靠性不是技术问题，首先是业务问题，而是产品问题。 产品用户可以接受什么程度的停机时间，他们期望什么，他们要支付多少钱，例如，他们损失了多少钱，系统损失了多少钱。
在这种情况下，一个重要的问题是其余组件的可靠性如何。 因为在具有2个9的可靠性的智能手机上看不到4个和5个9的差异。 粗略地说，如果您的服务中的智能手机每年发生故障10次，则很可能是在OS端发生了8次故障。 用户已经习惯了这一点，并且不会每年关注一次。 有必要将增加可靠性和增加利润的价格联系起来。
仅在有关SRE的书中，就有一个很好的例子，即从3个9增加到4个9。 事实证明，可用性的提高略低于0.1％。 如果服务收入为每年100万美元，那么收入增加额为900美元。 如果将可访问性提高九倍，每年花费我们不到900美元，则这种增加在财务上是有意义的。 如果它每年花费超过900美元，那就不再有意义了，因为收入增长根本无法补偿劳动力成本，资源成本。 而三个九就足够了。
当然，这是所有查询都相等的简化示例。 从3个9转换为4个9是很容易的，但是同时，例如，从2个9转换为3已经节省了9000美元，这在财务上是有意义的。 自然，实际上，注册请求的失败比显示页面的失败更糟糕；请求的权重不同。 从业务的角度来看，它们可能具有非常不同的标准，但是通常，如果我们不讨论任何特定服务，则这是一个相当可靠的近似值。
当选择服务的体系结构解决方案时，我们遇到一个问题，即SRE是否是协调者之一。 让我们假设已集成到现有基础架构中，因此不会损失其稳定性。 是的，SRE对拉取请求，提交，发布具有相同的影响，它们会影响体系结构，引入新服务，微服务以及引入新解决方案。 为什么在我说我需要经验，我需要资格之前，为什么要说？ 实际上，SRE是任何体系结构和软件解决方案中的阻碍声音之一。 因此，作为工程师的SRE首先应该不仅了解而且还要了解任何特定的解决方案将如何影响可靠性，稳定性，并了解其与业务需求的关系，以及从什么角度来看。它是允许的，什么都不是。
因此，现在我们只可以讨论可靠性标准，在SRE中传统上将其定义为SLA（服务水平协议）。 最有可能是一个熟悉的术语。 SLI（服务水平指示器）。 SLO（服务水平目标）。 服务水平协议可能是一个具有里程碑意义的术语，尤其是如果您使用过网络，提供商，托管服务。 这是一个一般性协议，描述了整个服务的性能，罚款，对错误的一些惩罚，指标和标准。 SLI本身就是可用性指标。 也就是说，可能是SLI：服务响应时间，错误数（以百分比表示）。 如果涉及某种文件托管，这可能是带宽。 如果我们谈论的是识别算法，那么指标可能甚至是答案的正确性。 SLO（服务水平目标）是SLI指标，其值和期间的组合。
假设SLA可以像这样。 全年有99.95％的时间提供服务。 或每季度3小时内关闭99张重要支持票。 或每个月的1.5秒内将答复85％的请求。 也就是说，我们逐渐了解到错误和故障是完全正常的。 这是可以接受的情况，我们正在计划中，甚至在某种程度上都可以指望它。 也就是说，SRE构建的系统可能会出错，应该对应该考虑到错误的错误做出正常响应。 并且如果可能的话，他们应该以用户不会注意到或注意到的方式来处理错误，但是由于存在一些变通办法，因此一切都不会完全掉下来。
例如，如果您将视频上传到YouTube，但YouTube无法立即对其进行转换，如果视频太大，如果格式不是最佳格式，则请求自然不会过期，YouTube不会出现502错误，YouTube会说：“我们都创建了，您的视频正在处理中。 它将在大约10分钟内准备就绪。” 这是适度降级的原理，例如，如果您曾经这样做过，则在前端的开发中很熟悉。
我们将要讨论的以下术语对于MTBF和MTTR是非常重要的，它们对于可靠性，错误，期望值的工作非常重要。 MTBF是两次故障之间的平均时间。 MTTR平均恢复时间，平均恢复时间。 也就是说，从检测到错误开始，到错误出现为止，到服务完全恢复正常为止，已经花费了多少时间。 MTBF通常是通过提高代码质量来固定的。 也就是说，SRE可以拒绝。 您需要整个团队的理解，即当SRE说“不”时，他说这不是因为他有害，不是因为他不好，而是因为每个人都会受苦。
同样，有很多文章，很多方法，很多方法，即使在我经常提到的那本书中，也要介绍如何防止其他开发人员开始讨厌SRE。 另一方面，MTTR正在您的SLO（服务水平目标）上工作。 这主要是自动化。 例如，因为我们的SLO每季度的正常运行时间为4个9。 这意味着在3个月内我们可以允许13分钟的停机时间。 事实证明，MTTR不能超过13分钟。 如果我们对至少1个停机时间做出了13分钟的反应，则意味着我们已经用完了该季度的全部预算。 我们正在打破SLO。 对于汽车来说，反应和修复故障需要13分钟，但对于一个人来说却很少。 因为只要警报响起，一个人就会做出反应，直到他理解错误为止，这已经是几分钟了。 直到一个人了解如何解决它，确切地解决什么，该做什么，然后再花几分钟。 实际上，即使您只需要重启服务器（事实证明是这样）或提升新节点，则手动MTTR大约需要7-8分钟。 在使流程自动化时，MTTR通常会达到一秒，有时甚至是一毫秒。 Google通常会谈论毫秒，但实际上，当然情况并非如此。
理想情况下，SRE应该几乎完全自动化其工作，因为它直接影响MTTR，其指标，整个服务的SLO，从而影响业务的利润。 如果超过时间，请问我们是否应该归咎于SRE。 永远，没有人应该责备。 这是一种称为无香的死后分离的文化，我们今天不再讨论，但我们将对Slurme进行分析。 这是一个非常有趣的话题，可以谈论很多。 粗略地讲，如果超过了四分之一的分配时间，那么每个人都应归咎于一点点，这意味着归咎于每个人都没有生产力，让我们代之以，也许不归咎于任何人，而是要纠正这种情况并利用我们现有的能力进行工作。 以我的经验，这种对大多数车队，尤其是俄罗斯车队的做法有些陌生，但它是有意义的，并且效果很好。 因此，我将建议在本文的末尾以及可以在该主题上阅读的文献。 或来Slurm SRE。
我会解释。 如果超出了每季度的SLO时间，那么停机时间不是13分钟，而是15分钟，那么谁应该对此负责呢？ 当然，应该责怪SRE，因为他显然进行了某种错误的提交或部署。 数据中心的管理员可能对此负责，因为也许执行了一些计划外的维护。 如果要归咎于数据中心管理员，则应归咎于协调SLO时未计算维护费用的Ops人员。 经理，技术总监或签署数据中心合同但没有注意SLA数据中心并非针对所需停机时间而设计的事实应归咎于此。 因此，这种情况应归咎于每个人。 这意味着在这种情况下责怪任何人都没有道理。 但是，当然，您需要修复它。 因此，有验尸。 而且，例如，如果您阅读Github的验尸报告，在每种情况下，这都是一个非常有趣，小巧而又出乎意料的故事，那么您可以取代没有人说要怪这个人。 罪恶感总是分配给特定的不完善过程。
让我们继续下一个问题。 自动化技术 当我在其他情况下谈论自动化时，通常会参考一个表，该表告诉您可以将任务自动化的时间长短，以免花费比通常节省的时间更多的时间来自动化任务。 有一个障碍。 , SRE - , , , MTTR. , , , . . , , .
, , SRE - . , error budget, . , , SLO, , . , SLO , . SLO 99% , 99,99%, , , , , . , .
. . , , , , maintenance, . : , , SLO. , - , , , - , SLO, , , , , - .
, , , SLO , - , , - , , . - , , SLO, , .
, , , : SRE, . , , , . SRE , . - . SRE , .
, SRE . chaos ingeneering, , , c Chaos Monkey.
Chaos Monkey CI/CD . , SRE , – , . , . , , , , , .
- , , Chaos Gorilla, . , -, , , , . , , , . , , , - , , , , , . . , , , , , CI/CD . , , , , , , , . , , , . , .
: ? . , . , SRE . , , . , , SRE , , , , , , , . SRE , - . , SRE, - .
, , . , SRE , , . , , . , , , , , , .
, . SRE , . , , SLA, SLI, SLO. , SLA SLO, . - , , , - , , . 4 , IT , . , - .
. , - , , Objectives, , 3 .
, , . SLA, SLI, SLO, , , Objectives, SLA. , : - , , . . , -. , , , , , -, , : - . -, , . , SRE , , .
3 . , , . – , . , , , . – , . , - , - , , . – , , , . , - - , . - . , , .
, , , , , . , . . . . . , .
, Observability. . , . , Observability . - , , , . : , . , , , . , - Kubernetes, , . Observability MTTR. Observability , , , , MTTR.
, , , , SRE. . , , , SRE . , - . , , -, SRE . , , , - . , . SRE . . .
, , , . - , - . SRE, -, , . , , , .
. , , , , , , . . , . canary, , , , - , , , . , , , , .
SRE. , - , SRE, . - , - , , , canary A/B . SRE , . SRE . , , . SRE , , , , 50 50 , , SRE . . , .
. - . , SRE . , , . , , , , , , . SRE.
SRE — , , , , , , . . . Booking.com . , . - . .
, . SRE. , 2 SRE, . SLA, SLI, SLO , . 3 SRE . – Keys to SRE , . — SRE . SRE . SRE , 5 SRE 190 . , DevOps , SRE , .
2 chaos ingeneering: (1) , (2) . 3 Awesome Lists chaos ingeneering , SRE SRE . SRE , , 200 . capacity planning blameless postmortem.
: SRE as a life choice
, . , - . , , . . .
.
PS：对于那些喜欢阅读的人，Edward提供了一份参考书目。SlörmeSRE欢迎那些喜欢在实践中理解的人。