一、系统不可能100%可靠
系统不可能100%可靠，人都不可能100%健康，更何况我们人类创造的系统？所以，任何软件系统都不应该一味地追求 100%可靠。事实证明，可靠性超过一定值后，再提高可靠性对于一项服务来说，结果可能会更差而不是更好！极端的可靠性会带来成本的大幅提升：比如过分追求稳定性限制了新功能的开发速度和产品交付速度，并且很大程度地增加了投资成本和运维成本。
二、管理风险
不可靠的系统会影响产品的信誉，虽然系统不可能100%可靠，但我们也要减少系统出故障的几率。然而，经验表明，可靠性进一步提升的成本并不是线性增加的：可靠性的下一个改进可能比之前的改进成本增加100倍。基于以上矛盾点，SRE的做法是管理风险，目标是：我们会努力提高一项服务的可靠性，但不会超过该服务需要的可靠性。管理风险旨在寻求快速创新和系统可靠性的平衡，而不是简单地将可靠性最大化。
三、度量风险
SRE的做法是通过一个客观的指标来体现一个系统的可靠性（或者是风险）。对于大多数服务而言，最直接的能够代表风险承受能力的指标就是对于计划外停机时间的可接受水平。对于系统而言，这个指标通常是基于系统正常运行时间比例的计算得出的。
代码语言：text复制可用性=系统正常运行时间/（系统正常运行时间 停机时间）使用这个公式，我们可以计算出一年内可接受的停机时间，从而可以使可用性达到预期目标。举例来说，一个可用性目标为99.99%的系统最多在一年中停机52.56分钟，就可以达到预计的可用性目标。当然，并不是所有的系统或者组件适用于这个公式，比如也可以通过请求成功率来定义服务可用性，具体如何度量还要结合实际情况灵活应对。
四、确定服务可靠性目标
如果 100% 不是一个正确的可靠性目标，那么多少才是呢?这其实并不是一个技术问题而是一个产品问题。要回答这个问题，必须考虑以下几个方面:
- 基于用户的使用习惯，服务可靠性要达到什么程度用户才会满意?
- 如果这项服务的可靠程度不够，用户是否有其他的替代选择?
- 服务的可靠程度是否会影响用户对这项服务的使用模式?
为了建立起一个合理的可靠性目标，SRE必须与产品负责人一起努力，将一组商业目标转化为明确的可以实现的工程目标。在实践中，这种转化说起来容易做起来难，SAAS层软件和IAAS层基础设施转化的方式又各不相同。
五、错误预算
SRE和产品负责人必须对每个系统建立起一个合理的可靠性目标。一旦建立，“错误预算”就是“1-可靠性目标”。如果一个服务的可靠性目标是99.99%,那么错误预算就是0.01%，这意味着产品研发部门和SRE部门可以在这个范围内将这个预算用于新功能上线或者产品的创新等任何事情。
错误预算可以用于什么范畴呢?研发团队需要用这个预算上线新功能，吸引新用户。理想情况下，我们应该使用错误预算来最大化新功能上线的速度，同时保障服务质量。这个基本模型建立起来之后，许多常见的战术策略，例如灰度发布、AB测试等手段就全说得通了。这些战术性手段都是为了更合理地使用整个服务的错误预算。
SRE通过引进“错误预算”的概念，解决了研发团队和 SRE 团队之间的组织架构冲突。SRE 团队的目标不再是“零事故运行”，SRE团队和产品研发团队目标一致，都是在保障业务服务可靠性需求的同时尽可能地加快功能上线速度。这个改动虽小，意义却很大。一次“生产事故”不再是一件坏事，而仅仅是创新流程中一个不可避免的环节，两个团队通过协作共同管理它。
