SRE 上下文
在我们探索与 SRE 相关的一些实践之前，最好把我们刚刚在上一个单元中了解到的一些概念引入上下文。 在这个简短的单元中，我们将了解 SRE 背后的一些历史以及 SRE 与你可能熟悉的其他运营做法的关系。 这些知识将使我们以后获得更大的成功，因为这些实践在上下文中会更有意义。 此外，当你的朋友询问“为何 SRE 不同于...”时，你会有一个现成的答案。
历史记录
SRE 的简短历史始于 2003 年的 Google。 Ben Treynor，即现在 Treynor Sloss，接管了 Google“生产团队”（当时只有 7 名软件工程师）的领导权。 Treynor 提出了这个想法，并将其形象地描述为“这就是要求软件工程师设计操作功能时发生的情况。” 这段历史很有用，它有助于解释为什么 SRE 能够让第一次使用它的操作人员感觉到非常“软件工程”化。 它采用了该领域的价值观和工具，如编码和源控制系统作为基本工具的重要性。 Google SRE 的初始实现和当前实现在 O'Reilly 出版的两本书中有详细记载（请参阅“入门”单元）。
Google 员工离职后（Google 员工公开对他们的实践进行了更深入的探讨），SRE 开始向行业内的更多组织传播。 随着 SRE 传播到新组织，这些组织采用并调整了 SRE 原则和实践以适应本地文化。 这种扩展过程在现场产生了许多不同的 SRE 实现。
DevOps 和 SRE
更多行业在以下方面面临着相同的挑战：缩放、开发速度与运行稳定性，以及引发站点可靠性工程移动的其他软件交付问题。 在 Google （以及当时的一些大型公司）之外，人们为解决这些问题开发出了 DevOps。
有关 DevOps 的大量有用信息，请参阅 DevOps 资源中心。
备注
值得注意的是，DevOps 和 SRE 是为解决相同挑战而同时进行的两种不同尝试。 SRE 不是 DevOps 之后的下一个进化步骤。 SRE 并不是“DevOps 的未来”。
SRE 和 DevOps 之间的区别仍是该领域中广泛讨论的主题。 以下是一些广泛认同的差异，包括：
- SRE 是一门专注于可靠性的工程专业。 DevOps 是一种文化运动，它源于打破通常与独立的开发和运营组织相关的壁垒的冲动。
- SRE 可以是“我是站点可靠性工程师 (SRE)”中的角色名称，而 DevOps 不能。 严格来说，没有人会以“DevOps”作为职业。
- SRE 往往更具规范性，而 DevOps 则有意避免。 二者最接近的方面是，几乎普遍采用持续集成/持续交付和敏捷原则。
这两个操作实践，DevOps 和 SRE，都专注于监视/可观察性和自动化（可能是出于不同的原因）。 这种融合是将 SRE 实践和原则导入具有现有 DevOps 实践的组织通常更容易的原因之一。 但必须谨慎小心地执行这个过程。 这一过程也可以并且应该逐步实施，而不要突然切换。
警告
仅为组织中的员工换个头衔是一种几乎永远不会成功的实现策略。 它不会产生 SRE 所提供的好处。 有关一些更好的建议，请参阅本单元的“入门”部分。
结论
这个简短单元致力于围绕 SRE 和 DevOps 进行一些简要介绍。 SRE 和 DevOps 最好被视为运营做法中相邻的思想流派。
现在我们已经简要介绍了 SRE 的一些背景，下面我们来介绍它的一些核心原则。