IT团队一直在寻求采用SRE方法。站点可靠性工程正在采用操作实践并将其移交给软件工程师，以实现人工任务、问题解决和系统管理的自动化。SRE团队负责服务的变更管理、应急响应、监控、可用性、性能、延迟、效率和容量规划，通常为流程自动化编写软件。

SRE是软件可靠性和可扩展性的重要资产，因为系统可以通过代码进行管理——在确保产品和功能可靠与发布新产品和功能之间取得平衡。

什么是SRE？

换个角度来看，站点可靠性工程是传统IT角色或系统管理角色与DevOps相遇的地方。在传统的IT环境中，组织可能有一个系统管理员团队来管理复杂的系统。重点和责任是确保正确部署软件并向最终用户提供可靠的服务。此外，他们的职责包括管理任何问题或软件部署后发生的问题。

但是，系统管理员并不专注于实际的软件开发，这是开发和系统管理员角色可能发生冲突的地方。开发人员专注于生产软件并将其交到用户手中，而不一定关心软件部署的方面或效果。正是在这个节点上，站点可靠性工程师的角色发挥了作用。站点可靠性工程师专注于创建可扩展且可靠的软件系统，因此这还包括确保开发工作高效且可靠，因此当成品准备好投入生产时，没有惊喜。

站点可靠性工程师做什么？

站点可靠性工程涉及在运营和开发之间划分时间。例如，站点可靠性工程师可能会参与帮助台工单、待命事件、手动任务等。除此之外，站点可靠性工程师还可能将时间花在主动项目上，例如自动化、提高系统可靠性等，试图减少手动工作量并确保保持软件部署实时所需的所有组件（基础架构/硬件、中间件、软件等）高效运行。

SRE基本规则

拥抱和管理风险

拥抱风险是SRE的首要原则，这是有充分理由的。为了提高系统的可靠性，衡量“假设”故障的影响非常重要。据了解，没有任何系统是100%可靠的。在某个时间点，有些事情会出错。不幸的是，日常用户或客户不知道也不关心如此理解。并且存在与确保可靠性相关的固有成本。这是否意味着财务成本、时间成本，或者仅仅是客户对您服务的信心。

SRE的职责是了解失败和风险，以了解他们如何最终使他们的服务和系统更具弹性。但是，有一些权衡需要考虑。例如，确保最大可靠性可能是以能够更快地部署未来服务为代价的。或许进一步的改进并不一定意味着收入的大幅增长？我们的目标是打造一个可靠的系统，但不会超出它的需要，因为这样做的成本和时间超过了潜在的收益。

服务水平目标

拥抱风险的原则与服务级别对象或SLO密切相关。更深入地说，SLO是服务水平协议(SLA)中的一组正式目标，这些目标是根据服务水平指标或SLI来衡量的。SLI是服务的实际性能指标。例如，如果您的SLO规定您的正常运行时间必须为99.9%，则实际SLI必须达到或超过该性能指标才能满足该特定SLO。SLI是SRE将持续监控的指标，因此，如果它超出该阈值，则会向团队发出警报并且可以快速解决问题。SLI确实与用户相关联，用于确定对他们的体验最重要的内容，因为它与服务相关。

SLA与SLO与SLI

• 服务协议，与您的客户或客户达成的协议，定义了将要提供的服务水平。
• SLO，SLA中规定特定指标的协议，例如正常运行时间、响应时间、安全性、问题解决方案等。
• SLI，确定合规级别的SLO的实际性能或测量值。

SLO用于根据SLA衡量实际性能，SLA是服务提供商和客户之间的协议。同样，这一切都回到了这样一种想法，即需要就给定服务可以允许多少风险或容忍度达成一致或理解。

消除辛劳

正如SRE角色的范围所定义的那样，是确保服务运行所需的手动工作量。SRE的主要目标之一是尽可能多地自动化工作。这允许SRE为更重要的任务腾出更多时间。仔细想想，减少劳动力确实应该成为任何人工作的一部分。从长远来看，冗余任务所需的时间越少，可确保更高的生产力。每当站点可靠性工程师必须从事与管理生产服务相关的重复性手动活动时，这都可以称为辛勤工作。

在很多情况下，有时SRE必须执行手动的、耗时的活动，但并非所有这些都应该被定义为辛勤工作。然而，定义SRE团队中哪些活动最耗时是关键。从那里，确定可以在哪些方面进行改进以减少工作量，从而更好地平衡工作。

