有很多很棒的资源可以用作关于SRE原理[SRE幻灯片]的灵感来源。
仍然找不到：
简短
简洁
示例
激励花费资源在组织中实施SRE。
我在职业生涯中所经历的大部分都是高度机密的案件和数字。我担心，SRE知道的大多数数字都将保持“内部”状态，以便在公司内部进行内部呈现。
但是，也许您知道一些研究（最好是一组）事后研究的例子。 （即使一个接一个都是好的），从中我们可以提出一个强有力的论据，例如“将SRE模型引入组织后，每x的发布速度从n增加到m的更改速度，可用性提高y，成本降低z （头脑风暴）还是其他硬数据点？
[SRE幻灯片]-一些示例：
站点可靠性工程：企业采用的故事（ITSM学院网络研讨会）由ITSM Academy，Inc.
SRE从头开始，由
Square平台工程师Grier Johnson
GOTO 2017•Google的站点可靠性工程•Christof Leng
聚苯乙烯如果可以将该问题改写为更好地适合本网站指南，请在评论中为我提供建议，并给我一些改进的建议。否则，我将不胜感激其他更好的平台（但是，例如reddit.com/r/sre对我的印象并不深刻）
#1 楼
您正在寻找的数字类型可能很难找到，因为它们是高度可变的（根据我的经验，即使在一个组织内，它也因服务与团队而异。）现在免费提供，其中包括两个可能有用的案例研究（第3章）。另外，New Relic的SRE电子书在总结SRE方面做得非常好。处理此问题的另一种方法是尝试利用对服务的了解来进行风险评估。并估计停机时间，可以避免是否有SRE和开发人员支持来消除这些风险
评论
随着时间的流逝，我了解到某些决策者在风险发生后将不会意识到。因此，您需要进行风险评估，并等待预期发生的事情或寻找数据点，例如x＆y发生了多少没有采用sre做法的公司，反之亦然。
– Grzegorz Wierzowiecki
19年2月12日在16:56
#2 楼
我同时在多家公司的DevOps和站点可靠性工程组织中工作。我想说SRE的优势比DevOps更为具体。DevOps强调原理和心态，例如DevOps的三种方式：系统思考，放大反馈回路以及不断实验和学习的文化。 DevOps是对敏捷的扩展，它是一种不同的运营模式。
站点可靠性工程强调Google（及其他公司）为实现高水平的服务可用性和对客户的信任度而采用的特定方法，指标和措施。 f.ex：SLI和SLO的辛苦与改进的比率，定量风险分析和数学方法。
由于SRE实施DevOps，尝试比较做一个但不做的组织有点不公平。这样做，所以我实际上建议可以将Accelerate中的所有内容同样容易地应用于站点可靠性工程，因此，如果您需要从同行评审的数据驱动分析开始。
评论
对于试图实施SRE做法的团队来说，SRE手册是一本好书。Chef.io有很多资源，其中包括4个关于devop和速度的网络研讨会，这可能会让您着迷：Chef.io/resources一些客户的故事，例如Rakuten也可以为您提供一些见解，我不知道有明确的硬性规定说
book.ACCELERATE（Forsgene，Gene）与DevOps相同，但某些数据点可能兼容，例如服务MTTR（平均恢复时间）