现场可靠性工程(SRE)为运行可靠的分布式系统提供了一种哲学，具有令人钦佩的原则和实践。然而，在短短几年内，SRE货运崇拜已经在一个层面上与2010年代的DevOps货运崇拜相抗衡，什么是SRE作为邪教，它作为邪教与DevOps是如何交叉的？为什么在拥有IT作为A成本中心的企业组织中应用SRE会如此困难？为什么强调可操作性对IT性能比SRE更重要？
成功的数字化转型取决于从IT作为成本中心向IT作为业务差异化的转变。IT成本中心创建了独立的交付和运营团队，陷入了速度和可靠性之间无休止的冲突。交付希望最大化部署，提高速度。运营部门希望最大限度地减少部署，提高可靠性。这会导致IT性能低下，并对盈利能力、市场份额和工作效率产生负面影响。
在“加速”一书中，Nicole Forsgren博士等人证明了速度和可靠性不是零和游戏。在持续交付和可操作性方面的投资将产生高性能的IT能力，可以发现新的产品收入来源。例如，将生产支持从您构建它转变为您运行它运行它将释放日常部署，并对服务可靠性产生积极影响。用户满意度、收入保护和品牌美誉度都将得到提高。
2004年，本·特雷诺·斯洛斯在谷歌内部发起了一项名为SRE的计划。他后来将SRE描述为IT运营的一种软件工程方法，开发人员将历史上由系统管理员拥有的谷歌以外的工作自动化。SRE关键概念包括：
可用性级别由可用性的九来表示。99.0%是2个9，99.999%是5个9。100%的可用性是无法实现的，因为可靠性较低的用户设备会限制用户体验。100%也是不可取的，因为最大化可用性会限制功能交付的速度，并增加运营成本。在开创性的“现场可靠性工程”一书中，Betsey Byers等人观察到“额外的9个可靠性需要多一个数量级的工程努力”。在任何可用性级别，都需要容忍一定数量的计划外停机，以便投资于功能交付。
服务级别目标(SLO)是公布的测量目标范围，它设置用户对服务性能某一方面的期望。产品经理根据自己的风险承受能力选择SLO。他们必须平衡满足SLO的工程成本与用户需求、服务的收入潜力以及竞争对手的产品。可用性SLO可以是24小时内99.9%的请求成功率中值，24小时内每分钟收集一次测量值作为服务级别指示器(SLI)。
错误预算是服务每季度可容忍的计划外停机时间。它用于缓解产品团队和SRE团队之间的任何团队间冲突，如您构建它的操作运行它中所述。它的计算方法是100%减去所选的9个可用性。例如，99.9%的可用性级别相当于0.01%不成功请求的错误预算。一周内0.002%的失败请求将消耗20%的错误预算，剩下80%用于本季度。
您构建它，SRE运行它是一种有条件的生产支持方法，其中一组SRE支持产品团队的服务。所有的产品团队都会构建它吗？默认情况下，您会运行它，并且对SRE团队有严格的进入和退出标准。服务必须具有关键级别的用户流量、一些提升的SLO，并通过就绪审查。SRE将接管随叫随到，并确保始终满足SLO。如果服务在其错误预算内，产品团队可以推出新功能。如果没有，则在解决所有错误之前，它们无法部署。如果错误预算一再被夸大，SRE团队可以随时召回给产品团队，由产品团队恢复到您构建并运行它。
这就是SRE作为一种哲学。SRE最大的礼物是一个根据产品收入量化可用性目标和工程成果的框架。SRE还推广了一些想法，如测量部分可用性、监控服务的黄金信号、从相同的遥测数据构建SLO警报和SLI仪表盘，以及在可能的情况下减少运营负担。
在2010年代，DevOps的协作哲学被DevOps斥为邪教。DevOps货运崇拜无处不在，而且是错误的。它的信念是：
DevOps自动化工具、DevOps工程师、DevOps团队和/或DevOps认证始终是该问题的解决方案。
同样，SRE的哲学也被SRE作为邪教而腐化了。SRE货物崇拜基于同样有缺陷的前提，并将SRE错误预算、SRE工程师、SRE团队和SRE认证作为灵丹妙药。例子包括帕特里克·希尔在爱情中陈述的DevOps？等到你遇到SRE，“SRE消除了关于什么可以推出以及何时推出的猜想和争论”，以及提供SRE认证的DevOps Institute。
作为一个邪教，SRE忽略了SRE哲学面临的核心问题-它作为成本中心对IT的适用性。SRE起源于单个独特组织中才华横溢、固执己见的软件工程师。谷歌将IT作为业务差异化的核心宗旨。使用罗恩·韦斯特勒姆(Ron Westrum)的“组织文化类型学”，它的组织文化可以被描述为生成性的。Accelerate发现，生产力文化预示着高性能的IT，员工倦怠程度较低。
将SRE应用于具有官僚主义或病态文化的IT成本中心组织存在根本挑战。产品、交付和运营团队将受到正交激励、资金压力和竖井竞争的阻碍。
可用性级别是跨组织支持SRE的领先指标。当失败导致替罪羊或正义时：
产品/交付/运营负责人可能不会接受额外的9个可靠性意味着更多的工程工作。
服务级别目标基于产品经理的风险容忍度。当责任被推卸或挫败时：
产品经理将需要交付团队的帮助来发现用户预期、计算服务收入潜力并检查竞争对手的可用性级别。
错误预算依赖于不同团队之间的共享协议，而不是诉诸于您构建它的团队间的斗争运营者运行它。当合作程度不高或较低时：
当错误预算为0%时，产品/开发负责人可能不会接受部署上的阻止。
当错误预算超过0%时，运营主管可能不会全天候接受部署。
您构建它，SRE运行它意味着一个中央开发团队支持具有高可用性级别和关键用户流量的服务，而其他开发团队在您构建它并运行它的情况下支持他们自己的服务。它与你建造它的世界截然不同，运营者运营它。当仅仅容忍或不鼓励桥接时：
运营主管可能不同意随叫随到的交付团队的运营成本预算。
开发主管可能不同意随叫随到的交付团队的资本支出预算
运营主管可能无法以运营支出预算为其系统管理员支付数月的软件工程培训费用。
开发人员可能不想为他们的服务提供随叫随到的服务，或者不想被重新标记为SRE。
交付团队将发现很难在错误和事件管理方面与运营SRE团队协作。
运营主管可能无法将不可靠的服务转移回最初的交付团队，如果该团队在资本支出资金结束时被解散。
在“站点可靠性工程”一书中，Ben Treynor Slos认为SRE招聘是谷歌面临的重大挑战。需要在软件工程和系统管理两方面都出类拔萃的开发人员，这是很少见的。他反驳说，SRE团队比运营团队更便宜，因为任务自动化减少了员工人数。由于招聘预算小得多，作为成本中心的IT组织的招聘挑战将会加剧。被吹捧的员工福利是荒谬的，因为开发人员的工资率总是高于系统管理员。
持续交付需要卓越的运营。可靠的生产服务将最大限度地减少操作返工，并增加功能交付的吞吐量。通向可操作性的途径有很多，SRE只是其中之一。作为一种崇拜，SRE将推动SRE哲学的世界级运营实践，但却掩盖了SRE适用于中小企业和企业组织的重要问题。
操作实践包括确定操作要求的优先顺序、自动化基础设施、部署运行状况检查、无处不在的遥测、故障注入、事件群集、从事件中学习，然后您构建并运行它。这些做法可以在有SRE的情况下实施，也可以在没有SRE的情况下实施。此外，某些SRE概念(如可用性级别和服务级别目标)可以独立于SRE实施。特别是，产品经理负责根据他们的风险容忍度计算可用性级别，这通常是从现状向前迈出的重要一步。
但是，您构建它SRE运行它很难适合作为成本中心组织的IT，而且它不是所有可用性级别的经济高效的生产支持方法。在员工培训、组织变革和任务自动化方面，运营一个SRE团队所需的投资额，与您构建和运营IT团队相比，要高出一个数量级。仅当存在具有关键用户流量的多个服务，且可用性级别为4个9或更高时，才有保证。
IT作为一个成本中心组织应该很好地实施您构建它，而不是运行它。它通过消除交付团队和运营团队之间的交接来解锁日常部署。它通过优先于功能开发的单级群集支持将事件解决时间降至最低。此外，它最大限度地激励开发人员专注于操作功能，因为他们自己在工作时间之外也是随叫随到的。这是一种具有成本效益的收入保护方法，从2个9增加到5个9可用。
在某些情况下，中小企业或企业组织每天将获得数千万的产品收入，其可靠性需求将是极端的，将投资SRE作为一种理念可能是合理的。否则，请注意SRE作为邪教的危险。正如Luke Stone在“寻找SRE”一书中所说，“从长远来看，SRE不会仅仅基于目前的受欢迎程度而在您的组织中蓬勃发展”。
感谢亚当·汉斯罗德、丹尼斯·余、斯派克·林赛和蒂埃里·德波的反馈。