监控

监控是角色中最重要的SRE原则之一。持续监控可确保服务按预期执行，并有助于识别问题出现的时刻，以便立即修复。就像我们在上一节中提到的，满足这些SLO是定义业务SLA的关键，最终也是用户的关键。监控可以为SRE和团队提供性能的历史趋势，并可以洞察什么是一次性问题与更广泛的系统性问题。监控的四个黄金信号包括以下几个指标：

• 延迟，延迟是服务响应请求所花费的时间或延迟量。显然，缓慢地响应时间会影响感知的用户体验。监控可以提供一种区分
• 交通，流量是指系统上的用户需求量或负载量。这可以通过每秒的HTTP请求数或取决于实际服务来衡量
• 错误，错误是指对服务的请求失败的速率。但是，对于SRE团队来说，区分硬故障（例如500个服务器错误）和软故障（例如由于设置了特定的性能阈值而超时的200OK响应）非常重要。考虑如何适当地监控这些不同的场景是很重要的。
• 饱和度，饱和度是关于测量给定服务拥有多少系统资源。到一定程度，大多数服务器都会出现性能下降。了解发生这种情况的位置有助于正确定义监控目标和指标，从而可以采取纠正措施。

自动化

为了减少在其职责的各个方面进行人工干预的可能性，自动化任务是业务成功的关键。随着服务的扩展和变得更加分散，管理也变得更加困难。全面自动化重复性任务，无论是测试、软件部署、事件响应，还是简单的团队之间的沟通，自动化提供了直接的好处、效率，最重要的是，一致性。自从构想SRE角色以来，开发、质量保证和运营团队的协作方式发生了转变。为了支持这些新的DevOps环境和实践，

发布工程

听起来像是一个复杂的主题，但实际上，它只是一种定义软件构建和交付方式的简单方法。虽然发布工程本身就是它自己的头衔和角色，但在SRE的概念中，这意味着提供稳定、一致且当然可重复的服务。这可以追溯到上一节关于自动化的内容。如果你打算做某事，那就把它做好，并且能够在必要时以一致的方式再次重复。构建一堆一次性服务既费时又费力。

简单

具有讽刺意味的是，对于SRE角色的职责和期望的数量似乎没有尽头的职位，最后一个原则是简单。在实践中说起来容易做起来难，这个原则侧重于开发一个系统或服务的想法，该系统或服务只在必要时变得复杂。虽然一开始这似乎违反直觉，但归根结底是想要一个可靠、一致和可预测的系统。这听起来可能很无聊，但对于SRE来说，这是最终目标之一。

SRE力求提供不复杂或难以管理的系统或服务。SRE想要一个简单地完成其设计工作的人。但是，从用户的角度来看，提供很多功能的服务可能也会提供很多好处，但对于SRE来说，这只是意味着更多潜在的头痛。但是，如果您想向Web服务添加新功能，更改总是不可避免的，请谨慎行事。与第一次构建和交付大量功能相比，管理较小的增量更改更容易（也更简单）。SRE还必须考虑业务的需求和目标。

常见的SRE职责

实际的SRE职责因公司而异，但在大多数情况下，SRE或SRE团队负责其服务产品的所有方面，并且可能需要以下一项、全部或多项职责：容量规划、可用性、表现、监控、事件响应、待命支持、事后反思。

因此，如您所见，SRE角色往往是多面手。前一分钟SRE可能正在AWS中配置存储，下一分钟SRE可能必须与客户交谈或为新项目编写一些Python代码。

SRE常用工具

站点可靠性工程师使用的工具和软件解决方案可能因组织而异。主要原因之一是在较大的组织中，SRE团队中通常会有更多的人员，因此，每个SRE的职责和范围将在团队之间进行划分，从而产生更加集中的角色。反过来，这也会减少他们使用的工具和平台的范围。因此，例如，在更大的企业组织中，SRE可能每天都在Jenkins中工作。

另一方面，较小组织中的站点可靠性工程团队或个人可能不得不戴上更多的帽子，因为人员可能会受到限制，因此，他们的工具集必须包括从配置管理平台和自动事件响应系统到监控的所有内容和分析工具。您可能已经熟悉SRE使用的一些工具，例如Docker、Terraform、Prometheus和Kibana。