SRE 这种模型是 Google尝试着从根本上避免产生这种矛盾的结果。SRE 团队通过雇佣软件工程师，创造软件系统来维护系统运行以替代传统模型中的人工操作。

SRE 究竟是如何在 Google起源的呢? 其实我的答案非常简单∶SRE就是让软件工程师来设计一个新型运维团队的结果。当我在 2003年加入 Google 的时候，我的任务就是领导一个由7名软件工程师组成的"生产环境维护组"。当时，我的整个职业生涯都专注于软件工程，所以很自然，我按照自己最习惯的工作方式和管理方式来组建了这个团队。时过境迁，当年的7人团队已经成长为公司内部1000余人的SRE团队，但是 SRE 团队的指导理念和工作方式还是基本保持了我最初的想法。

SRE方法论中的主要模块，就是SRE团队的构成。每个SRE团队里基本上有两类工程师。第一类，团队中 50%~60% 是标准的软件工程师，具体来讲，就是那些能够正常通过Google软件工程师招聘流程的人。第二类，其他 40%~50% 则是一些基本满足 Google 软件工程师标准（具备 85%~99% 所要求的技能），但是同时具有一定程度的其他技术能力的工程师。目前来看，UNIX系统内部细节和1~3 层网络知识是 Google最看重的两类额外的技术能力。

除此之外，所有的SRE 团队成员都必须非常愿意、也非常相信用软件工程方法可以解决复杂的运维问题。Google一直密切关注这两类候选人在招聘通过之后在SRE团队中的表现，但是到目前为止还没有发现他们在工作上和成绩上的显著差异。事实上，由于两类工程师技术背景互补，SRE 团队经常能够寻找到全新的、高效的解决问题的方法。

按照这个标准来招聘和管理 SRE 团队，我们很快发现 SRE 团队成员具有如下特点∶
（a） 对重复性、手工性的操作有天然的排斥感。
（b）有足够的技术能力快速开发出软件系统以替代手工操作。

同时，SRE团队和产品研发部门在学术和工作背景上非常相似。因此，从本质上来说，SRE 就是在用软件工程的思维和方法论完成以前由系统管理员团队手动完成的任务。这些 SRE 倾向于通过设计、构建自动化工具来取代人工操作。

SRE 模型成功的关键在于对工程的关注。如果没有持续的、工程化的解决方案，运维的压力就会不断增加，团队也就需要更多的人来完成工作。传统的 Ops团队的大小基本与所服务的产品负载呈线性同步增长。如果一个产品非常成功，用户流量越来越大，就需要更多的团队成员来重复进行同样的事情。

为了避免这一点，负责运维这个服务的团队必须有足够的时间编程，否则他们就会被运维工作所淹没。因此，Google为整个SRE 团队所做的所有传统运维工作设立了一个50%的上限值。传统运维工作包括∶工单处理、手工操作等。设立这样一个上限值确定了SRE 团队有足够的时间改进所维护的服务，将其变得更稳定和更易于维护。这个上限值并不是目标值。随着时间推移，SRE 团队应该倾向于将基本的运维工作全部消除，全力投入在研发任务上。因为整个系统应该可以自主运行，可以自动修复问题。我们的终极目标是推动整个系统趋向于无人化运行，而不仅仅是自动化某些人工流程。当然，在实际运行中，服务规模的不断扩张和新功能的上线已经让 SRE 够忙了!

Google的经验法则是，SRE团队必须将 50%的精力花在真实的开发工作上。那么我们是如何确保每个团队都是这样做的呢?首先，我们必须不断地度量每个团队的工作时间分配。依靠这个数据，SRE管理层会对在开发工作上投入时间不够的团队进行调整。通常，管理层会要求该团队将一些常见的运维工作交还给产品研发部门操作，或者从产品研发部门抽调人力参与团队轮值值班工作。此外，还可以停止该SRE 团队的一切新增运维工作。只有管理层主动维护每个SRE 团队的工作平衡，我们才能保障他们有足够的时间和精力去进行真正有创造性的、自主的研发工作，同时，这也保障了SRE 团队有足够的运维经验，从而让他们设计出切实解决问题的系统。

我们发现 Google SRE 模型在运维大规模复杂系统时有很多优势。由于SRE 在调整Google系统的过程中常常直接参与开发、修改代码，SRE文化在公司内部基本代表了一种快速、创新、拥抱变化的文化。实践证明，SRE团队运行、维护、改进一个复杂系统所需要的成员数量与系统部署规模呈非线性增长。而运维同样的系统，用传统的系统管理员模型维护则需要更多数量的人。最后，SRE 模型不仅消除了传统模型中研发团队和运维团队的冲突焦点，反而促进了整个产品部门水平的整体提高。因为SRE 团队和研发团队之间的成员可以自由流动，整个产品部门的人员都有机会学习和参与大规模运维部署活动，从中获得平时难以获得的宝贵知识。普通的开发人员有多少机会能将自己的程序同时跑在 100 万个 CPU 的分布式系统上呢?

虽然 SRE 模型带来了一些优势，但也存在一些问题。Google面对的一个持久性的难题就是如何招聘合适的SRE。首先SRE要和产品研发部门招聘传统的软件开发工程师竞争。其次，由于SRE 要求同时具备多项技能，市场上具有相关从业背景和经验的人就更少了。由于SRE 模型也比较新，行业内关于如何建立和维护SRE 团队的相关信息并不多。（本书希望能为改变这种情况而努力。）最后，SRE 团队建立之后，由于SRE 模型中为了提高可靠性需要采取一些与常规做法违背的做法，所以需要强有力的管理层支持才能推行下去。例如∶由于一个季度内的错误预算耗尽而停止发布新功能的决定，可能需要管理层的支持才能让产品研发部门重视起来。

