| 2022-04-03
Photo by ThisisEngineering RAEng on Unsplash
一直以来，IT企业总是雇佣系统管理员来运行复杂的系统。
这种系统管理员方法涉及构建现有的软件组件，并将它们部署到一起以生成服务。然后，系统管理员的任务是运行服务，并在事件和更新发生时做出响应。
随着系统复杂性和通信量的增加，事件和更新的发生率也相应增加，系统管理员团队需要扩大，以承担额外的工作。
服务管理的 sysadmin 模型有几个优点：
- 对于决定如何运行和配置服务的公司来说，这种方法相对容易实现：作为一个熟悉的行业示例，有许多示例可以学习和模仿。
- 相关人才库已经广泛可用。
- 一组现有的工具、软件组件（现成的或非现成的）和集成公司可以用来帮助运行这些组装好的系统，因此新手系统管理员团队不需要重新发明轮子，从头开始设计系统。
系统管理员方案的直接和间接成本
系统管理员和随之而来的开发/运维分离，有许多缺点和陷阱。这些成本大致分为两类：直接成本和间接成本。
直接成本既不微妙也不含糊。
随着服务和/或服务流量的增长，与依靠手动干预进行变更管理和事件处理的团队一起运行服务变得昂贵，因为团队的规模将不可避免地随着系统产生的负载而扩大。
间接成本却不容易量化
开发/运营部门的间接成本可能很小，但通常比直接成本贵。这些成本是由于两个团队在背景、技能和激励方面的巨大差异造成的。他们使用不同的词汇来描述情况；他们对技术解决方案的风险和可能性有不同的假设；他们对产品稳定性的目标水平有不同的假设。群体之间的划分很容易不仅成为一种激励，而且成为一种沟通、目标，最终是信任和尊重。
因此，传统的运维团队及其产品开发部门经常陷入冲突，最明显的是软件发布到生产环境上的速度。
开发团队的核心目标是推出新功能，并希望它们能被用户采用。基本上，运维团队希望确保在手持寻呼机时，服务不会中断。由于大多数停机时间都是由某种变更引起的，比如新配置、新功能发布或新用户的使用访问，这两个团队的目标从根本上来说是紧张的。
谷歌的解决方案：网站可靠性工程师（ Site Reliability Engineers）
2003年，Benjamin Treynor Sloss 加入了谷歌。他的首要任务之一，就是被要求管理一个由七名工程师组成的“生产环境团队（Production Team）”。
在此之前，他之前的工作经验是软件工程。因此，如果他担任 SRE ，他会按照自己希望的方式设计和管理团队。自那以后，这个团队已经发展成熟，成为谷歌现在的 SRE 团队，这一团队目前仍旧忠于这位终身软件工程师所设想的原始目的。
SRE 就是当你要求软件工程师设计一个运维团队时，所发生的事情
SRE 团队的组成
谷歌服务管理方式的主要组成部分就由每个 SRE 团队的组成。总体而言，SRE 可分为两大类。
- 50-60 % 的人是谷歌软件工程师，他们是通过谷歌软件工程师的标准程序聘用的。
- 另外 40-50% 的应聘者也非常接近谷歌软件工程资格，同时拥有一套对 SRE 有用，但对大多数软件工程师来说很少用的技术技能。
到目前为止，UNIX 系统内部知识和网络专业知识是他们寻求的两种最常见的替代技术技能。
所有 SRE 的共同点是，他们都有通过开发软件系统，来解决复杂问题的信念和能力。
在 SRE 内部，他们密切跟踪了这两个群体的职业发展。到目前为止，他们还没有发现工程师在这两个领域的实际表现存在差异。事实上，SRE 团队有不同的背景，这通常会产生一些智能且高质量的系统，这显然是多种技能组合的产物。
谷歌为招聘 SRE 所用的方法，最终的结果就是，他们最终拥有这样一个团队：
- 会很快对使用手工方式完成任务感到厌倦
- 具备编写软件以取代以前手工工作所需的技能，即使解决方案很复杂，也是一样。
SRE 最终会与其他开发组织分享了学术和知识背景。因此，SRE基本上是在做原来运维团队所做的工作，但其方式是启用具有软件专业知识的工程师，并基于这些工程师固有的使用软件设计和实施自动化的能力，来设计和实施自动化的能力。
SRE团队是如何管理的？
通过设计，SRE团队必须专注于工程化。如果没有持续的工程化，运维工作负担将增加，团队将需要更多的人来跟上工作量的增长。最终，传统的以运维为中心的团队将随着服务的规模线性增长：如果服务支持的产品成功，运给养负担将随着流量的增长而增加。这意味着雇佣更多的人一次又一次地执行相同的任务。
为了避免这种命运，负责管理服务的团队需要编写代码，否则它会被淹没。因此，谷歌对所有 SRE 的工单、onCall、手工任务，和其他“运维”的总和设定了 50% 的上限。这个上限确保 SRE 团队在计划中有足够的时间使服务稳定且运行。这个上限是一个上限；随着时间的推移，SRE 团队应该将这些锁事留给它所属的系统设施完成。最终，它只需要少量的操作负载，几乎可以完成开发任务，因为服务基本上可以自行运行和修复。
谷歌的SRE经验法则
谷歌的经验法则是，SRE 团队必须将预留 50% 时间用于开发。那么，他们如何实施这一限制呢？
首先，他们必须衡量 SRE 时间的使用方式。有了这些指标，他们可以确保团队在开发工作上花费的时间始终少于 50% ，以改变他们的实践。通常，这意味着将一些操作负担转移给开发团队，或者在不向团队分配其他操作职责的情况下向团队添加人员。有意识地在运维和开发工作之间保持这种平衡，使他们能够确保 SRE 有足够的带宽参与创造性和自主的工程化，同时仍然保留从运行服务的运营方面收集的智慧。
谷歌 SRE 运行大型系统的方法有很多优点。由于 SRE 可以直接修改代码以实现谷歌系统的独立运行，SRE 团队的特点是快速创新和广泛接受变化。这样的团队相对更便宜，如果使用「传统系统管理员支撑运维」方式支持相同多的服务，可能需要很多人。相反，运维操作、维护和改进系统所需的 SRE 数量与系统的大小成线性比例。
最后，SRE 不仅避免了开发/运维部门之间的功能失调，而且这种结构还改进了他们的产品开发团队：产品开发团队和 SRE 团队之间方便的人员转岗规则交叉训练了整个团队，提高了开发人员的能力。
尽管取得了这些净收益，SR E模式仍有其独特的挑战。谷歌面临的一个持续挑战是招聘 SRE ：SRE 不仅与产品开发招聘渠道竞争同一候选人，而且他们在编码和系统工程技能方面设置了如此高的招聘标准，这意味着他们的招聘池必然很小。
成为谷歌 SRE 的主要三个问题
根据 Benjamin Treynor Sloss 的访谈，他们主要关注以下三点。
- 他们有自动化的自然倾向吗？
- 他们能应对复杂性吗？（可扩展系统的设计）
- 他们对事物如何运作有好奇心吗？
结论
「网站可靠性工程」代表着管理大型复杂服务的现有行业最佳实践的重大突破。
从最早出于“作为一名软件工程师，我怎么样使用我的时间，以完成一系列重复性任务”的思考动机，现在已演变为：
- 一套原则
- 一套实践
- 一套激励措施
- 更广泛的软件工程团队的工作领域