Site reliability engineering (SRE) 并不是一个新的术语或实践。在把 SRE 定义为一个职位名称之前，把软件工程技能和原则应用到运维领域早就已经付诸实践了。在组织层面落地 SRE，用更加积极主动的方式来构建和维护软件，可以推动一些方面的长期成功，比如提升运维效率、数据驱动的路线规划、整体稳定性达成。正是由于 SRE 的广泛采用，我们才得以获得这些优势。

在这篇文章中，我将深入探讨如何开始 SRE、如何在您自己的组织中采用它、SRE 的核心原则和最佳实践。

SRE 是什么？

SRE，即站点可靠性工程，是将软件工程专业知识应用于 DevOps 和运维问题的实践。通常，这意味着主动编写代码和开发内部应用程序或服务来解决可靠性和性能问题。SRE 已经实践多年，但最近在谷歌于 2016 年 3 月首次发布《网站可靠性工程：谷歌如何运行生产系统》时得到推广。

SRE 是一个复杂的首字母缩略词，因为它既涉及职位名称“站点可靠性工程师”，也涉及开发和 IT 团队采用的一般做法“站点可靠性工程”。SRE 团队的组织方式通常因组织及其支持的服务而异。有时，站点可靠性工程师 (SRE) 分散在开发团队中。这意味着 SRE 可以在产品里程碑的各个节点参与其中并发声，可以和 QA 团队密切合作，共同推动产品新 feature 上线。

另一种方法将 SRE 团队组织为一个独立的团队。SRE 团队作为一个整体，专注在如下方面：监控应用程序和基础设施、建立可靠性指标、跟踪新版本的问题和 OnCall 值班。无论如何组织，所有这些 SRE 保持不变的是他们的初衷——可靠性和性能。

DevOps 对比 SRE

或许你已经采用了 DevOps 实践，或许会困惑于 “SRE 和 DevOps 的区别是什么？” 通常，这两个术语是相辅相成的。SRE 是一种实践，不一定是 DevOps 文化的一部分，但是通常来讲，恰恰是那些深度实践 DevOps 的组织会去落地 SRE。从 DevOps 成熟度模型来看，越成熟的公司越会采用 SRE 实践。

我们要探讨的并非 SRE 和 DevOps 之间的较量，而是如何通过构建一个主动的 SRE 团队来强化 DevOps 实践。不论是把 SRE 打散在研发、IT团队，还是成立独立的 SRE BU，你都应该了解 SRE 团队的职责。

SRE 团队的职责

SRE 负责具体定义 App、服务、基础设施的 性能 和 可靠性。SRE 的日常任务范围广泛，从引入新的监控解决方案到为技术支持团队构建自定义应用程序。他们可能会将新代码上线以修复错误或提供新功能，或者他们可能会实时响应生产事件并与支持团队密切合作以提供积极的客户体验。

归根结底，通过 SRE 角色的努力，我们可以知道我们的客户/用户的确切的产品访问体验，可以通过客户的视角来得知我们的系统性能和可靠性。SRE 团队需要弄清楚开发团队发布的内容和客户体验之间的关系。从那里，他们需要找到监控可靠性和性能问题的方法，以帮助您的内部团队主动识别风险并交付更好的软件。

SRE 团队在产品和开发团队中传播知识，以一致地（形成共识的）定义整个组织的可靠性。当大家拉齐认知之后，工程团队就可以在发布新功能或改进当前生产体验之间做出数据驱动的决策。

SRE 运营和成熟度模型

您可以执行站点可靠性工程师要求的许多职责，并且仍然拥有软件工程师的岗位 Title。那么，您如何知道您的 SRE 实践有多成熟呢？幸运的是，我们将提供一种快速方法来构建有效的 SRE 操作模型并跟踪您的成熟度。SRE 操作模型通常包括三个元素，您可以分阶段实现这些元素：

• 致力于 SRE 实践的团队（或至少一个人）
• 可以和产品、开发和运营团队的深度协同并影响他们
• 自主为您的应用程序（或系统的几乎任何部分）提供自动化工作流程和编写代码

