SRE最佳模型

在谷歌，SRE代表网站可靠性工程师。现场可靠性是关于我们工程师的速度和生产力，我们产品的性能和可靠性，以及我们代码库和生产环境的健康。我不想说SRE是谷歌做运营的方式，因为SRE是对我们如何做运营的一个重要的反思。SRE是一个独立的组织，在谷歌是一个独立的筒仓。他们维护着谷歌的大型生产系统，他们是任何与生产相关的咨询团队的核心，他们制定了最佳实践，他们为使我们的软件工程师易于生产的基础和工具做出了贡献。

使谷歌SRE显著不同的不仅仅是他们世界级的专业知识，而是他们在谷歌是可选的。是的，我没有遗漏前一句中的否定。它们是可选的。当我们开始在一个新产品/项目上工作时，开发团队拥有每一个方面。从写设计文档到写代码。从单元测试到集成测试。我们要经过一系列的审查，从安全到隐私，再到生产准备。我们有责任部署我们的代码，监控它，随叫随到，并在需要时把水放在火上。我们都是自己做的，好像没有SRE或者我们是自己的SRE。
但是如果SRE是可选的，它是如何工作的呢？在谷歌工作为您提供了一套您一直认为理所当然的基础设施。网络、存储系统、锁系统、自动伸缩和调度、命名、配置等等。基础结构组件由软件工程师组成，通常由SRE支持。另一方面，SRE不是一个亲自帮助每个团队的组织，但他们构建可重用的最佳实践并支持关键的技术基础设施服务，从而使生产体验更好。SRE文化和最佳实践在谷歌非常成熟。您想部署一个可扩展到全球的生产服务吗？我们有基础设施帮助你。你想拥有世界级的仪表板吗？我们有那个。您是否需要一个计划并更好地理解应该如何监控代码？SRE对此有解决方案和最佳实践。您想推出一项新的关键服务吗？SRE为此提供咨询服务。

主要思想是SRE组织不负责支持谷歌的任何产品。您都可以免费获得infra和SRE最佳实践，并且通过成为一个关键的大规模产品，值得兼职和以后的全职SRE支持。获得SRE支持的平均时间表：

• 建立一个产品，与支持团队协调发布，如果需要，请SRE咨询。
• 设定一个SLO，一旦达到临界规模，试着招募兼职SRE支持。
• SRE团队将需要一个需求列表，直到您的产品适合他们的支持。一旦你满足了他们的标准，开始将SRE添加到你的随叫随到的轮换中。
• 随着规模的增长，通过使用员工人数来增加SRE支持。让您的开发团队兼职响应prod问题，这样他们仍然可以理解prod中发生的事情。
• 如果您的项目规模正在缩小，则缩减SRE支持，如果规模不需要SRE支持，则最终让开发团队拥有SRE工作。

该模型使SRE组织能够专注于可扩展的解决方案，而不是在没有影响的特定产品上投入大量时间。团队中SRE的人数来自开发团队的人数，因此如果开发团队规模不够大，无法请求额外的帮助，他们更愿意自己处理SRE工作。对于复杂系统和大型基础设施，SRE作为团队的一部分亲自在场。当他们学习时，他们也为谷歌所有工程团队可重用的基础设施、工具和知识做出了贡献。
但这能让每个人都行动吗？在谷歌，我们可能拥有世界上最好的基础设施来构建大规模系统。单个团队不必关心锁系统、数据库或我们的内部命名服务。内部基础设施配备工作人员，工作良好。最重要的是，我们有一个非常成熟的SRE文化，软件工程师可以作为SRE来思考和行动，直到它超出了他们的规模，只需要采用基本原理和现有的基础设施。该模型帮助软件工程师对操作方面有一个清晰的理解，并使SRE团队有机会以高度可持续的方式专注于有影响力的项目。我认为行业需要产品和红外工程之间的细分，并开始讨论我们如何配备红外团队和支持产品开发团队与SRE。如果没有这种分解，假设每个人都在为他们的infra，ops服务，“DevOps”对话通常是不完整的。