尽管网站可靠性工程 (SRE) 理念早在 2003 年就由 Google 的 Ben Treynor Sloss 提出，但其近年来却一直受到追捧。随着 DevOps 实践已经在许多组织中牢固确立，两者之间的冲突是否已经显现？SRE 只不过是一种过时的趋势吗？是 SRE 补充了 DevOps，或者是 DevOps 补充了 SRE？让我们来回顾一下。
维基百科将 DevOps定义为"将软件开发 (Dev) 和 IT 运营 (Ops) 相结合的一组实践。它旨在缩短系统开发生命周期并提供高质量软件的持续交付。"根据网站可靠性工程，"SRE 专注于寻找改进系统设计和操作的方法，以使其更具可扩展性、更可靠和更高效。"通过简单回顾上述定义，我们可以看到 DevOps 的定义更侧重于实践，而 SRE 的定义包括设计和可靠性等词。确实，两者都涵盖了上述两方面，即：DevOps 不会忽略设计和可靠性，SRE 也不会没有实践，但是当我们着眼于每种方法的重点时，我们会发现两种定义中的这些细微差异在其实现中是显而易见的。我们将进行更深入的探讨，研究一些显著区别。
DevOps 与 SRE 的差异
文化
让我们从了解文化方面开始，DevOps 和 SRE 都被组织作为一种文化而非实践领域采用，从这个意义上说，它们是相同的，尽管团队可能被指定为主要负责支持该文化的实践。虽然每种文化都是灵活的，这使得团队（而不是跨团队的从业人员）可以直接专注于 DevOps 或 SRE 实践，组织通常会将 SRE 作为一个或多个专注的团队采用，而 DevOps 从业人员通常倾向于分散在团队中。
例如，再次参考这本书，2016 年 Google 雇佣了 1000 多名网站可靠性工程师负责支持全公司内的 SRE 文化。相反，一个仅仅雇佣网站可靠性工程师但不接受 SRE 文化的组织在 SRE 实践方面不太可能取得成功。尽管更加模糊，但在 DevOps 文化方面，组织也存在同样的二分法。
风险
接下来，我们应该研究各自的风险处理方法，这是 SRE 的核心属性。SRE 和 DevOps 都寻求最大限度地减少风险暴露并尽可能多地实施影响检测和响应，但是，SRE 文化将风险管理视为目标，而不是更常见的 DevOps 症状管理方法。假设两家几乎相同的网络应用程序公司，其中一家公司追求 DevOps，而另一家追求 SRE，它们都希望实现一个新功能作为其各自应用程序的一部分。
另外，假设每个相应的更改在应用程序中引入不可靠性的概率完全相同。由于 SRE 文化投资于风险承受能力定义，因此该公司必须立即更好地了解如何对拟议变更做出反应，这可能应在编写一行代码来支持它之前完成。当然，DevOps 组织可以定义和维护风险承受能力，也就是说，没有什么可以阻止 DevOps 采用相同的实践，但是将风险承受能力定义作为 SRE 的核心原则，在一开始就将对话中的风险背景定位为一件理所当然的事情。
机会成本
与风险承受能力相反的是机会成本。继续就前面的例子来说，DevOps 组织很可能处于更好的位置，可以最大限度地减少机会成本的损失。这是意料之中的，因为 SRE 组织已明确且有意地将机会成本置于风险管理之后。需重述的是，SRE 组织在必要时需接受机会成本损失，以达到预期的风险承受能力。这并不是说任何一个组织都希望失去机会成本，而是要强调稍微不同的优先级。
可观察性
DevOps 中常说的一句话就是，"如果未经测试，那么它就不起作用"。主动测试对于 DevOps 和 SRE 实践来说无疑是一项重要的活动，但是，使用测试结果的方式是 SRE 理念的核心。回顾我们最喜欢的书（第 3 章）："作为 Google 的标准做法，我们通常最好通过确定一个客观指标来代表我们想要优化的系统的属性。通过设定目标，我们可以评估当前的性能，并跟踪性能的改进或降低。"我们来设想两个组织，一个遵循 DevOps，另一个遵循 SRE。两个组织都跟踪部署失败率或新部署对服务造成负面影响的频率的关键绩效指标 (KPI)。两个组织都可能希望将此 KPI 设定为较低的值（例如 5% 或更低），但每个组织将该指标概念化的方式不同：DevOps 团队可能将较低的值作为减少服务中断的一种方式，而 SRE 团队会使用 KPI 作为计算服务错误预算的一部分（有关错误预算的更多信息，见下文）。
错误预算
为了将可观察性与环境结合起来，无论是在指标价值方面，还是在指标的成功优化方面，SRE 团队通常关注预算。从概念上讲，错误预算与财务预算没有什么不同，也就是定义支出金额，并根据该限额跟踪实际支出。错误预算作为 SRE 团队和一个或多个开发团队（DevOps 或其他）之间的协议而实施。这种策略可以帮助减缓两个团队之间的紧张关系，尽管他们在逻辑上对稳定性 (SRE) 和速度 (Dev) 的优先级是相反的；只要开发团队没有在一个时间范围内花费他们的错误预算，那么 SRE 团队就不需要提出有关稳定性的担忧，并且团队应该共同保持期望的速度。
事后析误
尽管有最好的计划和准备，服务仍会中断。处理此类中断是 DevOps 和 SRE 实践的重要部分，但是中断之后的事后析误也同样如此。记录事件、已采取的纠正措施、以及将采取哪些措施来防止事件再次发生，这些都是事后析误的组成部分，并有助于确保事件不会使团队或组织不堪重负。尽管任何组织都可以进行事后调查，但 SRE 理念明确规定了这种做法，任何追求这种文化的团队都应该这样做。DevOps 工程师要修复故障，肯定会进行故障分析，以某种方式记录问题所在，当然，还会尝试在将来避免该故障再次发生。但修复后，不一定要求 DevOps 工程师对故障进行全面的事后分析。如果您是一名 DevOps 工程师，并且确实实施了全面事后分析，那没关系，这可能只是意味着您正在实施 SRE 理念，而无关您是否了解这一理念。
采纳 SRE 文化
关于采纳，有几个问题需要回答：谁来采纳、为什么采纳以及如何采纳。
谁来采纳？
虽然 SRE 文化不仅仅是一套工具，甚至是一系列实践，但究其核心，SRE 注重的是可靠性。一个组织如果能从对其技术可靠性的日益关注中获益，不仅是对正常运行时间的潜在改进，还包括在提高可观察性方面的辅助收益、对增值指标的更加关注以及对错误预算的实施，就非常适合加入 SRE 文化。
在个人层面上，任何人都可以通过采用这一理念而成为 SRE 工程师。别误会我的意思，我并不是说你可以成为 SRE。不过，我确实认为，优秀的工程师可以学习采用 SRE 原则，从而追求 SRE 文化。没有什么可以阻止一个有动力的人学习如何遵循 SRE 实践。
在有些组织中，这涉及将现有的 DevOps 从业人员转变为专注于 SRE 实践的角色，或者作为一个集中的小组，或者嵌入到现有团队中。因为 SRE 很大程度上源于 DevOps 理念，所以从业人员获得的许多技能将在两个方向上转化。
值得注意的是，SRE 文化虽然源自谷歌，但并不是只有 Google 规模的组织可以从中受益。
为什么采纳？
更多地关注可靠性可能会使很多不同组织受益，但是，SRE 的主要好处来自于其文化，关注可操作的指标，通过错误预算、事件管理实践等查看技术堆栈。有很多（技术和文化）方法可以提高可靠性，但是追求 SRE 本身就是一种心态，也是一种实践。
如何采纳？
每个组织都是独一无二的，因此追求 SRE 文化对每个组织而言也具有内在的独特性。一些组织可能已经在内部构建了 DevOps 实践，或者遵循信息技术基础架构库 (ITIL) 框架来交付信息技术服务，或者遵循 Agile 方法来组织软件开发工作，无论现有模式如何，SRE 都可以是一个合适的选择。也就是说，考虑下列问题可能有助于推动事情顺利进行：
- SRE 应替代 DevOps 吗？
一些组织将两者结合起来，实现自然互补的目标和利益；事实上，一些从业人员将 SRE 视为 DevOps 的实现------"人们可以将 DevOps 视为几个核心 SRE 原则在更广泛的组织、管理结构和人员中的推广。我们同样也可以把 SRE 看作是具有一些特殊扩展的 DevOps 的一个特殊实现。"（DevOps 或 SRE -- 第 1 章，"简介" -- 网站可靠性工程）。一些团队发现，在单个 DevOps 团队中嵌入一个或多个 SRE 专家可以有效地确保横向采用 SRE 实践，而另一些团队则建立了 SRE 卓越中心。 - SRE 应替代 ITIL 吗？
就像 DevOps 一样，一些组织发现 ITIL 和 SRE 是非常互补的，两者都强调围绕变更管理的治理形式和对 SLO 的遵守。 - Agile 是实现 SRE 文化的必要条件吗？
当然不是。虽然许多组织发现 Agile 方法是 SRE 迭代过程的良好基础，并且与错误预算方法相匹配，但是任何方法都可以兼容。SRE 关注的是结果，而不是软件本身的生产，生产软件的方法并不直接相关。例如，遵循瀑布方法的组织将根据 SRE 的错误预算和测试方法实施风险评估和减免阶段。
需要注意
SRE 理念可能对许多组织有很多好处，但换句话说，"为所有人，但不是一切"，SRE 并不适合所有人，也不适合所有事情。
- 并非所有组织都能因可靠性提高而受益，或者，重申一下，提高可靠性的增量成本并不能为所有组织带来相等或更大的增量价值。对于一些组织而言，这是一个规模问题；Google 的全球规模并不能使其成为唯一可能从 SRE受益的公司，但一家拥有几千名用户的小型初创公司可能也不足以证明这项投资的合理性。
- 对于一些组织来说，可靠性的提高可能并不能证明开发速度的降低具有合理性。通过专注于错误预算等实践，SRE 组织必然会降低速度，而且应该有目的性地这么做。
- 通过建立 SRE 实践，组织可能陷入"可靠性现在完全是 SRE 责任"的思维陷阱。可靠性是 SRE 的责任，但它在整个组织中共享，就像采用 SRE 之前一样。虽然这不是避免采用 SRE 的直接原因，但它可能导致组织无法充分发挥 SRE 的潜力，甚至放弃采用。
- 将团队或团队成员重新标记为 "SRE" 并不意味着组织与 SRE 理念保持一致。例如，没有实施错误预算的 SRE 团队很难说与 SRE 支柱保持一致。这种差距可能会导致组织将 SRE 视为最新流行语，并将其视为昙花一现; 至少这种差距甚至会降低 SRE 的名义价值。
结论
SRE 不是一时的时尚，也不是灵丹妙药，它是一种建立在理解和接受某些可衡量参数范围内风险的文化。
希望采用 SRE 文化的组织可以在不破坏现有 DevOps、Agile、ITIL 或其他现有策略的情况下这样做。事实上，SRE 有意融入其中。尽管 SRE 的所有细节都不在本文的讨论范围内 ，但在互联网上有 SRE 从业人员，甚至是 SRE 的发明团队提供了大量可贵的资源，可以帮助我们采取下一步行动：
- https://sre.google/
- https://cloud.google.com/blog/products/devops-sre/how-sre-teams-are-organized-and-how-to-get-started
- https://cloud.google.com/blog/products/devops-sre/5-google-sre-resources-to-get-started
- https://www.blameless.com/the-essential-guide-to-sre
点击了解 Incredibuild 的 CI 构建加速方案，并获取试用 License！