站点可靠性工程
站点可靠性工程（ SRE ）是一组将软件工程方面应用于IT基础架构和运营方面的原则和实践。 SRE声称可以创建高度可靠和可扩展的软件系统。尽管它们密切相关，但SRE与DevOps略有不同。
历史
现场可靠性工程领域源于Google ，Ben Treynor Sloss于2003年加入公司后创立了一个网站可靠性团队。2016年，Google雇用了1,000多名网站可靠性工程师。该概念于2003年起源于Google之后，扩展到更广泛的软件开发行业，其他公司随后开始聘请网站可靠性工程师。该职位在较大的网络公司中更为普遍，因为小公司通常不按需要专用SRE的规模运作。采用该概念的组织包括Airbnb ， Dropbox ， IBM ， LinkedIn ， Netflix和Wikimedia 。根据Devops研究所2021年的一份报告，在一项针对2,000名受访者的调查中，有22％的组织采用了SRE模型。
定义
站点可靠性工程作为工作角色，可以由个人贡献者执行或在团队中组织，负责在更广泛的工程组织中结合以下内容：系统可用性，延迟，绩效，效率，效率，变更管理，监控，紧急响应，紧急响应，紧急响应，紧急响应，紧急响应，紧急响应，和能力计划。站点可靠性工程师通常具有软件工程，系统工程或系统管理方面的背景。 SRE的重点包括自动化，系统设计以及对系统弹性的改进。
站点可靠性工程作为一组原则和实践，可以由任何人执行。尽管每个人都应该为安全工程中的良好做法做出贡献，但公司最终可能会聘请专家和工程师从事这项工作。
网站可靠性工程也被描述为DEVOPS的特定实现，尽管它们略有不同。 SRE专门针对构建可靠的系统，而DevOps则更加广泛地关注。尽管他们有不同的重点，但一些公司将其运营团队重新命名为SRE团队，而有意义的变化很小。
原则和实践
已经有多次尝试定义网站可靠性工程原则的规范列表，但是尽管缺乏共识，但大多数定义通常包含以下特征：
- 自动化或以具有成本效益的方式自动化任何重复性。
- 避免追求比严格必要的更可靠性。定义必要的是一种练习本身（请参阅下面的实践列表）。
- 设计具有偏见的系统，以降低可用性，延迟和效率的风险。
- 可观察性- 就像在不必提前知道什么问题的情况下提出有关系统的任意问题的能力。
网站可靠性工程实践的差异也很大，但以下列表相对通常被视为至少部分实施：
- 劳力管理是上述第一个原则的实施。
- 定义和衡量可靠性目标 - SLIS ， SLO和错误预算。
- 非大规模系统设计（ NALSD ），重点是可靠性。
- 设计和实施可观察性。
- 定义，测试和运行事件管理过程。
- 容量规划.
- 更改和发布管理，包括CI/CD 。
- 混乱工程.
实施
网站可靠性工程团队与公司内的其他团队以及SRE的原则和实践都以各种形式互动。这是通用SRE团队实施的高级概述：
厨房水槽，又名“一切SRE”
涵盖的服务或工作流程的范围通常是无限的。
基础设施
这些专注于幕后系统的可靠性，这些系统有助于使其他团队的工作更加有效。这些通常与“平台”团队或“平台运营”团队相混淆。基础架构SRE团队可能会与一个或多个平台工程团队配对，但是它们的不同之处在于基础架构SRE团队专注于在上面列出的原则和实践中所描述的大部分（如果不是全部）的工作。平台团队倾向于专注于构建平台，尽管可靠性是可取的，但这不是他们的唯一优先级。
工具
团队专注于测量，维护和提高系统可靠性的工具。例如， Nagios Core或Prometheus（软件） 。
产品或应用
SRE团队用于产品和/或应用程序。一些大型公司倾向于为其中的几个配备。
嵌入
通常，在软件工程团队中配备人员的SRE独奏从业人员或配对应用上述大多数原则和实践。
咨询
这些团队会咨询如何实施SRE原则和实践。这些通常是经验丰富的SRE，他们在上述一个或几个实现的团队中工作。外部面向咨询SRE团队的SRE通常称为“客户可靠性工程师”。他们很少（如果有的话）更改客户的配置或代码。
采用SRE的大型公司倾向于结合上述实现的组合，包括相同实施的多个团队，例如多个产品/应用程序SRE团队，以满足多种产品的特定需求和一个基础架构SRE SRE团队，以与平台配对工程组满足两个产品/应用程序的共同平台的可靠性目标。
行业
自2014年以来， USENIX组织就该行业的现场可靠性工程师举行了年度SRECON会议，并举办了具有相似主题的区域会议。