👉️URL: https://www.dynatrace.com/news/blog/what-is-site-reliability-engineering/
✍️Author: Saif·Gunja
📝Description:
Site reliability engineering is a fundamental part of today’s DevOps frameworks. Here’s what you need to know about SRE. Learn what SREs do!
随着越来越多的组织采用基于云的计算和对数字服务的需求增加，站点可靠性工程（SRE） 实践变得至关重要。这些做法可帮助组织满足可用性、性能、用户体验和业务 KPI 方面的服务级别协议 （SLA）。
但究竟什么是 SRE，站点可靠性工程师是做什么的？
什么是站点可靠性工程？
站点可靠性工程 （SRE） 是将软件工程原则应用于运营和基础架构流程以帮助组织创建高度可靠和可扩展的软件系统的实践。作为一门学科，SRE 专注于提高关键类别的软件系统可靠性，包括可用性、性能、延迟、效率、容量和事件响应。执行相关任务的人员称为站点可靠性工程师。
“站点可靠性工程”一词是由谷歌工程副总裁 Ben Sloss 在 2003 年创造的，他在 LinkedIn 个人资料中指出，“如果谷歌停止工作，那就是我的错。”根据 谷歌 的说法，“当你把运维视为软件问题时，SRE 就是最优解。”
尽管每个组织和软件系统都是独一无二的，但在考虑如何优化软件的可靠性和整体质量时，了解 SRE 的基础知识以及工程师的技能和思维方式非常重要。
关于站点可靠性工程的五件事
1. SRE 专注于自动化
SRE 的一个主要目标是尽可能减少重复或冗余工作。SRE 团队专注于自动执行手动任务，例如预配访问和基础结构、设置帐户以及构建自助服务工具。这使开发团队能够专注于交付功能，而运营团队可以专注于管理基础架构。
随着组织加快将新功能交付到生产中的速度，自动化流程变得更加重要。一方面，速度来自 DevOps 团队，他们利用自动化来增加持续集成和持续交付 （CI/CD）。另一方面，向微服务架构的转变以及云原生技术、容器、Kubernetes 和无服务器架构的采用提供了更多更快地交付较小更改的方法。这些方法提高了效率和速度，但也要求一致、可重复的流程来降低风险，并为衡量运营提供反馈回路，以便团队可以确定需要改进的领域。
2. SRE 弥合了开发和运维之间的鸿沟
组织在价值流过程中所做的一切都应该回答这样一个问题：“我们如何确保它在生产中可靠地运行？”SRE 推动了基于弹性的工程设计。他们可以成为导师，并确保弹性是开发人员和运营的重中之重。
将 DevOps 思维模式和技能应用于软件可靠性有助于减少开发和运营团队之间的孤岛，方法是在开发生命周期的早期分担检测可靠性和性能问题的责任。开发人员、运营人员和产品所有者之间的协作使站点可靠性工程师能够定义并满足正常运行时间和可用性目标。
3. SRE 推动“左移”思维模式
SRE 是一个不断发展的学科，它提供了将方法、策略和流程构建到交付管道中的机会，这些管道允许应用程序“自动修复”或用户解决自己的问题。左移思维模式意味着 SRE 可以将从开发到运营的可靠性原则嵌入到每个流程、应用和代码更改中，以提高投入生产的软件的质量。
以下是 SRE 帮助推动“左移”思维模式的一些方法：
- 根据生产级服务等级目标 （SLO）开发质量门限，以便在开发周期的早期检测问题。
- 使用服务等级指标 （SLI） 和 SLO 自动执行构建测试和验证
- 在初始设计阶段影响架构决策，以确保软件开发开始时的弹性和规模。
目标是尽早采取积极主动的措施，以确保从一开始就内置质量和可靠性。SRE 可以更广泛地影响流程，并扩展到协调整个企业的测试，以支持 CI/CD 实践。
4. SRE 构建服务和工具来帮助运营和支持
传统上，运营团队的一个主要目标是提高正常运行时间。这种单维方法寻找令人垂涎的“五个九”的正常运行时间，即 99.999%，这意味着每年只有五分多钟的停机时间。
但是，分布式云原生环境中的更高变化频率需要多维方法。
SRE 的目标是在保持弹性的同时实现更高的变更率，从而实现令人垂涎的 99.999% 正常运行时间。在多云环境中，弹性是通过多个关键指标（如性能、用户体验、响应能力、转化率等）来衡量的。为了实现他们的目标，SRE 团队需要构建和实施服务，以改善运营并促进所有这些领域的发布过程。这可以是任何事情，从调整监视和警报到在生产中进行代码更改。站点可靠性工程师通常从头开始构建自定义工具，以满足软件交付或事件管理工作流程中的特定需求。
采用 SRE 方法还需要对团队使用的技术和工具进行标准化。标准化使管理运营变得更加容易，并减轻了管理不兼容技术的负担，从而使团队有更多时间进行协作和创新。
5. SRE 需要文化变革
由于 SRE 是一种实践，因此它需要改变跨多个学科的团队进行沟通、解决问题和实施解决方案的方式。要采用成功的 SRE 文化，组织必须采用新的方法来管理风险。这也意味着他们必须调整治理流程，投资于招聘，并培养精通工程和运营并快速学习和适应的协作员工队伍。
然后，组织可以在 DevOps 生命周期的关键点集成这些熟练的工程师。在开发和测试团队中，SRE 专家开发自动化功能，帮助开发人员尽早测试，并且通常不会妨碍敏捷的交付计划。在系统级别，SRE 专家开发工具来协调发布和启动，评估系统体系架构准备情况，并满足系统范围的 SLO 要求。在治理级别，SRE 专家帮助定义和监督企业体系架构，建立最佳实践，并选择支持公司范围站点可靠性的工具和资源。
站点可靠性工程师是做什么的？
为了获得专家对站点可靠性工程师工作的看法，我问了我们的 DevOps 活动家安迪·格拉布纳。
“站点可靠性工程师使用软件工程方面的良好实践，为其组织和实际交付新应用程序的人员提供弹性基础设施和弹性服务，”他解释说。他还指出，SRE 通常来自传统的运营角色，例如保持系统正常运行的系统工程师。“站点可靠性工程师确保系统保持可靠、弹性和可用性。”他补充道。
SRE 现状报告
我们邀请了各行各业的 450 家 SRE，分享了他们对站点可靠性工程 （SRE） 如何演变为一门学科的未经过滤的观点。该报告揭示了 SRE 必须克服的挑战，以及 SRE 的未来。
State of SRE Report: 2022 Edition - Full version | Dynatrace
对 SRE 的典型期望
通常，SRE 的任务是确保交付速度不会导致安全性、服务或解决方案中断。但正如 Grabner 所指出的那样，“每家公司的期望都有点不同。没有黄金法则。许多人负责监控和可观察性，并维护系统，并提供自动化来启动所需的环境。
Grabner 强调了 SRE 在为服务和应用程序部署提供框架和平台方面的作用。“当事情出错时，如果有警报，SRE 通常会扮演一线后卫的角色，”他说。“在一个伟大的组织中，他们不是独自完成的 - 他们不断与各个应用程序团队合作并在各个应用程序团队内部工作，以处理受到攻击的应用程序。
SRE 最重要的作用也许是构建复原能力。“你不能买弹性即服务，”Grabner 观察到。“你必须通过构建具有弹性设计的系统来构建它。这种架构方法最近帮助 Dynatrace 抵御了德国的 AWS 中断。自动交付、复原和自动修复有助于确保关键系统不受影响。
是什么造就了一个伟大的 SRE？
优秀的 SRE 是冒险家，修补者和创新者。他们弄清楚了如何将系统从 100 个用户扩展到 100，000 个用户，再到 1，000，000 个用户，同时保持正常运行时间和弹性。他们是系统思想家，他们考虑在开发过程中做出的决策如何影响生产环境，以及生产系统的需求如何影响设计。
这需要不断测试，接受故障，并在此过程中适应和自动化可重复的流程。成功的 SRE 为每种情况带来弹性和适应性思维。
格拉布纳强调，SRE 需要从错误中吸取教训。“一些公司运行’混乱日’来处理最坏的情况，以了解可能发生的事情以及如何应对它，”他说。
自动化是 SRE 成功的另一个标志。“当人们试图自动化所有可以并且必须自动化的任务时，他们在这个角色中表现出色，”Grabner 说。“这让他们能够腾出时间进行真正的创新。他指出，虽然任何人都可以在适当的情况下进行创新，但团队往往受到手动和重复性任务的“辛苦”的阻碍。“你的目标是让自己从目前的职位上自动化到下一个职位。
最后，格拉布纳明确表示，SRE 不能孤立地运行。“你需要让人们用新技术和实践来教育自己，”他说。“向世界展示。不要保守秘密 - 保持开放，分享自己的经验，以及向他人学习。有很多很棒的会议 - 值得从别人的所作所为中获得灵感，并用你所做的事情激励他人。
DevOps 团队专注于简化变更，而 SRE 有助于确保这些变更不会增加总体故障率。实际上，它们是同一枚硬币的两面：DevOps 自动化了速度，而 SRE 自动化了可靠性。“这是速度和安全性之间的平衡，”Grabner 说。
他认为 DevOps 流程是在整个开发生命周期中从左到右移动，使用自动化来加速新功能，这些功能通常由部署频率和更改的提前期来衡量。相比之下，SRE 使用开发中的生产级需求从右向左移动，重点是限制故障率和减少恢复服务所需的时间。“SRE 是关于确保即使有很多变化，这些变化也不会破坏事情。
格拉布纳认为，当涉及到 SLO 时，SRE 和 DevOps 是重叠的。“SLO 都是为了支持业务目标，”他说。“公司可能需要可靠性达到 99% 的系统。他们可能希望增加用户群或改善最终用户体验。满足这些目标是 DevOps 的作用。“但这些目标的背后是特定于您的目标的技术目标，”他说。“他们在正确的时间通过正确的功能为业务成功做出贡献，并帮助您应对变化。实现这些目标是 SRE 员工的工作。因此，“SLO 是将 DevOps 和 SRE 结合在一起的好方法。
解决站点可靠性问题
网站可靠性不是，也永远不会是一个“已解决的问题”。新的服务和应用程序与不断变化的企业需求相结合，意味着 SRE 团队总能工作，而且总有改进的余地。
正如 Grabner 所指出的那样，在提高 SRE 影响力方面，“最重要的是要开放并分享自己的经验，以及向他人学习。有很多很棒的会议 - 值得从别人的所作所为中获得灵感，并用你所做的事情激励他人。他还强调需要从错误中吸取教训。“一些公司运行’混乱日’来处理最坏的情况，以了解可能发生的事情以及如何应对它。最后，格拉布纳明确表示，SRE 不能孤立地运行。“你需要让人们用新技术和实践来教育自己。向世界展示。不要保守秘密，不要把它看成是一个孤岛。