您的 SRE 成熟度取决于您的组织在 SRE 运营模型的这三个要素中所处的位置。如果您已采取步骤组建 SRE 团队或聘请了您的第一位站点可靠性工程师，那么您就处于旅程的开始。如果你有一个团队，并且他们是路线图讨论、QA、部署工作流程、事件管理流程的重要组成部分，那么你就有了一个比较成熟的 SRE 实践。

只有当 SRE 业务部门拥有自动化工作流程、构建应用程序、拥有监控和警报解决方案或将自己插入几乎任何对话的自主权时，组织才会达到完全的 SRE 成熟度。提前表达性能和可靠性问题并积极讨论这些问题总是比简单地忽略它们要好，直到为时已晚。

监控、CI/CD 和组织自动化

站点可靠性工程师可以并将几乎所有事情自动化。如果它可以主动检测、补救或解决问题，则需要实现自动化。从持续集成和交付实践到生产环境监控，SRE 应该对所有这些都有一定的了解。如果他们能够找到主动发现性能和可靠性问题的方法，那么他们就需要有权实施这些更改。

今天围绕自动化、监控、人工智能和机器学习的 DevOps 和 IT 能力为 SRE 团队在识别问题、响应和修复问题时提供了巨大的优势。拥有成熟的 DevOps 和 SRE 实践的组织可以在 staging 阶段发现问题，他们还可以构建自动化的事件管理工作流和自愈系统。通过确定应用程序和基础架构中的关键组件，SRE 可以缩小那些可能导致重大线上问题的因素的范围。

Service Levels 的实践（SLI、SLO 和 SLA）

Service Levels 可以帮助 SRE 团队向所有利益相关者传达数字产品和服务的真正健康状况。这是通过识别和度量那些影响客户体验的关键模块来完成的。特别是，SRE 得知道哪些组件向外部客户直接提供功能。我们称这些交点为系统边界。系统边界是 SRE 应用 SLI 和 SLO 的地方，据此反映真实的系统性能和可靠性。

• Service-level indicators (SLIs) 是确定系统可用性的关键指标
• Service-level objectives (SLOs) 是您为系统的可用性设置的目标
• Service-level agreements (SLAs) 是合法的协约承诺，用于解释当系统无法满足 SLO 的时候会发生什么

虽然 SRE 并不总是负责管理 Service Levels，但这通常属于他们的职权范围。通过跟踪 SLI 并将它们与 SLO 绑定，您可以围绕系统性能设定目标。谷歌的 SRE 书籍将 Service Level 的四个黄金指标定义为延迟、流量、错误和饱和度。因此，举例来说，您可以查看 API 调用并跟踪其成功/失败请求的数量 (SLI) 以及客户获得良好体验所需的一般请求百分比 (SLO)。

SRE 团队通常会在其应用程序和服务中的关键组件上设置严格的 SLO，以更好地了解 SLA 可以定义为多少。团队可以应用错误预算来了解他们必须以多快的速度解决问题以保持符合他们的 SLO。服务级别允许团队汇总指标并创建整个组织的正常运行时间、性能和可靠性的透明视图。一目了然，业务领导者可以使用 Service Levels 来监控多个团队、应用程序、服务等的健康状况。

采用 SRE 最佳实践

采用 SRE 最佳实践和原则不会一蹴而就。监控您的团队负责的系统的性能和可靠性，确实需要花费很多时间和努力。但是，最终，您的 DevOps 团队，尤其是您的客户将感谢您决定利用站点可靠性工程实践。

本文机翻自：https://devops.com/how-to-adopt-an-sre-practice-when-youre-not-google/

告警风暴、告警漏报的烦恼

SRE 必须要做好监控，我们观察到很多公司都搭建了不止一套监控系统（Zabbix、Prometheus、Open-Falcon、Nightingale、云监控、Grafana），人员信息、告警事件散落在各个系统里，经常会遇到告警风暴、告警漏报的问题，我们提供 FlashDuty 告警事件 OnCall 中心的产品，可以做到告警聚合降噪、排班、认领、升级、协同、和钉钉/飞书/企微丝滑打通，快来免费注册试用吧：https://console.flashcat.cloud/。