什么是站点可靠性工程师?以及为何您应该考虑这条职业道路

如果您想要一个具有挑战性、市场需求高的职位,并且超越 DevOps,请考虑成为一名 SRE。
767 位读者喜欢这篇文章。
gears and lightbulb to represent innovation

Opensource.com

您是否正在寻找一份有趣且有竞争力的职业,让您亲身体验 DevOps 的全部力量,甚至更进一步?站点可靠性工程师的角色可能非常适合您。

什么是站点可靠性工程?

站点可靠性工程 (SRE) 诞生于 2003 年的 Google,早于 DevOps 运动,当时第一批软件工程师的任务是使 Google 已经大规模的站点更可靠、高效和可扩展。他们开发的实践非常好地响应了 Google 的需求,以至于其他大型科技公司,如亚马逊和 Netflix,也采用了它们,并带来了新的实践。

SRE 最终成为一个成熟的 IT 领域,旨在为运营方面开发自动化解决方案,例如随叫随到的监控、性能和容量规划以及灾难响应。它完美地补充了其他核心 DevOps 实践,例如持续交付和基础设施自动化。

“站点可靠性工程师通过将软件工程思维模式应用于系统管理主题,在开发和运营之间架起桥梁。”

Google 在一本书中描述了其经验和发现,即“站点可靠性工程 - Google 如何运行生产系统”,该书可在网上免费获取。该书介绍了强大的概念,如错误预算和服务级别目标,并描述了 Google 在自动化、处理紧急情况和事件、故障排除和监控、管理风险和构建可扩展系统方面的实践。它还讨论了诸如组织 SRE 团队和随叫随到职责等方面。

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

Google 工程副总裁兼 Google SRE 创始人 Ben Traynor 在此访谈中指出了 SRE 角色的本质

“SRE 从根本上来说是做历史上由运营团队完成的工作,但使用具有软件专业知识的工程师,并寄希望于这些工程师天生倾向于并且有能力用自动化代替人工劳动。一般来说,SRE 团队负责可用性、延迟、性能、效率、变更管理、监控、应急响应和容量规划。”

站点可靠性工程师通过将软件工程思维模式应用于系统管理主题,在开发和运营之间架起桥梁。他们将时间分配在运营/随叫随到职责和开发系统和软件之间,以帮助提高站点可靠性和性能。Google 非常强调 SRE 在运营上的时间不应超过 50%,并将任何违反此规则的行为视为系统状况不佳的迹象。

SRE 的最终目标是,正如 Google 所说,“通过自动化摆脱自己的工作。”实现这一目标的一个重要方法是为依赖其服务的用户群构建自助服务工具(例如,自动配置测试环境、日志和统计数据可视化)。这样做可以减少所有相关方正在进行的工作,使开发人员能够专注于功能开发,并让他们专注于下一个要自动化的任务。

SRE 与产品开发人员密切合作,以确保设计解决方案响应诸如可用性、性能、安全性以及可维护性等非功能性需求。他们还与发布工程师合作,以确保软件交付管道尽可能高效。

为了更好地了解在 Google 担任 SRE 意味着什么,请观看这五位 Google SRE 的证词

您应该考虑这条职业道路吗?

无论您在软件工程还是系统工程方面有什么背景,只要您在两者方面都有扎实的基础,并且有强烈的改进和自动化意愿,您都可以成为一名 SRE。如果您是一名系统工程师,并且想要提高您的编程技能,或者如果您是一名软件工程师,并且想要学习如何管理大规模系统,那么这个角色非常适合您。加深您在这两个领域的知识将为您提供竞争优势和未来的更大灵活性。

如果您像我一样是“持续改进的爱好者”,SRE 角色将使您获得系统全局视图:您将了解软件交付价值链如何运作,并知道如何确保敏捷性和可靠性并交付更多整体价值。这可能非常具有激励作用,并提供了一个展示您为组织带来的价值的理想职位。

也没有比这更好的角色来与 DevOps 世界的最新发展保持联系,并在基础设施自动化、发布工程和持续交付等高需求领域扩展您的知识和技能。您不太可能因为成为 SRE 而感到无聊。相反,这是一个极具创造性、刺激性和技术挑战性的角色。

最后但并非最不重要的一点是,由于 SRE 通常在高绩效科技公司中找到,这些公司拥有大型数据中心和复杂的技术挑战,因此他们的角色在财务和工作场所文化方面都可能令人鼓舞。另一个优点:Google 认为 SRE 是稀缺资源。

接下来阅读什么
标签
User profile image.
目前,我是一名独立的 DevOps、精益 IT 和敏捷顾问和培训师,我的大部分职业生涯都在科学领域度过,更准确地说是在 CERN,位于瑞士日内瓦的高能物理实验室,这里拥有世界上最大的质子加速器。在这里,我扮演了不同的开发、运营和协调角色,并获得了计算机科学博士学位。

1 条评论

感谢您对 SRE 角色及其比 DevOps 工程师更重要的价值的精彩解释。我只有一个考虑,或者无论如何是我个人的观点。专业人士的形象非常混合和熟练,因此在如此广泛的主题和应用中,一个人可能会冒着绑定或可能专注于单一技术堆栈或流程的风险,并使角色如此不同(或在共同意义上未明确定义),这取决于一个人工作的现实。对我来说,重要的是关注通用原则和方法,注意不要绑定到单个工具(这些工具在 IT 世界中总是不断变化的)。

Creative Commons License本作品根据知识共享署名-相同方式共享 4.0 国际许可协议获得许可。

下载终极 DevOps 招聘指南

通过这些针对潜在员工和招聘经理的最佳实践来构建您的 DevOps 团队。

© . All rights reserved.