在我们 之前的一篇文章中，我们讨论了什么是 SRE、它们做什么，以及典型的 SRE 可能承担的一些共同责任，如支持操作、处理故障票和事件响应以及一般系统监控和可观察性。 在本文中，我们将更深入地探讨站点可靠性工程师在其角色中实践的各种 SRE 原则和准则。 与 DevOps 一样，这些 SRE 原则也有助于推动与组织目标的对齐、会议和支持。
谷歌是第一家创建、拥抱和支持网站可靠性工程的公司。 自那时以来，随着行业的变化，SRE 的角色也发生了变化，从传统的单一结构转变为分布广泛的大型网络和微服务。 然而，有一件事基本上保持不变——SREs坚持的原则。 这些核心 SRE 原则侧重于一件事：驾驶系统和服务可靠性。 让我们更深入地探讨这些核心 SRE 原则。
SRE 原则
拥抱和管理风险
拥抱风险实际上是 SRE 的核心原则之一，原因很容易理解。为了使系统更可靠，您必须考虑 “假设” 场景并从潜在故障中吸取教训。没有系统是 100% 可靠的，在某些时候，肯定会出问题。不幸的是，大多数用户不知道（或特别关心）这一现实。他们只是希望一切正常，而实现这种可靠性总是需要付出代价的，无论是在金钱、时间，甚至是维护客户信任方面。
对于 SRE 来说，防范风险和从失败中吸取教训对于构建弹性系统至关重要。但总是需要权衡取舍。最大限度地提高可靠性可能意味着放慢新功能的步伐，或者可能会导致更多成本，而不会大幅增加收入。我们的想法并不是让系统比实际需要的更可靠。毕竟，如果额外的努力和资源没有增加有意义的价值，那么它们最好花在其他地方。在 SRE 中，一切都是为了找到平衡成本、速度和价值的“恰到好处”的可靠性级别。
服务级别目标
承担风险的原则与服务级别目标 （SLO） 密切相关。具体来说，SLO 是服务等级协议 （SLA） 中的特定性能目标，根据服务等级指标 （SLI） 进行衡量，SLI 是跟踪服务执行情况的实际指标。例如，如果您的 SLO 规定正常运行时间应为 99.9%，则 SLI 会衡量您是否达到该目标。这些 SLI 由 SRE 持续监控，因此如果性能低于商定的阈值，团队会收到警报并可以快速响应。SLI 归根结底是关于对用户最重要的事情，帮助团队确定直接影响用户体验的服务方面的优先级。
以下是这些术语的快速细分：
- SLA：与客户或客户就要提供的服务级别达成的总体协议。
- SLO：SLA 中的特定性能目标，例如正常运行时间、响应时间或安全标准。
- SLI：跟踪 SLO 合规性的实际性能度量。
从本质上讲，SLO 允许团队根据 SLA 衡量实际性能，从而对服务质量设定明确的期望。这种结构强化了对风险的约定容忍度，定义了服务在满足用户需求和业务目标的同时可以承受多少可变性或停机时间。
阅读： 了解有关在组织内 管理 SLA 合规的 更多内容。
消除辛劳
Toil 与 SRE 角色的范围一起定义，是确保服务运行所需的手动工作量。 SRE 的主要目标之一是实现尽可能多的工作自动化。 这使得 SREs 为更重要的任务打开更多时间。 当你想到它，减少辛劳真的应该是任何人工作的一部分。 从长远来看，冗余任务所需的时间越少，生产率就越高。 每当站点可靠性工程师必须从事重复的人工活动时，由于它与管理生产服务有关，这可以描述为辛劳。
在很多情况下，SRE 可能会进行人工的、耗时的活动，但并非所有活动都应定义为辛劳。 但是，确定 SRE 团队中的哪些活动消耗的时间最多是关键。 从那里，确定在哪里可以作出改进，以减少辛劳量，以更好地平衡工作。 当谷歌首次引入SRE角色时，他们设定了一个目标，即在SRE时间的一半时间应该集中在减少未来的运营工作或增加服务功能上。 开发新功能与提高可靠性和性能等指标相关，最终减少潜在的辛勤劳作。
监测
在 Dotcom-Monitor，我们致力于 监控跟踪 服务器、网站、服务和应用程序的运行时间、可用性、功能和全面性能的解决方案。 监控是角色中最重要的 SRE 原则之一。 持续监控可确保服务按预期执行，并有助于识别问题出现时，以便立即修复。 正如我们在上一节中提到的，满足这些 SLOs 是定义的业务 SLA 以及最终用户的关键。 监控可以为 SREs 和团队提供历史绩效趋势，并能够深入了解什么是一次性问题与更广泛的系统性问题。 根据 Google SRE 计划定义，监控的四个黄金信号包括以下指标：
- 延迟。 延迟是服务响应请求所需的时间或延迟。 显然，响应时间缓慢会影响感知到的用户体验。 监控可以提供一种区分的方法
- 交通。 流量是指系统上的用户需求量或负载量。 这可以通过每秒 HTTP 请求或根据实际服务进行测量
- 错误。 错误是指对服务请求失败的速度。 但是，SRE 团队必须区分硬故障（如 500 个服务器错误）和软故障（例如由于设置了特定的性能阈值而超时的 200 OK 响应）。 重要的是要考虑如何适当地监控这些不同的场景。
- 饱和度 。 饱和度是测量给定服务拥有多少系统资源。 到一定程度，大多数服务将经历绩效下降。 了解这种情况发生的位置有助于正确定义监控目标和目标，从而可以采取纠正行动。
自动化
自动化，自动化，自动化。 我们早些时候在讨论减少辛劳时谈到了这一原则，但不能低估这一原则。 SRE 角色的性质与角色一样多样化。 为了减少其职责各个方面的人工干预潜力，自动化任务是成功企业的关键。 随着服务规模和分布的扩大，管理变得更加困难。 全面自动化重复任务，无论是测试、软件部署、事件响应，还是团队之间的简单沟通，自动化都提供了立竿见影的好处、效率，最重要的是一致性。 自 SRE 角色构思以来，开发、QA 和运营团队的协作方式发生了转变。 为了支持这些新的 DevOps 环境和实践，开发了各种平台和工具。
阅读： 前 13 名站点可靠性 （SRE） 工具。
释放工程
释放工程。 听起来像是一个复杂的主题，但在现实中，它只是一个简单的方法来定义软件是如何构建和交付的。 虽然发布工程本身就是它自己的标题和角色，但在 SRE 的概念中，这意味着提供稳定、一致、当然可重复的服务。 这要追溯到上一节关于自动化。 如果你要做某事，做对了，并能够再次重复，在一致的方式，在必要时。 建立一堆一次性服务是耗时的，并创造了不需要的辛劳。
如果我们回到谷歌SRE职位的历史，他们有专门的发布工程师谁直接与SREs合作。 发布工程师通常负责定义最佳实践，因为它涉及到开发软件服务、部署更新、持续测试和解决软件问题，此外还有许多其他职责。 当您考虑如何扩展服务并快速部署服务时，此角色变得更加重要。 拥有一套最佳实践和工具（并实施这些做法和工具）对于满足这些需求至关重要，并且一旦该构建投入生产，SRE 团队就会安心。
单纯
具有讽刺意味的是，由于像SRE角色这样的责任和期望似乎并没有结束，最后一个原则是简单。 也许说起来容易做起来难，这个原则侧重于开发一个系统或服务的想法，这个系统或服务只是必要的复杂。 虽然这起初似乎有悖常理，但归根结底，它确实需要一个可靠、一致和可预测的系统。 这听起来可能很无聊， 但对 Sre 说， 这是最终目标之一。
SREs 努力寻求一个不复杂或难以管理的系统或服务。 SREs 想要一个能够完成其设计的工作的人。 然而，从用户的角度来看，提供大量功能的服务也可能提供很多好处，但对 SRE 而言，这意味着更多的潜在头痛。 但是，如果您想要在 Web 服务中添加新功能，更改总是不可避免的，请深思熟虑。 较小的增量更改比一次构建和运输大量功能更容易（更简单）管理。 SREs 还必须考虑业务的需求和目标。
SRE 原则：7 条基本规则 – 最终想法
SRE 的作用侧重于大规模构建、交付和维护可靠的系统和服务。 这七项核心原则有助于定义 SREs 的实践，这些实践有助于推动 DevOps 实践中的一致性，并支持业务目标。 这是一个复杂的角色，旨在平衡可靠性与功能发布，同时保持卓越的质量水平。
Dotcom-Monitor 平台为 SREs 提供所需的所有监控 功能 ，确保其服务的连续性。 从可配置的警报和报告到实时仪表板和报告，该平台提供了长期管理其所有服务绩效所需的必要工具。 例如，根据用户行为、操作和路径创建 Web 应用程序脚本，并设置 合成监控 任务，以确保随着时间的推移获得一致的体验。 无论您的团队需要什么级别的监控，都有满足您需求的解决方案。
免费开始使用 Dotcom-Monitor 免费试用 版，或与我们的一位性能工程师安排 演示 。