SRE 这种模型是 Google尝试着从根本上避免产生这种矛盾的结果。SRE 团队通过雇佣软件工程师，创造软件系统来维护系统运行以替代传统模型中的人工操作。

SRE 究竟是如何在 Google起源的呢? 其实我的答案非常简单∶SRE就是让软件工程师来设计一个新型运维团队的结果。当我在 2003年加入 Google 的时候，我的任务就是领导一个由7名软件工程师组成的"生产环境维护组"。当时，我的整个职业生涯都专注于软件工程，所以很自然，我按照自己最习惯的工作方式和管理方式来组建了这个团队。时过境迁，当年的7人团队已经成长为公司内部1000余人的SRE团队，但是 SRE 团队的指导理念和工作方式还是基本保持了我最初的想法。

SRE方法论中的主要模块，就是SRE团队的构成。每个SRE团队里基本上有两类工程师。第一类，团队中 50%~60% 是标准的软件工程师，具体来讲，就是那些能够正常通过Google软件工程师招聘流程的人。第二类，其他 40%~50% 则是一些基本满足 Google 软件工程师标准（具备 85%~99% 所要求的技能），但是同时具有一定程度的其他技术能力的工程师。目前来看，UNIX系统内部细节和1~3 层网络知识是 Google最看重的两类额外的技术能力。

除此之外，所有的SRE 团队成员都必须非常愿意、也非常相信用软件工程方法可以解决复杂的运维问题。Google一直密切关注这两类候选人在招聘通过之后在SRE团队中的表现，但是到目前为止还没有发现他们在工作上和成绩上的显著差异。事实上，由于两类工程师技术背景互补，SRE 团队经常能够寻找到全新的、高效的解决问题的方法。

按照这个标准来招聘和管理 SRE 团队，我们很快发现 SRE 团队成员具有如下特点∶
（a） 对重复性、手工性的操作有天然的排斥感。
（b）有足够的技术能力快速开发出软件系统以替代手工操作。

同时，SRE团队和产品研发部门在学术和工作背景上非常相似。因此，从本质上来说，SRE 就是在用软件工程的思维和方法论完成以前由系统管理员团队手动完成的任务。这些 SRE 倾向于通过设计、构建自动化工具来取代人工操作。

SRE 模型成功的关键在于对工程的关注。如果没有持续的、工程化的解决方案，运维的压力就会不断增加，团队也就需要更多的人来完成工作。传统的 Ops团队的大小基本与所服务的产品负载呈线性同步增长。如果一个产品非常成功，用户流量越来越大，就需要更多的团队成员来重复进行同样的事情。

为了避免这一点，负责运维这个服务的团队必须有足够的时间编程，否则他们就会被运维工作所淹没。因此，Google为整个SRE 团队所做的所有传统运维工作设立了一个50%的上限值。传统运维工作包括∶工单处理、手工操作等。设立这样一个上限值确定了SRE 团队有足够的时间改进所维护的服务，将其变得更稳定和更易于维护。这个上限值并不是目标值。随着时间推移，SRE 团队应该倾向于将基本的运维工作全部消除，全力投入在研发任务上。因为整个系统应该可以自主运行，可以自动修复问题。我们的终极目标是推动整个系统趋向于无人化运行，而不仅仅是自动化某些人工流程。当然，在实际运行中，服务规模的不断扩张和新功能的上线已经让 SRE 够忙了!

Google的经验法则是，SRE团队必须将 50%的精力花在真实的开发工作上。那么我们是如何确保每个团队都是这样做的呢?首先，我们必须不断地度量每个团队的工作时间分配。依靠这个数据，SRE管理层会对在开发工作上投入时间不够的团队进行调整。通常，管理层会要求该团队将一些常见的运维工作交还给产品研发部门操作，或者从产品研发部门抽调人力参与团队轮值值班工作。此外，还可以停止该SRE 团队的一切新增运维工作。只有管理层主动维护每个SRE 团队的工作平衡，我们才能保障他们有足够的时间和精力去进行真正有创造性的、自主的研发工作，同时，这也保障了SRE 团队有足够的运维经验，从而让他们设计出切实解决问题的系统。

我们发现 Google SRE 模型在运维大规模复杂系统时有很多优势。由于SRE 在调整Google系统的过程中常常直接参与开发、修改代码，SRE文化在公司内部基本代表了一种快速、创新、拥抱变化的文化。实践证明，SRE团队运行、维护、改进一个复杂系统所需要的成员数量与系统部署规模呈非线性增长。而运维同样的系统，用传统的系统管理员模型维护则需要更多数量的人。最后，SRE 模型不仅消除了传统模型中研发团队和运维团队的冲突焦点，反而促进了整个产品部门水平的整体提高。因为SRE 团队和研发团队之间的成员可以自由流动，整个产品部门的人员都有机会学习和参与大规模运维部署活动，从中获得平时难以获得的宝贵知识。普通的开发人员有多少机会能将自己的程序同时跑在 100 万个 CPU 的分布式系统上呢?

虽然 SRE 模型带来了一些优势，但也存在一些问题。Google面对的一个持久性的难题就是如何招聘合适的SRE。首先SRE要和产品研发部门招聘传统的软件开发工程师竞争。其次，由于SRE 要求同时具备多项技能，市场上具有相关从业背景和经验的人就更少了。由于SRE 模型也比较新，行业内关于如何建立和维护SRE 团队的相关信息并不多。（本书希望能为改变这种情况而努力。）最后，SRE 团队建立之后，由于SRE 模型中为了提高可靠性需要采取一些与常规做法违背的做法，所以需要强有力的管理层支持才能推行下去。例如∶由于一个季度内的错误预算耗尽而停止发布新功能的决定，可能需要管理层的支持才能让产品研发部门重视起来。