在我们 之前的一篇文章中，我们讨论了什么是 SRE、它们做什么，以及典型的 SRE 可能承担的一些共同责任，如支持操作、处理故障票和事件响应以及一般系统监控和可观察性。 在本文中，我们将更深入地探讨站点可靠性工程师在其角色中实践的各种 SRE 原则和准则。 与 DevOps 一样，这些 SRE 原则也有助于推动与组织目标的对齐、会议和支持。
谷歌是第一家创建、拥抱和支持网站可靠性工程的公司。 自那时以来，随着行业的变化，SRE 的角色也发生了变化，从传统的单一结构转变为分布广泛的大型网络和微服务。 然而，有一件事基本上保持不变——SREs坚持的原则。 这些核心 SRE 原则侧重于一件事：驾驶系统和服务可靠性。 让我们更深入地探讨这些核心 SRE 原则。
SRE 原则
拥抱和管理风险
接受风险是 SRE 原则的首要原则，这是有充分理由的。 为了提高系统的可靠性，重要的是要衡量”如果”故障的影响。 据了解，没有系统是百分之百可靠的。 在某个时间点，会出问题。 不幸的是，日常用户或客户不知道，或关心，是如此理解。 并且，确保可靠性具有固有的成本。 无论是财务成本、时间成本，还是客户对服务的信心。
SREs 的责任是陷入失败和风险，以便了解他们最终如何能够使其服务和系统更具弹性。 但是，需要考虑一些权衡。 例如，确保最大可靠性可能以能够更快速地部署未来服务为代价。 或者，进一步的改善并不一定意味着收入的大幅增长？ 目标是建立一个可靠的系统，但不超过它所需要的，因为与这样做相关的成本和时间超过了潜在的好处。
服务级别目标
接受风险的原则与服务级别对象（SLOs）密切相关。 更深入一点，SLOs 是服务级别协议 （SLA） 中根据服务级别指标（SLIs）衡量的正式目标集。 SLIs 是您服务的实际绩效指标。 例如，如果您的 SLO 指出您的启动时间必须为 99.9%，则实际 SLI 必须满足或超过该性能指标才能满足该特定 SLO。 SLIs 是 SRE 将持续监控的指标，因此，如果 SRE 超过该阈值，团队就会被提醒，问题可以快速解决。 SLIs 与用户紧密相连，以确定哪些内容对其体验最重要，因为它与服务相关。
斯拉斯 vs. 斯洛斯 vs. 斯莱
- 斯拉。 与客户或客户签订的协议定义了将要交付的服务水平。
- SLOs. SLA 中的一项协议，其中规定了特定指标，如启动时间、响应时间、安全性、问题解决等。
- SLIS. 决定合规性水平的 SLO 的实际性能或测量。
SLA 用于根据 SLA 衡量实际绩效，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 30 天的试用， 或安排与我们的性能工程师之一的 演示 。
